| Summary: | sys-apps/sysvinit-2.88-r9 stable request | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | William Hubbs <williamh> |
| Component: | [OLD] Keywording and Stabilization | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | felix.janda, wizardedit |
| Priority: | Normal | Keywords: | STABLEREQ |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 551626 | ||
|
Description
William Hubbs
2016-04-23 17:24:17 UTC
Could bug 551626 be fixed before stabilization (add an upstream patch)? *** Bug 581190 has been marked as a duplicate of this bug. *** (In reply to Felix Janda from comment #1) > Could bug 551626 be fixed before stabilization (add an upstream patch)? the patch just adds a header. we should be able to add the patch without a rev bump. any objections to me doing it? (In reply to Anthony Basile from comment #3) should be fine (In reply to SpanKY from comment #4) > (In reply to Anthony Basile from comment #3) > > should be fine added. so right now -r9 adds the following over -r7: 1. the fix for sysmacros.h 2. the fix for musl 3. call /sbin/openrc rather than /sbin/rc in the inittab, deprecating the sym link. The open bugs against sysvinit are either feature requests or have been fixed. The only one I'm not sure of is bug #506030, but that looks like it has been fixed with bug #573668 and was just left open. I haven't confirmed independently. If it is fixed, then I'd like to see this proceed with stabilization because it clears the path for glibc and musl to proceed forward. (In reply to Anthony Basile from comment #5) > I'm not sure of is bug #506030, but that looks like it > has been fixed with bug #573668 and was just left open. pageexec who originally reported that -r8 was broken, reports that its now fix in -r9, so i closed bug #506030. (In reply to Anthony Basile from comment #6) > (In reply to Anthony Basile from comment #5) > > I'm not sure of is bug #506030, but that looks like it > > has been fixed with bug #573668 and was just left open. > > pageexec who originally reported that -r8 was broken, reports that its now > fix in -r9, so i closed bug #506030. So, no remaining blockers then? (In reply to Austin English from comment #7) > (In reply to Anthony Basile from comment #6) > > (In reply to Anthony Basile from comment #5) > > > I'm not sure of is bug #506030, but that looks like it > > > has been fixed with bug #573668 and was just left open. > > > > pageexec who originally reported that -r8 was broken, reports that its now > > fix in -r9, so i closed bug #506030. > > So, no remaining blockers then? there's a man page issue which is minor. we could live with it but maybe i'll just produce a quick patch tomorrow. see bug #530940. there's also bug #533828 which i want to look at again. bug 530940 isn't a regression, so it's not a blocker (In reply to SpanKY from comment #9) > bug 530940 isn't a regression, so it's not a blocker Then, can the arches be CCed finally? :/ (In reply to Pacho Ramos from comment #10) > (In reply to SpanKY from comment #9) > > bug 530940 isn't a regression, so it's not a blocker > > Then, can the arches be CCed finally? :/ yes i've done it: KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ppc ppc64 s390 sh sparc x86" I've added arm64, m68k, s390 and sh even though they are strictly not stable arches anymore. I'll let vapier do what he wants there since he's taking care of them. Stable for HPPA PPC64. arm stable alpha stable amd64 stable x86 stable ppc stable Stable on sparc and ia64 per jmorgan. Removing unstable arches and closing; this is resolved. |