[gentoo-dev] Baselayout-2 progress?

[gentoo-dev] Baselayout-2 progress?

[Ed W]

Is it dead..?  Is anyone still working on it?

I have had a lot of success using it for linux vservers and in an 
embedded build. Would really hate to see it stall though...?

What are the big picture items still missing?  Seems that it's close to 
becoming a stable upgrade?  I have filed a few minor bugs against it 
(some more to come) - is there anything I can do to help progress 
development further?

Cheers

Ed W
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Baselayout-2 progress?

[Alon Bar-Lev]

Check out OpenRC it is baselayout successor and works great!

On 2/29/08, Ed W <lists@wildgooses.com> wrote:
> Is it dead..?  Is anyone still working on it?
>
>  I have had a lot of success using it for linux vservers and in an
>  embedded build. Would really hate to see it stall though...?
>
>  What are the big picture items still missing?  Seems that it's close to
>  becoming a stable upgrade?  I have filed a few minor bugs against it
>  (some more to come) - is there anything I can do to help progress
>  development further?
>
>  Cheers
>
>  Ed W
>
> --
>  gentoo-dev@lists.gentoo.org mailing list
>
>
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Baselayout-2 progress?

[Ed W]

Alon Bar-Lev wrote:
> Check out OpenRC it is baselayout successor and works great!
>   

Funnily enough I came across this earlier today for different reasons.  
However, I hadn't realised that it was a full baselayout competitor?

Does Roy hang out here?  Roy: Is this intended to be a baselayout 
replacement?  How likely is this to be on-track to become a "gentoo 
official" baselayout?  Do you (try to) support busybox and vserver 
environments?

Cheers

Ed W
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Baselayout-2 progress?

[Doug Klima]

Ed W wrote:
> Alon Bar-Lev wrote:
>> Check out OpenRC it is baselayout successor and works great!
>>   
>
> Funnily enough I came across this earlier today for different 
> reasons.  However, I hadn't realised that it was a full baselayout 
> competitor?

baselayout-2 was renamed to openrc when Roy left Gentoo as an official dev.

>
> Does Roy hang out here?  Roy: Is this intended to be a baselayout 
> replacement?  How likely is this to be on-track to become a "gentoo 
> official" baselayout?  Do you (try to) support busybox and vserver 
> environments?
Don't know. Yes. Very. Yes & Yes.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Baselayout-2 progress?

[Ed W]

Hi

> baselayout-2 was renamed to openrc when Roy left Gentoo as an official 
> dev.

Answering my own question (for the record). I found some explanation here:
http://lycos.dropcode.net/gregarius/author.php?author=Roy_Marples__uberlord_

>> Does Roy hang out here?  Roy: Is this intended to be a baselayout 
>> replacement?  How likely is this to be on-track to become a "gentoo 
>> official" baselayout?  Do you (try to) support busybox and vserver 
>> environments?
> Don't know. Yes. Very. Yes & Yes.

Excellent - this is exciting to hear

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?

Would it not make sense to start to snapshot some builds and push openrc 
out for testing?  (Seems like a gentoo job rather than an upstream is 
the reason I ask here?)

Cheers

Ed W
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Baselayout-2 progress?

[Doug Klima]

Ed W wrote:
> Hi
>
>> baselayout-2 was renamed to openrc when Roy left Gentoo as an 
>> official dev.
>
> Answering my own question (for the record). I found some explanation 
> here:
> http://lycos.dropcode.net/gregarius/author.php?author=Roy_Marples__uberlord_ 
>
>
>>> Does Roy hang out here?  Roy: Is this intended to be a baselayout 
>>> replacement?  How likely is this to be on-track to become a "gentoo 
>>> official" baselayout?  Do you (try to) support busybox and vserver 
>>> environments?
>> Don't know. Yes. Very. Yes & Yes.
>
> Excellent - this is exciting to hear
>
> 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?
>
> Would it not make sense to start to snapshot some builds and push 
> openrc out for testing?  (Seems like a gentoo job rather than an 
> upstream is the reason I ask here?)
>
> Cheers
>
> Ed W
sudo emerge layman
sudo layman -L
sudo layman -a openrc
sudo emerge openrc
sudo etc-update
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Baselayout-2 progress?

[Roy Marples]

On Friday 29 February 2008 15:56:44 Ed W wrote:
> Alon Bar-Lev wrote:
> > Check out OpenRC it is baselayout successor and works great!
>
> Funnily enough I came across this earlier today for different reasons.
> However, I hadn't realised that it was a full baselayout competitor?
>
> Does Roy hang out here?  Roy: Is this intended to be a baselayout
> replacement?  How likely is this to be on-track to become a "gentoo
> official" baselayout?  Do you (try to) support busybox and vserver
> environments?

It's not a full baselayout competitor - instead it's reduced baselayout to 
providing key base files such as /etc/passwd. OpenRC is just the service 
management system.

Yes
Yes [1]
A done deal [1]
No [2]

[1] The Gentoo Council and Gentoo base-system team know and approve of OpenRC.
Mike Frysinger of the Gentoo base-system team also has commit access to the 
git repo. So it's very very likely.

[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 don't 
and probably never will support vserver personally, but will work with Gentoo 
developers ensuring that at least one version works. In other words, I'll try 
and support it but it may break from time to time.

Thanks

Roy
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Baselayout-2 progress?

[Roy Marples]

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.

> Would it not make sense to start to snapshot some builds and push openrc
> out for testing?  (Seems like a gentoo job rather than an upstream is
> the reason I ask here?)

As Doug mentioned earlier, my git repo is available in an ebuild.
Why haven't I done a snapshot or release yet? Well, I have one last feature to 
add basically. That feature is so it can be installed "prefixed" and still 
work perfectly - with the exception of not booting or shutting down the host 
system. I'll be doing this on my NetBSD box next week hopefully.

But bugs are still being found and fixed - although at a slow rate :)

Thanks

Roy
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Baselayout-2 progress?

[Benedikt Bšoehm]

Roy Marples schrieb:
> [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 don't 
> and probably never will support vserver personally, but will work with Gentoo 
> developers ensuring that at least one version works. In other words, I'll try 
> and support it but it may break from time to time.
>   
actually, baselayout-2 and openrc work great in vservers ... and it is 
kind of hard to break it, most things are just "cosmetic", so you don't 
get errors on vserver startup

some (minor) cosmetic bugs still need to be fixed in openrc, but i'll 
send a patch to roy really soon now

HTH
Bene
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Baselayout-2 progress?

[Stefan Hellermann]

I just tried openrc and I really like it! All the things changed from baselayout-2.0.0-rc6
 are really good ideas! good work! Thanks!

> 
> But bugs are still being found and fixed - although at a slow rate :)
> 

Two small things happened here:

After Login I the shell looks like:
-bash-3.2#
when I start then bash again manually it looks nice, the environment is not setup
correctly the first time.

when rebooting, INIT stops with "no more processes left in this runlevel" after "remounting /"
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Baselayout-2 progress?

[Roy Marples]

On Friday 29 February 2008 18:32:44 Stefan Hellermann wrote:
> I just tried openrc and I really like it! All the things changed from
> baselayout-2.0.0-rc6 are really good ideas! good work! Thanks!

:)

> Two small things happened here:
>
> After Login I the shell looks like:
> -bash-3.2#
> when I start then bash again manually it looks nice, the environment is not
> setup correctly the first time.

Doesn't sound like an OpenRC issue as such as bash sets up it's own prompt. 
Also, OpenRC isn't responsible for setting up the environment. At most we 
suck in what's defined in /etc/profile.env

> when rebooting, INIT stops with "no more processes left in this runlevel"
> after "remounting /"

Curious. A suggest you open a bug a http://bugs.marples.name against openrc so 
we can move the debugging off this list.

Thanks

Roy
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Baselayout-2 progress?

[Stefan Hellermann]

Roy Marples schrieb:
>> Two small things happened here:
>>
>> After Login I the shell looks like:
>> -bash-3.2#
>> when I start then bash again manually it looks nice, the environment is not
>> setup correctly the first time.
> 
> Doesn't sound like an OpenRC issue as such as bash sets up it's own prompt. 
> Also, OpenRC isn't responsible for setting up the environment. At most we 
> suck in what's defined in /etc/profile.env
> 
>> when rebooting, INIT stops with "no more processes left in this runlevel"
>> after "remounting /"
> 
> Curious. A suggest you open a bug a http://bugs.marples.name against openrc so 
> we can move the debugging off this list.
> 

Here is something other badly broken :) So I don't think it's a openrc issue.

# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# env | grep PATH
*nothing*
# sysctl   # only a example for a app that works
*works*
# which sysctl    # this should work if sysctl works without typing /sbin/sysctl
which: no sysctl in ((null))

I think it could be a CFLAG, I compiled my whole System with -mfpmath=sse (not sse,387),
but while emerging openrc there are compiler warnings saying it uses -mfpmath=387 because
sse is not available. Does openrc block -msse?

Cheers
Stefan
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Baselayout-2 progress?

[Doug Klima]

Stefan Hellermann wrote:
> Roy Marples schrieb:
>   
>>> Two small things happened here:
>>>
>>> After Login I the shell looks like:
>>> -bash-3.2#
>>> when I start then bash again manually it looks nice, the environment is not
>>> setup correctly the first time.
>>>       
>> Doesn't sound like an OpenRC issue as such as bash sets up it's own prompt. 
>> Also, OpenRC isn't responsible for setting up the environment. At most we 
>> suck in what's defined in /etc/profile.env
>>
>>     
>>> when rebooting, INIT stops with "no more processes left in this runlevel"
>>> after "remounting /"
>>>       
>> Curious. A suggest you open a bug a http://bugs.marples.name against openrc so 
>> we can move the debugging off this list.
>>
>>     
>
> Here is something other badly broken :) So I don't think it's a openrc issue.
>
> # echo $PATH
> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
> # env | grep PATH
> *nothing*
> # sysctl   # only a example for a app that works
> *works*
> # which sysctl    # this should work if sysctl works without typing /sbin/sysctl
> which: no sysctl in ((null))
>
> I think it could be a CFLAG, I compiled my whole System with -mfpmath=sse (not sse,387),
> but while emerging openrc there are compiler warnings saying it uses -mfpmath=387 because
> sse is not available. Does openrc block -msse?
>
> Cheers
> Stefan
>   
To hijack this thread, you know you're getting worse performance and 
more problematic results by using -mfpmath=sse. This is the very same 
reason that -march=pentium2 / -march=athlon-tbird and newer based CPUs 
don't enable this flag by default. It requires specific changes to 
system headers.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Baselayout-2 progress?

[Stefan Hellermann]

Doug Klima schrieb:
> Stefan Hellermann wrote:
>> Roy Marples schrieb:
>>  
>>>> Two small things happened here:
>>>>
>>>> After Login I the shell looks like:
>>>> -bash-3.2#
>>>> when I start then bash again manually it looks nice, the environment
>>>> is not
>>>> setup correctly the first time.
>>>>       
>>> Doesn't sound like an OpenRC issue as such as bash sets up it's own
>>> prompt. Also, OpenRC isn't responsible for setting up the
>>> environment. At most we suck in what's defined in /etc/profile.env
>>>
>>>    
>>>> when rebooting, INIT stops with "no more processes left in this
>>>> runlevel"
>>>> after "remounting /"
>>>>       
>>> Curious. A suggest you open a bug a http://bugs.marples.name against
>>> openrc so we can move the debugging off this list.
>>>
>>>     
>>
>> Here is something other badly broken :) So I don't think it's a openrc
>> issue.
>>
>> # echo $PATH
>> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
>> # env | grep PATH
>> *nothing*
>> # sysctl   # only a example for a app that works
>> *works*
>> # which sysctl    # this should work if sysctl works without typing
>> /sbin/sysctl
>> which: no sysctl in ((null))
>>
>> I think it could be a CFLAG, I compiled my whole System with
>> -mfpmath=sse (not sse,387),
>> but while emerging openrc there are compiler warnings saying it uses
>> -mfpmath=387 because
>> sse is not available. Does openrc block -msse?
>>
>> Cheers
>> Stefan
>>   
> To hijack this thread, you know you're getting worse performance and
> more problematic results by using -mfpmath=sse. This is the very same
> reason that -march=pentium2 / -march=athlon-tbird and newer based CPUs
> don't enable this flag by default. It requires specific changes to
> system headers.

Thanks for the comment! This is the test-system on a new Via C7, I wanted to do some
performance check's, but haven't so far. I thought it could be a good flag :)

btw: All my problem are gone ... somehow I managed to not install baselayout from Roys
overlay, I only installed openrc.

Thanks Roy for your help!
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Baselayout-2 progress?

[Ed Wildgoose]

> btw: All my problem are gone ... somehow I managed to not install baselayout from Roys
> overlay, I only installed openrc.
>
> Thanks Roy for your help!
>   


So just to be clear, you need to install both openrc AND baselayout from 
the layman profile?  Sounds sensible enough

Cheers

Ed W
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Baselayout-2 progress?

[Ed Wildgoose]

Benedikt Bšoehm wrote:
> Roy Marples schrieb:
>> [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 
>> don't and probably never will support vserver personally, but will 
>> work with Gentoo developers ensuring that at least one version works. 
>> In other words, I'll try and support it but it may break from time to 
>> time.
>>   
> actually, baselayout-2 and openrc work great in vservers ... and it is 
> kind of hard to break it, most things are just "cosmetic", so you 
> don't get errors on vserver startup
>
> some (minor) cosmetic bugs still need to be fixed in openrc, but i'll 
> send a patch to roy really soon now

This would be excellent.

Actually I can't believe that there are people who run "normal" servers 
anymore.  Vserver has such a small overhead and allows so many more 
features that it's just a no brainer (for most servers).  I have been 
very very impressed with it!

Cheers

Ed W
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Baselayout-2 progress?

[Ed Wildgoose]

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

Thanks for continuing to work on this stuff!

Cheers


Ed W
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Baselayout-2 progress?

[Roy Marples]

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 
daemons using python without pidfiles)

I'm not sure that busybox would take any patches to add much of the above as 
most would add more bloat for sure.

Thanks

Roy
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: Baselayout-2 progress?

[Duncan]

Roy Marples <roy@marples.name> posted 200802291707.17936.roy@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.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

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

Re: [gentoo-dev] Re: Baselayout-2 progress?

[Doug Klima]

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


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

Re: [gentoo-dev] Re: Blockers (was: Baselayout-2 progress?)

[Ciaran McCreesh]

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

On Fri, 29 Feb 2008 23:59:06 -0500
Doug Klima <cardoe@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

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

[gentoo-dev] Re: Baselayout-2 progress?

[Duncan]

Doug Klima <cardoe@gentoo.org> posted 47C8E29A.2020003@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.

It's also worth mentioning that a call for testers went out, so it's not 
as if those that answered it, particularly if the DID actively look for 
and file bugs as they found them, were doing it entirely of their own 
accord.  Again, it's doing the developer a favor, so it's a nice gesture 
if the developer chooses to return the favor by smoothing the upgrade 
path.  Not something he has to do, but something he /can/ do, to increase 
the chances of folks who already know the process again taking him up on 
the invitation, the next time he needs something tested. =8^)

So anyway, I thought it was worth asking about, in case it had slipped 
his mind or he hadn't thought of it.  No big deal either way, but it'd be 
a nice gesture if it's not too difficult to setup.

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

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

Re: [gentoo-dev] Re: Baselayout-2 progress?

[Roy Marles]

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
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: Baselayout-2 progress?

[Duncan]

Roy Marles <roy@marples.name> posted 200803011050.50697.roy@marples.name,
excerpted below, on  Sat, 01 Mar 2008 10:50:50 +0000:

> 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

... And thank /you/! =8^)

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

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

Re: [gentoo-dev] Baselayout-2 progress?

[Ed W]

Hmm, all interesting stuff

You mention in the notes also that openrc has some kind of "keepalive" 
function which can restart crashing services.  Can point me towards how 
that works (assuming it needs some kind of config?)

I haven't had any time yet to try this on a test machine, but interested 
to give it a whirl on my embedded (busybox+uclibc) target...

Cheers

Ed W
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Baselayout-2 progress?

[Roy Marples]

On Saturday 01 March 2008 22:26:24 Ed W wrote:
> Hmm, all interesting stuff
>
> You mention in the notes also that openrc has some kind of "keepalive"
> function which can restart crashing services.  Can point me towards how
> that works (assuming it needs some kind of config?)

No such function :)
We can test to see if a service started daemon has crashed or not and report 
accordingly. The user can then restart the service if desired. This can be 
automated through scripts as well, but we don't automatically do this.

Thanks

Roy
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Baselayout-2 progress?

[Bernd Steinhauser]

Roy Marples schrieb:
> 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.
What about the timezone?
Baselayout had a setting for the timezone in /etc/conf.d/clock. 
baselayout-2.0.0
+ openrc doesn't seem to have that. Not needed?

Bernd
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: Baselayout-2 progress?

[Duncan]

Bernd Steinhauser <gentoo@bernd-steinhauser.de> posted
47C9DDA1.2000306@bernd-steinhauser.de, excerpted below, on  Sat, 01 Mar
2008 23:50:09 +0100:

> What about the timezone?
> Baselayout had a setting for the timezone in /etc/conf.d/clock.
> baselayout-2.0.0
> + openrc doesn't seem to have that. Not needed?

Not needed indeed.  The previous setting caused confusion because 
changing it didn't actually change the timezone (this isn't the place for 
the technical details).

Now, the clock config file simply sets local or UTC, while the timezone 
is set using the standard glibc /etc/localtime -> /usr/share/zoneinfo/
<whatever-zone> symlink or the TZ environmental variable (see the tzset 
and hwclock manpages among others).

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

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

Re: [gentoo-dev] Re: Baselayout-2 progress?

[Bernd Steinhauser]

Duncan schrieb:
> Bernd Steinhauser <gentoo@bernd-steinhauser.de> posted
> 47C9DDA1.2000306@bernd-steinhauser.de, excerpted below, on  Sat, 01 Mar
> 2008 23:50:09 +0100:
>
>   
>> What about the timezone?
>> Baselayout had a setting for the timezone in /etc/conf.d/clock.
>> baselayout-2.0.0
>> + openrc doesn't seem to have that. Not needed?
>>     
>
> Not needed indeed.  The previous setting caused confusion because 
> changing it didn't actually change the timezone (this isn't the place for 
> the technical details).
>
> Now, the clock config file simply sets local or UTC, while the timezone 
> is set using the standard glibc /etc/localtime -> /usr/share/zoneinfo/
> <whatever-zone> symlink or the TZ environmental variable (see the tzset 
> and hwclock manpages among others).
>
>   
Then there should be a note, that this setting is deprecated. Currently it
only says:
'If you want to manage /etc/localtime yourself, set this to "".'

If there is a note, that this setting isn't used anymore it won't make 
users,
that still have it set wonder why an etc update wants to remove it.

Bernd
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Baselayout-2 progress?

[Vaeth]

Bernd Steinhauser wrote:
> Duncan schrieb:
> > Bernd Steinhauser <gentoo@bernd-steinhauser.de> posted
> >   
> > > What about the timezone?
> > > Baselayout had a setting for the timezone in /etc/conf.d/clock.
> > > baselayout-2.0.0
> > > + openrc doesn't seem to have that. Not needed?
> > >     
> >
> > Not needed indeed.
> [...]
> Then there should be a note, that this setting is deprecated.

Please observe that the setting from /etc/conf.d/clock is not
only used by baselayout but also by the sys-libs/timezone-data
ebuild: It uses this setting to copy to /etc/timezone
(IIRC the symlink was officially deprecated, because it might point
to a different partition).
So the setting might be deprecated for openrc,
but it is not deprecated for gentoo.

Regards
Martin
-- 
gentoo-dev@lists.gentoo.org mailing list