headers
Roy Marples | 1 Mar 2008 01:56
Favicon
Gravatar

Re: Baselayout-2 progress?

On Friday 29 February 2008 23:23:34 Ed Wildgoose wrote:
> > [2] I use busybox as a shell and can support it when it's internal
> > start-stop-daemon applet disabled (as OpenRC has it's own variant).
>
> I guess I could just check it out instead of asking but....  What's
> missing from the busybox s-s-daemon?
>
> I am using the busybox version 95% successfully with baselayout-2 for
> example (just simple stuff mind).  The only thing it's breaking on right
> now is  a --test option which doesn't seem to exist?
>
> I'm not that fussed, I'm just curious?

s-s-d when used in an OpenRC service remembers how the daemon is started so it 
can poll to see if it's still running or not. We also use this ability to 
ensure the daemon really starts. A lot of daemons love to fork (and return 
success) before checking config and system for sanity, so sometimes it's 
needed.

OpenRC variant also works better for finding daemons on the whole, especially 
if you upgrade an already running daemon.

Plus, it supports more OS's than busybox - but to be fair, busybox only 
supports Linux.

It's also missing chroot and env options from the upstream Debian version.
It's also missing the Gentoo extras for PAM limits support and redirecting the 
daemons stdout/stderr to log files.
It also requires the crappy use of oknodo.
It fails to search for daemon arguments when stopping (important for say
(Continue reading)

Permalink | Reply | 2 comments |
headers
Duncan | 1 Mar 2008 03:08
Picon

Re: Baselayout-2 progress?

Roy Marples <roy <at> marples.name> posted 200802291707.17936.roy <at> marples.name,
excerpted below, on  Fri, 29 Feb 2008 17:07:17 +0000:

> On Friday 29 February 2008 16:15:51 Ed W wrote:
>> On the other hand since there still isn't a masked ebuild in portage
>> (and I seem some notes on my on Roy's site) then I have to assume that
>> in fact we are still a good way away from calling it a replacement and
>> starting to push it out to users?
> 
> It's actually been very stable and usable for a long time. It's not, and
> never will be a 100% drop in replacement for everything baselayout
> provides, but it's very very compatible.

Is direct upgrade from previous baselayout-2.0.0-rcX going to be 
supported?  I was running that for some time and just now added and
upgraded to the via layman version.  There's a blocker, of course, as 
openrc is now providing most of the files that baselayout did.

The problem is that unmerging the old 2.0.0-rcX baselayout in ordered to 
resolve the blockage is SCARY, since it leaves the system basically 
unbootable until the new setup is merged and at least basically 
configured.  There's also the issue of not knowing for sure just what's 
going to still be around in terms of config files and the like, since 
unmerging baselayout isn't exactly an everyday thing.

FWIW, I took the jump anyway, and the etc-update seemed to go reasonably 
well, but I've not rebooted yet...

--

-- 
Duncan - List replies preferred.   No HTML msgs.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Doug Klima | 1 Mar 2008 05:59
Picon
Favicon

Re: Re: Baselayout-2 progress?

Duncan wrote:
> Roy Marples <roy <at> marples.name> posted 200802291707.17936.roy <at> marples.name,
> excerpted below, on  Fri, 29 Feb 2008 17:07:17 +0000:
> 
>> On Friday 29 February 2008 16:15:51 Ed W wrote:
>>> On the other hand since there still isn't a masked ebuild in portage
>>> (and I seem some notes on my on Roy's site) then I have to assume that
>>> in fact we are still a good way away from calling it a replacement and
>>> starting to push it out to users?
>> It's actually been very stable and usable for a long time. It's not, and
>> never will be a 100% drop in replacement for everything baselayout
>> provides, but it's very very compatible.
> 
> Is direct upgrade from previous baselayout-2.0.0-rcX going to be 
> supported?  I was running that for some time and just now added and
> upgraded to the via layman version.  There's a blocker, of course, as 
> openrc is now providing most of the files that baselayout did.

You just answered your own question. If another package now provides 
files that an existing package provides, they must be blockers. 
Considering baselayout-2.0.0_rcX was a masked version and never 
recommended, it's also not in the direct upgrade path. The proper 
upgrade is what you've detailed out below. Such are the risks when you 
unmask a package and install it on your machine.

> 
> The problem is that unmerging the old 2.0.0-rcX baselayout in ordered to 
> resolve the blockage is SCARY, since it leaves the system basically 
> unbootable until the new setup is merged and at least basically 
> configured.  There's also the issue of not knowing for sure just what's
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ciaran McCreesh | 1 Mar 2008 06:04
Picon
Favicon

Re: Re: Blockers (was: Baselayout-2 progress?)

On Fri, 29 Feb 2008 23:59:06 -0500
Doug Klima <cardoe <at> gentoo.org> wrote:
> You just answered your own question. If another package now provides 
> files that an existing package provides, they must be blockers. 

That's really bad policy -- it's pushing a package manager limitation
onto users in a visible and highly messy way. Really, it needs to go in
the short term (along with collision-protect) to avoid this kind of
nonsense on upgrades, and in the long term be fixed by getting rid of
blockers in favour of a more verbose syntax that gives the package
manager the information it needs to handle all this itself.

--

-- 
Ciaran McCreesh
Permalink | Reply | 0 comments |
headers
Duncan | 1 Mar 2008 10:49
Picon

Re: Baselayout-2 progress?

Doug Klima <cardoe <at> gentoo.org> posted 47C8E29A.2020003 <at> gentoo.org,
excerpted below, on  Fri, 29 Feb 2008 23:59:06 -0500:

>> Is direct upgrade from previous baselayout-2.0.0-rcX going to be
>> supported?  I was running that for some time and just now added and
>> upgraded to the via layman version.  There's a blocker, of course, as
>> openrc is now providing most of the files that baselayout did.
> 
> You just answered your own question. If another package now provides
> files that an existing package provides, they must be blockers.

Thus the "of course"...

> Considering baselayout-2.0.0_rcX was a masked version and never
> recommended, it's also not in the direct upgrade path. The proper
> upgrade is what you've detailed out below. Such are the risks when you
> unmask a package and install it on your machine.

Which is why I'm not particularly complaining, just asking.

Practically speaking, while it's not required by any means, some devs 
choose to acknowledge the symbiotic relationship between pre-release 
testers willing to take that risk and do the work to find and file bugs, 
thus helping to make the general release far less buggy, and the devs who 
depend on such testers for that function.  The testers do a favor for the 
devs with all that early testing and bug filing (sometimes with patches), 
and many devs choose to return it by providing a working upgrade path 
from the pre-releases to the general release.  Among other things, it 
makes for happier testers, who are then likely to be repeat testers, the 
next time an upgrade comes along.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike Frysinger | 1 Mar 2008 06:30
Picon
Favicon
Gravatar

Monthly Gentoo Council Reminder for March

This is your monthly friendly reminder !  Same bat time (typically
the 2nd Thursday at 2000 UTC / 1600 EST), same bat channel
(#gentoo-council  <at>  irc.freenode.net) !

If you have something you'd wish for us to chat about, maybe even
vote on, let us know !  Simply reply to this e-mail for the whole
Gentoo dev list to see.

Keep in mind that every GLEP *re*submission to the council for review
must first be sent to the gentoo-dev mailing list 7 days (minimum)
before being submitted as an agenda item which itself occurs 7 days
before the meeting.  Simply put, the gentoo-dev mailing list must be
notified at least 14 days before the meeting itself.

For more info on the Gentoo Council, feel free to browse our homepage:
http://www.gentoo.org/proj/en/council/
--

-- 
gentoo-dev <at> lists.gentoo.org mailing list
Permalink | Reply | 67 comments |
headers
Roy Marles | 1 Mar 2008 11:50
Favicon
Gravatar

Re: Re: Baselayout-2 progress?

On Saturday 01 March 2008 02:08:44 Duncan wrote:
> Is direct upgrade from previous baselayout-2.0.0-rcX going to be
> supported?

Existing configs should work just fine - with the exception of the modules 
config. It's been moved to /etc/conf.d/modules instead of 
the /etc/modules.autoload.d folder. There is no automated migration as 
complex setups would go wrong.

> I was running that for some time and just now added and 
> upgraded to the via layman version.  There's a blocker, of course, as
> openrc is now providing most of the files that baselayout did.
>
> The problem is that unmerging the old 2.0.0-rcX baselayout in ordered to
> resolve the blockage is SCARY, since it leaves the system basically
> unbootable until the new setup is merged and at least basically
> configured.  There's also the issue of not knowing for sure just what's
> going to still be around in terms of config files and the like, since
> unmerging baselayout isn't exactly an everyday thing.
>
> FWIW, I took the jump anyway, and the etc-update seemed to go reasonably
> well, but I've not rebooted yet...

As others pointed out, this is a package manager issue and those blockers are 
there because of this. Not an OpenRC issue as such ;)

Thanks

Roy
--

--
(Continue reading)

Permalink | Reply | 1 comment |
headers
Raúl Porcel | 1 Mar 2008 11:55
Picon
Favicon

Re: Monthly Gentoo Council Reminder for March

I want to propose to the council to talk about the amd64 arch team and 
its big bug list [1] considering they are the most staffed arch team.

They have some bugs that are more than a month old and they are the last 
arch. Same for security bugs, and i think amd64 is an important arch and 
has a lot of users, and ATs. x86 doesn't have any AT active and we only 
have less than 10 bugs, amd64 has 144 bugs, and i'm talking about bugs 
with STABLEREQ keywords, just look at [1].

So it would be cool if they accepted help from other devs who don't have 
  an amd64 system but have access to one and can test stuff. Cla is 
willing to help.

There's even a bug that is a blocker...

[1]: http://tinyurl.com/3dms4y
--

-- 
gentoo-dev <at> lists.gentoo.org mailing list
Permalink | Reply | 20 comments |
headers
Richard Freeman | 1 Mar 2008 13:35
Picon
Favicon
Gravatar

Re: Monthly Gentoo Council Reminder for March

Raúl Porcel wrote:
> 
> So it would be cool if they accepted help from other devs who don't have 
>  an amd64 system but have access to one and can test stuff. Cla is 
> willing to help.
> 

I think this may be more a question of what our policy should be 
regarding level of testing/stability accepted.  I'm sure manpower is a 
factor as well (number of devs isn't necessarily directly proportional 
to number of hours spent by those devs per week on gentoo).

I don't keyword a package stable unless I've done at least a moderate 
amount of testing on the package to ensure that it works.  If a package 
looks simple but obscure I might go ahead and install it and play with 
it, but I'd probably never keyword an emacs package stable, since I 
don't ever use emacs and I won't pretend that all there is to it is 
installing it and typing "hello world" and figuring out how to quit.

Also, the more critical a package is the less likely I am to keyword it 
without care - I'm not going to keyword apache stable unless I've 
installed it and put several of my php/cgi-perl apps through a fair 
number of chores since I know that people who run apache generally care 
that it works.

If there are folks out there who can test on amd64 systems then I'm sure 
that the amd64 team would look forward to their help (just contact 
kingtaco about it) - either by arch testing or perhaps by just 
keywording as appropriate.  However, we do need to be careful about just 
going on a hunt to close bugs - "if it builds then it's stable" isn't
(Continue reading)

Permalink | Reply | 2 comments |
headers
Christian Faulhammer | 1 Mar 2008 13:56
Picon
Favicon

Re: Monthly Gentoo Council Reminder for March

Hi,

Richard Freeman <rich0 <at> gentoo.org>:

> Raúl Porcel wrote:
> > 
> > So it would be cool if they accepted help from other devs who don't
> > have an amd64 system but have access to one and can test stuff. Cla
> > is willing to help.
[...]
> I don't keyword a package stable unless I've done at least a moderate 
> amount of testing on the package to ensure that it works.  If a
> package looks simple but obscure I might go ahead and install it and
> play with it, but I'd probably never keyword an emacs package stable,
> since I don't ever use emacs and I won't pretend that all there is to
> it is installing it and typing "hello world" and figuring out how to
> quit.

 Hah, got you.  Emacs team has a collection of test plans, that are
understandable and have a step-by-step guide to the package.  You may
not have noticed because at the moment, Emacs teams handles nearly all
stabilisation requests itself on amd64.
 Yes, testing is crucial, but it eases your pain if you have an arch
tester going over it beforehand and amd64 is well equipped with that.

> If there are folks out there who can test on amd64 systems then I'm
> sure that the amd64 team would look forward to their help (just
> contact kingtaco about it) - either by arch testing or perhaps by
> just keywording as appropriate.  However, we do need to be careful
> about just going on a hunt to close bugs - "if it builds then it's
(Continue reading)

Permalink | Reply | 1 comment |

Gmane