[gentoo-dev] openrc-0.5.1 arrived in the tree

Matthias Schwarzott · External Since: May 17, 2006 Posts: 13

Hi there!

As some of you have waited long for this to happen, sys-apps/openrc-0.5.1 is
there. It has a default enabled (eapi-1) useflag oldnet to install the
old-style network scripts called net.*.
Regardless of this use-flag, the new init-script /etc/init.d/network is always
installed.

For transition to new-style network script there is something todo I think.
Unordered list of todos:
* hotplug? at least udev does explicitly call in net.* scripts
* New systems should get old or new scripts?
* does new scripts already can do all that was possible with net.* ?

So far I hope the update does not break any system.
In case this happens nevertheless open a bug as usual.

Regards
Matthias

Tomáš_Chvátal · External Since: Oct 10, 2009 Posts: 1

News item?
Will be/Wont be/In progress??

Matthias Schwarzott · External Since: May 17, 2006 Posts: 13

On Dienstag, 13. Oktober 2009, Markos Chandras wrote:
>
> I agree with Nirbheek. You should always provide an updated documentation (
> and a news item if necessary ) when you release a new major update of such
> core packages. I would like to see new openrc masked until the
> documentation is ready with full details about the transition to the new
> network init script.
> If you don't provide such documentation in time, you will fail to make
> users switch to new init script in the near future, since everybody will
> forget about this and will use the 'oldnet' use flag anyway.
> The sooner you will explain them how to migrate, the better
> results/feedback/updated systems you will get
>

You are right. If I want everybody to switch to new net init script. But do I
want that?
I still use the old one, as I think it is more powerful.
The old scripts will not be dropped in medium future if it does not break
stuff.

By the way I am no official maintainer of openrc, still caring about it and
fixing stuff if it annoys me or I have too much of free time.

About the new scripts in general: Do we consider them already good enough and
stable enough to recommend (non power-)users to transition?

Regards
Matthias

Samuli Suominen · External Since: Jun 02, 2009 Posts: 22

Nirbheek Chauhan wrote:
> [completely offtopic from this thread, please fork thread if/when replying]
>
> On Wed, Oct 14, 2009 at 6:40 AM, Jeroen Roovers <jer.RemoveThis@gentoo.org> wrote:
>> Since the advent of outside overlays and layman,
>> we've seen many more bugs that only got discovered when the tree was
>> synced with some developer overlay, or when a Great Unveiling was done
>> after limited, private, small scale testing (as with many GNOME and KDE
>> releases, not to point the finger).
>
> If GNOME is involved, I would like you to point some fingers and tell
> us exactly where you think we went wrong; exactly which "Great
> Unveiling" are you talking about? If you don't tell us what we did
> wrong, you surely can't expect us to fix the problem Smile

New dev-libs/glib, x11-libs/gtk+ and possible some other core libraries
should be in tree (package.masked perhaps) so users and developers can
help testing them. The current way they are moved from overlay into
~arch is forcing them to be tested, where as having them in tree now,
would allow people who *want* to test them to do so.

(I'm not pointing fingers, or blaming. That's just my humble view.)

Dawid Węgliński · External Since: Jul 23, 2007 Posts: 4

On Wednesday 14 October 2009 02:41:51 Branko Badrljica wrote:
> Mike Frysinger wrote:
> > i really dont buy this argument, but ignoring that, poor admin policy is
> > no excuse. blindly accepting all unstable versions of a package instead
> > of pinning a specific version and then expecting a stable system isnt
> > going to happen. Thomas is absolutely right here.
>
> Well, if eh is absolutely right, then I won't argue anymore.
>
> But just as an notice, I didn't expect STABLE but at least DOCUMENTED
> system ?
> Is that too much to ask ?

sapphire ~ # qlist openrc | grep doc
/usr/share/doc/openrc/net.example
/usr/share/doc/openrc/net.default

>
> And even if I did a mistake of keywording openrc-0* instead of
> openrc-0.4-r3, do I really deserve such knife in the back ?
>

Knife, eh? The worst thing could happen to you i lack of net connection.

> And who should write documentation for new code ? Unreasonable users
> that find it not working or perhaps authors ?
> While I recognise the fact that Gentoo is not commercial distro, I want
> also some recognition for value of my time as a passive tester.
>

Upstream already provides such a documentation as you can see above. Gentoo
provides migration guide. I believe doc team will update use flag description
as soon as it's possible.

But that's all has been already said.

--
Cheers
Dawid Węgliński

Branko Badrljica · External Since: Oct 16, 2009 Posts: 7

Mike Frysinger wrote:
>
> the mailing list is not bugzilla. any complaints you have about USE=oldnet
> have nothing to do with this thread. it's a bug and should be treated as
> such.
> -mike
>

Which is why I have posted here to gripe about having documented such
changes in future.

I was told that new openrc is surely fine because it works for some
group of people, that obviously includes developer.

It is not enough, and please, don't keep such things in the future in
more or less closed circles of your pals.

Even simple "WARNING!!! Big changes, untested, not(yet) documented!"
would be nice.

I know what arch~ _should_ mean, but you know what it actually means.
So, a little bit of pragmatic flexibility here would certainly decrease
amount of raining urine and improve Gentoo's likability.

In any event, I don't intend to further this debate.

Take it as a rant of some user that certainly can be wrong.

Jeremy Olexa · External Since: Aug 12, 2009 Posts: 5

On Tue, 13 Oct 2009 22:55:45 +0200, Branko Badrljica
<brankob.DeleteThis@avtomatika.com> wrote:

> Main question is NOT whether it works for you, but whether it will break

> stuff on significant percent of other users.
> It broke on my machine, for example, and it was quite disconcerting,
> since it was at quite inconvenient moment and I had note get to any
> shred of documentation about ANY kind of substantial behaviour change of

> new openrc...

This is an unreasonable expectation for ~arch. Matthias tested it himself,
had another person test it and then had a number of people say that there
were no problems for them on this thread alone. There was no behavior
change according to upstream, which suggested the method that Matthias took
with USE=oldnet (MKOLDNET?). I respect that every system might be
different, did you file a bug with relevant info so that the docs can get
updated for the people in your situation? We can't document information if
people don't help.

I guess what I am trying to say, is give Matthias a break here. He did
more testing than most of us can do before we bump packages in ~arch.
Progress will not be made if packages live in p.mask, this is proven with
libtool-2, gcc, etc.

-Jeremy

Branko Badrljica · External Since: Oct 16, 2009 Posts: 7

Mike Frysinger wrote:
> On Tuesday 13 October 2009 22:36:44 Branko Badrljica wrote:
>
>> Mike Frysinger wrote:
>>
>>> the mailing list is not bugzilla. any complaints you have about
>>> USE=oldnet have nothing to do with this thread. it's a bug and should be
>>> treated as such.
>>>
>> Which is why I have posted here to gripe about having documented such
>> changes in future.
>>
>
> USE=oldnet is documented, end of story. you're complaining about a *bug*, not
> lack of documentation. stop mixing the two as you're only muddling this
> thread.
> -mike
>

Not really, but my fingers hurt.
So, let's leave it at that, you were Right(tm) and I am misguided.
I'm truly sorry for all the noise in you signal that i caused and wish
you all the best.

Dawid Węgliński · External Since: Jul 23, 2007 Posts: 4

On Wednesday 14 October 2009 00:59:26 schism RemoveThis @subverted.org wrote:
> On Wed, Oct 14, 2009 at 12:52:06AM +0200, Dawid Węgliński wrote:
> > sapphire ~ # qlist openrc | grep doc
> > /usr/share/doc/openrc/net.example
> > /usr/share/doc/openrc/net.default
>
> That would be lovely if the concerns being raised weren't about 0.5.1,
> that's the output from a 0.4.3 series install.
>
# qlist -ICv openrc
sys-apps/openrc-0.5.1

Yeah, you're right. Wink

--
Cheers
Dawid Węgliński

Nirbheek Chauhan · External Since: May 26, 2009 Posts: 6

On Wed, Oct 14, 2009 at 12:47 AM, William Hubbs <williamh.DeleteThis@gentoo.org> wrote:
> The default is to use the old net.ethx style network scripts, which
> still work as usual, so, that is why I said that I disagree about there
> being a regression. A regression means that something worked before,
> but it doesn't now, and that is not the case if you accept the defaults.
>

Agreed, not a regression.

[snip]
> Yes, I would agree that there should be a warning about
> turning off the oldnet use flag, but I don't think this warrants masking
> the ebuild, unless I am missing something. If I am, definitely let me
> know.
>

If the USE-flags of an ebuild are visible to the user, it can be
assumed that they are safe to use (after following the documentation
and warnings if any). Which means that the maintainer needs to be even
more careful w.r.t. system packages; providing adequate warnings and
documentation.

If there's no documentation on how to use the new network scripts;
there should atleast be a big /FAT/ warning. Obviously the
documentation must be updated soon as well; unless the ebuild never
intends to make it to stable Wink

Personally, I wouldn't even dream of adding a core package like openrc
to ~arch until there was documentation about unexpected behaviour
(default or not). But to each his own.

--
~Nirbheek Chauhan

GNOME+Mozilla Team, Gentoo

Nirbheek Chauhan · External Since: May 26, 2009 Posts: 6

On Wed, Oct 14, 2009 at 5:08 PM, Samuli Suominen <ssuominen.DeleteThis@gentoo.org> wrote:
> New dev-libs/glib, x11-libs/gtk+ and possible some other core libraries
> should be in tree (package.masked perhaps) so users and developers can
> help testing them. The current way they are moved from overlay into
> ~arch is forcing them to be tested, where as having them in tree now,
> would allow people who *want* to test them to do so.
>

I'm not aware of any bugs related to new glib/gtk+ breaking packages
in recent times. Probably because Mart (leio) does a really good job
of combing through the ChangeLogs and making sure that there aren't
any regressions.

For instance, with gtk+-2.18, there are major changes which break
rendering in apps[1], so it won't be brazenly added to tree (likely
will get a p.mask like you say). However, glib-2.22 has no such
changes, and will be the first thing to get added to tree as ~arch
part of GNOME 2.28.

1. Client-Side windows (csw) /will/ break apps; there has been
extensive testing upstream, but breakage is inevitable.

--
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Branko Badrljica · External Since: Oct 16, 2009 Posts: 7

Mike Frysinger wrote:
> On Tuesday 13 October 2009 22:48:01 Branko Badrljica wrote:
>
>> Mike Frysinger wrote:
>>
>>> On Tuesday 13 October 2009 22:36:44 Branko Badrljica wrote:
>>>
>>>> Mike Frysinger wrote:
>>>>
>>>>> the mailing list is not bugzilla. any complaints you have about
>>>>> USE=oldnet have nothing to do with this thread. it's a bug and should
>>>>> be treated as such.
>>>>>
>>>> Which is why I have posted here to gripe about having documented such
>>>> changes in future.
>>>>
>>> USE=oldnet is documented, end of story. you're complaining about a
>>> *bug*, not lack of documentation. stop mixing the two as you're only
>>> muddling this thread.
>>>
>> Not really, but my fingers hurt.
>> So, let's leave it at that, you were Right(tm) and I am misguided.
>> I'm truly sorry for all the noise in you signal that i caused and wish
>> you all the best.
>>
>
> now that you've realized the error of your ways, i still dont see any bug
> reports in bugzilla about USE=oldnet. that leads me to conclude that testers
> have found no problems with it, only problems with USE=-oldnet.
> -mike
>
And you won't see it from my hurting fingers.
How can I trust my eyes and reason when I have you.
Keep the God's Work - someone has to do it.

Branko Badrljica · External Since: Oct 16, 2009 Posts: 7

William Hubbs wrote:
> On Tue, Oct 13, 2009 at 10:55:45PM +0200, Branko Badrljica wrote:
>
>> Main question is NOT whether it works for you, but whether it will break
>> stuff on significant percent of other users.
>> It broke on my machine, for example, and it was quite disconcerting,
>> since it was at quite inconvenient moment and I had note get to any
>> shred of documentation about ANY kind of substantial behaviour change of
>> new openrc...
>>
>
> The default is to use the old net.ethx style network scripts, which
> still work as usual, so, that is why I said that I disagree about there
> being a regression. A regression means that something worked before,
> but it doesn't now, and that is not the case if you accept the defaults.
>
>
Which I did. I don't have openrc in /etc/portage/package.use, so it was
emerged with default USE flags ( if you count default as in "as set in
make.conf" ). emerge -pv openrc woould emerge it as:

sys-apps/openrc-0.5.1 [0.4.3-r4] USE="ncurses oldnet%* pam unicode -debug"

.... which means with "oldnet" flag.

And whenever I tried it, it broke my system.

> If you accept the defaults and it doesn't work, I will gladly agree that
> there is a major regression and the package should be masked. On the
> other hand, if the new network scripts do not work, I don't see that as
> a show stopper. Yes, I would agree that there should be a warning about
> turning off the oldnet use flag, but I don't think this warrants masking
> the ebuild, unless I am missing something. If I am, definitely let me
> know.
I don't feel comfortable with your philosophy. It doesn't matter how
obvious matters seem to you, your changes can affect many people in many
situations and configurations, not necessarily allways without unforseen
consequences.

I understand that Gentoo is not for pussies and that you can't make an
ISO-9001 procedure for every change with every user, but it would really
be nice to have at least some _basic_ safety, like mentioning changes in
eselect news, or at least on home page of the package.

schism · External Since: Oct 16, 2009 Posts: 3

On Tue, Oct 13, 2009 at 08:40:48PM -0400, Mike Frysinger wrote:
> USE=oldnet is documented, end of story. you're complaining about a *bug*, not
> lack of documentation. stop mixing the two as you're only muddling this
> thread.

I don't think you are going to find anyone here stating that the USE
flag itself is not documented. The heart of the matter is that, not
only do we testers find the sweeping API changes poorly documented
(preventing properly testing them and starting this thread), but there
are many regressions, several of which are non-starters.

Seemingly simple things like configuring static routes, setting MTUs,
and bringing up interfaces after configuring them have fallen by the
wayside for no apparent reason, and with zero documentation. Even PPP
interface support has been dropped with little explanation other than
"get that old script from mrness and hope it works".

As far as I can tell, the new openrc network API has (and has only been
tested with) one extremely simple paradigm in mind: DHCP or statically
configured hosts on a flat, autoconfigured ethernet VLAN with only one
off-subnet route. That is a huge step backward.

Matthias Schwarzott · External Since: May 17, 2006 Posts: 13

On Mittwoch, 14. Oktober 2009, schism RemoveThis @subverted.org wrote:
>
> Oh, you mean the docs that only cover the "old" configuration mechanism
> and are only installed with USE=oldnet? How silly to think that changes
> that are likely to take testers' machines offline should be documented,
> if nothing else with, say, 'ewarn "USE=-oldnet changes the network
> configuration syntax, check it before rebooting"'. I wasn't bitten
> (because I am more cautious than that), but I WAS annoyed that a package
> was sent out to be tested with zero instructions on the drastic changes
> it made.

So this is my last mail to this topic.

At least /etc/conf.d/network does contain documentation. Or is a requirement
of documentation that it is not inside config files?

First: Default enabled use-flags may be enabled for a reason. One should think
before overriding it.
Another thing: There was no message that one should switch to new scripts NOW.
Old scripts will still be supported some time. I also keep using the old ones
for now.
As openrc-0.5.1 did work in the tests for me and some other people and no
breakage was expected I did commit it.
If you got a bug you should report it on bugzilla.

And no, package.mask does not help, as then the bug would show later when
unmasking.

The openrc ebuild does print a warning if old net.* init-scripts are enabled
in some runlevels. See this code:

if ! use oldnet; then
local f= links=$(find "${ROOT}"/etc/runlevels/ -name "net.*")
if [[ "${links}" != "" ]] ; then
ewarn "You have disabled installation of old-style network
scripts"
ewarn "but they are still enabled in some runlevels:"
for f in $links; do
ewarn "\t$f"
done
ewarn "You should migrate the settings"
ewarn "from /etc/conf.d/net to /etc/conf.d/network"
ewarn "and clean runlevels from /etc/init.d/net.* and"
ewarn "instead add /etc/init.d/network"
fi
fi

So if you disabled "oldnet" you definitely got the message above.
Yes, there is no big fat warning that stuff may break, but you still can roll
back to the config you had before.
But, as new network script is installed regardless of oldnet setting, the
warning must be printed always to be useful.

Did you have a look at demerge. That is a software that makes a snapshot of
which packages are installed with exact use-flag config and can rollback to
that snapshot.

The use-flag "oldnet" itself is described like this:
Install the old type of network init-scripts with a symlink net.IFACE for each
interface

Matthias

Jeroen Roovers · External Since: Mar 21, 2006 Posts: 27

On Tue, 13 Oct 2009 20:33:35 -0400
Mark Loeser <halcy0n DeleteThis @gentoo.org> wrote:

> I'd say this isn't correct. Unstable isn't a pure testing playground.
> its meant for packages that should be considered for stable.

I happen to disagree. Since the advent of outside overlays and layman,
we've seen many more bugs that only got discovered when the tree was
synced with some developer overlay, or when a Great Unveiling was done
after limited, private, small scale testing (as with many GNOME and KDE
releases, not to point the finger).

Keeping things out of the tree because they are "not ready for general
consumption", or indeed masking versions "for testing", are good ways
to ensure you get no widespread testing at all and find bugs at a late
stage, worst case being during or after stabilisation. When the
stable/testing mechanism works well, then all non-upstream bugs will be
discovered before stabilisation, and some can even be fixed while
stabilisation continues.

Maintainers should know what versions never to request stabilisation
for, otherwise users who expect things to more or less just
work get exposed to buggy upstream releases.

On the other hand, careful users should know to cherry-pick specific
versions to unmask through package.unmask and package.keywords instead
of using ACCEPT_KEYWORDS="arch ~arch" as a blanket measure to get the
latest versions, otherwise they will regularly see data loss,
misconfiguration, and programs that do not work at all, because:

Testing means that you are prepared to find and deal with bugs that
have not been fixed yet because they have not been found yet.

I've been working on Gentoo for nearly 4 years now to hold up that vital
distinction between testing (~hppa) and stable (hppa), and what you
propose here has proven unworkable in that practice and as a general
attitude is quite unusual.

Regards,
jer

Branko Badrljica · External Since: Oct 16, 2009 Posts: 7

Mike Frysinger wrote:
>
>
> i really dont buy this argument, but ignoring that, poor admin policy is no
> excuse. blindly accepting all unstable versions of a package instead of
> pinning a specific version and then expecting a stable system isnt going to
> happen. Thomas is absolutely right here.
>
>
Well, if eh is absolutely right, then I won't argue anymore.

But just as an notice, I didn't expect STABLE but at least DOCUMENTED
system ?
Is that too much to ask ?

And even if I did a mistake of keywording openrc-0* instead of
openrc-0.4-r3, do I really deserve such knife in the back ?

Having some reasonable safety margin is base of sanity. Your PSU is
galvanicaly insulated, but law demands that housing of your PC be
connected to earth potential in case of insulation failing. Had that
been done by Gentoo community courts would be full of cases of
"unreasonable dead jerks who should be grateful"...

> documentation doesnt write itself. this isnt directed specifically at you,
> but clamoring "gimme gimme gimme" is more likely to get people to tell you to
> toss off than get what you want.
And who should write documentation for new code ? Unreasonable users
that find it not working or perhaps authors ?
While I recognise the fact that Gentoo is not commercial distro, I want
also some recognition for value of my time as a passive tester.

I am happy to give what I can, but I expect at least some basic
foundations for that. Having documentation about public changes at least
for me falls well within that category.

At least for me, even otherwise useful changes can have NEGATIVE value,
if they gob heaps of my time totally unnecesarilly and total lack of
documentation is on top of the list of best ways to piss on masses.

schism · External Since: Oct 16, 2009 Posts: 3

On Wed, Oct 14, 2009 at 12:52:06AM +0200, Dawid Węgliński wrote:
> sapphire ~ # qlist openrc | grep doc
> /usr/share/doc/openrc/net.example
> /usr/share/doc/openrc/net.default

That would be lovely if the concerns being raised weren't about 0.5.1,
that's the output from a 0.4.3 series install.

Graham Murray · External Since: May 15, 2005 Posts: 89

Branko Badrljica <brankob.RemoveThis@avtomatika.com> writes:

> 2. About using bugzilla- how the heck was I supposed to use it without
> net access ?

If openrc did not start your networking, what was preventing you
starting it yourself? Even if the upgrade also corrupted both
sys-apps/net-tools and sys-apps/iproute2[1], you could have booted from
a rescue/install CD/DVD/USB stick[2].

[1] Which I very much doubt.

[2] Which I have had to do a couple of times when the system would not
boot following an update or change I have made.

Branko Badrljica · External Since: Oct 16, 2009 Posts: 7

Thomas Sachau wrote:

<SNIP>
>
> I disagree in this place. ~arch is called testing because it actually is about TESTING new versions
> and packages. You should expect problems and you should be able to recover from them and you should
> be able to use bugzilla. Else i suggest you move to a stable arch instead.
>
> Your arguments could make sense, if it would be about the stable tree, but forcing the testing tree
> to be a second stable tree, just with newer package versions isnt our goal nor does it help anyone.
>
>
1. Much of the time on Gentoo using of ~ packages is not user explicit
choice but forced compromise.
I don't remember exactly anymore what prompted me to enter openrc in
package.keywords, but I surely remember having a few headaches with it.
Same is with many other packages- many times using ~arch is the only
answer, so 99% of the time it is used for getting some package to work
and not for pure testing.
Having in mind state of the matter in_real_world, I really don't think
that having such things at least temporarily masked ( not to mention
DOCUMENTED!) is really not overdoing it.

2. About using bugzilla- how the heck was I supposed to use it without
net access ?

3. My main if not only argument was about at last documenting such changes.

As it was done, it presented me with nasty surprise. Machine has gotten
through upgrade world just fine and only after reboot it couldn't start
network interfaces. Manual restart croaked with some error about python
not being able to find some function.

It felt exactly like a few last times when my ext4 decided to lose a few
hundred essential system files. There was nothing to suggest openrc.
After I lost some time reemerging system files and sifting through
ebuilds, packages and scripts, that casual message here about new openrc
hit me purely by chance, otherwise I would be in for much more pain.
After I got system running again, I couldn't find anywhere anything at
all about any substantial change in openrc.
Not on bugzilla, not on openrc home page nor anywhere else.

4. About filing bugzilla bug, I can't do it now, since I am in a hurry
and without it I can't contribute any really useful data.
Will do when I get around to it...