[gentoo-dev] openrc portage news item

[gentoo-dev] openrc portage news item

[William Hubbs]

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

All,

this is the portage news item I am planning on committing to the tree.

This is based on an earlier version written by Christian Fallhammer.

If there are no suggestions for additions or corrections, this will be
committed on 5/1.

Thanks,

William


[-- Attachment #1.2: 2011-05-01-baselayout-update.en.txt --]
[-- Type: text/plain, Size: 1051 bytes --]

Title: Baselayout update
Author: Christian Faulhammer <fauli@gentoo.org>
Author: William Hubbs <williamh@gentoo.org>
Content-Type: text/plain
Posted: 2011-05-01
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: <sys-apps/baselayout-2

The baselayout package provides files which all systems must have in
order to function properly. You are currently using version 1.x, which
has several issues. The most significant of these is that the included
init system is written entirely in bash, which makes it slow and
not very flexable.

In the near future, you will see an update for sys-apps/baselayout to
2.x and a new package, sys-apps/openrc. It is recommended that you
perform this update as soon as possible.

After you install these packages, please do not reboot your system
untill you follow the upgrade guide located at
http://www.gentoo.org/doc/en/openrc-migration.xml.

It is important that you follow the guide as soon as possible after
these packages are upgraded. Otherwise, there is a chance that your
system will not reboot properly.

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

Re: [gentoo-dev] openrc portage news item

[Thomas Beierlein]

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

On Wed, 13 Apr 2011 13:15:38 -0500
William Hubbs <williamh@gentoo.org> wrote:

> All,
> 
> this is the portage news item I am planning on committing to the tree.
> 
> This is based on an earlier version written by Christian Fallhammer.
> 
> If there are no suggestions for additions or corrections, this will be
> committed on 5/1.

s/flexable/flexible/

Thomas
> 
> Thanks,
> 
> William
> 



-- 

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

Re: [gentoo-dev] openrc portage news item

[justin]

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


After you install these packages, please do not reboot your system
untill you follow the upgrade guide located at

/untill/until/

justin


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

Re: [gentoo-dev] openrc portage news item

["Paweł Hajdan, Jr."]

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

On 4/13/11 8:15 PM, William Hubbs wrote:
> The baselayout package provides files which all systems must have in
> order to function properly. You are currently using version 1.x, which
> has several issues. The most significant of these is that the included
> init system is written entirely in bash, which makes it slow and
> not very flexable.

I think it would be worth it to mention other problems too (just a list
of most important bugs if that makes sense).


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

Re: [gentoo-dev] openrc portage news item

[William Hubbs]

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

On Wed, Apr 13, 2011 at 08:41:16PM +0200, "Pawe?? Hajdan, Jr." wrote:
> On 4/13/11 8:15 PM, William Hubbs wrote:
> > The baselayout package provides files which all systems must have in
> > order to function properly. You are currently using version 1.x, which
> > has several issues. The most significant of these is that the included
> > init system is written entirely in bash, which makes it slow and
> > not very flexable.
> 
> I think it would be worth it to mention other problems too (just a list
> of most important bugs if that makes sense).

Does anyone on the list have any particular suggestions for what should
be mentioned?

Thanks,

William

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

[gentoo-dev] Re: openrc portage news item

[Duncan]

William Hubbs posted on Wed, 13 Apr 2011 14:58:51 -0500 as excerpted:

> On Wed, Apr 13, 2011 at 08:41:16PM +0200, "Pawe?? Hajdan, Jr." wrote:
>> On 4/13/11 8:15 PM, William Hubbs wrote:
>> > The baselayout package provides files which all systems must have in
>> > order to function properly. You are currently using version 1.x,
>> > which has several issues. The most significant of these is that the
>> > included init system is written entirely in bash, which makes it slow
>> > and not very flexable.
>> 
>> I think it would be worth it to mention other problems too (just a list
>> of most important bugs if that makes sense).
> 
> Does anyone on the list have any particular suggestions for what should
> be mentioned?

The definition of "important" might vary per person, but, while it has 
been awhile since I ran baselayout-1, here's what I recall that I'd 
consider significant.

1) While baselayout-1 had a parallel boot option, it was quite broken and 
(partly or entirely, not sure which) non-functional.  The same thing in 
baselayout-2/openrc works WELL and I use it all the time.  (Given the 
emphasis placed on this in the media, the various boot-timing contests, 
etc, and the fact that this feature puts Gentoo in-play again in regard to 
speed-boots, it's a pretty big positive in favor of upgrading.)

2) In baselayout-1, the early-boot wasn't actually dependency based, but 
rather, was strict-serial-order based on a list of IIRC four services 
started in the exact order they were listed.  (clock or whatever the 
baselayout-1 name was, was one of them, IDR the others).  OpenRC/
baselayout-2 is fully dependency based at every stage.

I mentioned both of these points earlier in a different context.

FWIW/IMHO, I don't believe the news item needs mentioning that it was bash 
that made it slow and inflexible.  Most users don't so much care whether 
it's C or bash or java that made it so, only that it was.  I'd personally 
put more emphasis on the /how/ instead of the /why/, as I believe that's 
what most users want to know.  The above two points support that, thus, 
reworking that whole bit:

"""
You are currently using version 1.x, which was slow and inflexible.  It 
was slow in part because the parallel boot option was broken, and 
inflexible in part because dependencies didn't work until later in the 
boot process, so the first few services had to be started in order 
according to an arbitrary list.
"""

No mention of bash as a reason because that's an internal implementation 
deal I as an admin don't want or need to care about.  What difference will 
it make in the way my system boots and how will that be better, that's 
what I as an admin want to know.

(That said, the above can surely be improved as well.  The ideas conveyed 
are better I believe, more direct to what a Gentoo user/admin will likely 
want to know, but I'm my wording isn't right, yet.)

-- 
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: openrc portage news item

[Rich Freeman]

On Thu, Apr 14, 2011 at 4:09 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> FWIW/IMHO, I don't believe the news item needs mentioning that it was bash
> that made it slow and inflexible.  Most users don't so much care whether
> it's C or bash or java that made it so, only that it was.

If this were Ubuntu I'd be inclined to agree.  However, I think that
most Gentoo users would be interested.  Maybe I have a different
perspective because I just gave a talk on booting two nights ago at an
LUG, but I wasn't even the one to bring up the shortcomings of bash in
the typical linux SysVInit-based service scripts.  Various approaches
that were discussed included symlinking /bin/sh to dash instead of
bash, and C-based solutions (or a combination of both).  It was
interesting to hear that at least a few other distros struggle with
bashisms in their init scripts, but no so much due to licensing/BSD
issues but because of a desire to use dash which does not support all
bashisms.

No need to go into gory details, but mentioning that it is C-based
instead of bash-based seems reasonable.  Granted, we're not really
getting rid of one of the problems with bash, which isn't just
/sbin/rc but rather it includes the init scripts themselves (every one
of which requires spawning a new bash, and many spawn additional
processes like sed/awk/etc).

Rich

[gentoo-dev] Re: openrc portage news item

[Peter Hjalmarsson]

tor 2011-04-14 klockan 08:09 +0000 skrev Duncan:
> 1) While baselayout-1 had a parallel boot option, it was quite broken and 
> (partly or entirely, not sure which) non-functional.  The same thing in 
> baselayout-2/openrc works WELL and I use it all the time.  (Given the 
> emphasis placed on this in the media, the various boot-timing contests, 
> etc, and the fact that this feature puts Gentoo in-play again in regard to 
> speed-boots, it's a pretty big positive in favor of upgrading.)
> 

This feature is still not really perfect, at least not perfect enought.
Use squid on a system where it takes longer for its daemon to exist
(like my router, where the media is a intel SSD, 4GB memory and a AMD
Athlon 2x on the AM3 socket) and you will see lots of outputs from
openrc about all those scripts waiting for it to end...

So maybe when that feature is ready to be enabled by default?

Regards
Peter Hjalmarsson

[gentoo-dev] Re: openrc portage news item

[Duncan]

Peter Hjalmarsson posted on Fri, 15 Apr 2011 16:04:09 +0200 as excerpted:

> [parallel boot] feature is still not really perfect, at least not
> perfect enought. Use squid on a system where it takes longer for its
> daemon to exist (like my router, where the media is a intel SSD,
> 4GB memory and a AMD Athlon 2x on the AM3 socket) and you will see
> lots of outputs from openrc about all those scripts waiting for it
> to end...

If you're talking about the 50...40... etc wait if something takes longer 
than 10 seconds (I get it here on startup with ntp-client), I'd argue 
that's demonstration of the feature's maturity.

What can start/stop does.  Other things wait, with a (configurable) 
timeout until their dependency comes up (or goes down, at shutdown).  If 
the wait is more than 10 seconds, the system tells you what is going on.

That's as designed and IMO a good thing.  What's broken about it?

> So maybe when that feature is ready to be enabled by default?

I believe it's ready for everyone to give a try.  If it doesn't work or 
they prefer the more ordered output of a serial boot, despite the longer 
wait time, fine, but it'll work for most, with possible tweaking of the  
the timeout, the services that don't timeout at all (fscks, by default), 
or fine dependency ordering, if necessary.

To have the system take far longer to POST than from end of POST to 
waiting for me to login (despite the idle-wait for ntp-client), is very 
nice indeed. =:^)

-- 
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] openrc portage news item

[William Hubbs]

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

All,

here is the latest update with typos fixed.

William


[-- Attachment #1.2: 2011-05-01-baselayout-update.en.txt --]
[-- Type: text/plain, Size: 1050 bytes --]

Title: Baselayout update
Author: Christian Faulhammer <fauli@gentoo.org>
Author: William Hubbs <williamh@gentoo.org>
Content-Type: text/plain
Posted: 2011-05-01
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: <sys-apps/baselayout-2

The baselayout package provides files which all systems must have in
order to function properly. You are currently using version 1.x, which
has several issues. The most significant of these is that the included
init system is written entirely in bash, which makes it slow and
not very flexible.

In the near future, you will see an update for sys-apps/baselayout to
2.x and a new package, sys-apps/openrc. It is recommended that you
perform this update as soon as possible.

After you install these packages, please do not reboot your system
until you follow the upgrade guide located at
http://www.gentoo.org/doc/en/openrc-migration.xml.

It is important that you follow the guide as soon as possible after
these packages are upgraded. Otherwise, there is a chance that your
system will not reboot properly.

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

Re: [gentoo-dev] openrc portage news item

[justin]

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

On 13/04/11 21:56, William Hubbs wrote:
> All,
> 
> here is the latest update with typos fixed.
> 
> William
> 

To me, it doesn't makes it totally clear that you screw everything when
rebooting before following the guide. Perhaps this should be made much
clearer.

justin


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

Re: [gentoo-dev] openrc portage news item

[Dirkjan Ochtman]

On Thu, Apr 14, 2011 at 07:30, justin <jlec@gentoo.org> wrote:
> To me, it doesn't makes it totally clear that you screw everything when
> rebooting before following the guide. Perhaps this should be made much
> clearer.

Huh?

"After you install these packages, please do not reboot your system
until you follow the upgrade guide located at
http://www.gentoo.org/doc/en/openrc-migration.xml.

It is important that you follow the guide as soon as possible after
these packages are upgraded. Otherwise, there is a chance that your
system will not reboot properly."

Seem quite clear to me.

Cheers,

Dirkjan

Re: [gentoo-dev] openrc portage news item

[justin]

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

On 14/04/11 09:21, Dirkjan Ochtman wrote:
> On Thu, Apr 14, 2011 at 07:30, justin <jlec@gentoo.org> wrote:
>> To me, it doesn't makes it totally clear that you screw everything when
>> rebooting before following the guide. Perhaps this should be made much
>> clearer.
> 
> Huh?
> 
> "After you install these packages, please do not reboot your system
> until you follow the upgrade guide located at
> http://www.gentoo.org/doc/en/openrc-migration.xml.
> 
> It is important that you follow the guide as soon as possible after
> these packages are upgraded. Otherwise, there is a chance that your
> system will not reboot properly."
> 
> Seem quite clear to me.
> 
> Cheers,
> 
> Dirkjan


_Underline_ or write it capital, I don't know. For us and those who know
gentoo this is clear. But user tend to over read things. I would do a
bet that a number of people will cry, because they just rebooted,
because they stopped reading till there; beside those who do not even
read the news item.
So really would suggest doing ugly things like *ATTENTION* or so.

justin


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

[gentoo-dev] Re: openrc portage news item

[Duncan]

Dirkjan Ochtman posted on Thu, 14 Apr 2011 09:21:48 +0200 as excerpted:

> On Thu, Apr 14, 2011 at 07:30, justin <jlec@gentoo.org> wrote:
>> To me, it doesn't makes it totally clear that you screw everything when
>> rebooting before following the guide. Perhaps this should be made much
>> clearer.
> 
> Huh?
> 
> "After you install these packages, please do not reboot your system
> until you follow the upgrade guide located at
> http://www.gentoo.org/doc/en/openrc-migration.xml.
> 
> It is important that you follow the guide as soon as possible after
> these packages are upgraded. Otherwise, there is a chance that your
> system will not reboot properly."
> 
> Seem quite clear to me.

From my read, while it does actually say it's important, the politeness 
with which it does so don't well convey the true importance and urgency of 
the situation.

If there's a fire, you don't say "Please, excuse me for interrupting, but 
there's a fire and at your convenience, please make your way to the 
exit."  Rather, it's "*FIRE*!  Please STAY CALM.  WALK DON'T RUN.  The 
exit is OVER THERE. Make your way to it IMMEDIATELY!"

So more along the lines of:

"""
After installing these packages, please DO NOT REBOOT
until you follow the upgrade guide located at
http://www.gentoo.org/doc/en/openrc-migration.xml.

If you do not follow the guide as soon as possible after
these packages are upgraded and you reboot or crash
without doing so, the system will likely fail to
boot properly, and you may be looking at some time in
manual recovery mode to fix it.
"""

Yes, the DO NOT REBOOT is shouting, not exactly polite,
but that's arguably what's called for in this situation.

-- 
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: openrc portage news item

[Dale]

Duncan wrote:
>
> > From my read, while it does actually say it's important, the politeness
> with which it does so don't well convey the true importance and urgency of
> the situation.
>
> If there's a fire, you don't say "Please, excuse me for interrupting, but
> there's a fire and at your convenience, please make your way to the
> exit."  Rather, it's "*FIRE*!  Please STAY CALM.  WALK DON'T RUN.  The
> exit is OVER THERE. Make your way to it IMMEDIATELY!"
>
> So more along the lines of:
>
> """
> After installing these packages, please DO NOT REBOOT
> until you follow the upgrade guide located at
> http://www.gentoo.org/doc/en/openrc-migration.xml.
>
> If you do not follow the guide as soon as possible after
> these packages are upgraded and you reboot or crash
> without doing so, the system will likely fail to
> boot properly, and you may be looking at some time in
> manual recovery mode to fix it.
> """
>
> Yes, the DO NOT REBOOT is shouting, not exactly polite,
> but that's arguably what's called for in this situation.
>
>    

Plus having it in all caps makes it stand out.  If a person even looks 
at the message, they will see that at least.  Then hopefully, they will 
read the rest.  I think bold would be nice to tho.  It's not like this 
is not really really important.

Even with that, I see a few people not even noticing it and the next 
reboot going badly.

Dale

:-)  :-)

Re: [gentoo-dev] Re: openrc portage news item

[Matthew Summers]

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

Hi,

I have a few suggestions regarding this major change to Gentoo systems.

1. We should determine and then announce the precise date (appears to
be in May) and time that baselayout-2 will be stabilized via:
  1.1 A front page News item on www.g.o (PR team assemble!),
  1.2 The main MLs (gentoo-announce, gentoo-users, etc),
  1.3 Add a link to the www news item to /topic in #gentoo, and
  1.4 Post a sticky topic in the Forum.
all in addition to the eselect news item under discussion here. The
above would link to the migration guide too.

The rationale for this effort at getting the word out is to prevent
users from hosing their system(s). While I tend to agree that users
should read these eselect news items, its often not the case.
Therefore I recommend shooting for the widest possible distribution of
this information. Also, this gives PR a chance to let the world know
about openrc and its benefits to Gentoo.

2. We should prepare a quick "recover-your-system" guide (could also
create a script too) that can be quickly linked to for user support.
This will save time for people providing support via IRC, email, etc,
and give people a reasonable means of system recovery without huge
pain.

3. Update the handbook to reflect these changes as soon as possible,
and have that all go public simultaneously with the stabilization.

4. I have attached an edited and unfinished version of the original
news item for review. I attempted to be succinct.

This is a really exciting and potentially also rather
anxiety-provoking change for our user base and Gentoo. We all know
that the new baselayout is awesome, and users will find out soon
enough. We simply need to make our best effort at easing the
transition so we minimize the number of casualties.

Thank you,
Matt
-- 
Matthew W. Summers

[-- Attachment #2: 2011-05-01-baselayout-update.en.txt --]
[-- Type: text/plain, Size: 877 bytes --]

Title: Baselayout update
Author: Christian Faulhammer <fauli@gentoo.org>
Author: William Hubbs <williamh@gentoo.org>
Content-Type: text/plain
Posted: 2011-05-01
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: <sys-apps/baselayout-2

On May XX 2011, you will see an update for sys-apps/baselayout to
2.x and a new package, sys-apps/openrc. It is recommended that you
perform this update as soon as possible. Please note, it is
__Absolutely_Critical__ that you follow the steps outlined in the 
migration guide located at the following URL.
http://www.gentoo.org/doc/en/openrc-migration.xml

FAILURE TO FOLLOW THE MIGRATION GUIDE
CAN RESULT IN AN UNBOOTABLE SYSTEM!

For more information or supprt regarding this change please see the
following:
- link to news item (should contain info regarding where to obtain support)
- link to recover-system guide
- link to handbook

Re: [gentoo-dev] Re: openrc portage news item

[Dale]

Matthew Summers wrote:
> Hi,
>
> I have a few suggestions regarding this major change to Gentoo systems.
>
> 1. We should determine and then announce the precise date (appears to
> be in May) and time that baselayout-2 will be stabilized via:
>    1.1 A front page News item on www.g.o (PR team assemble!),
>    1.2 The main MLs (gentoo-announce, gentoo-users, etc),
>    1.3 Add a link to the www news item to /topic in #gentoo, and
>    1.4 Post a sticky topic in the Forum.
> all in addition to the eselect news item under discussion here. The
> above would link to the migration guide too.
>
> The rationale for this effort at getting the word out is to prevent
> users from hosing their system(s). While I tend to agree that users
> should read these eselect news items, its often not the case.
> Therefore I recommend shooting for the widest possible distribution of
> this information. Also, this gives PR a chance to let the world know
> about openrc and its benefits to Gentoo.
>
> 2. We should prepare a quick "recover-your-system" guide (could also
> create a script too) that can be quickly linked to for user support.
> This will save time for people providing support via IRC, email, etc,
> and give people a reasonable means of system recovery without huge
> pain.
>
> 3. Update the handbook to reflect these changes as soon as possible,
> and have that all go public simultaneously with the stabilization.
>
> 4. I have attached an edited and unfinished version of the original
> news item for review. I attempted to be succinct.
>
> This is a really exciting and potentially also rather
> anxiety-provoking change for our user base and Gentoo. We all know
> that the new baselayout is awesome, and users will find out soon
> enough. We simply need to make our best effort at easing the
> transition so we minimize the number of casualties.
>
> Thank you,
> Matt
>    

I wouldn't mind seeing this on the main Gentoo page as soon as 
possible.  Some people may not visit the Gentoo page very often, I'm one 
of those.  This could be done even if it has to be changed as things 
update.  Maybe one that it is coming and one a few days before it hits 
stable in the tree.

+1 on this being a good idea.  This is a really important update since 
it can cause a system to be unbootable.  I'm thinking about folks that 
may admin a box remotely too.

If all the above is done and people miss that it is coming, I think it 
could safely be said that everything that could be done was done to 
inform people.  The list above includes about every means of 
communication Gentoo has.

Great post.

Dale

:-)  :-)

Re: [gentoo-dev] Re: openrc portage news item

[William Hubbs]

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

Hi Matt,


On Thu, Apr 14, 2011 at 10:41:23AM -0500, Matthew Summers wrote:
> 1. We should determine and then announce the precise date (appears to
> be in May) and time that baselayout-2 will be stabilized via:
>   1.1 A front page News item on www.g.o (PR team assemble!),
>   1.2 The main MLs (gentoo-announce, gentoo-users, etc),
>   1.3 Add a link to the www news item to /topic in #gentoo, and
>   1.4 Post a sticky topic in the Forum.
> all in addition to the eselect news item under discussion here. The
> above would link to the migration guide too.

The problem is that the date is still subject to change. If we get more
bugs that we think should block stabilization, those would be fixed,
then a new release put out, then we are back to waiting 30 days unless
we make an exception to the 30 day rule.

> 2. We should prepare a quick "recover-your-system" guide (could also
> create a script too) that can be quickly linked to for user support.
> This will save time for people providing support via IRC, email, etc,
> and give people a reasonable means of system recovery without huge
> pain.
 
 As far as I know, the only thing that can go wrong here is rebooting
 after installing bl2/openrc without following the migration guide. If
 you do that, the only thing you can do is boot a live cd, chroot into
 the system and follow the migration guide from there.

There's not really a way I know of that we could write a script to do
that.

> 3. Update the handbook to reflect these changes as soon as possible,
> and have that all go public simultaneously with the stabilization.

There is a bug that is blocked by the tracker for this.

> 4. I have attached an edited and unfinished version of the original
> news item for review. I attempted to be succinct.

Ok, I took your news item, and I'll look it over. I may add more to it
about what will happen if you do not follow the migration guide.


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

Re: [gentoo-dev] openrc portage news item

[Kfir Lavi]

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

On Wed, Apr 13, 2011 at 9:15 PM, William Hubbs <williamh@gentoo.org> wrote:

> All,
>
> this is the portage news item I am planning on committing to the tree.
>
> This is based on an earlier version written by Christian Fallhammer.
>
> If there are no suggestions for additions or corrections, this will be
> committed on 5/1.
>
> Thanks,
>
> William
>
>
Hi,
When i run world update, I usually don't really check all the written stuff.

If I do this, I'm sure a lot more Gentoo users do the same.
So do expect people rebooting the machine without checking what your have
wrote.
This can be a major headache if you have few systems that are doing auto
updates.
I would solve this issue by stopping the emerge and getting the attention of
the user.
If I don't get the attention of the user, no openrc will be installed.
It should be something like emerge -C ... 1 .2 3 4 5...

To conclude, you can't issue such a change without proper confirmation from
the user.

Regards,
Kfir

[-- Attachment #2: Type: text/html, Size: 1412 bytes --]

Re: [gentoo-dev] openrc portage news item

[Kfir Lavi]

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

On Wed, Apr 13, 2011 at 9:15 PM, William Hubbs <williamh@gentoo.org> wrote:

> All,
>
> this is the portage news item I am planning on committing to the tree.
>
> This is based on an earlier version written by Christian Fallhammer.
>
> If there are no suggestions for additions or corrections, this will be
> committed on 5/1.
>
> Thanks,
>
> William
>
>
Hi,
When i run world update, I usually don't really check all the written stuff.

If I do this, I'm sure a lot more Gentoo users do the same.
So do expect people rebooting the machine without checking what your have
wrote.
This can be a major headache if you have few systems that are doing auto
updates.
I would solve this issue by stopping the emerge and getting the attention of
the user.
If I don't get the attention of the user, no openrc will be installed.
It should be something like emerge -C ... 1 .2 3 4 5...

To conclude, you can't issue such a change without proper confirmation from
the user.

Regards,
Kfir

[-- Attachment #2: Type: text/html, Size: 1412 bytes --]

Re: [gentoo-dev] openrc portage news item

[Tomá? Chvátal]

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

On Thursday 14 of April 2011 13:32:04 Kfir Lavi wrote:
> When i run world update, I usually don't really check all the written stuff.
> 
> If I do this, I'm sure a lot more Gentoo users do the same.
> So do expect people rebooting the machine without checking what your have
> wrote.
> This can be a major headache if you have few systems that are doing auto
> updates.
> I would solve this issue by stopping the emerge and getting the attention of
> the user.
> If I don't get the attention of the user, no openrc will be installed.
> It should be something like emerge -C ... 1 .2 3 4 5...
> 
> To conclude, you can't issue such a change without proper confirmation from
> the user.
> 
This was discussed multiple times, news items are to be read.
Users ignore elog informations/web announcements/... so it was agreed that 
news item is agressive enough to user so they must read it.
If they don't do so it is just their fault.
And no runtime changing for portage where it expect some input is seriously 
stupid idea, most of us script updates in batch and noone would actualy read 
it.

Never the less as I said we expect user to read that stuff and if he does not 
he is on his own due to his dumb approach.
-- 
Tomáš Chvátal
Gentoo Linux Developer [Cluster/Council/KDE/QA/Sci/X11]
E-Mail          : scarabeus@gentoo.org
GnuPG FP        : 94A4 5CCD 85D3 DE24 FE99 F924 1C1E 9CDE 0341 4587
GnuPG ID        : 03414587


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

Re: [gentoo-dev] openrc portage news item

[Pacho Ramos]

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

El jue, 14-04-2011 a las 12:51 +0200, Tomá? Chvátal escribió:
> On Thursday 14 of April 2011 13:32:04 Kfir Lavi wrote:
> > When i run world update, I usually don't really check all the written stuff.
> > 
> > If I do this, I'm sure a lot more Gentoo users do the same.
> > So do expect people rebooting the machine without checking what your have
> > wrote.
> > This can be a major headache if you have few systems that are doing auto
> > updates.
> > I would solve this issue by stopping the emerge and getting the attention of
> > the user.
> > If I don't get the attention of the user, no openrc will be installed.
> > It should be something like emerge -C ... 1 .2 3 4 5...
> > 
> > To conclude, you can't issue such a change without proper confirmation from
> > the user.
> > 
> This was discussed multiple times, news items are to be read.
> Users ignore elog informations/web announcements/... so it was agreed that 
> news item is agressive enough to user so they must read it.
> If they don't do so it is just their fault.
> And no runtime changing for portage where it expect some input is seriously 
> stupid idea, most of us script updates in batch and noone would actualy read 
> it.
> 
> Never the less as I said we expect user to read that stuff and if he does not 
> he is on his own due to his dumb approach.

I also thought about this problem: I usually read news items before
updating, but I have also seen how other people with root access to
other machines I mainly maintain forget from time to time to do so. 

This is why I opened:
http://bugs.gentoo.org/show_bug.cgi?id=363567

As news items are really there to be read BEFORE updating, I think that
it should be enforced to prevent people from updating before reading
them (I have also read Lars comment, I obviously have no problem at all
with adding some option to revert this behavior, but I still think
default behavior should be to prevent update if news items are not
read).


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

Re: [gentoo-dev] openrc portage news item

[Thomas Beierlein]

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

On Thu, 14 Apr 2011 12:51:55 +0200
Tomá? Chvátal <scarabeus@gentoo.org> wrote:

> On Thursday 14 of April 2011 13:32:04 Kfir Lavi wrote:
> > When i run world update, I usually don't really check all the
> > written stuff.
> > 
> > If I do this, I'm sure a lot more Gentoo users do the same.
> > So do expect people rebooting the machine without checking what
> > your have wrote.
> > This can be a major headache if you have few systems that are doing
> > auto updates.
> > I would solve this issue by stopping the emerge and getting the
> > attention of the user.
> > If I don't get the attention of the user, no openrc will be
> > installed. It should be something like emerge -C ... 1 .2 3 4 5...
> > 
> > To conclude, you can't issue such a change without proper
> > confirmation from the user.
> > 
> This was discussed multiple times, news items are to be read.
> Users ignore elog informations/web announcements/... so it was agreed
> that news item is agressive enough to user so they must read it.
> If they don't do so it is just their fault.
> And no runtime changing for portage where it expect some input is
> seriously stupid idea, most of us script updates in batch and noone
> would actualy read it.
> 
> Never the less as I said we expect user to read that stuff and if he
> does not he is on his own due to his dumb approach.

Maybe we should underline our intention by having that policy
documented in the installation handbook. A good place may be section 2
"Working with
Gentoo" (http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2).

At least all newbies will stumble upon it once.

Regards,
	Thomas.

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

Re: [gentoo-dev] openrc portage news item

[Sylvain Alain]

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

2011/4/14 Thomas Beierlein <tomjbe@gentoo.org>

> On Thu, 14 Apr 2011 12:51:55 +0200
> Tomá? Chvátal <scarabeus@gentoo.org> wrote:
>
> > On Thursday 14 of April 2011 13:32:04 Kfir Lavi wrote:
> > > When i run world update, I usually don't really check all the
> > > written stuff.
> > >
> > > If I do this, I'm sure a lot more Gentoo users do the same.
> > > So do expect people rebooting the machine without checking what
> > > your have wrote.
> > > This can be a major headache if you have few systems that are doing
> > > auto updates.
> > > I would solve this issue by stopping the emerge and getting the
> > > attention of the user.
> > > If I don't get the attention of the user, no openrc will be
> > > installed. It should be something like emerge -C ... 1 .2 3 4 5...
> > >
> > > To conclude, you can't issue such a change without proper
> > > confirmation from the user.
> > >
> > This was discussed multiple times, news items are to be read.
> > Users ignore elog informations/web announcements/... so it was agreed
> > that news item is agressive enough to user so they must read it.
> > If they don't do so it is just their fault.
> > And no runtime changing for portage where it expect some input is
> > seriously stupid idea, most of us script updates in batch and noone
> > would actualy read it.
> >
> > Never the less as I said we expect user to read that stuff and if he
> > does not he is on his own due to his dumb approach.
>
> Maybe we should underline our intention by having that policy
> documented in the installation handbook. A good place may be section 2
> "Working with
> Gentoo" (http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2).
>
> At least all newbies will stumble upon it once.
>
> Regards,
>         Thomas.
>

Yeah, before the stabilization of OpenRc and Baselayout 2.x, the Gentoo
handbook really need to be updated too.

I don't see how a newbie should be able to install his box with an outdated
handbook.

-- 
Salut
alp
Sylvain

[-- Attachment #2: Type: text/html, Size: 2764 bytes --]

Re: [gentoo-dev] openrc portage news item

[Donnie Berkholz]

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

On 13:32 Thu 14 Apr     , Kfir Lavi wrote:
> When i run world update, I usually don't really check all the written 
> stuff.
> 
> If I do this, I'm sure a lot more Gentoo users do the same. So do 
> expect people rebooting the machine without checking what your have 
> wrote. This can be a major headache if you have few systems that are 
> doing auto updates. I would solve this issue by stopping the emerge 
> and getting the attention of the user. If I don't get the attention of 
> the user, no openrc will be installed. It should be something like 
> emerge -C ... 1 .2 3 4 5...
> 
> To conclude, you can't issue such a change without proper confirmation from
> the user.

I know this is the case. You're going to get literally thousands of 
people (or more) who break their Gentoo systems if that indeed is the 
consequence of not reading the migration guide and doing some action. 

From a glance over the guide, it wasn't immediately obvious what in 
there would result in a broken system. Perhaps it's the "run 
dispatch-conf" that's buried in the middle of a paragraph without enough 
emphasis? That's particularly confusing for people who use etc-update 
instead, and it *needs* to move somewhere more obvious like a separate 
code listing with big <important> tags and bold text. The line of red 
text just isn't enough, it needs to stand out even more.

It seems like nobody's really clear on what exactly happens though, 
since I've seen people talking about this *maybe* resulting in an 
unbootable system. Has anyone tested it?

One potential cleaner approach to the same idea Kfir suggested is to 
make it an interactive emerge with an ACCEPT_LICENSE-like feature that 
pops up something you must read and agree to.

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com

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

Re: [gentoo-dev] openrc portage news item

[Jeroen Roovers]

On Wed, 20 Apr 2011 20:12:21 -0500
Donnie Berkholz <dberkholz@gentoo.org> wrote:

> From a glance over the guide, it wasn't immediately obvious what in 
> there would result in a broken system. Perhaps it's the "run 
> dispatch-conf" that's buried in the middle of a paragraph without
> enough emphasis? That's particularly confusing for people who use
> etc-update instead, and it *needs* to move somewhere more obvious
> like a separate code listing with big <important> tags and bold text.
> The line of red text just isn't enough, it needs to stand out even
> more.

I have converted all my systems to baselayout-2/openrc now, and on all
of them, the very /last/ message shown after the emerge run is that "[x]
important configuration files [in /etc]" need to be updated.

I would think that Gentoo users are already primed to this message and
that they would respond accordingly. Even when it's dozens of packages
you have updated, this message should stand out, because it's basically
the first one you read scrolling back up.

> One potential cleaner approach to the same idea Kfir suggested is to 
> make it an interactive emerge with an ACCEPT_LICENSE-like feature
> that pops up something you must read and agree to.

I've been thinking about an openrc mechanism that refuses rebooting
(reboot, halt, which are calls that openrc handles)
when /etc/{conf,init}.d files have not been updated. Anyone game to get
coding? :)


     jer

Re: [gentoo-dev] openrc portage news item

[Jeroen Roovers]

On Thu, 21 Apr 2011 04:23:19 +0200
Jeroen Roovers <jer@gentoo.org> wrote:

> I have converted all my systems to baselayout-2/openrc now, and on all
> of them, the very /last/ message shown after the emerge run is that
> "[x] important configuration files [in /etc]" need to be updated.
> 
> I would think that Gentoo users are already primed to this message and
> that they would respond accordingly. Even when it's dozens of packages
> you have updated, this message should stand out, because it's
> basically the first one you read scrolling back up.

Adding to that, the appropriate response is to not file a bug report or
complain otherwise, but to bow your head in shame, bring the system up
with some kind of boot medium and chroot in to run your favourite /etc
updating tool, then reboot cleanly and be running again.


     jer

Re: [gentoo-dev] openrc portage news item

[Lars Wendler]

[-- Attachment #1: Type: Text/Plain, Size: 3099 bytes --]

-- 
Lars Wendler (Polynomial-C)
Gentoo package maintainer and bug-wrangler

Am Donnerstag 21 April 2011, 03:12:21 schrieb Donnie Berkholz:
> On 13:32 Thu 14 Apr     , Kfir Lavi wrote:
> > When i run world update, I usually don't really check all the written
> > stuff.
> > 
> > If I do this, I'm sure a lot more Gentoo users do the same. So do
> > expect people rebooting the machine without checking what your have
> > wrote. This can be a major headache if you have few systems that are
> > doing auto updates. I would solve this issue by stopping the emerge
> > and getting the attention of the user. If I don't get the attention of
> > the user, no openrc will be installed. It should be something like
> > emerge -C ... 1 .2 3 4 5...
> > 
> > To conclude, you can't issue such a change without proper confirmation
> > from the user.
> 
> I know this is the case. You're going to get literally thousands of
> people (or more) who break their Gentoo systems if that indeed is the
> consequence of not reading the migration guide and doing some action.
> 
> From a glance over the guide, it wasn't immediately obvious what in
> there would result in a broken system. Perhaps it's the "run
> dispatch-conf" that's buried in the middle of a paragraph without enough
> emphasis? That's particularly confusing for people who use etc-update
> instead, and it *needs* to move somewhere more obvious like a separate
> code listing with big <important> tags and bold text. The line of red
> text just isn't enough, it needs to stand out even more.
> 
> It seems like nobody's really clear on what exactly happens though,
> since I've seen people talking about this *maybe* resulting in an
> unbootable system. Has anyone tested it?

I didn't test it intentionally. The last time I accidently rebooted a system 
freshly moved to bl-2/openrc without updating the config files the boot process 
threw a couple of strange errors. I cannot exactly remember what kind of 
errors that were but the result was a system hanging in the middle of the boot 
process with a message similar to "nothing left to do in this runlevel" and I 
wasn't able to log into the system.
Another problem I've once encountered after updating a system to use openrc 
was no running udev daemon after boot. I first didn't notice this but X didn't 
start and funny part was that X won't tell you it cannot start because the 
devicenodes in /dev for the graphics card were missing. So took me nearly a 
day of frustrating research until I found that the udev init script wasn't 
added to the sysinit runlevel. Of course this is mentioned in the migration 
guide but it should be explicitly pointed out how fatal this can be to not 
have udev getting started.

I can offer to "abuse" my two stable VMs (amd64 / x86) for this to test if 
there's interest in getting "exact results".  :)

> One potential cleaner approach to the same idea Kfir suggested is to
> make it an interactive emerge with an ACCEPT_LICENSE-like feature that
> pops up something you must read and agree to.


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

Re: [gentoo-dev] openrc portage news item

[Brian Harring]

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

On Fri, Apr 22, 2011 at 12:39:04PM +0200, Lars Wendler wrote:
> Am Donnerstag 21 April 2011, 03:12:21 schrieb Donnie Berkholz:
> > It seems like nobody's really clear on what exactly happens though,
> > since I've seen people talking about this *maybe* resulting in an
> > unbootable system. Has anyone tested it?
> 
> I didn't test it intentionally. The last time I accidently rebooted a system 
> freshly moved to bl-2/openrc without updating the config files the boot process 
> threw a couple of strange errors. I cannot exactly remember what kind of 
> errors that were but the result was a system hanging in the middle of the boot 
> process with a message similar to "nothing left to do in this runlevel" and I 
> wasn't able to log into the system.
> Another problem I've once encountered after updating a system to use openrc 
> was no running udev daemon after boot. I first didn't notice this but X didn't 
> start and funny part was that X won't tell you it cannot start because the 
> devicenodes in /dev for the graphics card were missing. So took me nearly a 
> day of frustrating research until I found that the udev init script wasn't 
> added to the sysinit runlevel. Of course this is mentioned in the migration 
> guide but it should be explicitly pointed out how fatal this can be to not 
> have udev getting started.
> 
> I can offer to "abuse" my two stable VMs (amd64 / x86) for this to test if 
> there's interest in getting "exact results".  :)

Exact results please; the pkg_pretend crap proposed elsewhere (which 
is yet another way to crap up stage builds) frankly sucks.

Mind you I'm just looking in, but this whole upgrade process really 
reads fairly suboptimal to me.  It's definitely possible that this is 
the best that can be done, but I'd like to see exactly which issues we 
can't resolve in some fashion via pkg_postinst tricks w/in openrc.

I'd much rather have an ebuild that violates a few rules than forced 
"you must accept this beyond normal mechanisms" and potential "can't 
boot" upgrade processes.

So... details please, and why we can't script our way past chunks of 
this. :)
~brian

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

Re: [gentoo-dev] openrc portage news item

[William Hubbs]

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

On Fri, Apr 29, 2011 at 11:41:35AM -0700, Brian Harring wrote:
> Exact results please; the pkg_pretend crap proposed elsewhere (which 
> is yet another way to crap up stage builds) frankly sucks.
> 
> Mind you I'm just looking in, but this whole upgrade process really 
> reads fairly suboptimal to me.  It's definitely possible that this is 
> the best that can be done, but I'd like to see exactly which issues we 
> can't resolve in some fashion via pkg_postinst tricks w/in openrc.
>
> I'd much rather have an ebuild that violates a few rules than forced 
> "you must accept this beyond normal mechanisms" and potential "can't 
> boot" upgrade processes.
>
> So... details please, and why we can't script our way past chunks of 
> this. :)

The biggest part of the migration is running dispatch-conf, etc-update
or another configuration file updater and accepting all of the openrc
changes.  Most of the stuff in the migration guide is just directing
you to verify changes that the openrc ebuild has made and telling you
which configuration files may need to be altered to match your system.
I'm not sure how to script passed any of that.

William


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

Re: [gentoo-dev] openrc portage news item

[Brian Harring]

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

On Fri, Apr 29, 2011 at 09:19:50PM -0500, William Hubbs wrote:
> On Fri, Apr 29, 2011 at 11:41:35AM -0700, Brian Harring wrote:
> > Exact results please; the pkg_pretend crap proposed elsewhere (which 
> > is yet another way to crap up stage builds) frankly sucks.
> > 
> > Mind you I'm just looking in, but this whole upgrade process really 
> > reads fairly suboptimal to me.  It's definitely possible that this is 
> > the best that can be done, but I'd like to see exactly which issues we 
> > can't resolve in some fashion via pkg_postinst tricks w/in openrc.
> >
> > I'd much rather have an ebuild that violates a few rules than forced 
> > "you must accept this beyond normal mechanisms" and potential "can't 
> > boot" upgrade processes.
> >
> > So... details please, and why we can't script our way past chunks of 
> > this. :)
> 
> The biggest part of the migration is running dispatch-conf, etc-update
> or another configuration file updater and accepting all of the openrc
> changes.

Yeah, with respect this is the hand wavey part I wanted details for.  
I wanted to know *which* files were incompatible in conf differences, 
things like that.  From the sounds of it, the main concern is a set of 
files moving (including their format), and CONFIG_PROTECT firing- it 
takes some planning, but it's possible to work around this (suppress 
it if needs be) or do pkg_postinst tricks outside the PM's normal 
protections for it.


> Most of the stuff in the migration guide is just directing
> you to verify changes that the openrc ebuild has made and telling you
> which configuration files may need to be altered to match your system.
> I'm not sure how to script passed any of that.

Migration of settings from /etc/conf.d/rc to /etc/rc strikes me as 
pretty damn scriptable, within limits- I've not used non-openrc for a 
*long* time, but the settings are basically booleans or simple string.  
Just requires a mapping of conf.d/rc:value -> rc:value .

Kernel modules, no different.

Checking the boot levels, udev included, same thing- if ROOT=/ and 
baselayout is there already you likely *could* look at the running 
system to see what's needed/in use, and kick rc-update as needed for 
spots where it *isn't*.

So... yeah, scriptable, at least from where I'm sitting.  To do it, 
need to snapshot that info, and kick it via pkg_postinst.

I realize it's more work, but I'm frankly a bit concerned this isn't 
beng looked at ("you must run etc-update" isn't the level of detail I 
expected neither), nor trying very, very hard to remove the potential 
of non-bootable system here- trying to rely on pkg_pretend nastyness 
just sidesteps it and introduces other issues.

Again, I'm aware it may not be possible, but sharing the details of 
why this it *isn't* an option would be rather useful.

Cheers-
~brian

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

[gentoo-dev] Re: openrc portage news item

[Duncan]

Brian Harring posted on Fri, 29 Apr 2011 21:59:45 -0700 as excerpted:

> Checking the boot levels, udev included, same thing- if ROOT=/ and
> baselayout is there already you likely *could* look at the running
> system to see what's needed/in use, and kick rc-update as needed for
> spots where it *isn't*.

Um... 32-bit chroots for amd64 comes to mind, tho that's just a single 
supported case of the general idea.  Here, I've adapted the idea slightly 
by simply installing a complete system to the chroot, just never actually 
/running/ it from there, as a maintained system image that was initially 
transferred to USB, now updated thru rsync, for my netbook.

Portage's ROOT is unchanged in these cases, but depending on how the 
detection of the running system is achieved, the script might attempt 
changes based on the components of the 64-bit HOST system, not the 32-bit 
chroot system image, or conversely, changes inappropriate for an image 
that never actually boots on its host system.  That would *NOT* be a good 
thing!

So any such detection would have to be based on far more than the setting 
for ROOT and existence of baselayout.

Meanwhile, all this is a rather nice idea in theory, but with literally 
days left before pulling the trigger, now's rather late in the game to 
bring the suggestion.  Development and proper testing of such a script 
would certainly take months, at least.  This whole idea, suggested now, 
seems to me to be a rather advanced case of letting the perfect be the 
enemy of the far better but nobody claiming perfect.  The time for such a 
suggestion would have been several months ago when the final push toward 
stabilization and development of the final migration technique was 
announced.  And certainly, trying to shove the required development and 
testing into anything less something like six more months reasonable 
minimum, is folly indeed.  Meanwhile, existing stable gets further and 
further behind and harder to maintain, and Gentoo looks more and more 
"legacy".

Are you actually trying to delay the upgrade to OpenRC /forever/?  Why?  
There's other questions I could ask but there ARE things worse than 
unasked questions.  I'm seriously fighting the urge to go there as that 
bit of list history is something that doesn't need repeated, for sure.

Meanwhile, Gentoo has always been about expecting Gentoo's users to take 
responsibility as their own sysadmins.  Yes, we document, and automate 
where reasonably possible, but there's a reason for etc-update, dispatch-
conf, etc.  This is as good a case for letting Gentoo users take ultimate 
responsibility as admins on their own systems as it gets.  We've waited 
long enough.  The guides are ready.  The systems are ready.  The warnings 
are ready.  Now it's time to pull that trigger.

-- 
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: openrc portage news item

[Brian Harring]

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

On Sat, Apr 30, 2011 at 07:13:59AM +0000, Duncan wrote:
> Brian Harring posted on Fri, 29 Apr 2011 21:59:45 -0700 as excerpted:
> 
> > Checking the boot levels, udev included, same thing- if ROOT=/ and
> > baselayout is there already you likely *could* look at the running
> > system to see what's needed/in use, and kick rc-update as needed for
> > spots where it *isn't*.
> 
> Um... 32-bit chroots for amd64 comes to mind, tho that's just a single 
> supported case of the general idea.  Here, I've adapted the idea slightly 
> by simply installing a complete system to the chroot, just never actually 
> /running/ it from there, as a maintained system image that was initially 
> transferred to USB, now updated thru rsync, for my netbook.

What I'm suggesting is mangling the default configs that get pushed in 
via postinst to reflect the old configs for the spots where it's 
necessary.  The 32bit/64bit scenario there still is addressable- scan 
the pre-existing rc-update show.  If you're just chroot'ing into the 
sucker without kicking any services within it, you're unaffected 
either way if it rc-update's a couple of services- you weren't 
starting the services in the /first/ place after all, so no further 
fall out.

If you were starting services, udev for example, spotting that and 
transferring it across isn't hard.

It's actually slightly more complex than that to track the settings 
from setup through postinst, but that's implementation details, 
secondary issue to my original question.


> Portage's ROOT is unchanged in these cases, but depending on how the 
> detection of the running system is achieved, the script might attempt 
> changes based on the components of the 64-bit HOST system, not the 32-bit 
> chroot system image, or conversely, changes inappropriate for an image 
> that never actually boots on its host system.  That would *NOT* be a good 
> thing!

Already outlined above how this interpretation is incorrect.  It's 
basically identification of scenarios- your posited (presumably what 
you run locally since you seem fairly heated about it) scenario looks 
like it still would fly due to pre-existing configuration being 
referencable- or you weren't actually configuring it in full, nor 
running the services from w/in it, so it's a non issue anyways.

Either way, I did not say it was necessarily simple; I'm fundamentally 
asking why those potentials, from the rough look of it, were ruled 
out.

If they were considered, then it should be reasonably easy to point 
folks at bugs/discussions clarifying why it wasn't considered viable.

32bit chroot is one example of where it might be dicey, although 
frankly I still consider that deployment a bit whacked on it's own.  
I'm looking for more than just that however


> Meanwhile, all this is a rather nice idea in theory, but with literally 
> days left before pulling the trigger, now's rather late in the game to 
> bring the suggestion.

It's an arbitrary deadline.  To be clear, it's an arbitrary deadline 
that has a horrid ass set of "do these things or your system is 
fubared", plus that pkg_pretend frankly is a different form of 
horrible beyond that.

While late in the game, frankly it just came to the attention- I've 
ran openrc basically since day 1.  It crossed the radar only recently
due to the desired announcement requesting feedback- which means 
feedback on the change itself, fundamentally. 

Regardless, what you're offering up here is deflections/excuses to 
just do it.  Which... frankly, that's fine.  If that's peoples 
decision in full, fine, they own that decision.

If the potentials weren't explored, it would be useful *knowing* so 
looking at reducing the pain can be done- if they *were* explored and 
discarded, then it saves folks the time of digging into it further.

Simple enough.


> Are you actually trying to delay the upgrade to OpenRC /forever/?  Why?  

Chill the hell down.  I didn't kick your puppy, nor did I steal your 
lunch money in 7th grade.  I may have mocked your 'flock of seagulls' 
haircut (or 'bieber' haircut for the younguns), but they're stupid 
haircuts- it was deserved ;)

Joke aside, I asked a valid question.  Rhetorical nonsense isn't a 
valid response, nor useful.


> Meanwhile, Gentoo has always been about expecting Gentoo's users to take 
> responsibility as their own sysadmins.  Yes, we document, and automate 
> where reasonably possible, but there's a reason for etc-update, dispatch-
> conf, etc.

While that's a fun quotation to use, you basically just aligned with 
exactly why I'm asking this.  Yes, users must function as the 
sysadmin/SA of their system.

A proper SA avoids upgrade pathways were possible that require 
manual intervention.  This requires manual intervention.

Said proper SA's also have a rather large hatred of anything that can 
leave a system nonbootable (rant: including crappy SA's who don't 
verify the !@#*ing thing comes back up in a proper hot/warm state).  
This qualifies for that.

Again, not saying this approach can't be taken if needed- I'm asking 
what alternatives were ruled out in getting to this point.

~brian

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

Re: [gentoo-dev] Re: openrc portage news item

[Rich Freeman]

On Sat, Apr 30, 2011 at 7:46 AM, Brian Harring <ferringb@gmail.com> wrote:
> A proper SA avoids upgrade pathways were possible that require
> manual intervention.  This requires manual intervention.
>
> Said proper SA's also have a rather large hatred of anything that can
> leave a system nonbootable (rant: including crappy SA's who don't
> verify the !@#*ing thing comes back up in a proper hot/warm state).
> This qualifies for that.

This will be far from the first Gentoo upgrade which has required
either manual intervention, or which leaves the system in a
potentially-unbootable state.  Gentoo just generally doesn't offer the
level of handholding that you are asking for.  Users who want that
kind of experience may be better off with RHEL or another platform.

I think we need a reasonable balance here.  From what I've seen the
openrc upgrade seems pretty straightforward.  The only caveat is that
you need to read the instructions before doing it.  Nervous users
should burn rescue discs in advance.

I think the important thing is to widely announce the upgrade.  The
maintainers intend to do exactly this.  I have complained in the past
when maintainers have made disruptive changes without notice, or with
notice committed at the same time as the change (which means that if
your emerge --sync is in a cron job you first hear about it AFTER
running emerge -au world).  This isn't being done here.

I'm afraid that if we set the bar as high as you're proposing, then
nobody will ever get around to providing an Ubuntu-like level of
polish or whatever and we'll just end up with two baselayouts for the
next five years.  Keep in mind that ~arch having such major
differences from stable defeats some of the purpose of testing.  Sure,
if somebody worked hard I'm sure they could meet your level of polish
in a few weeks, but unless you're personally willing to do it I'm not
sure that the maintainers are going to be willing - this is a
volunteer organization so when you say "do it this way or don't do it
at all" you're more likely to get the latter than the former.

My feeling is that the openrc upgrade fragility is in keeping with the
general traditions of Gentoo - we expect Gentoo users to be reasonably
willing to get their hands dirty.  I'm more concerned with making sure
our users are INFORMED than hand-held.

And as far as "proper SAs" go - a "proper SA" always deploys changes
on a production-equivalent test environment anyway.  Most "proper SAs"
also make backups and VM snapshots so that a borked upgrade is just a
bump in the road.  "Proper SAs" also run on managed hardware so that
they can boot off of a rescue disc without being physically present.
Most of these "Proper SAs" also run RHEL anyway.  :)

Rich

Re: [gentoo-dev] Re: openrc portage news item

[Brian Harring]

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

On Sat, Apr 30, 2011 at 08:03:43AM -0400, Rich Freeman wrote:

<snip a lot of crap that is ignoring what I've been asking>

Frankly getting fairly annoyed people are immediately taking it to 
the rhel/ubuntu extremes- that is *not* what I asked and is frankly 
a strawman argument.  Occasional pain on upgrades is a given in 
gentoo, although anyone claiming we've not kept an eye on those sharp 
corners is delusional (versioned eapi, etc-update's very existance, 
portage warning on removal of a pkg in the system set, the list goes 
on).  Hell, even the notification mechanism y'all want to use for 
informing is an example of trying to soften those corners were 
possible, rather than precluding their existance.

I asked if we had looked at scripting away some of the upgrade pains.  

It's a pretty simple fucking question requiring either a 5 second 
"no" or 5 minutes of "yes, heres what we looked at, they were deemed 
too painful".  Answering that also is a helluva lot quicker then 
people trading barbs over "we need to release it now" or proper SA; 
while your retort was dead on for what folks should do, it was 
completely unrelated to answering the question I'm *asking*.

If we didn't look into it, that's fine.  Means I've got something to 
poke at over the weekend.

If we did, and it was ruled out, awesome, I have other things on my 
todo list I'll poke at this weekend.

~harring

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

Re: [gentoo-dev] Re: openrc portage news item

[Jeremy Olexa]

On 04/30/2011 07:58 AM, Brian Harring wrote:
> On Sat, Apr 30, 2011 at 08:03:43AM -0400, Rich Freeman wrote:
>
> <snip a lot of crap that is ignoring what I've been asking>
>
> Frankly getting fairly annoyed people are immediately taking it to
> the rhel/ubuntu extremes- that is *not* what I asked and is frankly
> a strawman argument.  Occasional pain on upgrades is a given in
> gentoo, although anyone claiming we've not kept an eye on those sharp
> corners is delusional (versioned eapi, etc-update's very existance,
> portage warning on removal of a pkg in the system set, the list goes
> on).  Hell, even the notification mechanism y'all want to use for
> informing is an example of trying to soften those corners were
> possible, rather than precluding their existance.
>
> I asked if we had looked at scripting away some of the upgrade pains.

This openrc upgrade is the *least* painful Gentoo upgrade I have 
experienced. What a waste of time (IMO) to "script" some defaults.
-Jeremy

>
> It's a pretty simple fucking question requiring either a 5 second
> "no" or 5 minutes of "yes, heres what we looked at, they were deemed
> too painful".  Answering that also is a helluva lot quicker then
> people trading barbs over "we need to release it now" or proper SA;
> while your retort was dead on for what folks should do, it was
> completely unrelated to answering the question I'm *asking*.
>
> If we didn't look into it, that's fine.  Means I've got something to
> poke at over the weekend.
>
> If we did, and it was ruled out, awesome, I have other things on my
> todo list I'll poke at this weekend.
>
> ~harring

Re: [gentoo-dev] Re: openrc portage news item

[Brian Harring]

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

On Sat, Apr 30, 2011 at 08:06:37AM -0500, Jeremy Olexa wrote:
> This openrc upgrade is the *least* painful Gentoo upgrade I have 
> experienced. What a waste of time (IMO) to "script" some defaults.

Basically answering my question- it wasn't considered since it 
ain't worth the time.

Danke- consider it dropped.
~harring

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

Re: [gentoo-dev] openrc portage news item

[William Hubbs]

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

All,

here is an updated version of the news item. If there are no
objections/corrections/criticisms, this will be committed on 2011/5/1.

This includes input from several comments I received on this thread.

Someone suggested that we make emerge not work until the news item is
read. There is nothing I can do in openrc to make something like that
happen. It would be something that would require a portage modification.
Also, that wouldn't really do much for us, because someone could still
read the news item, emerge the packages, then they could still end up
rebooting before they follow the steps, so I don't see what something
like that buys us.

I still do not have a link to the front page news item. If there isn't
one, should I delete the last paragraph before I commit?

Also, the way you can recover if you boot your system before following
the steps is mentioned in the news item now, and there's not really
anything more to it, so I'm not sure where else it should be mentioned.

What does everyone think?

William


[-- Attachment #1.2: 2011-05-01-baselayout-update.en.txt --]
[-- Type: text/plain, Size: 1405 bytes --]

Title: Baselayout update
Author: Christian Faulhammer <fauli@gentoo.org>
Author: William Hubbs <williamh@gentoo.org>
Content-Type: text/plain
Posted: 2011-05-01
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: <sys-apps/baselayout-2

The baselayout package provides files which all systems must have in
order to function properly. You are currently using version 1.x, which
has several issues. The most significant of these is that the included
init scripts are written entirely in bash, which makes them slow and
not very flexible.

On 2011/05/08, you will see an update for sys-apps/baselayout to
2.x and a new package, sys-apps/openrc. It is recommended that you
perform this update as soon as possible.

Please note, after these packages are emerged, it is
__Absolutely_Critical__ that you immediately update your configuration
files with dispatch-conf, etc-update or a similar tool then follow the
steps in the migration guide located at the following URL.
http://www.gentoo.org/doc/en/openrc-migration.xml

FAILURE TO FOLLOW ALL OF THESE STEPS WILL RESULT IN AN UNBOOTABLE
SYSTEM! IF THIS SHOULD HAPPEN, YOU WILL NEED TO BOOT FROM A LIVE CD OR
DVD, MOUNT YOUR ROOT FILE SYSTEM, CHROOT INTO THAT ENVIRONMENT AND
FOLLOW THE ABOVE STEPS!

For more information or support regarding this change please see the
following:
- link to news item (should contain info regarding where to obtain support)

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

Re: [gentoo-dev] openrc portage news item

[Rich Freeman]

On Fri, Apr 29, 2011 at 3:08 AM, William Hubbs <williamh@gentoo.org> wrote:
> Someone suggested that we make emerge not work until the news item is
> read. There is nothing I can do in openrc to make something like that
> happen. It would be something that would require a portage modification.

Honestly - I see that as a future enhancement for portage/PMS/etc, and
not something that should hold up openrc.  There are a number of
situations where such a feature would be useful, and trying to
shoehorn in a hack for openrc doesn't make sense.

Perhaps a future/in-progress EAPI could define a mechanism where an
ebuild can indicate that a particular update or set of circumstances
is a system-critical change, and that the package manager should
consequently alert the user and ensure that they have confirmed the
action.  Then we have a nicely defined interface that we can use for
things like major baselayout changes, gcc/glibc ABI changes, and so
on.

Otherwise the best we can do is widely publicize the change (news,
lists, website, etc).  In this case the news is out a full week before
the update, which I think is good timing (long enough that missing it
is less likely, not so long that forgetting it is likely).

Rich

Re: [gentoo-dev] openrc portage news item

[Ciaran McCreesh]

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

On Fri, 29 Apr 2011 07:21:23 -0400
Rich Freeman <rich0@gentoo.org> wrote:
> Perhaps a future/in-progress EAPI could define a mechanism where an
> ebuild can indicate that a particular update or set of circumstances
> is a system-critical change, and that the package manager should
> consequently alert the user and ensure that they have confirmed the
> action.

pkg_pretend can do that...

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] openrc portage news item

[Alex Alexander]

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

On Fri, Apr 29, 2011 at 12:28:03PM +0100, Ciaran McCreesh wrote:
> On Fri, 29 Apr 2011 07:21:23 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
> > Perhaps a future/in-progress EAPI could define a mechanism where an
> > ebuild can indicate that a particular update or set of circumstances
> > is a system-critical change, and that the package manager should
> > consequently alert the user and ensure that they have confirmed the
> > action.
> 
> pkg_pretend can do that...

indeed. it works quite well too. please have a look at the attached
patch. it forces the user to acknowledge and verify that he has read the
printed message by prepending a variable to the emerge command.

I know it is a bit nasty, but it accomplishes our goal by making sure
the users read the message.

-- 
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com

[-- Attachment #1.2: openrc-0.8.2-r1.ebuild.require.verification.patch --]
[-- Type: text/plain, Size: 1362 bytes --]

Index: openrc-0.8.2-r1.ebuild
===================================================================
RCS file: /var/cvsroot/gentoo-x86/sys-apps/openrc/openrc-0.8.2-r1.ebuild,v
retrieving revision 1.1
diff -u -B -r1.1 openrc-0.8.2-r1.ebuild
--- openrc-0.8.2-r1.ebuild	28 Apr 2011 19:50:51 -0000	1.1
+++ openrc-0.8.2-r1.ebuild	29 Apr 2011 17:10:34 -0000
@@ -2,7 +2,7 @@
 # Distributed under the terms of the GNU General Public License v2
 # $Header: /var/cvsroot/gentoo-x86/sys-apps/openrc/openrc-0.8.2-r1.ebuild,v 1.1 2011/04/28 19:50:51 williamh Exp $
 
-EAPI="1"
+EAPI="4"
 
 inherit eutils flag-o-matic multilib toolchain-funcs
 
@@ -34,6 +34,22 @@
 DEPEND="${RDEPEND}
 	virtual/os-headers"
 
+pkg_pretend() {
+	if [[ -z ${REPLACING_VERSIONS} ]] && [[ ${WARNING_OPENRC} != 1 ]]; then
+		eerror
+		eerror "You're upgrading your system to openrc. After emerge is"
+		eerror "complete, you MUST follow the guide located here:"
+		ewarn "  http://www.gentoo.org/doc/en/openrc-migration.xml"
+		eerror "FAILING TO DO SO WILL PROBABLY RESULT IN AN *NON-BOOTABLE* SYSTEM."
+		eerror
+		eerror "To verify you read and understood this message, please prepend"
+		ewarn "  WARNING_OPENRC=1"
+		eerror "to your emerge command."
+		eerror
+		die "We need user verification to proceed."
+	fi
+}
+
 make_args() {
 	unset LIBDIR #266688
 

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] openrc portage news item

[Ulrich Mueller]

>>>>> On Fri, 29 Apr 2011, Alex Alexander wrote:

> please have a look at the attached patch.

> -EAPI="1"
> +EAPI="4"

Shouldn't the ebuild's phase functions be updated from "EAPI 0 style"
to "EAPI 2 style" too?

Ulrich

Re: [gentoo-dev] openrc portage news item

[Alex Alexander]

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

On Fri, Apr 29, 2011 at 07:25:12PM +0200, Ulrich Mueller wrote:
> >>>>> On Fri, 29 Apr 2011, Alex Alexander wrote:
> 
> > please have a look at the attached patch.
> 
> > -EAPI="1"
> > +EAPI="4"
> 
> Shouldn't the ebuild's phase functions be updated from "EAPI 0 style"
> to "EAPI 2 style" too?

Yeah :)

My goal was to see that the idea actually works as intended and get
feedback from the list so I didn't make it that far.

-- 
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] openrc portage news item

[Rich Freeman]

On Fri, Apr 29, 2011 at 1:25 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>> On Fri, 29 Apr 2011, Alex Alexander wrote:
>
>> please have a look at the attached patch.
>
>> -EAPI="1"
>> +EAPI="4"
>
> Shouldn't the ebuild's phase functions be updated from "EAPI 0 style"
> to "EAPI 2 style" too?

If the goal is to get this stable in a week, and bypass the 1 month
waiting period, do we really want to change EAPI at this point?  From
an end-user perspective updating the EAPI on the ebuild provides no
benefit.  Why not just deal with that in a future revision?

I don't see much value in rewriting the ebuild to use a new EAPI
simply because 4 > 1.

Rich

Re: [gentoo-dev] openrc portage news item

[Alex Alexander]

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

On Fri, Apr 29, 2011 at 01:52:15PM -0400, Rich Freeman wrote:
> On Fri, Apr 29, 2011 at 1:25 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
> >>>>>> On Fri, 29 Apr 2011, Alex Alexander wrote:
> >
> >> please have a look at the attached patch.
> >
> >> -EAPI="1"
> >> +EAPI="4"
> >
> > Shouldn't the ebuild's phase functions be updated from "EAPI 0 style"
> > to "EAPI 2 style" too?
> 
> If the goal is to get this stable in a week, and bypass the 1 month
> waiting period, do we really want to change EAPI at this point?  From
> an end-user perspective updating the EAPI on the ebuild provides no
> benefit.  Why not just deal with that in a future revision?
> 
> I don't see much value in rewriting the ebuild to use a new EAPI
> simply because 4 > 1.

EAPI was bumped so I could use pkg_pretend, please check out my
(incomplete) patch.

-- 
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] openrc portage news item

[William Hubbs]

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

On Fri, Apr 29, 2011 at 08:58:31PM +0300, Alex Alexander wrote:
> On Fri, Apr 29, 2011 at 01:52:15PM -0400, Rich Freeman wrote:
> > On Fri, Apr 29, 2011 at 1:25 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
> > >>>>>> On Fri, 29 Apr 2011, Alex Alexander wrote:
> > >
> > >> please have a look at the attached patch.
> > >
> > >> -EAPI="1"
> > >> +EAPI="4"
> > >
> > > Shouldn't the ebuild's phase functions be updated from "EAPI 0 style"
> > > to "EAPI 2 style" too?
> > 
> > If the goal is to get this stable in a week, and bypass the 1 month
> > waiting period, do we really want to change EAPI at this point?  From
> > an end-user perspective updating the EAPI on the ebuild provides no
> > benefit.  Why not just deal with that in a future revision?
> > 
> > I don't see much value in rewriting the ebuild to use a new EAPI
> > simply because 4 > 1.
> 
> EAPI was bumped so I could use pkg_pretend, please check out my
> (incomplete) patch.

I don't remember the details  right now, but I remember speaking with
vapier when I first started working on openrc, and he stated that he
felt we should stay away from higher eapis for system packages.

I don't really remember his reasoning for that right now, but I remember
that is why I didn't migrate the ebuild to a higher eapi a while back.

Also, this patch doesn't stop baselayout-2 from being installed, so I do
not know what state it would leave a system in if you ran this and
happened to upgrade baselayout, then reboot without installing openrc.

William


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

Re: [gentoo-dev] openrc portage news item

[Sergei Trofimovich]

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

> I don't remember the details  right now, but I remember speaking with
> vapier when I first started working on openrc, and he stated that he
> felt we should stay away from higher eapis for system packages.
> 
> I don't really remember his reasoning for that right now, but I remember
> that is why I didn't migrate the ebuild to a higher eapi a while back.

Ebuild installability on horribly outdated systems? (where portage is too old to
support recent EAPIs).

-- 

  Sergei

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

Re: [gentoo-dev] openrc portage news item

[Roy Bamford]

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

On 2011.04.30 01:34, William Hubbs wrote:
[snip]
> 
> Also, this patch doesn't stop baselayout-2 from being installed, so I
> do
> not know what state it would leave a system in if you ran this and
> happened to upgrade baselayout, then reboot without installing 
> openrc.
> 
> William
> 
> 

William,

I've been there and done that.  My firewall was blocking git as I 
thought I had no use for it, so I got baselayout2 but not openrc.
openrc was only available from git in 2007
I was late, so I just switched off and went to bed.

I had to back out baselayout2 and do it again.  Its was fairly easy for 
me as I keep binpackages of everything I build.  It still needed a 
liveCD boot.
 
-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
gentoo-ops
forum-mods
trustees

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

[gentoo-dev] Re: openrc portage news item

[Duncan]

William Hubbs posted on Fri, 29 Apr 2011 02:08:31 -0500 as excerpted:

> Also, the way you can recover if you boot your system before following
> the steps is mentioned in the news item now, and there's not really
> anything more to it, so I'm not sure where else it should be mentioned.
> 
> What does everyone think?

This one looks very reasonable, to me.

The bases are all covered including the level of criticality, what to do 
to recover if it becomes necessary, and links for migration and further 
information.

Thanks again for your work on this. =:^)

-- 
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] openrc portage news item

[William Hubbs]

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

All,

the trigger has been pulled so to speak -- the news item is now in the
tree.

I did not have any links for the last paragraph (the section that
referred people to other places for support etc), so I had to remove
that.

As far as I know, we are moving forward with stabilization on
2011/05/08.

William

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