This package is dead upstream and has multiple related bugs in Gentoo. I think it is time to treeclean it. Thanks, William
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3fbd58fe70b289986671812e8e2e199e611a32ce commit 3fbd58fe70b289986671812e8e2e199e611a32ce Author: William Hubbs <williamh@gentoo.org> AuthorDate: 2024-08-21 18:38:14 +0000 Commit: William Hubbs <williamh@gentoo.org> CommitDate: 2024-08-21 18:38:14 +0000 profiles: last rite sys-process/runit Bug: https://bugs.gentoo.org/938282 Signed-off-by: William Hubbs <williamh@gentoo.org> profiles/package.mask | 7 +++++++ 1 file changed, 7 insertions(+)
Void Linux seems to be the de-facto upstream of at least the last four years. I can't deduce what the rationale for hitching this package to Debian's wagon was; it's not explained at all in the commit log, their patches drastically alter the software's behaviour in incompatible ways, and they never claimed first class support for this init system anyway. Most of the mentioned bugs (linked below for readers' convenience) seem to be either self-inflicted wounds (a lot of unfixed ebuild jank), contain patches that have received no ack from the package owner, or are already fixed and not marked as such. Runit isn't intrinsically broken, the world around it seems to be losing the plot. Otherwise I do agree that this should be treecleaned, as continuing to offer it to users in this state is doing them and upstream a disservice. For a replacement sys-apps/s6 has a much higher bus factor (and they recently exercised their disaster recovery procedures too). https://bugs.gentoo.org/575478 https://bugs.gentoo.org/611846 https://bugs.gentoo.org/814551 https://bugs.gentoo.org/892653 https://bugs.gentoo.org/904989 https://bugs.gentoo.org/934410 https://bugs.gentoo.org/935656 https://bugs.gentoo.org/938262
In addition to treecleaning, I propose that base-system drop the package immediately from maintainership. Strongly in favour of treecleaning - if anybody outside of base-system has a good use case and is willing to do the work; they can submit PRs and/or move it to an overlay. The last upstream release however was 2014/08/10 - nearly a decade ago, and this package does contain C code that doesn't build cleanly on more modern GCC versions. Back in June 2024, I used the Debian patches because the void-linux fork is 2 years out of date; and the Debian patch series is actively maintained: last commits were in March 2024: https://salsa.debian.org/debian/runit At the time my objective for the ebuild was moving to EAPI=8, and building on GCC-12 & GCC-13. As of 2020, the runit author was still around, because he orphaned his packages in Debian: https://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/2020-January/002915.html
(In reply to Robin Johnson from comment #3) > The last upstream release however was 2014/08/10 - nearly a decade ago, and > this package does contain C code that doesn't build cleanly on more modern > GCC versions. Yeah, it was already emitting warnings and GCC14 won't compile it at all. You can brute force past the errors by adding -fpermissive, but that's hacky and I'm not a C person so I have no idea what effects that flag has. I've looked at the code a few times to see how hard it'd be to fix those errors properly and I don't think it's worth it at this point. It seems to be mostly small mechanical changes but they're spread over the entire codebase, they touch a lot of ancient sysv concepts and one-letter variable names that nobody's going to fully understand, and a patch would probably be pushing $FILESDIR size restrictions. Best to let it go.
We're using runit actively, so please don't remove it. If possible, I'd like to fix the bugs, please let me known howto contribute.
> Yeah, it was already emitting warnings and GCC14 won't compile it at all. I submit a patch at https://bugs.gentoo.org/934410 the reason is modern compiler treat many warning (previously) as error which cause test of sigprocmask failed.
(In reply to Zhixu Liu from comment #5) > We're using runit actively, so please don't remove it. > > If possible, I'd like to fix the bugs, please let me known howto contribute. You've been a long-term user IIRC and made some good contributions. I'm happy to take your word for it and give it a go, if you are willing to maintain runit in Gentoo. Please see https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/User_Guide.
I'm also using runit a lot and while I'm not a "C person" too I'm able to proxy-maintain it if Liu will need some help with this. In general, runit is much simpler than s6 and worth to be supported. As for "upstream dead" it's not actually true. Upstream consider it "finished software" and there is a lot of true in this: there are no known bugs in last decade (at least I don't remember such in runit maillist, not sure what issues Debian devs has patched). Yeah, compilers change and it result in some extra support is needed, but this is too far from considering "upstream dead" or use this as a valid reason for a package removal. All of this sounds more like a "maintainer needed" for the package, no more.
(In reply to Alex Efros from comment #8) > I'm also using runit a lot and while I'm not a "C person" too I'm able to > proxy-maintain it if Liu will need some help with this. > > In general, runit is much simpler than s6 and worth to be supported. > > As for "upstream dead" it's not actually true. Upstream consider it > "finished software" and there is a lot of true in this: there are no known > bugs in last decade (at least I don't remember such in runit maillist, not > sure what issues Debian devs has patched). Yeah, compilers change and it > result in some extra support is needed, but this is too far from considering > "upstream dead" or use this as a valid reason for a package removal No, that's not how we work. If nobody in Gentoo is willing to fix those, whatever they are, and they're substantial, then it goes if nobody steps up. Now, if you're going to step up, that's great, but it's not a reason to not last-rite it to begin with. See below too. > All of this sounds more like a "maintainer needed" for the package, no more. Yes, but no such maintainer existed until now (thank you Zhixu and hopefully you too, Alex!). Last-riting is generally an opportunity for people like you to speak up. It is usually not irreversible. (Sometimes a situation is *really* bad and we won't, but this is not one of those times. In particular here, I'd say the last-rites were merited given trying to update it to Debian patches ended up with it not being able to reboot, which is what prompted the last-rites ;) (See bug 938262).
Zhixu Liu*
> In particular here, I'd say the last-rites were merited given trying to > update it to Debian patches ended up with it not being able to reboot, which > is what prompted the last-rites ;) (See bug 938262). I'll try to setup a test machine and have a loook at this issue. We use runit in docker container, so don't know this problem.
(In reply to Zhixu Liu from comment #11) > I'll try to setup a test machine and have a loook at this issue. We use > runit in docker container, so don't know this problem. I'm using runit to boot (and I don't use openrc at all, it's pure runit system). I've just tested -r3 ebuild and can confirm: ctrl-alt-del is actually broken and has no effect, plus `/sbin/runit-init 6` halts the system instead of reboot. I didn't installed any of runit scripts (like /etc/runit/ctrlaltdel or any others) provided by -r3, so my scripts which works with -r1 is fail with -r3 runit binary, so it's clear the problem is in ubuntu patches for the runit binary. To me, it looks like -r3 is just turned wrong way: it has added ubuntu patches for unknown reason which are clearly broken, and also it has added hard openrc dependency which is clearly must be optional. If -r1 won't compile using GCC 14/15 then we need to make a patch just for this issue, and it shouldn't break ctrl-alt-del or reboot. Taking all ubuntu patches does not looks like a good idea.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c3e38688c65897ac005a120104e61a84979639b9 commit c3e38688c65897ac005a120104e61a84979639b9 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2024-08-22 14:06:04 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2024-08-22 14:06:04 +0000 sys-process/runit: drop to maintainer-needed Bug: https://bugs.gentoo.org/938282 Signed-off-by: Mike Gilbert <floppym@gentoo.org> sys-process/runit/metadata.xml | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-)
(In reply to Alex Efros from comment #12) > (In reply to Zhixu Liu from comment #11) > > I'll try to setup a test machine and have a loook at this issue. We use > > runit in docker container, so don't know this problem. > > I'm using runit to boot (and I don't use openrc at all, it's pure runit > system). > I've just tested -r3 ebuild and can confirm: ctrl-alt-del is actually broken > and has no effect, plus `/sbin/runit-init 6` halts the system instead of > reboot. > > I didn't installed any of runit scripts (like /etc/runit/ctrlaltdel or any > others) provided by -r3, so my scripts which works with -r1 is fail with -r3 > runit binary, so it's clear the problem is in ubuntu patches for the runit > binary. > > To me, it looks like -r3 is just turned wrong way: it has added ubuntu > patches for unknown reason which are clearly broken, and also it has added > hard openrc dependency which is clearly must be optional. > > If -r1 won't compile using GCC 14/15 then we need to make a patch just for > this issue, and it shouldn't break ctrl-alt-del or reboot. Taking all ubuntu > patches does not looks like a good idea. @ (In reply to Alex Efros from comment #12) > (In reply to Zhixu Liu from comment #11) > > I'll try to setup a test machine and have a loook at this issue. We use > > runit in docker container, so don't know this problem. > > I'm using runit to boot (and I don't use openrc at all, it's pure runit > system). > I've just tested -r3 ebuild and can confirm: ctrl-alt-del is actually broken > and has no effect, plus `/sbin/runit-init 6` halts the system instead of > reboot. > > I didn't installed any of runit scripts (like /etc/runit/ctrlaltdel or any > others) provided by -r3, so my scripts which works with -r1 is fail with -r3 > runit binary, so it's clear the problem is in ubuntu patches for the runit > binary. > > To me, it looks like -r3 is just turned wrong way: it has added ubuntu > patches for unknown reason which are clearly broken, and also it has added > hard openrc dependency which is clearly must be optional. > > If -r1 won't compile using GCC 14/15 then we need to make a patch just for > this issue, and it shouldn't break ctrl-alt-del or reboot. Taking all ubuntu > patches does not looks like a good idea. @alex Could you please have a look at https://bugs.gentoo.org/938262 to confirm whether I find the real reason or not? Thanks.
(In reply to Sam James from comment #7) > (In reply to Zhixu Liu from comment #5) > > We're using runit actively, so please don't remove it. > > > > If possible, I'd like to fix the bugs, please let me known howto contribute. > > You've been a long-term user IIRC and made some good contributions. I'm > happy to take your word for it and give it a go, if you are willing to > maintain runit in Gentoo. > > Please see https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/User_Guide. @sam I submit a PR in https://github.com/gentoo/gentoo/pull/38266 please have a look at it if have time and tell me what else need to be done before become a active proxy maintainer for runit. thanks.
I'd post a comment at https://github.com/gentoo/gentoo/pull/38266#issuecomment-2325047881 , get no reply yet, so I repost here for comments, thanks. The patches for runit are almost ready, see https://github.com/clan/runit/compare/master...ftbfs.v3 . There are a total of 20 patches for now. Currently the patches are divided into the following categories (by order of patches): 1. helpful for development & debug, e.g, provide full command line and result, to check what's going on 2. required, build will failed if not included 3. patch from author w/ new feature provided (don't change existing behaviour) 4. documentation change: w/ tiny (unlikely to cause problem) modification of source code 5. source code changed to silence compiler warnings 6. source code changed to handle obsolete C function during compiling The fact is that there is no active upstream for runit for now, so what's the principle to determine which patch to be included or not. I'd like to include all the patches, if it's not ok, 1 & 2 must be included, it's best to include 3 & 4, the rest can be postponed (submitted as a new patch if not accepted this time?). BTW: Is it possible to maintain runit under Gentoo? Of course, I don't know the author's opinion, just ask for a possibility.
Reviewing 20 patches is hard. So, again, I recommend you to not push them all into single PR. Open several PRs, make each one as small as possible for ease review, and this will increase chances PR be reviewed and accepted. On my side, I can confirm I've reviewed these 20 patches and they all looks good to me. > 3. patch from author w/ new feature provided (don't change existing behaviour) I'm unsure is we actually need this one. It patches more than decade old Debian vserver-related issue with unknown root cause so it's hard to say how actual it is for today's Gentoo users. All other patches shouldn't change runit behaviour.
(In reply to Alex Efros from comment #17) > It patches more than decade old Debian vserver-related issue Actually it's not "patches" that issue, it adds a new feature to work around that issue by disabling `sync` on halt/reboot. So (mis)using this feature on a real server (i.e. not in a docker container etc.) may lead to data loss on halt/reboot. So, is it good (works around some real issue still actual today) or bad (provides a new way for shooting yourself in the foot) is at least questionable.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f0506961c5d9a3edacdf0bfe041fc84753665e4f commit f0506961c5d9a3edacdf0bfe041fc84753665e4f Author: Z. Liu <zhixu.liu@gmail.com> AuthorDate: 2024-08-23 16:35:50 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2024-09-05 14:40:12 +0000 sys-process/runit: fix errors & warnings with clang 18/gcc 15 20 patches from https://github.com/clan/runit/tree/ftbfs.v4 , which are divided into the following categories: 1. patch: 0001 purpose: helpful for development & debug: make full command line & result available in build.log, otherwise extra directives are required when debug 2. patch: 0002, 0003, 0004, 0005, 0006 purpose: required, build will failed if not apply 0005 & 0006 are warnings only for gcc < 14, errors if gcc >= 14 3. patch: 0007 purpose: patch from author w/ new feature provided, but don't change any "user-observable functionality" 4. patch: 0008 purpose: documentation change: w/ tiny (unlikely to cause problem) modification of source code 5. patch: 0009 - 0019 purpose: fix compilation warnings reported by gcc/clang, with -Wall, -Wextra 6. patch: 0020 purpose: usleep is obsoleted in POSIX.1-2001, handled this in compile time by feature test macro, replace w/ nanosleep if available Closes: https://bugs.gentoo.org/934410 Closes: https://bugs.gentoo.org/938262 Closes: https://bugs.gentoo.org/938282 Closes: https://github.com/clan/runit/issues/2 Signed-off-by: Z. Liu <zhixu.liu@gmail.com> Tested-by: Alex Efros <powerman-asdf@yandex.ru> Closes: https://github.com/gentoo/gentoo/pull/38425 Signed-off-by: Mike Gilbert <floppym@gentoo.org> sys-process/runit/Manifest | 1 + sys-process/runit/metadata.xml | 12 +++++++++++- .../{runit-2.1.2-r4.ebuild => runit-2.1.2-r5.ebuild} | 16 +++++++++++++++- 3 files changed, 27 insertions(+), 2 deletions(-)
