For better or worse, gummiboot has been merged into systemd. The upstream repository has been cleared out[1], making the -9999 ebuild useless. If systemd's build system allows gummiboot to be built by itself, maybe an ebuild could be written which does something like that. This seems to be roughly what sys-fs/udev does, and I think gummiboot is probably less integrated with the rest of systemd than udev is, so I imagine it can be done. [1] http://cgit.freedesktop.org/gummiboot/commit/?id=55df1539c9d330732e88bd196afee386db6e4a1d Reproducible: Always
I added an ebuild in my overlay if you would like to try it. https://bitbucket.org/floppym/floppym-overlay/src/master/sys-boot/systemd-boot/systemd-boot-224.ebuild It is almost certainly missing dependencies, and may need some additional configure args to disable optional libraries.
This should be primarily handled by maintainer of gummiboot, I think.
Here's the current version of an ebuild for systemd-boot in my overlay. If there is any real demand for it, I might move it to the gentoo repo one day. https://bitbucket.org/floppym/floppym-overlay/src/master/sys-boot/systemd-boot/
Either this has a maintainer or we simply remove this (otherwise people will start relying on a completely obsolete gummiboot version)
Can we get systemd-boot in tree as a replacement? It'd suck to remove something without a replacement.
(In reply to Pacho Ramos from comment #4) > Either this has a maintainer or we simply remove this (otherwise people will > start relying on a completely obsolete gummiboot version) FML, seriously? Guys, dont "simply remove" this. As you could imagine there are users who actually use it to boot their systems! Offer a migration plan, push systemd-boot to the tree or whatever the replacement is (would be great if it could work with openrc).
Who is going to maintain that? This is not about "pushing" things to the tree, this is about maintaining them and not pushing others to do all the work Do you want to proxy-maintain the new package? Nice, please tell me, do you want to become a dev, nice, mail me and we can start
(In reply to Pacho Ramos from comment #7) > Who is going to maintain that? do you need to wash it everyday?? Leave in the tree until systemd-boot is in the tree and there is an alternative solution.
everyday? This is opened for more than one year ago
Any reason not to just move this to maintainer-needed? Is there anything actually broken with this package. It is a pretty useful/important package in general. Now, if there is something actually wrong with it I'm fine with treecleaning. However, if this is getting rid of it just because it is dated that seems premature.
What are you really FUD-ing about? systemd-boot does not need to be packaged since it's in Gentoo for quite a long time already. It's in sys-apps/systemd[gnuefi]. You install it via 'bootctl install'. Enjoy.
(In reply to Michał Górny from comment #11) > What are you really FUD-ing about? systemd-boot does not need to be packaged > since it's in Gentoo for quite a long time already. It's in > sys-apps/systemd[gnuefi]. You install it via 'bootctl install'. Enjoy. If this can be readily installed when using openrc then I don't see any reason not to move in this direction. However, I'm skeptical as to whether bootctl would work without a running systemd+dbus, based on how all the other tools work. If it isn't trivial to use the version bundled in systemd on an openrc system I suggest just leaving this in the tree at least to tide things over, unless it breaks.
(In reply to Richard Freeman from comment #12) > If it isn't trivial to use the version bundled in systemd on an openrc > system I suggest just leaving this in the tree at least to tide things over, > unless it breaks. bootctl is pretty much standalone; it doesn't need to talk to systemd to do anything. It would still be good for someone running openrc to confirm that it actually works, however.
It is worth noting that packaging bootctl separately from systemd got somewhat more complex with the addition of libsystemd-shared.so in systemd-231.
(In reply to Mike Gilbert from comment #14) > It is worth noting that packaging bootctl separately from systemd got > somewhat more complex with the addition of libsystemd-shared.so in > systemd-231. I'd say that working without systemd running is more important than being installable without the rest of systemd. Sure, it is a few extra binaries on the system, but if sysvinit being on my hard drive doesn't bother me, then others can live with a few systemd binaries they don't need if they choose to run systemd-boot among the various alternatives. I just want to preserve the option for openrc users in some way, unless there is some reason we can't.
I updated the systemd-boot ebuild in my overlay. I don't want to move it to the gentoo repository unless I can get someone to commit to testing it on openrc first.
(In reply to Mike Gilbert from comment #16) > I updated the systemd-boot ebuild in my overlay. > > I don't want to move it to the gentoo repository unless I can get someone to > commit to testing it on openrc first. try to compile it, got the following: checking for x86_64-pc-linux-gnu-pkg-config... no checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for DBUS... yes checking for BLKID... yes checking for MOUNT... no configure: error: *** libmount support required but libraries not found
I moved my systemd-boot ebuild to the gentoo repository. Thanks to Anton Bolshakov and Peter Humphrey for testing it.
On building a new Gentoo system from bare metal, I found that sys-boot/systemd-boot needs a dependency on app-text/docbook-xml-dtd:4.5 That's likey to be present already on a full desktop system, but it wasn't on mine at the time I was installing a boot loader.
(In reply to Peter Humphrey from comment #19) > On building a new Gentoo system from bare metal, I found that > sys-boot/systemd-boot needs a dependency on app-text/docbook-xml-dtd:4.5 Please file separate bugs for problems with systemd-boot.
removed
