| Summary: | sys-apps/baselayout-2.0.2 and sys-apps/openrc-0.8.2-r1 stable request | ||
|---|---|---|---|
| Product: | Gentoo Hosted Projects | Reporter: | William Hubbs <williamh> |
| Component: | OpenRC | Assignee: | OpenRC Team <openrc> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | 1i5t5.duncan, amigadave, ansla80, arne_bab, asturm, axiator, barzog, bberberov+gentoo, betelgeuse, bug, bugs+gentoo, dabbott, dschridde+gentoobugs, ecyoung, eras, esigra, fauli, flow, gef.kornflakes, gengor, gentoo, jaak, jacobgodserv, johnparmitage, junghans, kanelxake, kfm, kjackie, maekke, marat.buharov, marat, mmk, mpagano, mr.jarry, nikoli, nirbheek, pacho, pchrist, polynomial-c, rahul, rdalek1967, ryoichiro.suzuki, stlman, sven.koehler, tanstaafl, tomka |
| Priority: | High | Keywords: | STABLEREQ |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 205286, 206621, 218033, 221903, 222889, 241884, 250978, 251730, 266395, 266804, 297439, 298824, 301473, 302074, 302103, 302116, 302171, 302181, 310293, 310805, 314589, 326865, 336378, 347583, 349389, 351465, 351712, 360367, 360963, 361465, 363501, 363611, 363637, 363671, 363693, 363949, 363957, 363959, 367467, 369085 | ||
| Bug Blocks: | 208178, 213988, 241002, 323031 | ||
|
Description
William Hubbs
2009-12-04 04:36:51 UTC
*** Bug 218859 has been marked as a duplicate of this bug. *** (In reply to comment #1) > *** Bug 218859 has been marked as a duplicate of this bug. *** > I hit this by mistake, not a dupe. Removing OP from CC. Please, add Bug 266875 to "depends on"-list Please add bug 266395 to "Depends on". It is actually an openrc-related bug (network subsystem). Most of the dependent bugs seem to have gone inactive. Is there anything that can be done to help out? Dropping openrc+baselayout into my keywords and upgrading worked wonderful on two stable amd64 installs. I just updated a stable ppc32 system (old iMac) successfully to OpenRC and baselayout-2. The only problems I hit: * The network settings were broken (switched to wpa_cli — I used the chance to really switch to wpa_cli :) ) * I was careless with the config merging, so kdm got replaced with xdm and I had to manually switch it back. It only needed baselayout-2 and openrc in the keywords, `emerge -auD system` and dispatch-conf (though cfg-update would have cleverer, as it would have avoided the xdm merge :) ). Also I use openrc/baselayout2 on an otherwise completely stable OLPC XO without any problems. Same for my mostly stable (except for KDE4 from the overlay) amd64 system. All of them use parallel init, though mostly because I prefer the output (yes, I know that that’s a kinda strange reason ;) ). …just wanted to write that it works — and tell you that you do a hell of a great job with openrc/baselayout2! Many thanks! arg — overlooked the „don’t add comments here“ :( sorry for the noise… (In reply to comment #6) > All of them use parallel init, though mostly because I prefer the output +1 Are there going to be baselayout2-based stages available soon? Only the documentation bug is left and it has no unresolved dependencies of its own. (In reply to comment #9) > Are there going to be baselayout2-based stages available soon? Only the > documentation bug is left and it has no unresolved dependencies of its own. Stages are based on the stable tree, so not until openrc and baselayout 2 go stable. This bug now blocks bug #213988 instead of depending on it, per the comments in the other bug. The current status is that we are going through other bugs to make sure that we do not have any blockers. Once that is done, we will request stabilization unless a new release has to be done to fix other issues. Please add bug 346805 to the depends list, as Comment 17 suggested, and if possible merge an if statement into base layout-1 until base layout-2 is stable. (In reply to comment #12) > Please add bug 346805 to the depends list, as Comment 17 suggested, and if > possible merge an if statement into base layout-1 until base layout-2 is > stable. If I add it to the depends list of this tracker, it means that it cannot be fixed until openrc goes stable, or openrc cannot go stable until it is fixed, depending on which way I add it. This bug is a baselayout-1 bug, so it doesn't belong in the depends for this bug imho. (In reply to comment #13) > (In reply to comment #12) > > Please add bug 346805 to the depends list, as Comment 17 suggested, and if > > possible merge an if statement into base layout-1 until base layout-2 is > > stable. > > If I add it to the depends list of this tracker, it means that it cannot be > fixed until openrc goes stable, or openrc cannot go stable until it is fixed, > depending on which way I add it. > > This bug is a baselayout-1 bug, so it doesn't belong in the depends for this > bug imho. > Then where should it go? Where ever you think it goes put it there, so someone smarter than me will write the if test that will solve the issue Openrc-0.8.1 is the stable candidate. On 5/1 a news item will be committed which will remind stable users of this upgrade. The target date for stabilization will be 5/8. (In reply to comment #15) > Openrc-0.8.1 is the stable candidate. Noticed a small and probably unimportant bug after update from openrc-0.7.0 to openrc-0.8.1 (I skipped 0.8.0 due to bug with /proc mount detection). When shutting down, I do not get "[ ok ]" for "Stopping local". openrc-0.8.1: * Stopping local openrc-0.7.0: * Stopping local ... [ ok ] Probably some typo in /etc/init.d/local. I did not investigate it deeper... (In reply to comment #16) > (In reply to comment #15) > > Openrc-0.8.1 is the stable candidate. > Noticed a small and probably unimportant bug after update from openrc-0.7.0 to > openrc-0.8.1 (I skipped 0.8.0 due to bug with /proc mount detection). When > shutting down, I do not get "[ ok ]" for "Stopping local". This could be a bug, but this tracker bug is not the place for it. Please open a separate bug. Due to regressions, openrc-0.8.1 was removed from the tree. Now, the stable candidate is 0.8.2. Since the differences between 0.8.1 and 0.8.2 are very small, I want to keep the news item release date and stabilization date the same. I assume bug #363949 is a dependency on this bug. (title: openrc-0.8.2 does not migrate /etc/conf.d/local.start to /etc/local.d) (In reply to comment #19) > I assume bug #363949 is a dependency on this bug. (title: openrc-0.8.2 does not > migrate /etc/conf.d/local.start to /etc/local.d) Please see comment #0 for how to do this in the future; comments like this should not be added to the tracker. The news item has been committed to the tree. We will request stabilization of openrc-0.8.2-r1 and baselayout-2.0.2 on 2011/05/08. Arch teams, The day is here... Take a deep breath.... and... Please test and mark stable the following packages: sys-apps/baselayout-2.0.2 sys-apps/openrc-0.8.2-r1 target keywords: alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86 using it since a years on all my machines (except my stable system test) and it works without a problem. So, it is ok for me on: x86/amd64 both also with hardened environment. Only issue that i've found is: scanelf: rpath_security_checks(): Security problem with relative DT_RPATH '../librc:../libeinfo:/lib64' in /tmp/portage/sys-apps/openrc-0.8.2-r1/image/sbin/rc scanelf: rpath_security_checks(): Security problem with relative DT_RPATH '../libeinfo:/lib64' in /tmp/portage/sys-apps/openrc-0.8.2-r1/image/sbin/rc scanelf: rpath_security_checks(): Security problem with relative DT_RUNPATH '../librc:../libeinfo:/lib64' in /tmp/portage/sys-apps/openrc-0.8.2-r1/image/sbin/rc scanelf: rpath_security_checks(): Security problem with relative DT_RUNPATH '../libeinfo:/lib64' in /tmp/portage/sys-apps/openrc-0.8.2-r1/image/sbin/rc scanelf: rpath_security_checks(): Security problem with relative DT_RPATH '../librc:../libeinfo' in /tmp/portage/sys-apps/openrc-0.8.2-r1/image/lib64/libeinfo.so.1 scanelf: rpath_security_checks(): Security problem with relative DT_RPATH '../libeinfo' in /tmp/portage/sys-apps/openrc-0.8.2-r1/image/lib64/libeinfo.so.1 scanelf: rpath_security_checks(): Security problem with relative DT_RUNPATH '../librc:../libeinfo' in /tmp/portage/sys-apps/openrc-0.8.2-r1/image/lib64/libeinfo.so.1 scanelf: rpath_security_checks(): Security problem with relative DT_RUNPATH '../libeinfo' in /tmp/portage/sys-apps/openrc-0.8.2-r1/image/lib64/libeinfo.so.1 scanelf: rpath_security_checks(): Security problem with relative DT_RPATH '../librc:../libeinfo' in /tmp/portage/sys-apps/openrc-0.8.2-r1/image/lib64/librc.so.1 scanelf: rpath_security_checks(): Security problem with relative DT_RPATH '../libeinfo' in /tmp/portage/sys-apps/openrc-0.8.2-r1/image/lib64/librc.so.1 scanelf: rpath_security_checks(): Security problem with relative DT_RUNPATH '../librc:../libeinfo' in /tmp/portage/sys-apps/openrc-0.8.2-r1/image/lib64/librc.so.1 scanelf: rpath_security_checks(): Security problem with relative DT_RUNPATH '../libeinfo' in /tmp/portage/sys-apps/openrc-0.8.2-r1/image/lib64/librc.so.1 scanelf: rpath_security_checks(): Security problem with relative DT_RPATH '../librc:../libeinfo:/lib64' in /tmp/portage/sys-apps/openrc-0.8.2-r1/image/sbin/rc scanelf: rpath_security_checks(): Security problem with relative DT_RPATH '../libeinfo:/lib64' in /tmp/portage/sys-apps/openrc-0.8.2-r1/image/sbin/rc scanelf: rpath_security_checks(): Security problem with relative DT_RUNPATH '../librc:../libeinfo:/lib64' in /tmp/portage/sys-apps/openrc-0.8.2-r1/image/sbin/rc scanelf: rpath_security_checks(): Security problem with relative DT_RUNPATH '../libeinfo:/lib64' in /tmp/portage/sys-apps/openrc-0.8.2-r1/image/sbin/rc scanelf: rpath_security_checks(): Security problem with relative DT_RPATH '../librc:../libeinfo' in /tmp/portage/sys-apps/openrc-0.8.2-r1/image/lib64/libeinfo.so.1 scanelf: rpath_security_checks(): Security problem with relative DT_RPATH '../libeinfo' in /tmp/portage/sys-apps/openrc-0.8.2-r1/image/lib64/libeinfo.so.1 scanelf: rpath_security_checks(): Security problem with relative DT_RUNPATH '../librc:../libeinfo' in /tmp/portage/sys-apps/openrc-0.8.2-r1/image/lib64/libeinfo.so.1 scanelf: rpath_security_checks(): Security problem with relative DT_RUNPATH '../libeinfo' in /tmp/portage/sys-apps/openrc-0.8.2-r1/image/lib64/libeinfo.so.1 scanelf: rpath_security_checks(): Security problem with relative DT_RPATH '../librc:../libeinfo' in /tmp/portage/sys-apps/openrc-0.8.2-r1/image/lib64/librc.so.1 scanelf: rpath_security_checks(): Security problem with relative DT_RPATH '../libeinfo' in /tmp/portage/sys-apps/openrc-0.8.2-r1/image/lib64/librc.so.1 scanelf: rpath_security_checks(): Security problem with relative DT_RUNPATH '../librc:../libeinfo' in /tmp/portage/sys-apps/openrc-0.8.2-r1/image/lib64/librc.so.1 scanelf: rpath_security_checks(): Security problem with relative DT_RUNPATH '../libeinfo' in /tmp/portage/sys-apps/openrc-0.8.2-r1/image/lib64/librc.so.1 but i can't reproduce atm..is a problem? (In reply to comment #23) > using it since a years on all my machines (except my stable system test) and it > works without a problem. > So, it is ok for me on: x86/amd64 both also with hardened environment. > Only issue that i've found is: *snip* > but i can't reproduce atm..is a problem? I haven't seen this issue on my system, and since you can't reproduce it, I would say it isn't a problem. (In reply to comment #24) > I haven't seen this issue on my system, and since you can't reproduce it, I > would say it isn't a problem. Yes, i have see this only at first time compile of openrc. After, also with the same use flag I didn't reproduce. Anyway also if i didn't reproduce it now, there is the log who explain the "issue" Could someone please confirm that there shouldn't be any problem for those of us using the 'server' profile? Have been testing openrc and baselayout-2 on one of my SPARCs, seems to work quite well. Could stabilise. Seems to build and run fine on x86 (I was able to reboot my system). Please mark stable for x86. x86 done now...I cannot verify for server profiles, but I do not know any reason why it shouldn't work there. Here we go! amd64 stable Stable for HPPA. Pls see #366635 (In reply to comment #32) > Pls see #366635 See bug 363501 Arch teams, pleas continue stabilizing. Marked ppc/ppc64 stable. alpha/arm/ia64/sh/sparc stable What is the status for stabilizing these on m68k and s390? Thanks, William m68k can be done now, but s390 still has Bug 367467 marked m68k/s390 stable now that the s390 net bug is fixed |
