This will become the next OpenRc stable request. Currently, it is just a place-holder so that I can add it to the tasks that need to be done for >=udev-189 stabilization.
Personally, I am using it since I started to test newer udev at end of July and works fine (only found bug #434800 regression, but it doesn't look to have any major effect apart of the message)
Updated to 0.11.5 some days ago and looks to work perfect :D
@base-system: We need this version of OpenRC to go stable for several reasons. I believe we need baselayout-2.2 also for this. If so, can you sign off on it, update the dependency in openrc-0.11.5.ebuild and add the arch teams so we can get both of them stabilized simultaneously? Thanks, William
(In reply to comment #3) > @base-system: > We need this version of OpenRC to go stable for several reasons. I > believe we need baselayout-2.2 also for this. > I am running it with stable -2.1-r1, what is broken with it? (to also update to latest baselayout) Thanks for the info
@jmbsvicetto: Didn't Releng need baselayout-2.2 to go stable when the newer OpenRC does because of the /run directory being created?
(In reply to comment #5) > @jmbsvicetto: > Didn't Releng need baselayout-2.2 to go stable when the newer OpenRC > does because of the /run directory being created? Stable baselayout-2.1-r1 already creates the /run directory. baselayout-2.2 only contains a BSD-related fix and adds /etc/os-release file.
Arch teams, please test and mark stable openrc-0.11.5. Thanks, William
(In reply to comment #5) > @jmbsvicetto: > Didn't Releng need baselayout-2.2 to go stable when the newer OpenRC > does because of the /run directory being created? afaik, this is not the case. we need >=genkernel-3.4.39 and >=openrc-0.10.5
amd64 stable
x86 stable
openrc 0.11.5 should block <udev-init-scripts-17, as in udev-mount from udev-init-scripts-16 does not provide dev-mount. Hence, devfs is started before udev-mount, which results in a non-functioning xterm, gnome-terminal, etc. https://forums.gentoo.org/viewtopic-t-942250-highlight-openrc.html
(In reply to comment #11) > openrc 0.11.5 should block <udev-init-scripts-17, as in udev-mount from > udev-init-scripts-16 does not provide dev-mount. Hence, devfs is started > before udev-mount, which results in a non-functioning xterm, gnome-terminal, > etc. > https://forums.gentoo.org/viewtopic-t-942250-highlight-openrc.html The new udev-init-scripts you want require ~arch udev and kmod. I don't think we are ready for that yet... are we? Is there another solution maybe?
(In reply to comment #12) > (In reply to comment #11) > > openrc 0.11.5 should block <udev-init-scripts-17, as in udev-mount from > > udev-init-scripts-16 does not provide dev-mount. Hence, devfs is started > > before udev-mount, which results in a non-functioning xterm, gnome-terminal, > > etc. > > https://forums.gentoo.org/viewtopic-t-942250-highlight-openrc.html > > The new udev-init-scripts you want require ~arch udev and kmod. I don't > think we are ready for that yet... are we? > > Is there another solution maybe? I suggested a block, not a dependency.
(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > openrc 0.11.5 should block <udev-init-scripts-17, as in udev-mount from > > > udev-init-scripts-16 does not provide dev-mount. Hence, devfs is started > > > before udev-mount, which results in a non-functioning xterm, gnome-terminal, > > > etc. > > > https://forums.gentoo.org/viewtopic-t-942250-highlight-openrc.html > > > > The new udev-init-scripts you want require ~arch udev and kmod. I don't > > think we are ready for that yet... are we? > > > > Is there another solution maybe? > > I suggested a block, not a dependency. The forum post you linked says upgrading to 17 solved the issue for him, so I'm a bit confused why you are suggesting a block.
stable ppc, thanks peratu
(In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #12) > > > (In reply to comment #11) > > > > openrc 0.11.5 should block <udev-init-scripts-17, as in udev-mount from > > > > udev-init-scripts-16 does not provide dev-mount. Hence, devfs is started > > > > before udev-mount, which results in a non-functioning xterm, gnome-terminal, > > > > etc. > > > > https://forums.gentoo.org/viewtopic-t-942250-highlight-openrc.html > > > > > > The new udev-init-scripts you want require ~arch udev and kmod. I don't > > > think we are ready for that yet... are we? > > > > > > Is there another solution maybe? > > > > I suggested a block, not a dependency. > > The forum post you linked says upgrading to 17 solved the issue for him, so > I'm a bit confused why you are suggesting a block. People that have a stable udev version are fine. On such systems, /etc/init.d/udev-mount is provided by sys-fs/udev. However, unstable versions of udev depend on udev-init-scripts. And udev-init-scripts installs the version of /etc/init.d/udev-mount, that does not provide dev-mount. The only solution I see that works for users of both stable and unstable udev is a block.
Another option is to not make too early stable requests. Seriously something is went wrong with openrc and often revision bumps without proper testing ground
(In reply to comment #17) > Another option is to not make too early stable requests. Seriously something > is went wrong with openrc and often revision bumps without proper testing > ground The last version marked stable was 04 Feb 2012, I'd hardly call this stable bump too quick, more the opposite considering release media was broken since mid june because of the /run change. This is a gentoo hosted project, that means that minor versions and revisions can be used for testing and a new release that fixes the bugs really isn't that big a deal to do a two week stabilization instead of 30 days. More importantly there is exactly _zero_ issue with users who are actually running a stable system, only with users running unstable (or at least partiality unstable) systems, guess what, it's unstable. That said, I'm all for looking into this issue, but seriously, don't pretend it's a stable issue when it's not.
The blocker has been added. In the future, please open separate bugs for issues like this instead of highjacking a stable request. This issue does not affectt stable users at this point, so it was completely irrelevent to stabilization. Arch teams, please continue. Thanks, William
Arch teams, please continue stabilization with openrc-0.11.6. Thanks, William
arm stable
ppc64 stable
ia64 stable
Stable for HPPA.
sparc stable
I test-drove it on my private alpha and it checks out ok, both in serial and VGA mode. Also tested interactive boot with serial. Unfortunately, my CVS setup currently is b0rked, so I'll defer keywording until next year.
I've taken the extra time to also test USE=newnet for my very simple static setup and it works fine. Stable on alpha.
alpha/m68k/s390/sh stable
