Re: [gentoo-dev] Baselayout 2 stabilisation todo
On Saturday 23 May 2009, Roy Marples wrote: Basically as Doug said, each OpenRC version comes with a few big chances. Well not massive as in your box will break now, but just a different spin on how things should work. OpenRC-0.5 will have the biggest re-spin to date - net.lo (net.eth0 etc) is considered deprecated. If future changes of this magnitude are still expected, I wonder if we want to go stable with OpenRC anytime soon. I do not intend to hinder fast progress and design changes in OpenRC in any way, but if its design is not considered final, I suggest we do not make it the default recommandation for our users. Marking it stable might also be contraproductive for upstream since revised configurations need to stay supported a lot longer than they would had they been used only by ~arch users. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Baselayout 2 stabilisation todo
Robert Buchholz wrote: On Saturday 23 May 2009, Roy Marples wrote: Basically as Doug said, each OpenRC version comes with a few big chances. Well not massive as in your box will break now, but just a different spin on how things should work. OpenRC-0.5 will have the biggest re-spin to date - net.lo (net.eth0 etc) is considered deprecated. If future changes of this magnitude are still expected, I wonder if we want to go stable with OpenRC anytime soon. I do not intend to hinder fast progress and design changes in OpenRC in any way, but if its design is not considered final, I suggest we do not make it the default recommandation for our users. Let us be clear on one point - net.lo and friends are still somewhat supported upstream, just no future development will take place on them. The network script is just the preferred default as it makes my life a lot easier and places the support burden onto the maintainers of the various utils needed to be used directly. It's also a lot faster :) I don't expect any more userland changes before the move to OpenRC-1.0 There are two features on the cards - rc events [1] and feature removal for space limited embedded systems (basically dependecy is only used to order scripts on initial startup, reducing /sbin/rc and /sbin/runscript to shell stubs the aim on saving 75k on the binary size. Marking it stable might also be contraproductive for upstream since revised configurations need to stay supported a lot longer than they would had they been used only by ~arch users. If there is a real drive to make OpenRC stable then I suggest that I roll openrc-0.5.0 out sometime this week and try to roll rc events into 0.6.0, the embedded stubs into 0.7.0 and we'll go from there. I know that Cardoe has been busy in RL of late and I've never pressed or been pressed into considering it stable. However, real bug reports and new feature implementations have slowed somewhat, so either it's Ready For Stable or no-ones using it. Thanks Roy
Re: [gentoo-dev] Baselayout 2 stabilisation todo
Mike Auty wrote: Roy Marples wrote: Attached is the new conf.d/net sample. Sorry, I missed those. Did lists.g.o remove them, or were they not attached? As such, a side project I've started is a new ifconfig tool [1] to handle everything from vlans, to bridging, to bonding, to wireless (up to WEP) with a similar syntax to the BSD ifconfig. Also [1]'s missing, and I couldn't find it at http://roy.marples.name/. Where should I be looking? This decision is heavily influenced by NetBSD (disclaimer - I'm now a NetBSD dev). Congrats on becoming a NetBSD dev! 5:) Gah, posting just before bed! Anyway, attached and [1] was just a blog entry by me, not much more content than here. There's no project page as yet for ifconfig as it's display only right now. Thanks Roy [1] http://roy.marples.name/projects/self/blog/2009/04/19_ifconfig
Re: [gentoo-dev] Baselayout 2 stabilisation todo
Hi! On Fri, 22 May 2009, Dawid Węgliński wrote: Haven't tested it yet on my box, but i'd like to know if openrc handles 801.2Q support. Near as I can tell, it does (some lines shortened for brevity): [r...@sareth ~]# eix -Ic openrc [I] sys-apps/openrc (0.4.3...@05/15/2009): OpenRC manages the services, startup and shutdown of a host [r...@sareth ~]# ip addr sh [...] 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 [...] link/ether 00:1e:0b:46:50:ba brd ff:ff:ff:ff:ff:ff 3: eth1: NO-CARRIER,BROADCAST,MULTICAST,UP mtu 1500 [...] link/ether 00:1e:0b:46:50:b8 brd ff:ff:ff:ff:ff:ff 4: eth0@eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 [...] link/ether 00:1e:0b:46:50:ba brd ff:ff:ff:ff:ff:ff inet 192.168.2.166/28 brd 192.168.2.175 scope global eth0.381 inet 192.168.2.164/28 brd 192.168.2.175 scope global secondary eth0.381 inet 192.168.2.165/28 brd 192.168.2.175 scope global secondary eth0.381 5: eth0@eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 [...] link/ether 00:1e:0b:46:50:ba brd ff:ff:ff:ff:ff:ff inet 192.168.3.102/24 brd 192.168.3.255 scope global eth0.146 6: eth0@eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 [...] link/ether 00:1e:0b:46:50:ba brd ff:ff:ff:ff:ff:ff inet 10.104.22.1/24 brd 10.104.22.255 scope global eth0.271 [r...@sareth ~]# grep -v '^#' /etc/conf.d/net routes_eth0_381=(default via 192.168.2.161) config_eth1=( null ) config_eth0=( null ) vlans_eth0=381 146 271 config_eth0_381=( 192.168.2.166/28 192.168.2.164/28 192.168.2.165/28 ) config_eth0_146=(192.168.3.102/24) config_eth0_271=(10.104.22.1/24) Regards, Tobias -- panic(%s: CORRUPTED BTREE OR SOMETHING, __FUNCTION__); linux-2.6.6/fs/xfs/xfs_bmap.c
Re: [gentoo-dev] Baselayout 2 stabilisation todo
On Saturday 23 of May 2009 10:53:49 Tobias Klausmann wrote: Hi! On Fri, 22 May 2009, Dawid Węgliński wrote: Haven't tested it yet on my box, but i'd like to know if openrc handles 801.2Q support. Near as I can tell, it does (some lines shortened for brevity): [r...@sareth ~]# eix -Ic openrc [I] sys-apps/openrc (0.4.3...@05/15/2009): OpenRC manages the services, startup and shutdown of a host [r...@sareth ~]# ip addr sh [...] 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 [...] link/ether 00:1e:0b:46:50:ba brd ff:ff:ff:ff:ff:ff 3: eth1: NO-CARRIER,BROADCAST,MULTICAST,UP mtu 1500 [...] link/ether 00:1e:0b:46:50:b8 brd ff:ff:ff:ff:ff:ff 4: eth0@eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 [...] link/ether 00:1e:0b:46:50:ba brd ff:ff:ff:ff:ff:ff inet 192.168.2.166/28 brd 192.168.2.175 scope global eth0.381 inet 192.168.2.164/28 brd 192.168.2.175 scope global secondary eth0.381 inet 192.168.2.165/28 brd 192.168.2.175 scope global secondary eth0.381 5: eth0@eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 [...] link/ether 00:1e:0b:46:50:ba brd ff:ff:ff:ff:ff:ff inet 192.168.3.102/24 brd 192.168.3.255 scope global eth0.146 6: eth0@eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 [...] link/ether 00:1e:0b:46:50:ba brd ff:ff:ff:ff:ff:ff inet 10.104.22.1/24 brd 10.104.22.255 scope global eth0.271 [r...@sareth ~]# grep -v '^#' /etc/conf.d/net routes_eth0_381=(default via 192.168.2.161) config_eth1=( null ) config_eth0=( null ) vlans_eth0=381 146 271 config_eth0_381=( 192.168.2.166/28 192.168.2.164/28 192.168.2.165/28 ) config_eth0_146=(192.168.3.102/24) config_eth0_271=(10.104.22.1/24) Regards, Tobias Thank you very much Tobias!
Re: [gentoo-dev] Baselayout 2 stabilisation todo
Doug Goldstein wrote: The only reason why OpenRC has not come up for stabilization by it's maintainers is the fact that everytime there's a new version readied for release, on the horizon there's new incompatible changes being planned for the next version. The OpenRC maintainers in Gentoo have always chosen to wait until OpenRC settles down a little bit. Now with the plan to drop support for certain features (ADSL and PPP support in the networking code), it's going to rewrite more Gentoo people to step up to develop and maintain this code. rp-pppoe support should be removed because its scripts don't work well under baselayout, but are you sure OpenRC mantainers also plan to drop generic PPP support? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Baselayout 2 stabilisation todo
Alin Năstac wrote: Doug Goldstein wrote: The only reason why OpenRC has not come up for stabilization by it's maintainers is the fact that everytime there's a new version readied for release, on the horizon there's new incompatible changes being planned for the next version. The OpenRC maintainers in Gentoo have always chosen to wait until OpenRC settles down a little bit. Now with the plan to drop support for certain features (ADSL and PPP support in the networking code), it's going to rewrite more Gentoo people to step up to develop and maintain this code. rp-pppoe support should be removed because its scripts don't work well under baselayout, but are you sure OpenRC mantainers also plan to drop generic PPP support? I don't usually troll -dev anymore, but I feel urged to reply to this. Basically as Doug said, each OpenRC version comes with a few big chances. Well not massive as in your box will break now, but just a different spin on how things should work. OpenRC-0.5 will have the biggest re-spin to date - net.lo (net.eth0 etc) is considered deprecated. Instead OpenRC now ships with network (provides net) which is a simple wrapper around calling ifconfig (or ip) and with the ability to run shell scripts. Attached is the new conf.d/net sample. You'll notice it's a lot smaller than the old one as it relies heavily on the user being able to read and understand man pages for userland tools requires to do the job. Now, the one weakness with this approach is that the Linux userland tools are quite frankly crap compared to the BSD counterparts. Why is there the need for many badly written tools to configure a network interface? As such, a side project I've started is a new ifconfig tool [1] to handle everything from vlans, to bridging, to bonding, to wireless (up to WEP) with a similar syntax to the BSD ifconfig. However, work on this has stopped as a side product of this means I have to get some wpa_supplicant changes I have pushed upstream so it can start on any wireless interface - and when it appears (pcmcia, etc). One side effect of this is that daemons such was wpa_supplicant and PPP are now init scripts proper - this is good. The only downside is that you lose the ability to control each interface via init.d. Instead I propose you control this via ifconfig. This decision is heavily influenced by NetBSD (disclaimer - I'm now a NetBSD dev). FWIW, the only re-spin I have on my list is to remove dependencies from rc and runscript so that dependencies are only taken into account when rc is run and not for each script. Essentially, making rc and runscript light shell wrappers and removing a few tools so that it's smaller for space critical devices. Thanks Roy
Re: [gentoo-dev] Baselayout 2 stabilisation todo
Roy Marples wrote: One side effect of this is that daemons such was wpa_supplicant and PPP are now init scripts proper - this is good. The only downside is that you lose the ability to control each interface via init.d. Instead I propose you control this via ifconfig. Uh, so in summary any external daemons such as wpa_supplicant and PPP will be controlled fully by init scripts external to OpenRC. OpenRC may supply example init scripts, but not installed by default. Thanks Roy
Re: [gentoo-dev] Baselayout 2 stabilisation todo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roy Marples wrote: Attached is the new conf.d/net sample. Sorry, I missed those. Did lists.g.o remove them, or were they not attached? As such, a side project I've started is a new ifconfig tool [1] to handle everything from vlans, to bridging, to bonding, to wireless (up to WEP) with a similar syntax to the BSD ifconfig. Also [1]'s missing, and I couldn't find it at http://roy.marples.name/. Where should I be looking? This decision is heavily influenced by NetBSD (disclaimer - I'm now a NetBSD dev). Congrats on becoming a NetBSD dev! 5:) Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkoYdCoACgkQu7rWomwgFXq5NwCfdI7nIk7Am0goWcbip9eCWBE/ iHgAnjHS2V/HpvngD9EUmnBa3ZNCUk4D =aiQu -END PGP SIGNATURE-
[gentoo-dev] Baselayout 2 stabilisation todo
Hi, I'd like to collect some things we need to do before Baselayout 2 and OpenRC can go stable. Up to now I have: * eselect 1.1 stable (current RC3) for the support in the rc module * a newer splashutils stable * documentation updates (http://bugs.gentoo.org/213988, thanks Jeremy) What else? As some of you might foresee, this can be as hard as a major GCC stabilisation, so it must be well-planned and organised. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Baselayout 2 stabilisation todo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Faulhammer wrote: What else? As some of you might foresee, this can be as hard as a major GCC stabilisation, so it must be well-planned and organised. Depends on which version of openrc gets stabilized in the process. We're currently working out some issues with 4.3.2-r2 in bug 270646 [1]. Mike 5:) [1] http://bugs.gentoo.org/270646 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkoWfUgACgkQu7rWomwgFXpuVwCeLJRmQ4fparXM+fGzX4Ufr6Yj kkMAn1JzD8yGhiUUrEHaEJrDA0ZR8o75 =+r5R -END PGP SIGNATURE-
Re: [gentoo-dev] Baselayout 2 stabilisation todo
On Fri, May 22, 2009 at 5:17 AM, Christian Faulhammer fa...@gentoo.org wrote: Hi, I'd like to collect some things we need to do before Baselayout 2 and OpenRC can go stable. Up to now I have: * eselect 1.1 stable (current RC3) for the support in the rc module * a newer splashutils stable * documentation updates (http://bugs.gentoo.org/213988, thanks Jeremy) What else? As some of you might foresee, this can be as hard as a major GCC stabilisation, so it must be well-planned and organised. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ The only reason why OpenRC has not come up for stabilization by it's maintainers is the fact that everytime there's a new version readied for release, on the horizon there's new incompatible changes being planned for the next version. The OpenRC maintainers in Gentoo have always chosen to wait until OpenRC settles down a little bit. Now with the plan to drop support for certain features (ADSL and PPP support in the networking code), it's going to rewrite more Gentoo people to step up to develop and maintain this code. If you're volunteering for this position, Christian, I'll happily step down and allow you to maintain this. I would also discuss this with zzam and vapier, the other 2 maintainers of OpenRC. -- Doug Goldstein
Re: [gentoo-dev] Baselayout 2 stabilisation todo
On Fri, May 22, 2009 at 5:17 AM, Christian Faulhammer fa...@gentoo.org wrote: Hi, I'd like to collect some things we need to do before Baselayout 2 and OpenRC can go stable. Up to now I have: * eselect 1.1 stable (current RC3) for the support in the rc module * a newer splashutils stable * documentation updates (http://bugs.gentoo.org/213988, thanks Jeremy) What else? As some of you might foresee, this can be as hard as a major GCC stabilisation, so it must be well-planned and organised. I forgot to add... The other TODO items would be to resolve some of the roughly 60 opened bugs with OpenRC and other packages supporting OpenRC correctly. Breaking a person's ability to boot his system is the worst kind of bug we can introduce and is not acceptable in the we need to stabilize this package mindset. -- Doug Goldstein
Re: [gentoo-dev] Baselayout 2 stabilisation todo
On Friday 22 of May 2009 12:17:17 Christian Faulhammer wrote: Hi, I'd like to collect some things we need to do before Baselayout 2 and OpenRC can go stable. Up to now I have: * eselect 1.1 stable (current RC3) for the support in the rc module * a newer splashutils stable * documentation updates (http://bugs.gentoo.org/213988, thanks Jeremy) What else? As some of you might foresee, this can be as hard as a major GCC stabilisation, so it must be well-planned and organised. V-Li Haven't tested it yet on my box, but i'd like to know if openrc handles 801.2Q support.
