Package Details: fbsplash

Git Clone URL: (read-only)
Package Base: fbsplash
Description: Userspace splash screen implementation (formerly 'gensplash') (deprecated, see: Plymouth)
Upstream URL:
Licenses: GPL
Conflicts: fbsplash-scripts, initscripts-extras-fbsplash
Submitter: None
Maintainer: nemesys
Last Packager: nemesys
Votes: 298
Popularity: 0.002685
First Submitted: 2007-11-01 02:26
Last Updated: 2016-10-19 21:33

Dependencies (11)

Sources (9)

Latest Comments

ventto commented on 2018-06-08 05:37


Install miscsplashutils:

Install fbsplash:

It should work.

roytje88 commented on 2018-05-20 10:39

The link should be "". By editing this in the PKGBUILD, it succeeds.

steftim commented on 2018-03-20 08:22

The link "" is not working.

nemesys commented on 2016-10-19 21:35

Corrected PKGBUILD to include working source mirror and also implemented freetype2.patch to correct freetype2 related errors and allow for successful build and use.

Det commented on 2016-08-12 18:12

Disowned. If it still works, and you still prefer over Plymouth, you should adopt.

ironman820 commented on 2016-08-12 18:10

Latest version of Freetype2 moved the old Freetype packages to a subdirectory.

I had to change the lines that handle that to:

#Fix freetype => freetype2
sed -i 's|\(#include <freetype\)/|\12/freetype/|' src/libfbsplashrender.c
sed -i 's|\(#include <freetype\)/|\12/freetype/|' src/ttf.h
sed -i 's|\(#include <freetype\)/|\12/freetype/|' src/ttf.c

tomkwok commented on 2014-09-27 13:39

Updated with patches from alex.syrel

alex.syrel commented on 2014-02-04 21:16

To build without such errors:

ttf.c:28:30: fatal error: freetype/ftoutln.h: No such file or directory
#include <freetype/ftoutln.h>
compilation terminated.

Edit PKGBUILD and in section build() before make add:

#Fix freetype => freetype2
sed -i 's:\(#include <freetype\)/:\12/:' src/libfbsplashrender.c
sed -i 's:\(#include <freetype\)/:\12/:' src/ttf.h
sed -i 's:\(#include <freetype\)/:\12/:' src/ttf.c

ShadowKyogre commented on 2014-01-13 18:29

I'm disowning this package because I no longer use fbsplash and the related packages and currently do not have the time to set up a test machine to help maintain the package. If there's anyone out there that wants to maintain these packages, it would be greatly appreciated :).

Aspiring commented on 2013-12-11 05:45 error: possibly undefined macro: AC_MSG_ERROR
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1

cmsigler commented on 2013-09-28 00:19


I hope I've come up with a solution more or less done The Arch Way (TM) now. I've posted an updated PKGBUILD here:

This incorporates the current version of freetype2 (, so I use the patches from freetype2 in ABS, which are here:

I also make some patches to splashutils, which are here:

With this PKGBUILD and these patches, as well as the other files and patches provided with the current version of fbsplash, this will hopefully build and work correctly. I've been testing it for a few days with no problems.



cmsigler commented on 2013-09-10 14:28


This was a bit of a pain to diagnose. When I tried to rebuild, I kept getting this error message:

"/usr/bin/ld: cannot find -lfreetype"

But the libraries for freetype2 were installed. Happily, Ubuntu forums bought me a clue:

fbsplash needs to link against the static library, libfreetype.a, but this is no longer provided by freetype2 since its upgrade to version 2.5. So, we need to install a local alternative package to freetype2. Here's the PKGBUILD I use for what I've called freetype2-static

Once freetype2-static is built and installed, patches are needed to get fbsplash to build against lcms2, since libmng version 2 builds against lcms2, not the older lcms version 1. I also included fixes to get autoconf/automake to stop complaining. This is the patch I've put together:

Finally, here's a patch to update fbsplash's PKGBUILD:

Using a static library-built freetype2 package along with this revised PKGBUILD and new patch to get fbsplash to build against lcms2 should get things working again. After all of this, I was able to rebuild uswsusp-fbsplash and it seemed to work fine.



Anonymous comment on 2013-08-11 12:09

Doesn't work anymore because of freetype 2.5

ShadowKyogre commented on 2013-06-04 15:01

@cmsigler: Updated the PKGBUILD to consider the binaries that were left floating in the sbin directory and updated the source URL to point to a working source.

cmsigler commented on 2013-06-04 12:59


After the update to ver., on my system there are still a few binaries in /sbin/ directory:


Also, I used the following as the source URL:${pkgver}.tar.bz2

As always, HTH.


UnsolvedCypher commented on 2013-06-03 19:58

It looks like the source is down or has been moved.

ShadowKyogre commented on 2013-06-03 19:10

Updated to consider /usr/bin move.

FoolEcho commented on 2013-06-03 15:53

Could you update to take care about the /usr/bin/move ?


Jristz commented on 2013-05-01 08:51

my issue is that miscsplashutils is a 404 in they downloas source making impossible to build this one

and the daemon thai is intalled fbcondecor.daemon is for initscript and Arch support systemd

Primoz commented on 2013-03-27 00:32

Hi I get this message:
line 32: autoreconf: command not found

I have no idea what I have to install or do to get that to work. Help please.

emorkay commented on 2013-01-12 18:10


My issue with prograss bar is not resolved with this update. I am suspecting it is the problem with fbsplash-extras package.Is it? Because when I execute 'mkinitcpio -p linux', it is producing the following error:
/etc/rc.d/functions.d/ line 370: /etc/rc.conf: No such file or directory


cmsigler commented on 2013-01-10 15:29

@ShadowKyogre: Thanks for updating. fbsplash WFM. Cheers. Clemmitt

cmsigler commented on 2013-01-05 13:36

@ShadowKyogre: Apologies for the delay -- Real Life issues :(

I'm not having any problems -- it just WFM :/ I get a working count-down progress bar on the hibernation splash screen (first it says "Snapshot" then "Saving xxxxxx pages, press Esc to abort" or something like that with progress bar counting down from top to bottom). It works just like it did before mkinitcpio-0.12.0-2 *shrug*

I think I'm just doing something simple, running s2disk from root command line to hibernate, then rebooting with kernel command line option resume=UUID=blahblah-blah-blah-blah-blahblah to do a fast resume without any splash screen on reboot. All this works fine. Please note than I'm not running in a VM but on bare iron on an x86_64 laptop.

One problem I ran into: I'm not able to build fbsplash as-is from AUR. I get this error from autoreconf:

parallel-tests: error: required file './test-driver' not found
parallel-tests: 'automake --add-missing' can install 'test-driver'
autoreconf: automake failed with exit status: 1

I've been able to fix this by changing 'autoreconf' to 'autoreconf -i' in PKGBUILD. HTH.

One other thing I noticed: In fbsplash.initcpio_install, the function add_runscript doesn't appear to take an argument (although it doesn't throw an error or warning, either). mkinitcpio seems to require that the name of the hooks script be identical to the name of the hook itself, i.e., 'fbsplash'. Since this is already true, there's no immediate problem. Again, HTH.


ShadowKyogre commented on 2013-01-04 00:39

@emorkay: Had a look at and I think that's what needs to be fixed. Since the script is written with the old initscripts in mind, I think we need to add something that hooks into similar events in systemd.

ShadowKyogre commented on 2013-01-04 00:24

@emorkay: I'm aware of that, as I made that comment on here before I uploaded the package. On the guest machine I was testing fbsplash on, I wasn't using the proprietary drivers. I'll take a look to see what else is preventing the progress bar from working right.

emorkay commented on 2013-01-03 18:41

The progress bar isn't moving at all. Also, the only message I see is 'Initializing the kernel'.
Using arch with full systemd. I have ATI card and using proprietary drivers.

ShadowKyogre commented on 2013-01-03 14:28

@sausageandeggs: I'm not on testing on the virtual computer or on my computer and was able to build it. However, I do have a live CD on here with the kernel from testing along with grsecurity patches. Let me see if compiling it from there generates problems.

Anonymous comment on 2013-01-03 05:02

Not sure if its my box or not but the only way I could get this to compile was by adding the "-i" option to "autoreconf" cmd, otherwise it kept giving error

parallel-tests: error: required file './test-driver' not found
parallel-tests: 'automake --add-missing' can install 'test-driver'
autoreconf: automake failed with exit status: 1

Also, adding " sed -ie 's|INCLUDES|ACLOCAL_AMFLAGS|g' src/ " before running "autoreconf [-i]" gets rid of warning " src/ warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS') "
I'm running testing btw

ShadowKyogre commented on 2013-01-03 01:04

@cmsigler: Tested the change suggested in the test virtual computer. The progress bar doesn't move anywhere, but at least it's better than nothing.

cmsigler commented on 2013-01-02 16:20

With the upgrade to mkinitcpio-0.12.0-2 last month (December 2012), the deprecated SCRIPT keyword is now ignored. I believe the fix for fbsplash is simple; I commented out the SCRIPT line in /usr/lib/initcpio/install/fbsplash and in the next line added a call to add_runscript. HTH. Clemmitt

ShadowKyogre commented on 2012-12-17 07:00

Finally on winter break and installed fbsplash on a fresh virtual machine (desktop machine uses Plymouth, both are on systemd). Fbsplash doesn't seem to appear at all (the screen shows the splash screen, then it just shows the login screen).

ShadowKyogre commented on 2012-11-17 20:24

@wassup: I'll look into it as soon as I start winter break, since there's about three weeks left of the semester at my university. During that time, I'll also be investigating what's mentioned here:

Hopefully my mother doesn't try to drag me off during the winter break. She has a habit of doing that whenever I'm free from school ><.

wassup commented on 2012-10-23 13:25

@cyberpatrol: I'll miss you. Did you change the distro itself as well?
@current-team: How about fixing the bug relating to the inability of applying the splash to all ttys?

Anonymous comment on 2012-09-30 13:54

Due to recent changes in Arch Linux for the worse, and the bad, ignorant and arrogant attitude of the Arch Linux devs, who aren't able to take criticism, who only want to hear their own opinion, I decided to not contribute to Arch Linux anymore. So I orphan this package.

Anonymous comment on 2012-09-14 09:33

@wassup: It doesn't seem to be an upstream bug, since it only doesn't work in the fbcondecor initscript, but in rc.local which is executed directly after the DAEMONS array. And if the verbose splash is set manually on the console it works, too. So I'm pretty sure it has something to do with the scripts. But there are still some more issues due to the many changes made in initscripts and the infiltration of initscripts by this systemd(-tools) crap (yes, I've tested systemd meanwhile) recently.

wassup commented on 2012-09-13 23:33

@cyberpatrol: I just came here to ask whether there is any improvement on this matter or if that is an upstream bug. Happily, I see there is some development - good work. I hope you will eventually trace down the scripts bug.

Anonymous comment on 2012-09-08 00:55

It took a long time, but I found at least a workaround for the FBIOCONDECOR_SETCFG bug.

Remove fbcondecor from DAEMONS and add these lines to /etc/rc.local:

. /etc/conf.d/fbcondecor
. /sbin/
for tty in ${SPLASH_TTYS}; do
fbcondecor_set_theme ${SPLASH_THEME} ${tty}

I guess the bug is somewhere in the scripts, since rc.local is run directly after the daemons, and adding a sleep to the fbcondecor initscript doesn't help.

Anonymous comment on 2012-07-15 20:56

@nvlplx: If you had updated fbsplash before glibc, there shouldn't have been any files from fbsplash in /lib anymore. But this way worked, too, of course.

Anonymous comment on 2012-07-15 20:53

@cyberpatrol : you're right. But Glibc refused to upgrade because of the presence of files from fbsplash in /lib. So finally I've remove fbsplash and dependances, then upgrade glibc and reinstall fbsplash.
Now; fbsplash compile without problem.


Anonymous comment on 2012-07-15 14:20

@nvlplx: librt is part of glibc. So I guess there's an issue with your glibc installation. This package compiles with glibc 2.16.0-1, which used /lib, and with glibc 2.16.0-2, which uses /usr/lib. So this move actually can't be the reason. I'd suggest first updating your system as described in the News on the Arch Linux homepage, if you haven't done it, yet, or to reinstall glibc.

Anonymous comment on 2012-07-15 12:41

I can't compile fbsplash because of this error :

checking for clock_gettime in -lrt... no
configure: error: 'librt' library was not found.

I don' found any librt package or something like that.

If anyone has an idea ?

Anonymous comment on 2012-07-14 07:49

ok, removing fbsplash-extras fixed the progress bar issue. re-installing it brought the issue back, so moving my comments to fbsplash-extras package.


Anonymous comment on 2012-07-14 06:43

@cyberpatrol, yes I have extras installed. Had a fully functioning fbsplash until this update. Config has not changed and only using a basic theme (literally a background and progress bar). Tried a mkinitcpio -p linux but this made no difference. Same issue on 3 machines - xbmc media centre intel video, main desktop nvidia binary blob, and touchscreen tablet ati radeon drivers.


Anonymous comment on 2012-07-14 00:45

@padfoot: Do you have fbsplash-extras installed? I haven't tried it, yet, with fbsplash-extras, and without it I can't reproduce it. The only issue besides the FBIOCONDECOR_SETCFG bug is that the screen gets black for a short time while cryptsetup opens the containers. But that's a bug in the initscripts. If this still exists after the next update I'll report it.

Anonymous comment on 2012-07-13 23:22

With this latest package, my progressbar no longer updates during boot. I am not getting any errors and my boot and the rest of the splash all work fine. I am guessing this is all to do with the migration from /lib to /usr/lib? Should this rectify itself once the migration is complete?


Anonymous comment on 2012-07-10 14:30

Changed it anyway. Both methods should actually work.

Anonymous comment on 2012-07-10 14:20

@Det: Btw., the directories /lib/splash/cache and /lib/splash/tmp shouldn't exist anymore when post_upgrade() is run, because these directories belong to the package and are removed by pacman before the install script is executed. So I guess something goes wrong with your interpreter when interpreting the install script.

Anonymous comment on 2012-07-10 14:01

@Det: When or how do you get this error? I can't reproduce it with bash. This is needed, because there have been direcotries (sys) and files created at runtime by fbsplash, which are not known and removed by pacman. So /lib/splash has to be removed manually.

Det commented on 2012-07-10 13:24

You should use quotes with:

if [ ! (")`ls -A /lib/splash`(") ]; then
rmdir /lib/splash

to not produce:

/tmp/alpm_WT0vKG/.INSTALL: line 23: [: cache: unary operator expected

But why is this needed if the folders 'cache' and 'tmp' are created there anyway?

Anonymous comment on 2012-07-08 13:22

Fixed /usr/etc in
/lib/splash gets removed after an upgrade from a previous version if it still exists and is empty.
/usr/lib/splash/sys now belongs to the package.

Anonymous comment on 2012-07-08 08:08

Hmm, appears to be broken now:
grep -n usr/etc/ $( find pkg/ -type f )
pkg/sbin/ if [ -x "/usr/etc/splash/${SPLASH_THEME}/scripts/${event}-pre" ]; then
pkg/sbin/ /usr/etc/splash/"${SPLASH_THEME}"/scripts/${event}-pre ${args}
pkg/sbin/ if [ -x "/usr/etc/splash/${SPLASH_THEME}/scripts/${event}-post" ]; then
pkg/sbin/ /usr/etc/splash/"${SPLASH_THEME}"/scripts/${event}-post ${args}
pkg/sbin/ [ -f /usr/etc/splash/splash ] && . /usr/etc/splash/splash
pkg/sbin/ [ -f /usr/etc/conf.d/splash ] && . /usr/etc/conf.d/splash
pkg/sbin/ [ -f /usr/etc/conf.d/fbcondecor ] && . /usr/etc/conf.d/fbcondecor
pkg/usr/bin/bootsplash2fbsplash:9:$path_bp = "/usr/etc/bootsplash/";

Anonymous comment on 2012-07-08 00:46

Moved from /lib to /usr/lib (hopefully), and (hopefully) fixed the command not found issue. The FBIOCONDECOR_SETCFG is still there, probably an upstream issue or an issue caused by the initscripts.

For people who use harddisk encryption the screen could get black while the harddisk gets unlocked. This is an issue with initscripts, since it was fixed with the last initscripts update and came back with the latest initscripts update. I'll wait for the next initscripts update.

Anonymous comment on 2012-06-29 01:20

@cesarramsan: Of course, that's a different issue. There are currently 3 or 4 issues with fbsplash. I'm still working on it. The replacement of the command should just fix the "command not found" error. But I don't know if systemd-vconsole-setup does the same as set_consolefont, because I couldn't find a documentation about it, yet. At least I don't see a difference, so I guess this issue is fixed. Still remain 2 or 3 issues.

cesarramsan commented on 2012-06-28 23:43

@cyberpatrol: I tried your fix of replacing the command set_consolefont on line 98 by the command /usr/lib/systemd/systemd-vconsole-setup but I still get the "FBIOCONDECOR_SETCFG failed, error code 22." errors.

Anonymous comment on 2012-06-25 22:09

@ShadowKyogre: Could you, please, edit the file /etc/rc.d/funcions.d/ on your system, and replace the command set_consolefont on line 98 by the command /usr/lib/systemd/systemd-vconsole-setup. I don't get this error message, but I know that you're not alone. So before just do a lot of useless updates on AUR, it would be nice, if you could test it this way.

There are some other bugs, I'm currently trying to fix.

ShadowKyogre commented on 2012-06-18 18:37

@cyberpatrol: I'm also getting the same issues as wassup along with the following two:
* "/etc/rc.d/functions.d/ line 98: set_consolefont: command not found"
* Various "FBIOCONDECOR_SETCFG failed, error code 22." and "FBIOCONDECOR_SETSTATE failed, error code 22." even though the terminals have their backgrounds set after logging in to manually start the daemon.

Anonymous comment on 2012-06-14 18:54

This is most likely related to the latest update of initscripts and the switch to systemd-tools. I have to look into it, but it can take a while. I better don't say what I think of Lennart Poettering and his crap.

wassup commented on 2012-06-14 11:38

Setting the splash screen to more than one tty fails during boot with the exit code 22 (FBIOCONDECOR_STATE exited with error code 22). The same happens if I try to run /etc/rc.d/fbcondecor start from cron on reboot. However, if I log into a console and run manually the abovementioned command - everything works fine and the splash screen is set to the rest of the ttys. I have tried a couple of splash screens, so this is not a config issue I believe. Moreover, it happened after a couple of the latest upgrades. Anyone having an idea what might be wrong?

wassup commented on 2012-06-14 11:31

Setting the splash screen to more than one tty fails during boot with the exit code 22 (FBIOCONDECOR_STATE exited with error code 22). The same happens if I try to run /etc/rc.d/fbcondecor start from cron on reboot. However, if I log into a console and run manually the abovementioned command - everything works fine and the splash screen is set to the rest of the ttys. I have tried a couple of splash screens, so this is not a config issue I believe. Moreover, it happened after a couple of the latest upgrades. Anyone having an idea what might be wrong?

Anonymous comment on 2012-05-30 12:51

I guess the server was temporarily down. I can reach and download the source package from there.

Anonymous comment on 2012-05-28 13:20

To download "splashutils" change in PKGBUILD "" with "" it works

Anonymous comment on 2012-05-27 20:59

the server seems to be down. tried from both my home computer in Winnipeg and my VPS in Toronto

Anonymous comment on 2012-04-15 14:38

Thanks for the info. Changed the path and moved the hook from /lib/initcpio to /usr/lib/initcpio.

trya commented on 2012-04-15 13:00

'sleep' path is not '/bin/sleep' anymore, but '/usr/bin/sleep'. Can you correct, please?

Anonymous comment on 2012-02-06 00:13

Don't forget to rebuild this package after the libpng update from [extra].

Anonymous comment on 2011-11-23 19:01

As far I understand, the .la files are necessary for static libraries (.a files). The static libraries are necessary in fbsplash for at least the early boot stage in the initrd. So, yes, the .la files seem to be necessary in fbsplash.

rafaelff commented on 2011-11-23 04:33

The *.la files (libtool related) in /usr/lib are needed in this package?

Anonymous comment on 2011-11-16 04:29

makedepends should include autoconf

Anonymous comment on 2011-11-16 04:28

makedepends should include autoconf

Anonymous comment on 2011-10-13 13:38

@trontonic: I know, but I'm not the upstream maintainer. And it's closing down in 2 1/2 months.

xyproto commented on 2011-10-13 11:36 is closing down, fyi

Anonymous comment on 2011-10-11 21:02

I don't know systemd and I'm not sure if I want to get to know it. I guess all the scripts which are written by kujub would need to be rewritten for systemd. Kujub may correct me if I'm wrong.

misc commented on 2011-10-10 21:14

fbsplash doesn't (yet) properly work with systemd, does it?

Anonymous comment on 2011-10-03 22:32

@windel: Please, read the AUR User Guidelines in the wiki. Link is on the AUR homepage.

windel commented on 2011-10-03 18:09

Thanks for the package!

Please add 'autoconf' to build depends.

Anonymous comment on 2011-09-07 14:43

Well, the fun is a point. But in this case I wouldn't be too sure that you can fix it depending on the reason for this issue.

Anonymous comment on 2011-09-07 14:19

But wheres the fun in that! Besides I only 'break' what I know I can fix

Anonymous comment on 2011-09-07 14:15

@sausageandeggs: Better don't try to break it if it's working for you.

Anonymous comment on 2011-09-07 13:46

@cyberpatrol Everything been working on (both) my setup now for a while (can't remember since which pkg), nothing about my setup has changed at all, I thought it was something you'd done. I'll have a fiddle and see if I can break it again!

Anonymous comment on 2011-09-07 11:27

@cyberpatrol: Works only if the splash daemon is able to open the keyboard event device. For that purpose, /sbin/ splash_start() calls splash_set_event_dev() which tries to find the device node and, on success, sends its path-name to the daemon via FIFO. When starting the daemon early in the initcpio and splash_start_initcpio.patch isn't applied, the daemon seems to do the initial painting (fadein) first before reading and processing the "set event dev /dev/input/${t}" FIFO command. Because the painting takes time, the daemon appears to be unable to open the device node in case initcpio init already did switch_root at its end. (root filesystem where daemon was started is gone)

Anonymous comment on 2011-09-06 17:36

@kujub: Do you have a idea why it's not possible to switching back from verbose to silent splash after switching vice versa? I couldn't look at it, yet.

Anonymous comment on 2011-09-06 17:34

I'm coming back to a very old issue, which I couldn't reproduce. So I couldn't go deeper into it. Now that I replaced my PS/2 keyboard by a USB keyboard I can confirm this issue:

cat: can't open '/sys/class/input/input*/capabilities/ev' no such file or directory
/init: line 619: arithmetic syntax error

I made some tests now and found out that this is a udev and a timing issue. I have the impression that `udevadm settle` doesn't work correctly and doesn't wait for every device to be settled what it actually is supposed to do as far as I understand its manpage. I guess that's the same reason why I have or at least had some issues with the official Arch install CD.

Regarding fbsplash at least a workaround, which works for me, is to move fbsplash to the end of the HOOKS array in /etc/mkinitcpio.conf and to add, of course, the hooks udev and usbinput to the HOOKS array. The HOOKS array shoud look like this:
HOOKS="base udev autodetect usbinput ... fbsplash"

The only difference I could determine is that switching from silent to verbose splash is done by pressing Alt-F1 during the kernel initialization and after this by pressing F2.

@ShadowKyogre and sausageandeggs: Could you, please, test this?

Anonymous comment on 2011-09-05 10:41

@xaer0knight: Possible reasons could be that you either have missing x rights for your /tmp directory resp. the related subdirectories or you have mounted /tmp with the noexec option.

Anonymous comment on 2011-09-05 08:29

@xaer0knight: I can't reproduce it, neither with pure makepkg nor with yaourt. I guess you either have wrong file permissions for your /tmp directory or the related subdirectories or there's an issue with your yaourt installation.

Anonymous comment on 2011-09-05 05:51

I have encountered this error since Oct/Nov 2011:

==> Starting build()...
/tmp/yaourt-tmp-xaer0/aur-fbsplash/./PKGBUILD: line 49: ./configure: Permission denied
==> ERROR: A failure occurred in build().
==> ERROR: Makepkg was unable to build fbsplash.

Anonymous comment on 2011-08-12 21:11

Had to remove some unnecessary sed commands which I added just for testing purposes.

Maxr commented on 2011-08-12 05:56

works. Thanks!

Anonymous comment on 2011-08-11 23:37

Well, kozzi already mentioned that adding export LIBS="-lbz2" shall fix the issue. When I tried this after he mentioned it it didn't work for me. Now it is working. I don't know why. Nevertheless I've adopted it.

Tell me, if it doesn't work for you.

Anonymous comment on 2011-08-11 23:30

Adopted. Thanks.

Anonymous comment on 2011-08-11 22:54

Guys, I found solution!
Just edit PKGBUILD file and append LIBS="-lbz2" before ./configure line, e.g.:
LIBS="-lbz2" ./configure --prefix=/usr --sysconfdir=/etc --without-klibc --enable-fbcondecor --with-gpm --with-mng --with-png --with-ttf --with-ttf-kernel

It works well for me

Anonymous comment on 2011-08-11 19:09

@Maxr: If you disable ttf support you won't see any text messages anymore like "Press F2 for verbose screen", "Initializing kernel", textboxes, etc.

Maxr commented on 2011-08-11 19:00

disabling ttf in configure will let you build the package at least. Don't know wether some themes won't work then, tough. Didn't test that yet.

Anonymous comment on 2011-08-09 13:28

@Shanto: If you have read my comment you would know that this is an upstream bug which is already filed to upstream. Now we have to wait until a new upstream release. And, no, this hasn't anything to do with the kernel.

Anonymous comment on 2011-08-09 13:27

Please, stop flagging this package as out-of-date as long as there's no NEW upstream release!

Shanto commented on 2011-08-09 05:55

Seems like fbsplash and miscsplashutils needs some work after linux (formerly kernel26) hits 3.0 in the official repo.

Anonymous comment on 2011-08-01 23:32

fbsplash currently doesn't compile due to an upstream bug either in fbsplash due to a change in freetype2 or in freetype2. Adding "export LIBS='-lbz2'" doesn't work.
Fbsplash upstream is already contacted.

Det commented on 2011-07-14 17:44

I do know [testing] is not a stable repo, my friend :D. What the name implies is kinda obvious.

Anonymous comment on 2011-07-14 12:12

@Det: You'd better read the mailing lists. Then you'd know that [testing] is not a stable repo. See e.g. all those e-mails regarding non-bootable systems after a kernel update in [testing], etc. No, it was not my fault, it was [testing] which has caused my broken system. [testing] is what it says: it's for testing purposes and not for production systems.

Det commented on 2011-07-14 06:20

That's also what the not-as-lazy-as-I-am people are for. And I don't doubt you've broken your system in the past. It's not a child distribution.

Anonymous comment on 2011-07-13 21:32

If you know that this is a freetype2 bug, why don't you file a bug report? That's what [testing] is for.

And if you're really using [testing] then you should know what you're doing and how to edit the PKGBUILD by yourself. I'm not supporting [testing] because it can break your system pretty easily. And I know what I'm talking about.

Det commented on 2011-07-13 19:53

No, because it _is_. But this "LIBS='-lbz2'" trick didn't work for me.

E: D'oh, it has to be "export LIBS='-lbz2'", so something like this would fix this:
[ `pacman -Q freetype2 | cut -d " " -f2` > 2.4.4 ] && export LIBS='-lbz2'

It's a bit ugly as it is and if you don't even like (supporting) [testing] then that doesn't make things look good.

Det commented on 2011-07-13 19:44

No, because it _is_. But this "LIBS='-lbz2'" trick didn't work for me.

Anonymous comment on 2011-07-13 18:53

@kozzi and Det: Are you sure that this is not a bug in the freetype2 package from [testing]?

kozzi commented on 2011-07-13 17:08

@Det: how i already write, you must add LIBS='-lbz2' before configure in PKGBUILD

Anonymous comment on 2011-07-13 14:38

@cyberpatrol: Done. :D

Anonymous comment on 2011-07-13 13:04

@kujub: No objections, patch applied. But don't forget to make these changes in fbsplash-extras, too. ;-)

Anonymous comment on 2011-07-13 08:52

I made a patch for fixing the initcpio hook to use the new /run/ tmpfs now instead of abusing /dev/ for the early daemon start.
Please apply if no objections.

Anonymous comment on 2011-07-13 01:32

@Det: Which freetype version do you have installed? And do you use [core]/[extra] or [testing]?

Det commented on 2011-07-13 01:16

Is it just me?:

/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/../../../../lib/libfreetype.a(ftbzip2.o): In function `FT_Stream_OpenBzip2':
(.text+0x5fe): undefined reference to `BZ2_bzDecompressInit'
collect2: ld returned 1 exit status

Anonymous comment on 2011-07-12 17:55

grep 'err.*()' /lib/initcpio/*functions
/lib/initcpio/functions:error() {
/lib/initcpio/init_functions:err () {
So please revert 'error' to 'err' in run_hook() as installing hooks and running hooks are two totally different things.

Anonymous comment on 2011-07-12 16:45

Replaced err by error.

Anonymous comment on 2011-07-12 16:26

@falconindy: The err function still exists in mkinitcpio 0.7.x in the file /lib/initcpio/init_functions and is still used by the hooks net and encrypt of mkinitcpio 0.7.x.

falconindy commented on 2011-07-12 15:56

The 'err' function no longer exists in mkinitcpio 0.7.x as I also pointed out here:

If you're not seeing the error regarding the missing command, then you're obviously never hitting the block of code that triggers it. Please update to use the new mkinitcpio API (error, not err).

Anonymous comment on 2011-07-12 11:18

@rubyinthedust: I have the same HOOKS array so far and I also upgraded to the new mkinitcpio version, but I only got the message about the deprecated function call (that was due to a change in the new mkinitcpio version) but not the "command not found" error. And the function err is also used by other hooks from the mkinitcpio package. So you must get this error message by the other hooks, too, if you have one of them in your HOOKS array. Maybe try to temporarily add the hooks net and encrypt to your HOOKS array if you don't have them anyway and see if you get the error for these hooks, too. Btw., I have the encrypt hook in my HOOKS and don't get this error message.

Anonymous comment on 2011-07-12 06:42

HOOKS="base fbsplash udev autodetect..."
There was a mkinitcpio update just the other day, but it's strange that it is only in the fbsplash hook. I'll ask around in the forum.

Anonymous comment on 2011-07-11 22:31

@kozzi: Sorry, but I don't support [testing] for good reasons. If you're using [testing] you should know what you're doing and be prepared for serious breakages. [testing] should only be used for testing purposes and not on production systems. That's what [testing] is meant for.

Nevertheless it would be nice, if you would tell me, which package from [testing] causes this build failure, and if you would post the error messages you get.

kozzi commented on 2011-07-11 18:01

Doesnt build on testing, please add LIBS="-lbz2" before ./configure

Anonymous comment on 2011-07-11 10:39

Fixed the function call. Thanks.

But I can't reproduce the other error "command not found". Err is a function in /lib/initcpio/init_functions which is part of the package mkinitcpio and is added to the initrd by the base hook. Do you have the hook base at the first position of the HOOKS array in /etc/mkinitcpio.conf?

Anonymous comment on 2011-07-11 08:02

just updated and get errors while generating hooks with mkinitcpio -p kernel26

==> WARNING: Hook 'fbsplash' uses a deprecated 'install' function. This should be renamed 'build'
/lib/initcpio/install/fbsplash: line 90: err: command not found

Det commented on 2011-06-22 12:08

Just responding to a apparently over 2 months old comment.

Anonymous comment on 2011-06-22 10:52

@kujub: Thanks. Patch applied.

Anonymous comment on 2011-06-22 09:06

Patch for removing obsolete workaround code for FS#10536:

Anonymous comment on 2011-06-14 12:21

@Det: What do you want to tell us? And what does this have to do with fbsplash?

Det commented on 2011-06-14 12:13

Reinstallation shouldn't be needed anyway since we can always chroot o_O:

And even if our _Pacman_ didn't work we could still manually extract our required package(s) from Live-CD and put them in place.

graysky commented on 2011-06-13 22:56

I get the following error when I rebuild the initrd.

# mkinitcpio -p kernel26-ck
==> Building image "default"
==> Running command: /sbin/mkinitcpio -k 2.6.39-ck -c /etc/mkinitcpio.conf -g /boot/kernel26-ck.img
:: Begin build
:: Parsing hook [base]
:: Parsing hook [fbsplash]
grep: /lib/initcpio/install/dev: No such file or directory
FATAL: Hook 'dev' can not be found.
==> FAIL
==> Building image "fallback"
==> Running command: /sbin/mkinitcpio -k 2.6.39-ck -c /etc/mkinitcpio.conf -g /boot/kernel26-ck-fallback.img -S autodetect
:: Begin build
:: Parsing hook [base]
:: Parsing hook [fbsplash]
grep: /lib/initcpio/install/dev: No such file or directory
FATAL: Hook 'dev' can not be found.
==> FAIL

Anonymous comment on 2011-06-13 21:57

@artiom: Do you still get the error with the new version?

artiom commented on 2011-05-17 09:26

I have this error every time on boot.

Anonymous comment on 2011-05-05 12:27

@artiom: I can't reproduce this. Do you have these errors always or only once?
I can find a similar error message in my logs but for plugin-container resp. and only once. So I guess that something went wrong only once.

artiom commented on 2011-05-02 14:54

fbsplash stop daemon logs this error in the system log:
fbsplashd.stati[2480]: segfault at 7facdec99010 ip 000000000052398b sp 00007facdcbd6c88 error 4 in fbsplashctl[400000+1e4000]

Anonymous comment on 2011-04-08 10:40

@sharsma: Reinstallation of the complete system wasn't necessary. Just a `nano /etc/makepkg.conf` as root and probably a `pacman -S base-devel`.

Anonymous comment on 2011-04-08 10:00

@cyberpatrol: i reinstall arch x86_64 and select the (base-devel) and everything is ok, thanks!

Anonymous comment on 2011-04-08 08:22

@sharsma: Have you looked at your /etc/makepkg.conf?

The first error message is:
make[3]: O2: command not found

This is most likely just a consequential error resulting from the first:
... jcapimin.o: file or directory not found

As O2 is a CFLAG, you most likely have a typo, a missing "-" in your /etc/makepkg.conf, so that O2 is not interpreted as a flag, but sa a command, which, of course, can't be found.

Anonymous comment on 2011-04-08 08:16

can not build under x86_64, the error message likes:

make[3]: O2: command not found
... jcapimin.o: file or directory not found

may have problems with libjpeg?

Anonymous comment on 2011-04-08 08:10

@sharma: You probably don't have (base-devel) installed or have a typo in your /etc/makepkg.conf.
Is it possible that you've edited your makepkg.conf and removed a "-"?

CFLAGS="-march=x86-64 -mtune=generic O2 -pipe"
CXXFLAGS="-march=x86-64 -mtune=generic O2 -pipe"

instead of

CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe"
CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe"

Anonymous comment on 2011-04-08 07:55

can not build under x86_64, the error message likes:

make[3]: O2: command not found
... jcapimin.o: file or directory not found

may have problems with libjpeg?

Anonymous comment on 2011-04-03 11:36

No It doesn't work with or without the patch (unless i comment the for loop, -35 does without the patch, but I'm pretty sure it just because of my terminally slowly mounting disk.

Anonymous comment on 2011-04-03 10:24

@sausageandeggs: Doesn't it work with the current version, without the patch and with the later function call, too?

Anonymous comment on 2011-04-03 09:58

@cyberpatrol It seems to be a timing issue like you said, it's the for loop in splash_set_event_dev that throws the error. Running these cmds myself always returns a value for $t. I'm not sure but I think it's happening because the partition that holds sysfs is ext4 which isn't mounting quick enough and ..... etc etc. Commenting out the for loop and hard coding a value for $t if it's empty fixes the problem.(not ideal I know but my keyboard is always the same and otherwise it doesn't seem to change). Thanks for the pointer s anyway, if I do find that its a different reason I'll let you know.

Anonymous comment on 2011-04-01 01:18

@sausageandeggs: You're welcome. I guess it's a timing issue. I guess your input device isn't settled if this function is called earlier. So the devices aren't in sysfs at that time, but probably a millisecond later.

Just as a matter of interest you could have a look at /sbin/ There you find the function splash_set_event_dev(), and in this function you see some if clauses and a for loop. Maybe you could execute the commands in these if clauses (grep ..., cat ..., echo ...) one after another and look which condition is met for your system.

At least when the patch was applied, and the function was called earlier the if clause in the for loop was caught. My assumption is that there haven't been the directories /sys/class/input/input*. So the for loop couldn't expand the wildcard and $i didn't get the file names but the path as a string. So in the next if clause cat didn't give an integer value but a string. Thus you had the arithmetic syntax error.

Anonymous comment on 2011-04-01 01:02

Thanks for your help cyberpatrol, when I get time, hopefully at the weekend, I'll take a look at it. If I find anything I'll let you know.

Anonymous comment on 2011-03-31 08:54

Thanks, sausageandeggs.

I personally can't find any differences between fbsplash with or without this patch. So I didn't remove the patch completely, but commented it. If somebody has issues with or concerns about this, please, write a comment.

Anonymous comment on 2011-03-31 02:50

I've rebuilt the pkg and made sure that fbsplash was second (I had it 3rd) and the error has reoccurred. I'll just leave that patch out for now.

Anonymous comment on 2011-03-30 06:31

Yes the msg was just a one liner with the wildcard

can't open '/sys/class/input/input*/capabilities/ev' no such file or directory
/init: line 619: arithmetic syntax error

I'm pretty sure that I have fbsplash second in the hooks array, it's definitely early anyway, No access at the moment but I'll check/rebuild later on.

Anonymous comment on 2011-03-30 06:01

@ShadowKyogre and sausageandeggs: Yet another question: Have you added fbsplash to the HOOKS array in /etc/mkinitcpio.conf? If yes, could you, please, set base at the first and fbsplash at the second position in the HOOKS array (HOOKS="base fbsplash ..."), reinstall fbsplash with the patch (uncomment the line with the patch in the PKGBUILD again), rebuild the initrd and test it again?

Anonymous comment on 2011-03-30 05:50

@sausageandeggs: It's not too easy to find out and admittedly it was just a wild guess to find out where to look for the reason.

@ShadowKyogre and sausageandeggs: Another question: Was the error message really only a one-liner with the wildcard in it like the following?
cat: can't open '/sys/class/input/input*/capabilities/ev' no such file or directory

Or have there been several lines with the expanded wildcard like the following?
cat: can't open '/sys/class/input/input0/capabilities/ev' no such file or directory
cat: can't open '/sys/class/input/input1/capabilities/ev' no such file or directory
cat: can't open '/sys/class/input/input2/capabilities/ev' no such file or directory

I'm currently trying to find out if this is indeed a bug in the script or if the function call was done too early for your systems with kujub's patch.

Anonymous comment on 2011-03-30 02:14

Yes the rebuilt pkg without the patch works fine, F2 switching also works. Thanks Cyebrpatrol, I really can't believe that that didn't occour to me!

Anonymous comment on 2011-03-29 18:20

@ShadowKyogre and sausageandeggs: If the modified package works and boots correctly, please, also test, if you can switch between the silent and the verbose splash and vice versa with F2.

Anonymous comment on 2011-03-29 18:10

@ShadowKyogre and sausageandeggs: Could you, please, rebuild and reinstall this package. But before doing this, please, comment the following line in the PKGBUILD:
patch -Np2 -i ${srcdir}/splash_start_initcpio.patch

So that it looks like this:
#patch -Np2 -i ${srcdir}/splash_start_initcpio.patch

I guess that your issue is either caused by kujubs new patch or it's an upstream bug probably caused by one of the two latest bash updates.

Anonymous comment on 2011-03-23 16:34

I to have this problem, it started around the same time as the *-35 update but I've downgraded to *-34 and it's still the same.
I'm using bash (only shell installed),evdev is there

ShadowKyogre commented on 2011-03-23 16:02

@cyberpatrol: Ah, okay. Output:
evdev 7179 5

Anonymous comment on 2011-03-23 15:07

@ShadowKyogre: Of course you mustn't enter the `.

ShadowKyogre commented on 2011-03-23 14:50

@cyberpatrol: When I run `lsmod | grep evdev`, I get "bash: evdev: command not found". However, lsmod does say I have the evdev driver loaded. I do have the latest fbsplash, kernel26-fbcondecor, and bash installed.

@kujub: Yes, it still boots. It just can't resume from hibernate if I select the silent option for some odd reason.

ShadowKyogre commented on 2011-03-23 14:48

@cyberpatrol: When I run `lsmod | grep evdev`, I get "bash: evdev: command not found". However, lsmod does say I have the evdev driver loaded. I do have the latest fbsplash, kernel26-fbcondecor, and bash installed.

Anonymous comment on 2011-03-23 10:48

@ShadowKyogre: Before rebuiling the initcpio, please, run `lsmod | grep evdev`. I don't need to explicitly add evdev to MODULES, neither in /etc/rc.conf nor in /etc/mkinitcpio.conf.

Have you updated your system particularly kernel26-fbcondecor and fbsplash to the latest versions?

And which shell are you using? Have you bash installed?

What I'm wondering is "can't open '/sys/class/input/input*/capabilities/ev' no such file or directory". Of course there's no directory .../input*/... The * is a wildcard which should be substituted by bash.

And I'm wondering about "/init: line 619: arithmetic syntax error". I guess your shell interprets the * probably as an arithmetical operator.

Anonymous comment on 2011-03-23 08:57

@ShadowKyogre: Am I right thinking your system still boots with silent splash enabled? So this would be not a big problem since you don't see that message normally. :) To fix it anyways, please add evdev to MODULES in your mkinitcpio configuration, rebuild your initcpio and try again.

Anonymous comment on 2011-03-23 00:38

@kujub: Is it possible that this error message is related to your latest changes regarding evdev?

ShadowKyogre commented on 2011-03-22 23:36

@kujub: When I installed fbsplash recently, I get this error whenever I tell the kernel to silently boot:
cat: can't open '/sys/class/input/input*/capabilities/ev' no such file or directory
/init: line 619: arithmetic syntax error
I'm not sure what's causing this, but it only happens when I include the hook in my initramfs.

Anonymous comment on 2011-03-07 15:13

@kujub: Updated. Thanks for the patch,

Anonymous comment on 2011-03-07 12:22

@cyberpatrol: I made a patch for a new pkgrel 35:
This is a cleanup of the scripts and also contains the following fixes:
- Fix procfs missing when calling splash_setup in case of boot w/o initcpio (custom kernels).
- Also find and include referenced files (images) when including the entire theme into initcpio.
- Also allow daemon start in initcpio with scripted themes (like arch-banner-icons with fbsplash-extras>=2.0.10)
- Use evdev if available to allow changing back to the splash screen when using F2-key.

Anonymous comment on 2011-01-10 23:12

@m0nhawk: Why should that be fbsplash 2? There is no fbsplash 2, yet. As you saw on upstream's page this is the latest fbsplash version. Btw., splash-utils-gentoo is Gentoo specific.

dsadcsadsadacasd commented on 2011-01-10 13:04

From official page:
"13 Nov 2008: splashutils- and splashutils-gentoo-1.0.16 released."

Is it real fbsplash 2 yo?

Anonymous comment on 2010-10-17 02:14

Just a PKGBUILD cleanup.

Anonymous comment on 2010-10-10 16:05

I have installed fbsplah and fbcondecor.
It works well if I use the themes "arch-black" and "arch-banner".
However, when I change my own picture, it fails to load either silent or verbose mode.
I've wonder whether the size of my picture is too large, but I replaced a small one, either.
Anyone knows?

Anonymous comment on 2010-08-07 12:17

Unknown didn't mention, yet, which bootloader he is using. And how shall GRUB2 be able to preventing a framebuffer device?
I guess it has something to do with a system configuration, probably kernel line or whatever. But I'm not a framebuffer expert. So I'd suggest asking for help with setting up a framebuffer device in the forums or the mailing lists.

Anonymous comment on 2010-08-07 10:26

It seems to me your problem has nothing to do with fbsplash at all since you are talking about GRUB2 here.

unknown commented on 2010-08-06 20:35

ok, it seems that vga= is needed. I replaced it with gfxpayload= as vga= is depreciated which broke things.

Still cant run a demo though due to the missing framebuffer device.

Anonymous comment on 2010-08-06 19:24

@unknown: As I said this hasn't anything to do with fbsplash, because this package hasn't changed anything except for merging two packages to one. The software is exactly the same and fbsplash is not concerned with setting up a framebuffer device.

If you don't have a framebuffer device, you can look at your kernel line in /boot/grub/menu.lst or in lilo.conf and check if you have the necessary parameters in there particularly vga= or video=. Please read the Wiki page again for details. Or check if you have "fbsplash" behind "udev" in the HOOKS array in /etc/mkinitcpio.conf.

Otherwise you should ask in the forums or the mailing lists for getting help with setting up the framebuffer device.

unknown commented on 2010-08-06 19:12

I did follow the guide. And as i said, something broke after an update.
Afaik, releases <.31 work fine. After that something broke.

I'm sorry, I meant to edit that. It is indeed looking for /dev/fb0.
So the question is, why isn't it there? I dont know if it was a requirement
for rels <.31

I tried creating /dev/fb0 with `mknod /dev/fb0 c 29 0', to no avail.

unknown commented on 2010-08-06 19:11

I did follow the guide. And as i said, something broke after an update.
Afaik, releases <.31 work fine. After that something broke.

I'm sorry, e meant to edit that. It is indeed looking for /dev/fb0.
So the question is, why isn't it there? I dont know if it was a requirement
for rels <.31

I tried creating /dev/fb0 with `mknod /dev/fb0 c 29 0', to no avail.

unknown commented on 2010-08-06 19:11

I did follow the guide. And as i said, something broke after an update.
Afaik, releases <.31 work fine. After that something broke.

I'm sorry, e meant to edit that. It is indeed looking for /dev/fb0.
So the question is, why isn't it there? I dont know if it was a requirement
for rels <.31

I tried creating /dev/fb0 with `mknod /dev/fb0 c 29 0', to no avail.

Anonymous comment on 2010-08-06 18:26

@unknown: Btw., the latest fbsplash update didn't change anything except for the merging of the daemon with the scripts into one package instead of two and one additional option for another login manager.

Anonymous comment on 2010-08-06 18:22

@unknown: fbsplash is first complaining about a missing framebuffer device and insufficient permissions:
> open("/dev/tty0", O_RDWR) = -1 EACCES (Permission denied) <-- fbsplashd is not run as root and has not enough permissions.
> open("/dev/fb0", O_RDWR) = -1 ENOENT (No such file or directory) <-- There's no framebuffer device.
> open("/dev/fb/0", O_RDWR) = -1 ENOENT (No such file or directory) <-- There's no framebuffer device.
> open("//etc/splash/arch-black/0x0.cfg", O_RDONLY) = -1 ENOENT (No such file or directory) <-- It, of course, can't find this file, because there's no theme for the screen resolution 0x0.

Please read the fbsplash wiki and configure your system accordingly.

Don't forget to create a new initrd image after you changed your configuration, so run `mkinitcpio -p <kernel_name>`.

unknown commented on 2010-08-06 17:41

fbsplash is complaining about a missing theme, not a missing framebuffer device.

Why isn't there such a framebuffer device, and why did things break with a recent fbsplash update?

Anonymous comment on 2010-08-06 17:31

@unknown: And you need to start fbsplashd as root.

unknown commented on 2010-08-06 17:17

please *read* the strace. the problem is not with a missing framebuffer, but with te fact that it cant read the theme.

Anonymous comment on 2010-07-24 11:16

> open("/dev/tty0", O_RDWR) = -1 EACCES (Permission denied)
You have to be root to be able to start fbsplashd.
> open("/dev/fb0", O_RDWR) = -1 ENOENT (No such file or directory)
> open("/dev/fb/0", O_RDWR) = -1 ENOENT (No such file or directory)
> open("//etc/splash/arch-black/0x0.cfg", O_RDONLY) = -1 ENOENT (No such file or directory)
You need some sort of framebuffer ;-)

unknown commented on 2010-07-23 03:58

This version broke my fbsplash setup:
Failed to load theme 'arch-black'.
Strace from console:

Anonymous comment on 2010-07-08 20:09

Pacman asks for removal confirmation only with conflicts. That's why I added this one. ;-)

Anonymous comment on 2010-07-08 20:03

Hmm, I actually don't know - does pacman ask the user for removal confirmation with replaces too?

Anonymous comment on 2010-07-08 19:57

I'll add optdepends. But replaces isn't necessary, conflicts is sufficient.

Anonymous comment on 2010-07-08 19:21

OK, well done and very good timing too :) I already submitted a new package 'fbsplash-extras' replacing 'initscripts-extras-fbsplash'. Could you change your optdepends and maybe add a replaces=('fbsplash-scripts')?

Anonymous comment on 2010-07-08 17:26

Merged fbsplash-scripts to fbsplash. I set conflicts=('fbsplash-scripts' 'initscripts-extras-fbsplash') to avoid pacman errors due to the dupes. So fbsplash-scripts and initscripts-extras-fbsplash are deinstalled during the update, but the config files are backed up.

@kujub: I'd suggest not to move initscripts-extras-fbsplash to fbsplash-scripts but to a new package fbsplash-extras, fbsplash-extra-scripts or the like and let fbsplash-scripts and initscripts-extras-fbsplash be removed from AUR. This would clarify that this package only adds optional extra functionality to fbsplash and makes the update more convenient for the users. I also added two options to /etc/conf.d/splash for lxdm and slim users. If you need to make any changes at the scripts just send me the updated scripts.

Anonymous comment on 2010-06-24 17:40

cyberpatrol: Now 'initscripts-extras-fbsplash' no longer depends on 'fbsplash-scripts'. Both contain the same configuration and fbcondecor script files now. If you want to reduce the amount of packages to be installed further, you could merge 'fbsplash-scripts' into 'fbsplash' (after waiting for any bug reports for a while). Then I could drop the dupes from 'initscripts-extras-fbsplash' and move/rename the remaining improved scripts to 'fbsplash-scripts'.

Anonymous comment on 2010-06-21 20:24

Hi, tpavlic, as splash_cache_cleanup in /sbin/ would create that directory and additionally redirects mount --move errors to /dev/null, I guess you are actually using 'initscripts-extras-fbsplash' which provides its own splash_cache_cleanup function. ;-) For solving your problem it should be enough to reinstall the 'fbsplash' package, since the directory should be in there (according to the last line of the PKGBUILD).

tpavlic commented on 2010-06-21 20:01

Lately, I've noticed a "/lib/cache/tmp mountpoint doesn't exist" (or something along those lines) after rc.multi finishes loading deamons. I also notice that

cachedir on /lib/splash/cache type tmpfs (rw,relatime,size=4096k,mode=644)

remains mounted (it contains the "arch-banner-icons" folder from my rotating arch-banner animated splash screen). I believe this cache is suppoesd to be removed after the splash screen finishes, and so I think there is a bug in the cache_cleanup code in /sbin/ script.

Anonymous comment on 2010-06-07 19:21

Sorry for not responding for such a long time, but I hadn't had time to look at it.

Generally I agree, but at first glance I think it would be better to also include the initscripts-extras-fbsplash, because I think one package should provide every feature. Features should be enabled or disabled just by config files and not by installing or uninstalling separate packages in spite of what the devs say about the "long" scripts. I'll think about it.

Currently it's working as it is. That's essential.

Anonymous comment on 2010-06-07 18:33

Thank you KaoDome, but there are new versions of initscripts, mkinitcpio, fbsplash-scripts and initscripts-extras-fbsplash on the way now. So if cyberpatrol would agree, he could wait until some days beyond the new packages hit core and AUR to save him some work. Hopefully the mkinitcpio stuff wont change very often in the future. :)

KaoDome commented on 2010-06-07 18:20

I agree with kujub, right now I'm installing fbsplash-scripts and initscripts-extras-fbsplash. Shouldn't be better to have only one scripts package?

Anonymous comment on 2010-03-28 10:26

cyberpatrol: May I ask you to consider a new PKGBUILD: ? That one would move in the config-file, the initcpio-hook and the fbcondecor-daemon-script from fbsplash-scripts.
* The fbsplash-scripts dependency could be dropped again from initscripts-extras-fbsplash. (Say: Two scripts for boot splash to choose.)
* Those who just want fbcondecor (verbose mode) could even install fbsplash without any further script package
* fbsplash could even be used for a silent mode splash without initscripts but with upstart or something (no progress though, but some animation maybe, unless someone contributes some additional script code)
That would mean keeping the number of packages to install as small as possible while giving the users any options I can imagine. :) What do you think?