Would be needed by genkernel-next, but I am not sure if plymouth is ready to be stabilized, if not, we can USE mask it
I have nothing against stabilizing this. Be aware there is -r2 pending, see bug #485034 . I'm waiting someone to bump it. The only change is to sync with the current location of udevadm in gentoo, and since it has been moved to /usr also plymouth is going to be moved. I use playmouth daily with dracut, cannot say how it works with genkernel-next.
+*plymouth-0.8.8-r2 (11 Oct 2013) + + 11 Oct 2013; Pacho Ramos <pacho@gentoo.org> +plymouth-0.8.8-r2.ebuild: + Move things to /usr (#485034 by Kirill Elagin and fix by Enrico Tagliavini), + this also causes to rhgb-compat-link to be dropped due it pointing to old + location, use readme.gentoo.eclass, move to eapi5, move the openrc vs systemd + blocker behind 'systemd' USE flag to prevent people enabling it globally from + getting systemd blocked. + Are you ok with this version? (I needed a bit more changes as noted in ChangeLog)
genkernel from genkernel-next-29 can not find /sbin/plymouthd from plymouth-0.8.8-r2, because it is installed under /usr/sbin/plymouthd * >> Installing plymouth [ using the spinner theme and plugin: "two-step" ]... * ERROR: Binary /sbin/plymouthd could not be found downgraded plymouth to version 0.8.8-r1 and genkernel works again
Why are you moving things around without worrying about backward compatiblity? This is very very wrong! :/
I didn't predict genkernel-next was hardcoding the full path -> that (hardcoding paths) is also wrong :|
+*plymouth-0.8.8-r3 (13 Oct 2013) + + 13 Oct 2013; Pacho Ramos <pacho@gentoo.org> +plymouth-0.8.8-r3.ebuild, + -plymouth-0.8.3-r5.ebuild, -plymouth-0.8.4.ebuild, -plymouth-0.8.8-r2.ebuild, + -plymouth-0.8.8.ebuild: + Install compat symlinks as some rdeps need them, drop old + Looks like gdm also hardcodes it (just reported), dracut uses type for getting right path, but their unit file rely on old path
Sorry for the delay, but I got few days off and I was without my pc. Looking at your change on -r3 I remembered that sys-boot/plymouth-openrc-plugin is unmaintained. Both the ebuild and the code. If you want to stabilize plymouth I recommend to just drop support for sys-boot/plymouth-openrc-plugin. About systemd USE..... I think it can be removed. It is not an hardcore runtime deps, plymouth just provides unit files for systemd and those should be installed unconditionally. Any objection or though on this?
(In reply to Enrico Tagliavini from comment #7)> > If you want to stabilize plymouth I recommend to just drop support for > sys-boot/plymouth-openrc-plugin. How will it affect openrc users? Thanks :)
(In reply to Pacho Ramos from comment #8) > (In reply to Enrico Tagliavini from comment #7)> > > If you want to stabilize plymouth I recommend to just drop support for > > sys-boot/plymouth-openrc-plugin. > > How will it affect openrc users? Thanks :) I guess it will simply stop working. It is unmaintained from a long time, but if someone steps up to maintain it, that's ok. I'm not that guy, sorry. But to be clear: no plugin is needed to use plymouth. You can simply call the client to tell the deamon what to do. So the most simple setup can be with 2 service files, one starting at very beginning of the boot process (ideally even before the real init is called if an initramfs is used) and one just before Xorg.
+*plymouth-0.8.8-r4 (16 Oct 2013) + + 16 Oct 2013; Pacho Ramos <pacho@gentoo.org> +plymouth-0.8.8-r4.ebuild: + systemd USE flag is not needed (#487674#c9 by Enrico Tagliavini) +
(In reply to Pacho Ramos from comment #10) > +*plymouth-0.8.8-r4 (16 Oct 2013) > + > + 16 Oct 2013; Pacho Ramos <pacho@gentoo.org> +plymouth-0.8.8-r4.ebuild: > + systemd USE flag is not needed (#487674#c9 by Enrico Tagliavini) > + Looks very nice to me, thank you for that. Few mors (like swite words about the openrc plugin: I had a quick look at the source code and what it does is starting plymouth early, update the statuching to runlevel blabla yadda and similar), and then stop it when shutting down. The plugin itself should be good and working until OpenRC / plymouth API changes, but quite a lot of stuff is missing elsewhere, like integration with plymouth helpers for user interaction (e.g. when asking crypt passwords). This is because that stuff should go in the init script files, and not in the plugin AFAIK. If the initramfs support this (like with dracut with crypt stuff) it can be a workaround, but still not an optimal solution, since this force user interaction to be done during initramfs before calling openrc. Dunno what the plans for openrc are, but the best thing is probably to do something similar to what systemd does: it provides an helper for generic password ask agent and it can work both with plain tty and plymouth. Init script creation is easy that way, you just call a command to have a password back, regardless if you are using plymouth or not. Until OpenRC plymouth support is fully in place I'm not sure if this can be a blocker for genkernel users. I cannot think other scenario requiring user interaction if not crypt, so it should work for "common" setups (for a definition of common where crypt is not common), but I'll recommend to put an ewarn about that in genkernel-next if compiled with USE=plymouth
amd64 stable
x86 stable
ppc64 stable
This script /usr/libexec/plymouth/plymouth-populate-initrd installs plymouthd and plymouth into the /sbin & /bin path of initrd file system. It will cause problem for initrd generated by the latest dracut(034-r4) in a system using systemd, as the gentoo plymouth unit files are expecting they uder /usr. Can I propose doing the same trick to these files as it's been done for udevadm? ---- diff --git a/sys-boot/plymouth/plymouth-0.8.8-r4.ebuild b/sys-boot/plymouth/plymouth-0.8.8-r4.ebuild index c6f91e1..7731f48 100644 --- a/sys-boot/plymouth/plymouth-0.8.8-r4.ebuild +++ b/sys-boot/plymouth/plymouth-0.8.8-r4.ebuild @@ -47,6 +47,11 @@ src_prepare() { 'ask-password sed failed' sed -i 's:/bin/udevadm:/usr/bin/udevadm:g' \ systemd-units/plymouth-start.service.in || die 'udevadm sed failed' + sed -i 's:/sbin/plymouthd:/usr/sbin/plymouthd:g' \ + scripts/plymouth-populate-initrd.in || die 'plymouthd sed failed' + sed -i 's:/bin/plymouth:/usr/bin/plymouth:g' \ + scripts/plymouth-populate-initrd.in || die 'plymouth sed failed' + autotools-utils_src_prepare }
Please open a new bug report for that issue
Hi, Though plymouth emerged successfully on ia64 (had to emerge again libdrm[libkms] and genkernel-next[plymouth] nevertheless), I'm seeking for installation steps before declaring ia64 stable or not. Indeed, informations in /usr/share/doc/plymouth-0.8.8-r4/README.gentoo.bz2 seem pretty outdated (link to http://dev.gentoo.org/~aidecoe/doc/en/plymouth.xml that was last updated in October 24, 2011) and focus on OpenRC/dracut/grub systems. I'm running systemd/genkernel-next/elilo. I remember having successfully played with rhgb and elilo in the Fedora ia64 early days. Émeric
That is not arch specific but deserves a new bug report, could you add a new one for that doc issue? Thanks! + 14 Jan 2014; Pacho Ramos <pacho@gentoo.org> plymouth-0.8.8-r4.ebuild: + ia64 stable, bug #487674 (thanks to Emeric Maschino for testing) +
arm stable
alpha stable
ppc stable
sparc stable. Closing.
