plymouth 0.9.2 has been released, notable feature: ported to gtk3! Reproducible: Always
Created attachment 399202 [details] plymouth-0.9.2.ebuild New ebuild for 0.9.2 and also for 9999. @proxy-main anybody wishing to do the bump for me please?
I'm kind of new to plymouth.. is this sensible? >>> /usr/lib64/libply-splash-core.so.4 -> libply-splash-core.so.4.0.0 [0/1995] >>> /usr/lib64/libply.so -> libply.so.4.0.0 >>> /usr/lib64/libply.so.4 -> libply.so.4.0.0 * QA Notice: Symbolic link /halt.target.wants/plymouth-halt.service points to /plymouth-halt.service which does no t exist. >>> /halt.target.wants/plymouth-halt.service -> ../plymouth-halt.service * QA Notice: Symbolic link /poweroff.target.wants/plymouth-poweroff.service points to /plymouth-poweroff.service w hich does not exist. >>> /poweroff.target.wants/plymouth-poweroff.service -> ../plymouth-poweroff.service * QA Notice: Symbolic link /kexec.target.wants/plymouth-kexec.service points to /plymouth-kexec.service which does not exist. >>> /kexec.target.wants/plymouth-kexec.service -> ../plymouth-kexec.service * QA Notice: Symbolic link /reboot.target.wants/plymouth-reboot.service points to /plymouth-reboot.service which d oes not exist. >>> /reboot.target.wants/plymouth-reboot.service -> ../plymouth-reboot.service * QA Notice: Symbolic link /multi-user.target.wants/plymouth-quit-wait.service points to /plymouth-quit-wait.servi ce which does not exist. >>> /multi-user.target.wants/plymouth-quit-wait.service -> ../plymouth-quit-wait.service * QA Notice: Symbolic link /multi-user.target.wants/plymouth-quit.service points to /plymouth-quit.service which d oes not exist. >>> /multi-user.target.wants/plymouth-quit.service -> ../plymouth-quit.service * QA Notice: Symbolic link /sysinit.target.wants/plymouth-read-write.service points to /plymouth-read-write.servic e which does not exist. >>> /sysinit.target.wants/plymouth-read-write.service -> ../plymouth-read-write.service * QA Notice: Symbolic link /sysinit.target.wants/plymouth-start.service points to /plymouth-start.service which do es not exist. >>> /sysinit.target.wants/plymouth-start.service -> ../plymouth-start.service * QA Notice: Symbolic link /initrd-switch-root.target.wants/plymouth-switch-root.service points to /plymouth-switc h-root.service which does not exist. >>> /initrd-switch-root.target.wants/plymouth-switch-root.service -> ../plymouth-switch-root.service * QA Notice: Symbolic link /initrd-switch-root.target.wants/plymouth-start.service points to /plymouth-start.servi ce which does not exist. >>> /initrd-switch-root.target.wants/plymouth-start.service -> ../plymouth-start.service * Follow the following instructions to set up Plymouth: * http://dev.gentoo.org/~aidecoe/doc/en/plymouth.xml * * (Note: Above message is only printed the first time package is * installed. Please look at /usr/share/doc/plymouth-0.9.2/README.gentoo* * for future reference) * If you want initramfs builder with plymouth support, please emerge * sys-kernel/dracut or sys-kernel/genkernel-next[plymouth]. >>> sys-boot/plymouth-0.9.2 merged. >>> Regenerating /etc/ld.so.cache...
Oh that's unexpected indeed, I'll have a look at that. For sure that didn't happened on my system, any clue how I can reproduce that by any chance? Thank you for looking at it :)
Created attachment 399262 [details] plymouth-0.9.2.ebuild Ok I think I figured it out. The build system of plymouth will not handle the --enable-systemd-integration option very well if systemd is actually missing from the system. Snippet of code from configure.ac: if test x$enable_systemd_integration = xyes; then AC_DEFINE(PLY_ENABLE_SYSTEMD_INTEGRATION, 1, [Coordinate boot up with systemd]) SYSTEMD_UNIT_DIR=$($PKG_CONFIG --variable=systemdsystemunitdir systemd) AC_SUBST(SYSTEMD_UNIT_DIR) fi so if systemd is not installed SYSTEMD_UNIT_DIR can be empty. I'm not sure if this a bug in the AC macro since it doesn't handle the pkg-config failure or if it is supposed to be handled manually by other means. For the time being I don't see any solution other then introducing the systemd USE flag for the package and hard depend on it if the USE is enabled. Not very nice, but unless anybody has a better idea that's my best bet. If I can find some time I might try to hack a patch for the build system and see if upstream like it.
is systemd a hard requirement for plymouth or can be optional? or does plymouth also work with OpenRC?
Created attachment 399284 [details, diff] 0.9.2-systemdunitdir.patch
Created attachment 399286 [details] plymouth-0.9.2.ebuild hi Enrico I've updated the ebuild, you may like to ping upstream to see if they like the systemdunitdir patch or not. I'm not sure if plymouth need USE=systemd or not, generally we do *not* introduce USE for installing systemdunit files, see General guidelines of 4 [1] and a quick scan shows me plymouth do not link to systemd libraries.. but I‘ll let you do the homework. [1] http://wiki.gentoo.org/wiki/Project:Systemd/Ebuild_policy
Hi Yixun, yeah your patch is the best solution, I was looking forward to do something like that as well, thank you for that. I'll contact upstream and see if they like it. With said patch the DEPEND on systemd and the USE flag can be removed indeed.
Created attachment 399310 [details, diff] 0.9.2-systemdsystemunitdir.patch Ok, before talking to upstream: I noticed that in systemd.eclass it says # @FUNCTION: systemd_with_unitdir # @USAGE: [<configure-option-name>] # @DESCRIPTION: # Output '--with-systemdsystemunitdir' as expected by systemd-aware configure # scripts. This function always succeeds. Its output may be quoted in order # to preserve whitespace in paths. systemd_to_myeconfargs() is preferred over # this function. # # If upstream does use invalid configure option to handle installing systemd # units (e.g. `--with-systemdunitdir'), you can pass the 'suffix' as an optional # argument to this function (`$(systemd_with_unitdir systemdunitdir)'). Please # remember to report a bug upstream as well. systemd_with_unitdir() { debug-print-function ${FUNCNAME} "${@}" local optname=${1:-systemdsystemunitdir} echo --with-${optname}="$(systemd_get_unitdir)" } so the suggested option name should be --with-systemdsystemunitdir. I also checked the portage tree and 99% packages are using this option name. I'm attaching your patch with the name changed. If this is ok for you the following line in the ebuild --with-systemdunitdir="$(systemd_get_unitdir)" can be changed to "$(systemd_with_unitdir)" Any objection?
(In reply to Enrico Tagliavini from comment #9) no objection, it's reasonable! I'm good with this patch, so pushed it to portage tree (instead of waiting for upstream's ACK). even if upstream have better solution, then we certainly can adapt it later, for example bump upstream updated patch at next revision. I only pushed systemdunit patch to version 0.9.2, didn't touch live ebuild (-9999). I feel it's wrong to patch live ebuild, since it's more volatile.. also I fixed following warning with ":=" (assume dep changes require a rebuild), see [1] sys-boot/plymouth/plymouth-0.9.2.ebuild: RDEPEND: '>=media-libs/libpng-1.2.16' matches more than one slot, please specify an explicit slot and/or use the := or :* slot operator [1] https://wiki.gentoo.org/wiki/Sub-slots_and_Slot-Operators +*plymouth-0.9.2 (20 Mar 2015) + + 20 Mar 2015; Yixun Lan <dlan@gentoo.org> +plymouth-0.9.2.ebuild, + plymouth-9999.ebuild, +files/0.9.2-systemdsystemunitdir.patch: + version bump, update to gtk3 dep, add systemdunit patch, proxy for Enrico + Tagliavini
Well, they pushed it right away! http://cgit.freedesktop.org/plymouth/commit/?id=4519fe0db5eb00e8a29b3eeb144e4ada4fe971dc So also 9999 can be bumped now, minus the PATCHES array :) Thank you very much for your help Yixun, appreciated
