Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 621470 - sys-boot/plymouth-0.8.8 is required when using openrc; Please undo commit dc5f5087
Summary: sys-boot/plymouth-0.8.8 is required when using openrc; Please undo commit dc5...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Deadline: 2017-09-02
Assignee: Matthew Thode ( prometheanfire )
Depends on:
Reported: 2017-06-11 06:39 UTC by Sora Lee
Modified: 2018-05-31 06:45 UTC (History)
14 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Sora Lee 2017-06-11 06:39:18 UTC
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.
Comment 1 Pacho Ramos gentoo-dev 2017-06-12 11:04:21 UTC
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 :/
Comment 2 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-08-03 20:11:58 UTC
# Michał Górny <> (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.
Comment 3 Mart Raudsepp gentoo-dev 2017-08-04 00:26:14 UTC
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
Comment 4 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-08-04 06:56:27 UTC
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.
Comment 5 Mart Raudsepp gentoo-dev 2017-08-04 14:09:47 UTC
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.
Comment 6 Marvin Beckers 2017-08-06 15:45:02 UTC
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.

Comment 7 Marvin Beckers 2017-08-06 15:51:34 UTC
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.
Comment 8 sakaki 2017-08-06 16:48:39 UTC
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.
Comment 9 Bob Carroll 2017-08-06 17:57:48 UTC
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.
Comment 10 Matthew Thode ( prometheanfire ) archtester Gentoo Infrastructure gentoo-dev Security 2017-08-09 01:38:17 UTC
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?
Comment 11 Matthew Thode ( prometheanfire ) archtester Gentoo Infrastructure gentoo-dev Security 2017-08-09 01:44:07 UTC
for some of these bugs I wonder if 9999 has the fix, since stuff like is in.  Tons of stuff since 0.9.2.

Perhaps a (point to a particular commit) would be useful to see if some of the bugs are still valid.
Comment 12 Matthew Thode ( prometheanfire ) archtester Gentoo Infrastructure gentoo-dev Security 2017-08-09 01:44:46 UTC
see also,

just search the log for drm
Comment 13 David 2017-08-09 19:43:46 UTC
Upstream has release 0.9.3 today :)
Comment 14 Tony Murray 2017-08-10 18:54:09 UTC
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.
Comment 15 Gilles Dartiguelongue (RETIRED) gentoo-dev 2017-08-11 06:59:53 UTC
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.
Comment 16 lperkins 2018-04-02 20:36:30 UTC
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.
Comment 17 Jari_42 2018-05-30 19:54:45 UTC
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.