As stated in the title, sys-boot/plymouth-0.8.8 is not an obsolete ebuild and should not have been removed. Currently there only exist workarounds to get plymouth versions 0.9.0+ working with openrc, and none of them have worked on my system.
That version was suffering from many other bugs as far as I remember and that was the reason people should move to 0.9.x at that time. Later, there were also bugs affecting 0.9.x and, since this has no maintainer (and upstream also looks pretty inactive) this package is in general broken with all the versions :/
# Michał Górny <mgorny@gentoo.org> (04 Aug 2017) # sys-boot/plymouth is unmaintained since Apr 2016. The current version # has multiple bugs, including not supporting OpenRC. It really needs # an active maintainer. Removal in 30 days. Bug #621470. # # The remaining packages are sys-boot/plymouth reverse dependencies. # They have no use without it, so they are being removed as well. kde-plasma/breeze-plymouth kde-plasma/plymouth-kcm sys-boot/plymouth sys-boot/plymouth-openrc-plugin
I am not aware of any plymouth bugs this with systemd, why is this being last rited after requests to not do so on gentoo-dev thread and some people stepping up to proxy-maintain it? Yes, sure, 30 days time to resurrect this or whatever, but quite a few systemd users are using this package, especially if they use things like disk encryption
Because nobody cared enough to even leave a comment on the bug. I have better things to do than to scan gentoo-dev for random fruitless bikeshed.
Nobody left a comment because the gentoo-dev mail about it didn't reference any particular bug. People have better things to do than scan bugzilla for all the plymouth openrc issues as systemd users and guess which bug you might pick for the last rite tracking in the future.
Just a heads up, masking plymouth completly broke my tty1, probably because my initramfs had Plymouth and my actual system did not anymore. I can understand that Plymouth not working with OpenRC is frustrating for the people running OpenRC but it runs perfectly fine with systemd and genkernel-next and does exactly what it is supposed to do. It is included with every major distro anyway. The list of issues[1] is not *that* long and I fail to see the issue that makes masking and removing Plymouth without opening an issue such as "maintainer needed" first necessary. [1] https://bugs.gentoo.org/buglist.cgi?quicksearch=sys-boot%2Fplymouth&list_id=3610706
And to add something I forgot to mention: Yeah I'm an idiot for running depclean without checking the things to be unmerged, no doubt about that. I did not expect a "core" component of my system to be masked though.
FWIW, I know of quite a large number of users who will definitely be affected by this, as they have followed my EFI install guide on the Gentoo wiki, and have currently got a (working) plymouth / systemd / full disk encryption system, which will now cease to build, and which they'll have to revert to running with textual boot / LUKS password entry. plymouth seems to work perfectly well in systemd atm (granted it is broken in OpenRC); it's well integrated with genkernel-next and most other major distros still ship it AFAIK. Seems a shame to lose it from the tree like this.
I've had >=sys-boot/plymouth-0.8.8-r4 locally masked for two years because of the OpenRC issue. Both versions being kept in the tree with the #517572 work-around documented in the wiki seems reasonable. It's a boot splash that I see for 5 seconds every couple of months when I reboot. How impactful could its bugs possibly be? Removing this will just force people to maintain an overlay.
It's working for me on openrc. I only use it so I only have to enter a password once on multi disk systems though. Works on my laptop as well (systemd). If it comes down to it can we just drop support for openrc in plymouth?
for some of these bugs I wonder if 9999 has the fix, since stuff like https://cgit.freedesktop.org/plymouth/commit/?id=8d1764981bbb7c258c13b0bcada9ea00d3fc0ee0 is in. Tons of stuff since 0.9.2. Perhaps a 0.9.2.99 (point to a particular commit) would be useful to see if some of the bugs are still valid.
see also, https://cgit.freedesktop.org/plymouth/commit/?id=041ea9a59c787441004396e5350c27429755bad2 just search the log for drm
Upstream has release 0.9.3 today :)
Please remove, this junk keeps getting pulled back into my system by openrc even though I don't use openrc (another story)... Basically doubles my boot and shutdown time without even being configured by me.
Please be more specific. Openrc does not depend on plymouth so something else is pulling it on your system. Please paste the output of emerge --tree when you get this issue.
I've done some testing here, and while I don't know the exact problem I believe I can narrow it down sufficiently to allow someone who understands ebuilds better than I do to fix it. Plymouth 0.9.x ebuilds with openrc produce a build that works fine on the main system, but which fail to load themes when used in an initrd (I couldn't determine what was going wrong.) Plymouth 0.8.x ebuilds work fine. Plymouth 9999 live ebuild also works fine, even if you point it to the same commits as the 0.9.x ebuilds. If I pull the 0.8.x ebuild from prior to commit c5455e9 and update it to point at the same release files as the 0.9.x ebuilds (need to change from .bz2 to .xz) That works fine too. So, some change between c5455e9 and the present seems to have broken the correct building of plymouth for openrc, but not in a way that causes the build to error out. The commit removing the autoreconf step from the ebuild stands out as potentially worth investigation, but it could be anywhere in there. I can help with testing if there's somebody who understands ebuilds well enough to pick out the source of the problem without breaking something else.
I can confirm the above: pulling the Plymouth 0.8.8-r5 ebuild from prior to commit c5455e9 and pointing it at the 0.9.3 release produces a build that works fine but using the current stable 0.9.3-r1 ebuild produces a build which fails to load themes when used in an initrd.
