[gentoo-dev] baselayout-2 stablisation plans

[gentoo-dev] baselayout-2 stablisation plans

[Roy Marples]

This is just a heads up for getting baselayout-2 stable. Next week I
plan to put baselayout-2.0.0_rc1 into the tree without any keywords and
it will be removed from package.mask (keeping the current alphas masked
though). Arch teams will then be pinged on a bug to keyword
baselayout-2.

Now there are, as usual, some daemons and init scripts that probably
won't work. For those that don't, I have either fixed or there's patches
in our bugzilla. Here's a rough summary.

Regarding init scripts.
Init scripts should now be strictly bourne or POSIX shell. ie, no
bashisms. bash init scripts will work, but ONLY if /bin/sh is bash.
Shells as /bin/sh that I've tested and found to be working are
bash
dash
busybox
zsh
FreeBSD sh

Also, as there's no bashisms, that also means no bash arrays. This
includes our net config.
config_eth0=( "1.2.3.4/24" "5.6.7.8 netmask 255.255.255.0" )
becomes
config_eth0="'1.2.3.4/24' '5.6.7.8 netmask 255.255.255.0'"
Pay attention to the quoting there.
We still support bash arrays if and only if /bin/sh is really bash, so
your existing net config should work as is.

Regarding start-stop-daemon. It will now test to see if the daemon is
running after it returns as some daemons love to fork and then error on
a bad config. So we trap this. However, there are also some false
positives where there is a big gap between forking and writing the
pidfile. Examples of this are ntpd (patch in portage) and nscd (part of
glibc).

Also, when running in parallel, we now prefix all output. This looks
very pretty on screen and is almost perfect. However, this also comes at
a cost - daemons are now expected to close stdin, stdout and stderr
after forking like all well written daemons should. Some don't - like
gpm (latest rev is patched) and noip (patch in bugs). If they don't,
then it will hang rc. Sadly, there isn't much I can do about this.

Lastly, reiserfs3 and jfs users should comment on bug #116016 to ensure
that my proposed patches to the userland tools actually work as I don't
use those fs's much aside from basic testing.

Well, that's about it. It's been a fun journey making baselayout-2 and
we're almost at the end of this road :)

Thanks

Roy

PS - Now is a very good time to test it if you're concerned about it
running on your obscure arch or use some funky networking foo.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-2 stablisation plans

[Daniel Drake]

Roy Marples wrote:
> This is just a heads up for getting baselayout-2 stable. Next week I
> plan to put baselayout-2.0.0_rc1 into the tree without any keywords and
> it will be removed from package.mask (keeping the current alphas masked
> though). Arch teams will then be pinged on a bug to keyword
> baselayout-2.

You should find someone from the GDP to write some user migration docs. 
The two things that spring to mind are having to use init scripts for 
device-mapper and crypto fs stuff (I can see lots of unbootable systems 
for those who don't realise this...) and having to compile the new 
splashutils *after* baselayout to keep fbsplash working.

Thanks for all your work on baselayout-2!

Daniel

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-2 stablisation plans

[Roy Marples]

On Sat, 2007-07-21 at 12:15 -0400, Daniel Drake wrote:
> Roy Marples wrote:
> > This is just a heads up for getting baselayout-2 stable. Next week I
> > plan to put baselayout-2.0.0_rc1 into the tree without any keywords and
> > it will be removed from package.mask (keeping the current alphas masked
> > though). Arch teams will then be pinged on a bug to keyword
> > baselayout-2.
> 
> You should find someone from the GDP to write some user migration docs. 

Good idea. Any volunteers?

> The two things that spring to mind are having to use init scripts for 
> device-mapper and crypto fs stuff (I can see lots of unbootable systems 
> for those who don't realise this...) and having to compile the new 
> splashutils *after* baselayout to keep fbsplash working.

I don't actually know how to set those up or what the migration path
would be. Maybe devzero and strerror could document this as I understand
they do this.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-2 stablisation plans

[Daniel Drake]

Roy Marples wrote:
> I don't actually know how to set those up or what the migration path
> would be. Maybe devzero and strerror could document this as I understand
> they do this.

I manage systems with a single RAID 0 stripe (not dmraid) managed by 
device-mapper. When upgrading baselayout, we also have to upgrade to a 
recent device-mapper version which provides the device-mapper init 
script. Then we must run:

  # rc-update add device-mapper boot

If we don't, we get an unbootable system.

Daniel

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-2 stablisation plans

[Roy Marples]

On Sat, 2007-07-21 at 12:45 -0400, Daniel Drake wrote:
> Roy Marples wrote:
> > I don't actually know how to set those up or what the migration path
> > would be. Maybe devzero and strerror could document this as I understand
> > they do this.
> 
> I manage systems with a single RAID 0 stripe (not dmraid) managed by 
> device-mapper. When upgrading baselayout, we also have to upgrade to a 
> recent device-mapper version which provides the device-mapper init 
> script. Then we must run:
> 
>   # rc-update add device-mapper boot
> 
> If we don't, we get an unbootable system.

Probably a good idea to add that to the ebuild output too?

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-2 stablisation plans

[Petteri Räty]

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

Roy Marples kirjoitti:
> On Sat, 2007-07-21 at 12:45 -0400, Daniel Drake wrote:
>> Roy Marples wrote:
>>> I don't actually know how to set those up or what the migration path
>>> would be. Maybe devzero and strerror could document this as I understand
>>> they do this.
>> I manage systems with a single RAID 0 stripe (not dmraid) managed by 
>> device-mapper. When upgrading baselayout, we also have to upgrade to a 
>> recent device-mapper version which provides the device-mapper init 
>> script. Then we must run:
>>
>>   # rc-update add device-mapper boot
>>
>> If we don't, we get an unbootable system.
> 
> Probably a good idea to add that to the ebuild output too?
> 
> Roy
> 

Yes. That coupled with the ~arch Portage elog output at the end of
emerge will go a long a way to notifying users. If we would even have
news on that of that...

Regards,
Petteri


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

Re: [gentoo-dev] baselayout-2 stablisation plans

[Doug Goldstein]

Roy Marples wrote:
> On Sat, 2007-07-21 at 12:45 -0400, Daniel Drake wrote:
>> Roy Marples wrote:
>>> I don't actually know how to set those up or what the migration path
>>> would be. Maybe devzero and strerror could document this as I understand
>>> they do this.
>> I manage systems with a single RAID 0 stripe (not dmraid) managed by 
>> device-mapper. When upgrading baselayout, we also have to upgrade to a 
>> recent device-mapper version which provides the device-mapper init 
>> script. Then we must run:
>>
>>   # rc-update add device-mapper boot
>>
>> If we don't, we get an unbootable system.
> 
> Probably a good idea to add that to the ebuild output too?
> 
> Roy
> 

I added that ages ago.

-- 
Doug Goldstein <cardoe@gentoo.org>
http://dev.gentoo.org/~cardoe/
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-2 stablisation plans

[Josh Saddler]

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

Roy Marples wrote:
> On Sat, 2007-07-21 at 12:15 -0400, Daniel Drake wrote:
>> Roy Marples wrote:
>>> This is just a heads up for getting baselayout-2 stable. Next week I
>>> plan to put baselayout-2.0.0_rc1 into the tree without any keywords and
>>> it will be removed from package.mask (keeping the current alphas masked
>>> though). Arch teams will then be pinged on a bug to keyword
>>> baselayout-2.
>> You should find someone from the GDP to write some user migration docs. 
> 
> Good idea. Any volunteers?

(GDP): you give us the info, we'll document it for you. Or I will at least.

Of equal concern to me, however are a few issues:

1) How will stabilization work? Is it a forced upgrade from stable 1.x
to 2.x, or can it be slotted?
2) It will be completely unmanageable to have more than one set of
baselayout instructions in the handbook & other docs, so there
definitely is a need for the migration doc.
3) How long will 1.x be kept stable? (This affects how long the old
instructions are in the handbooks etc.)
4) What baselayout will be used in the next release? (Maybe that's more
of a releng question.)
5) Do you have a rough estimate (month, 3 weeks, 5 weeks, what?) on when
the first arches might be stabilizing 2.x?

This is all from the GDP's perspective, almost none of it is of interest
to me as a user; I expect this sh** to work just as well as
baselayout-1.x when I hit the upgrade myself. :)

Documenting this will be a major arsepain--er, effort--since baselayout
1.x directions are already mixed in so well with pretty much every doc
we have. I'm not at all looking forward to fixing the docs when the time
comes, but I will do it provided I get to borrow your brain for a good
long time. :)


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

Re: [gentoo-dev] baselayout-2 stablisation plans

[Roy Marples]

On Sat, 2007-07-21 at 11:48 -0700, Josh Saddler wrote:
> (GDP): you give us the info, we'll document it for you. Or I will at least.

Well, the changes are as outlined in my first email.
The user changes are mainly a few variables in the /etc/conf.d/* files
that baselayout ships. For example a few have been removed and a few
have been added, and a few have changed.

>From our perspective, /etc/conf.d/* is quite well documented, so GDP
could easily diff the files to see what has changed.

> Of equal concern to me, however are a few issues:
> 
> 1) How will stabilization work? Is it a forced upgrade from stable 1.x
> to 2.x, or can it be slotted?

It cannot be slotted in any way or form.
Also, the daemon state data is non transferable as the format has
changed in baselayout-2. This is the data that records how a daemon was
started by s-s-d so we can check if it's running or not. However, most
end users won't be concerned by this.

I've tested the ebuilds for upgrading and downgrading quite extensively,
with the following notes.
baselayout-1 *requires* bash. As such /bin/sh should point to bash
before downgrading.
If the /etc/init.d files are not immediately updated by etc-update or
other means then errors will happen. What errors and how severe entirely
depend on the scripts the user has in /etc/init.d

> 2) It will be completely unmanageable to have more than one set of
> baselayout instructions in the handbook & other docs, so there
> definitely is a need for the migration doc.

That's your call.

> 3) How long will 1.x be kept stable? (This affects how long the old
> instructions are in the handbooks etc.)

Good question. We normally keep at least one major revision prior to the
current stable in the tree. They can stay in the tree indefinitely I
suppose, but the GDP should only follow the current stable. Maybe
archive the handbook?

> 4) What baselayout will be used in the next release? (Maybe that's more
> of a releng question.)

baselayout team just makes baselayout releases. If you mean the LiveCD
then ask releng.

> 5) Do you have a rough estimate (month, 3 weeks, 5 weeks, what?) on when
> the first arches might be stabilizing 2.x?

No.
If the RC's prove stable and no serious regressions are reported for a
month then we'll probably release a final 2.0.0 and get arch teams to
mark stable a week later, or right away if no last minute changes have
been made.

> This is all from the GDP's perspective, almost none of it is of interest
> to me as a user; I expect this sh** to work just as well as
> baselayout-1.x when I hit the upgrade myself. :)

In theory it should just work. Especially as Gentoo/FreeBSD has been
running it as our standard baselayout for around 6 months now. So
hopefully this should be a very smooth release.

> Documenting this will be a major arsepain--er, effort--since baselayout
> 1.x directions are already mixed in so well with pretty much every doc
> we have. I'm not at all looking forward to fixing the docs when the time
> comes, but I will do it provided I get to borrow your brain for a good
> long time. :)

Most of the documentation should still apply. I've tried to be as
compatible as possible - the one possible exception being networking as
baselayout-1 used bash arrays extensively. But we still support that
if /bin/sh is bash, which it is by default for Gentoo/Linux

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-2 stablisation plans

[Mike Frysinger]

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

On Saturday 21 July 2007, Roy Marples wrote:
> On Sat, 2007-07-21 at 11:48 -0700, Josh Saddler wrote:
> >From our perspective, /etc/conf.d/* is quite well documented, so GDP
>
> could easily diff the files to see what has changed.
>
> > Of equal concern to me, however are a few issues:
> >
> > 1) How will stabilization work? Is it a forced upgrade from stable 1.x
> > to 2.x, or can it be slotted?
>
> It cannot be slotted in any way or form.
> Also, the daemon state data is non transferable as the format has
> changed in baselayout-2. This is the data that records how a daemon was
> started by s-s-d so we can check if it's running or not. However, most
> end users won't be concerned by this.
>
> I've tested the ebuilds for upgrading and downgrading quite extensively,
> with the following notes.
> baselayout-1 *requires* bash. As such /bin/sh should point to bash
> before downgrading.
> If the /etc/init.d files are not immediately updated by etc-update or
> other means then errors will happen. What errors and how severe entirely
> depend on the scripts the user has in /etc/init.d

i really think this bash vs POSIX issue is getting way more emphasis than it 
should.  i'd make the claim the majority of people out there dont even know 
about /bin/sh, bash, dash, and friends, so most people out there will 
have /bin/sh pointing to bash and as such, none of these things will be an 
issue for them.  anyone who has tried to switch /bin/sh to point to something 
else has already seen their system blow up.  or they're using baselayout-2 
and so they're aware of the issues.

in other words, you want to put info in there about POSIX shell and changing 
your conf.d files, great ... but dont emphasize it like it's doomsday and all 
hell's gonna break loose when you upgrade.
-mike

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

Re: [gentoo-dev] baselayout-2 stablisation plans

[Roy Marples]

On Sat, 2007-07-21 at 15:28 -0400, Mike Frysinger wrote:
> i really think this bash vs POSIX issue is getting way more emphasis than it 
> should.  i'd make the claim the majority of people out there dont even know 
> about /bin/sh, bash, dash, and friends, so most people out there will 
> have /bin/sh pointing to bash and as such, none of these things will be an 
> issue for them.  anyone who has tried to switch /bin/sh to point to something 
> else has already seen their system blow up.  or they're using baselayout-2 
> and so they're aware of the issues.
> 
> in other words, you want to put info in there about POSIX shell and changing 
> your conf.d files, great ... but dont emphasize it like it's doomsday and all 
> hell's gonna break loose when you upgrade.

True enough, but now I've said it I'll sleep better tonight knowing that
I've at least warned some people who think wow - baselayout-2 supports
*faster* shells like busybox. I'll rock with my -fomg-optimized flags.
IE ricers who then bitch that their box is broke if they downgrade.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-2 stablisation plans

[Josh Saddler]

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

Roy Marples wrote:
> On Sat, 2007-07-21 at 11:48 -0700, Josh Saddler wrote:
>> (GDP): you give us the info, we'll document it for you. Or I will at least.
> 
> Well, the changes are as outlined in my first email.
> The user changes are mainly a few variables in the /etc/conf.d/* files
> that baselayout ships. For example a few have been removed and a few
> have been added, and a few have changed.

Yeah, I planned on doing some heavy reading of the new stuff, but I hope
I can get you all alone (heh heh heh) for awhile to go over questions
that will surely pop up. In case things like new networking configs
aren't intuitive, or whatever.

>> 3) How long will 1.x be kept stable? (This affects how long the old
>> instructions are in the handbooks etc.)
> 
> Good question. We normally keep at least one major revision prior to the
> current stable in the tree. They can stay in the tree indefinitely I
> suppose, but the GDP should only follow the current stable. Maybe
> archive the handbook?

Archiving the handbook isn't possible. The only thing we archive for
historical purposes are the networkless handbooks, in
/doc/en/handbook/2006.0/, 2006.1/, etc. I'm thinking that if
baselayout-2 is the way of the future, then as soon as it's stabled for
all arches (see below for a bit more) then we should pretty much just
document that exclusively in all handbooks & docs. That's where a
migration guide will be so crucial. Since the thing can't be slotted,
and it's a forced upgrade (short of masking, but BAH to those users that
do it), I don't think we need to document two completely different
systems if they're both stable.

>> 5) Do you have a rough estimate (month, 3 weeks, 5 weeks, what?) on when
>> the first arches might be stabilizing 2.x?
> 
> No.
> If the RC's prove stable and no serious regressions are reported for a
> month then we'll probably release a final 2.0.0 and get arch teams to
> mark stable a week later, or right away if no last minute changes have
> been made.

What'd really be nice is if it goes stable for all arches (or at least
all of the ones that matter, subjectively) either in time or after the
next release. Otherwise, there's going to be some more complications
from users who install from media containing old baselayout-1.x and have
to deal with the new 2.x right away. I guess we'll see. /me pokes
wolf31o2. ;)

> Most of the documentation should still apply. I've tried to be as
> compatible as possible - the one possible exception being networking as
> baselayout-1 used bash arrays extensively. But we still support that
> if /bin/sh is bash, which it is by default for Gentoo/Linux

Yeah. Though I still don't know the whole story, I anticipate that
updating the networking configs will be the biggest headache.



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

Re: [gentoo-dev] baselayout-2 stablisation plans

[Roy Marples]

On Sat, 2007-07-21 at 17:25 -0700, Josh Saddler wrote:
> Archiving the handbook isn't possible.

Why? Unless I'm missing something, it should be fairly trivial.

> What'd really be nice is if it goes stable for all arches (or at least
> all of the ones that matter, subjectively) either in time or after the
> next release.

That's kinda the plan. When the base system team was 4 people, we all
agreed that we just "make it stable" as it was mostly script based and
needed to be done at the same time.

I'd like to treat baselayout-2 the same, but as we're mostly C based
it's up to the arch teams to decide.

> 
> > Most of the documentation should still apply. I've tried to be as
> > compatible as possible - the one possible exception being networking as
> > baselayout-1 used bash arrays extensively. But we still support that
> > if /bin/sh is bash, which it is by default for Gentoo/Linux
> 
> Yeah. Though I still don't know the whole story, I anticipate that
> updating the networking configs will be the biggest headache.

Only for non bash /bin/sh - like FreeBSD.
But we don't have a handbook for that yet so it's no worry :)

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-2 stablisation plans

[Josh Saddler]

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

Roy Marples wrote:
> On Sat, 2007-07-21 at 17:25 -0700, Josh Saddler wrote:
>> Archiving the handbook isn't possible.
> 
> Why? Unless I'm missing something, it should be fairly trivial.

It ain't. It's an old issue.

Current networked (requires a net connection to install) handbooks go to
/doc/en/handbook/. Networkless (needs no net connection, only a liveCD
of some sort) goes to /doc/en/handbook/release_number/, like /2007.0/.
Whenever there's a new release, we can archive the networkless versions
because we just add a new dir for the latest version number. But
everything in /doc/en/handbook/ (networked) gets overwritten with the
stuff for the new release.

No way we can archive anything but the networkless handbooks. Besides,
that's mostly what you'd want anyway -- if you do the much more
up-to-date networked install, you're going to pull in all the new stuff
like baselayout-2 anyway, so you wouldn't want the old directions.

That's the theory, at least.


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

Re: [gentoo-dev] baselayout-2 stablisation plans

[Chris Gianelloni]

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

On Sat, 2007-07-21 at 17:25 -0700, Josh Saddler wrote:
> >> 5) Do you have a rough estimate (month, 3 weeks, 5 weeks, what?) on when
> >> the first arches might be stabilizing 2.x?
> > 
> > No.
> > If the RC's prove stable and no serious regressions are reported for a
> > month then we'll probably release a final 2.0.0 and get arch teams to
> > mark stable a week later, or right away if no last minute changes have
> > been made.
> 
> What'd really be nice is if it goes stable for all arches (or at least
> all of the ones that matter, subjectively) either in time or after the
> next release. Otherwise, there's going to be some more complications
> from users who install from media containing old baselayout-1.x and have
> to deal with the new 2.x right away. I guess we'll see. /me pokes
> wolf31o2. ;)

We'll definitely want the same version stable across the board.  I'll be
sure to work with Roy and you to ensure we come to an agreement on what
to use and that we're all on the same page.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

Re: [gentoo-dev] baselayout-2 stablisation plans

[Roy Marples]

On Mon, 2007-07-23 at 13:30 -0700, Chris Gianelloni wrote:
> We'll definitely want the same version stable across the board.  I'll be
> sure to work with Roy and you to ensure we come to an agreement on what
> to use and that we're all on the same page.

Fair enough.

Should I open a bug (when the time comes) just requesting the blessing
of the arch teams or just unmask it anyway?

Note that the following arch's have been tested by people other than me
amd64
arm
ppc
ppc64
sparc (fbsd only i think so far)
x86

I did compile test it on a s390 a few months ago, but I seem to have
lost my account there now.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-2 stablisation plans

[Mike Frysinger]

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

On Monday 23 July 2007, Roy Marples wrote:
> On Mon, 2007-07-23 at 13:30 -0700, Chris Gianelloni wrote:
> > We'll definitely want the same version stable across the board.  I'll be
> > sure to work with Roy and you to ensure we come to an agreement on what
> > to use and that we're all on the same page.
>
> Fair enough.
>
> Should I open a bug (when the time comes) just requesting the blessing
> of the arch teams or just unmask it anyway?

open a bug, package.mask it, and let arch teams test it by filling out 
KEYWORDS ... once everyone is on board, unmask it

> I did compile test it on a s390 a few months ago, but I seem to have
> lost my account there now.

that's cause you smell like poop.  oh and we formatted those boxes.
-mike

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

Re: [gentoo-dev] baselayout-2 stablisation plans

[Chris Gianelloni]

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

On Mon, 2007-07-23 at 22:24 +0100, Roy Marples wrote:
> On Mon, 2007-07-23 at 13:30 -0700, Chris Gianelloni wrote:
> > We'll definitely want the same version stable across the board.  I'll be
> > sure to work with Roy and you to ensure we come to an agreement on what
> > to use and that we're all on the same page.
> 
> Fair enough.
> 
> Should I open a bug (when the time comes) just requesting the blessing
> of the arch teams or just unmask it anyway?

Well, the "best" for us is if it is already stable in the tree before we
snapshot, as that means it was tested and stabilized prior to our
snapshot and likely has more QA done on it before we even start the
release.  If we can do that, then Release Engineering will be set and
we'll love you long time.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

[gentoo-dev] Re: baselayout-2 stablisation plans

[Christian Faulhammer]

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

Chris Gianelloni <wolf31o2@gentoo.org>:

> Well, the "best" for us is if it is already stable in the tree before
> we snapshot, as that means it was tested and stabilized prior to our
> snapshot and likely has more QA done on it before we even start the
> release.  If we can do that, then Release Engineering will be set and
> we'll love you long time.

 x86 will do some extensive testing, too.  So we should be ready soon.

V-Li

-- 
http://www.gentoo.org/
http://www.faulhammer.org/
http://www.gnupg.org/

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

Re: [gentoo-dev] baselayout-2 stablisation plans

["José Luis Rivero (yoswink)"]

Roy Marples escribió:
> On Mon, 2007-07-23 at 13:30 -0700, Chris Gianelloni wrote:
>> We'll definitely want the same version stable across the board.  I'll be
>> sure to work with Roy and you to ensure we come to an agreement on what
>> to use and that we're all on the same page.
> 
> Fair enough.
> 
> Should I open a bug (when the time comes) just requesting the blessing
> of the arch teams or just unmask it anyway?
> 
> Note that the following arch's have been tested by people other than me
> amd64
> arm
> ppc
> ppc64
> sparc (fbsd only i think so far)
> x86
> 

In alpha is under testing by Tobias Klausman (B|ackbird) but, a part 
from the net.eth0 lost link issue, seems to be sane AFAIK. We will be 
ready very soon.

Thanks.

-- 
Jose Luis Rivero <yoswink@gentoo.org>
Gentoo/Doc Gentoo/Alpha
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-2 stablisation plans

[Andrew Gaffney]

Roy Marples wrote:
>> 4) What baselayout will be used in the next release? (Maybe that's more
>> of a releng question.)
> 
> baselayout team just makes baselayout releases. If you mean the LiveCD
> then ask releng.

It'll be whatever version of baselayout is stable at the time we take the 
initial release snapshot. However, if baselayout-2 will go stable a week after 
we take the initial snapshot, it would probably be incorporated.

-- 
Andrew Gaffney                                 http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer             Catalyst/Installer + x86 release coordinator
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-2 stablisation plans

[Chris Gianelloni]

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

On Sat, 2007-07-21 at 11:48 -0700, Josh Saddler wrote:
> 4) What baselayout will be used in the next release? (Maybe that's more
> of a releng question.)

Whichever is stable around September(ish) time frame will be what we
use, unless it is requested that we use something different.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

Re: [gentoo-dev] baselayout-2 stablisation plans

[Denis Dupeyron]

On 7/21/07, Roy Marples <uberlord@gentoo.org> wrote:
> Now there are, as usual, some daemons and init scripts that probably
> won't work. For those that don't, I have either fixed or there's patches
> in our bugzilla. Here's a rough summary.

About the nscd issue we discussed on irc on friday (i.e. daemon not
playing nice with parallel startup), your patch worked. It stayed on
my work laptop, though, so I can't file a bug right now. But I'll do
so monday morning.

Oh, and by the way, baselayout-2 is great stuff, thanks !

Denis.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-2 stablisation plans

[Rémi Cardona]

Denis Dupeyron a écrit :
> About the nscd issue we discussed on irc on friday (i.e. daemon not
> playing nice with parallel startup), your patch worked. It stayed on
> my work laptop, though, so I can't file a bug right now. But I'll do
> so monday morning.

I'll add mine about the dhcdbd patch you gave me 2 weeks ago. Works great.

> Oh, and by the way, baselayout-2 is great stuff, thanks !

+1 on that as well.

Rémi
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-2 stablisation plans

[Tobias Klausmann]

Hi! 

[... baselayout-2 is on the horizon ...]

Is there a common bug to report snags to? I've hit one:
/etc/init.d/net.eth0 used to be a symlink to net.lo. After
installing, it was gone (I figure it went with baselayout-1).
Luckily, I have direct console access, otherwise the machine
would have been gone after the reboot. Definitely something to
yell about during merging.

Regards,
Tobias

PS: If said bug exists, I'll gladly re-report there, but my
cursory search didn't turn up anything. 
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-2 stablisation plans

[Roy Marples]

On Sat, 2007-07-21 at 22:22 +0200, Tobias Klausmann wrote:
> Is there a common bug to report snags to? I've hit one:
> /etc/init.d/net.eth0 used to be a symlink to net.lo. After
> installing, it was gone (I figure it went with baselayout-1).
> Luckily, I have direct console access, otherwise the machine
> would have been gone after the reboot. Definitely something to
> yell about during merging.

We don't ship with net.eth0 because there is no guarantee an interface
called eth0 exists. net.lo (net.lo0 in *BSDs) always exists so we just
ship that.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-2 stablisation plans

[Roy Marples]

On Sat, 2007-07-21 at 21:28 +0100, Roy Marples wrote:
> On Sat, 2007-07-21 at 22:22 +0200, Tobias Klausmann wrote:
> > Is there a common bug to report snags to? I've hit one:
> > /etc/init.d/net.eth0 used to be a symlink to net.lo. After
> > installing, it was gone (I figure it went with baselayout-1).
> > Luckily, I have direct console access, otherwise the machine
> > would have been gone after the reboot. Definitely something to
> > yell about during merging.
> 
> We don't ship with net.eth0 because there is no guarantee an interface
> called eth0 exists. net.lo (net.lo0 in *BSDs) always exists so we just
> ship that.

One very good idea would be to get udev to create any net links that do
not exist to net.lo

Then we truly have plug and play :)

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-2 stablisation plans

[Mike Frysinger]

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

On Saturday 21 July 2007, Roy Marples wrote:
> On Sat, 2007-07-21 at 21:28 +0100, Roy Marples wrote:
> > On Sat, 2007-07-21 at 22:22 +0200, Tobias Klausmann wrote:
> > > Is there a common bug to report snags to? I've hit one:
> > > /etc/init.d/net.eth0 used to be a symlink to net.lo. After
> > > installing, it was gone (I figure it went with baselayout-1).
> > > Luckily, I have direct console access, otherwise the machine
> > > would have been gone after the reboot. Definitely something to
> > > yell about during merging.
> >
> > We don't ship with net.eth0 because there is no guarantee an interface
> > called eth0 exists. net.lo (net.lo0 in *BSDs) always exists so we just
> > ship that.
>
> One very good idea would be to get udev to create any net links that do
> not exist to net.lo
>
> Then we truly have plug and play :)

indeed, that'd be sleeky and sexy ... go file a bug ;)
-mike

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

Re: [gentoo-dev] baselayout-2 stablisation plans

[Roy Marples]

On Sat, 2007-07-21 at 17:22 -0400, Mike Frysinger wrote:
> indeed, that'd be sleeky and sexy ... go file a bug ;)

Let bug #186156 [1] be henceforth known as the sleeky and sexy bug!

[1] http://bugs.gentoo.org/show_bug.cgi?id=186156

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-2 stablisation plans

[Vlastimil Babka]

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

Roy Marples wrote:
> On Sat, 2007-07-21 at 17:22 -0400, Mike Frysinger wrote:
>> indeed, that'd be sleeky and sexy ... go file a bug ;)
> 
> Let bug #186156 [1] be henceforth known as the sleeky and sexy bug!
> 
> [1] http://bugs.gentoo.org/show_bug.cgi?id=186156
> 
> Thanks

As you wish! [1] :)

[1] http://bugs.gentoo.org/show_activity.cgi?id=186156

- --
Vlastimil Babka (Caster)
Gentoo/Java
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGooZEtbrAj05h3oQRApS1AKCU0vyw+Oka3yPc4bByDHxPyQEDFwCgpzIL
F8ot8iOS1irR5UlcvDgpxFY=
=Ydgn
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-2 stablisation plans

[Michiel de Bruijne]

On Saturday 21 July 2007 16:36:03 Roy Marples wrote: 
> This is just a heads up for getting baselayout-2 stable. Next week I 
> plan to put baselayout-2.0.0_rc1 into the tree without any keywords and 
> it will be removed from package.mask (keeping the current alphas masked 
> though). Arch teams will then be pinged on a bug to keyword 
> baselayout-2. 
> 
> Well, that's about it. It's been a fun journey making baselayout-2 and 
> we're almost at the end of this road :) 
> 
> Thanks 
> 
> Roy 
 
Hereby a friendly reminder that gcc-config should be keyworded as well, 
current gcc-config isn’t compatible with baselayout-2. According to Mike 
gcc-config-1.4.0 is compatible with baselayout-2. (doesn’t work on my system, 
but I haven’t investigated yet).
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-2 stablisation plans

[Alon Bar-Lev]

On 7/21/07, Roy Marples <uberlord@gentoo.org> wrote:
> This is just a heads up for getting baselayout-2 stable. Next week I
> plan to put baselayout-2.0.0_rc1 into the tree without any keywords and
> it will be removed from package.mask (keeping the current alphas masked
> though). Arch teams will then be pinged on a bug to keyword
> baselayout-2.

Hi!
Just an issue I thought a long while ago...
What about adding USE flags for all optional networking components...
So that they installed without manually merging them one by one?

Best Regards,
Alon Bar-Lev.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-2 stablisation plans

[Roy Marples]

On Tue, 2007-07-24 at 21:31 +0300, Alon Bar-Lev wrote:
> Just an issue I thought a long while ago...
> What about adding USE flags for all optional networking components...
> So that they installed without manually merging them one by one?

Too many use flags - simply install the package.
In the future, once the API for out network scripts doesn't change then
we will punt the scripts to the packages.

I don't want baselayout to rival PHP in terms of USE flags - heh.

Thanks

Roy



-- 
gentoo-dev@gentoo.org mailing list