[gentoo-dev] Baselayout 2 stabilisation todo

[gentoo-dev] Baselayout 2 stabilisation todo

[Christian Faulhammer]

[-- Attachment #1: Type: text/plain, Size: 597 bytes --]

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/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Baselayout 2 stabilisation todo

[Mike Auty]

-----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-----

[gentoo-dev] Re: Baselayout 2 stabilisation todo

[Duncan]

Christian Faulhammer <fauli@gentoo.org> posted
20090522121717.1904971d@gentoo.org, excerpted below, on  Fri, 22 May 2009
12:17:17 +0200:

> 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.

What about the "deprecated" reliance on the old-style addons code as used 
by at least the mdraid (mdadm package) and lvm (lvm2 package) services?  
(I'd quote except the messages don't appear to be logged so I can't get 
'em without rebooting.)

I've not filed a bug as I'm sure the maintainers can read as well as I 
can, but if we're talking about stabilizing openrc, getting them in shape 
and stable without dependence on already deprecated functionality so 
stable users never see that warning would be nice.  Such warnings tend to 
be (generally unnecessarily) alarming to normal users, especially when a 
brand spanking new upgrade is already emitting "deprecated" warnings.

Or should I file the bugs?  It seems no one else has and maybe the 
maintainers don't have the config for what they're maintaining, or 
otherwise don't see the warnings.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Baselayout 2 stabilisation todo

[Mike Auty]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Duncan wrote:
> Or should I file the bugs?  It seems no one else has and maybe the 
> maintainers don't have the config for what they're maintaining, or 
> otherwise don't see the warnings.

I'm aware of the dm-crypt issue and will try and spend some time this
weekend getting that into shape.  If you do file bugs, please make them
block bug 251730 [1], which is the deprecated warning tracker.  Thanks...

Mike  5:)

[1] http://bugs.gentoo.org/251730
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoWoI8ACgkQu7rWomwgFXo0UgCeKTtnrZAR0y8rIdNSDOJRje1w
F5MAoKr1jJIM/JtBJL+ibxmzkFIV96lB
=AyNP
-----END PGP SIGNATURE-----

[gentoo-dev] Re: Baselayout 2 stabilisation todo

[Duncan]

Mike Auty <ikelos@gentoo.org> posted 4A16A08F.8060602@gentoo.org,
excerpted below, on  Fri, 22 May 2009 13:54:39 +0100:

> I'm aware of the dm-crypt issue and will try and spend some time this
> weekend getting that into shape.  If you do file bugs, please make them
> block bug 251730 [1], which is the deprecated warning tracker. 
> Thanks...

... And to think of all the time I just spent looking for mdadm and lvm2 
bugs and missed that one!

Thanks.  I couldn't believe there weren't bugs on it at this late stage, 
but I sure couldn't see 'em.  CCed.



-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Baselayout 2 stabilisation todo

[Doug Goldstein]

On Fri, May 22, 2009 at 5:17 AM, Christian Faulhammer <fauli@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

[Alin Năstac]

[-- Attachment #1: Type: text/plain, Size: 747 bytes --]

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?



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [gentoo-dev] Baselayout 2 stabilisation todo

[Roy Marples]

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]

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

[Mike Auty]

-----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-----

Re: [gentoo-dev] Baselayout 2 stabilisation todo

[Roy Marples]

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

[Roy Marples]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: network --]
[-- Type: text/plain, Size: 2461 bytes --]

# Assign static IP addresses and run custom scripts per interface.
# Seperate commands with ;
# Prefix with ! to run a shell script.
# Use \$int to represent the interface
#ifconfig_eth0="192.168.0.10 netmask 255.255.255.0"

# You also have ifup_eth0 and ifdown_eth0 to run other commands when
# eth0 is started and stopped.
# You should note that we don't stop the network at system shutdown by default.
# If you really need this, then set shutdown_network=YES

# You can assign a default route
#defaultroute="192.168.0.1"
# Lastly, the interfaces variable pulls in virtual interfaces that cannot
# be automatically detected.
#interfaces="br0 bond0 vlan0"

# You can also use files instead of variables here if you like:
# /etc/ifconfig.eth0 is equivalent to ifconfig_eth0
# /etc/ip.eth0 is equivalent to ifconfig_eth0
# /etc/ifup.eth0 is equivalent to ifup_eth0
# /etc/ifdown.eth0 is equivalent to ifdown_eth0
# Any files found will automatically be put into the interfaces variable.
# You don't need to escape variables in files, so use $int instead of \$int.

# If you require DHCP, you should install dhcpcd and it to the boot or
# default runlevel.

# ifconfig under Linux is not that powerful and doesn't easily handle
# multiple addresses
# On the other hand, ip (iproute2) is quite powerful and is also supported
#ip_eth0="192.168.0.10/24; 192.168.10.10/24"

# Create a bonded interface
#interfaces="bond0"
#ifup_bond0="modprobe bonding; ifconfig \$int up; ifenslave \$int bge0"
#ifconfig_bond0="192.168.0.10 netmask 255.255.255.0"
#ifdown_bond0="rmmod bonding"

# Create tap interface and a bridge interface.
# We add the tap to the bridge.
# An external program, like dhcpcd, will configure the IP on the bridge
#interfaces="tun0 br0"
#ifup_tun0="tunctl -t \$int"
#ifdown_tun0="tunctl -d \$int"
#ifup_br0="brctl addbr \$int; brctl add \$int eth1; brtctl add \$int eth2"
#ifdown_br0="ifconfig \$int down; btctl delbr \$int"

# Create VLAN
#interfaces="eth0_2 eth0_3 eth0_4"
#ifup_eth0="vconfig add \$int 2; vconfig add \$int 3; vconfig add \$int 4"
#ifconfig_eth0_2="192.168.2.10 netmask 255.255.255.0"
#ifconfig_eth0_3="192.168.3.10 netmask 255.255.255.0"
#ifconfig_eth0_4="192.168.4.10 netmask 255.255.255.0"
#ifdown_eth0="vconfig rem \$int.2; vconfig rem \$int.3; vconfig rem \$int.4"

# Normally you would use wpa_supplicant to configure wireless, but you can
# use iwconfig also
#ifup_wlan0="iwconfig \$int key s:secretkey enc open essid foobar"

Re: [gentoo-dev] Baselayout 2 stabilisation todo

[Robert Buchholz]

[-- Attachment #1: Type: text/plain, Size: 856 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Baselayout 2 stabilisation todo

[Roy Marples]

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

[gentoo-dev] Re: Baselayout 2 stabilisation todo

[Christian Faulhammer]

[-- Attachment #1: Type: text/plain, Size: 1142 bytes --]

Hi,

Roy Marples <roy@marples.name>:
> 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.

 Sounds fine to me.  I don't want to press anything, just some kind of
plan would be fine so we can work towards a goal.
 
> 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.

 I am using it productively on many systems even before the split-off
to OpenRC.  And bringing such a crucial piece of software to stable is
a hard task.  I have some experience in working with the surroundings
from some GCC stabilisations so I can lend a hand here and be a
pathfinder in stableland to prepare everything there.

V-Li 

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: Baselayout 2 stabilisation todo

[Christian Faulhammer]

[-- Attachment #1: Type: text/plain, Size: 2080 bytes --]

Hi,

Doug Goldstein <cardoe@gentoo.org>:

> On Fri, May 22, 2009 at 5:17 AM, Christian Faulhammer
> <fauli@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.

 After having seen vapier speaking about stabilisation on -core we had
a discussion about the wanted news item, which i posted for review.
Before the "todo" mail, I wrote to the maintainers (Roy and
base-system) some days in advance, with only a reaction from Roy.

> 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.

 All I want to do is help with the stabilisation...which I though is
nigh.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Baselayout 2 stabilisation todo

[Doug Goldstein]

On Fri, May 22, 2009 at 5:17 AM, Christian Faulhammer <fauli@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

[Dawid Węgliński]

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.

Re: [gentoo-dev] Baselayout 2 stabilisation todo

[Tobias Klausmann]

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):

[root@sareth ~]# eix -Ic openrc
[I] sys-apps/openrc (0.4.3-r2@05/15/2009): OpenRC manages the services, startup and shutdown of a host
[root@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.381@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.146@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.271@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
[root@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

[Dawid Węgliński]

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):
>
> [root@sareth ~]# eix -Ic openrc
> [I] sys-apps/openrc (0.4.3-r2@05/15/2009): OpenRC manages the services,
> startup and shutdown of a host [root@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.381@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.146@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.271@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
> [root@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!