[gentoo-dev] OpenRC available for testing.

[gentoo-dev] OpenRC available for testing.

[Roy Marples]

Hi List

2008 is here and it's time for some change!

OpenRC is now ready for testing. There are no ebuilds in the tree, but
some are available here [1] that offers a baselayout-2 shell that pulls
in openrc-9999. I'll just offer a git ebuild for the time being, so bugs
can be fixed fast without having to bump all the time. But it should be
fairly smooth going.

As the code has been split, I cannot provide a downgrade path back to
baselayout-1, so if you do downgrade you'll have to reboot the host.
However, it should upgrade perfectly.

I'd appreciate a lot of testing, and just email this thread or me saying
that it works or there's a bug. Hopefully we can get this into portage
soonish.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] OpenRC available for testing.

[Roy Marples]

Uh, forgot the link :)

http://git.overlays.gentoo.org/gitweb/?p=dev/uberlord.git;a=summary

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] OpenRC available for testing.

[Alon Bar-Lev]

Publish to layman?

On 1/1/08, Roy Marples <roy@marples.name> wrote:
> Uh, forgot the link :)
>
> http://git.overlays.gentoo.org/gitweb/?p=dev/uberlord.git;a=summary
>
> --
> gentoo-dev@gentoo.org mailing list
>
>
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] OpenRC available for testing.

[Petteri Räty]

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

Alon Bar-Lev kirjoitti:
> Publish to layman?
> 

Done. layman -a openrc after the web nodes have synced from CVS.

Regards,
Petteri


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

Re: [gentoo-dev] OpenRC available for testing.

[Alon Bar-Lev]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 294 bytes --]

Thanks!
Works!

Roy, why didn't you digest and commit the files?

On 1/1/08, Petteri Räty <betelgeuse@gentoo.org> wrote:
> Alon Bar-Lev kirjoitti:
> > Publish to layman?
> >
>
> Done. layman -a openrc after the web nodes have synced from CVS.
>
> Regards,
> Petteri
>
>
>
éí¢‡^¾\a§¶Š(®	šŠX§‚X¬

Re: [gentoo-dev] OpenRC available for testing.

[Roy Marples]

On Tue, 2008-01-01 at 18:55 +0200, Alon Bar-Lev wrote:
> Thanks!
> Works!
> 
> Roy, why didn't you digest and commit the files?

Dunno. Have now done so.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] OpenRC available for testing.

[Alon Bar-Lev]

Thanks for adding digest, but:

Calculating dependencies /!!! Digest verification failed:
!!! /usr/portage/local/layman/openrc/sys-apps/openrc/openrc-9999.ebuild
!!! Reason: Filesize does not match recorded size
!!! Got: 3629
!!! Expected: 3602

On 1/1/08, Alon Bar-Lev <alonbl@gentoo.org> wrote:
> Thanks!
> Works!
>
> Roy, why didn't you digest and commit the files?
>
> On 1/1/08, Petteri Räty <betelgeuse@gentoo.org> wrote:
> > Alon Bar-Lev kirjoitti:
> > > Publish to layman?
> > >
> >
> > Done. layman -a openrc after the web nodes have synced from CVS.
> >
> > Regards,
> > Petteri
> >
> >
> >
>

Re: [gentoo-dev] OpenRC available for testing.

[Roy Marples]

On Tue, 2008-01-01 at 19:22 +0200, Alon Bar-Lev wrote:
> Thanks for adding digest, but:
> 
> Calculating dependencies /!!! Digest verification failed:
> !!! /usr/portage/local/layman/openrc/sys-apps/openrc/openrc-9999.ebuild
> !!! Reason: Filesize does not match recorded size
> !!! Got: 3629
> !!! Expected: 3602

Fixed

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] OpenRC available for testing.

[Alon Bar-Lev]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 927 bytes --]

Again...
!!! Digest verification failed:
!!! /usr/portage/local/layman/openrc/sys-apps/openrc/openrc-9999.ebuild
!!! Reason: Filesize does not match recorded size
!!! Got: 3666
!!! Expected: 3629

On 1/1/08, Alon Bar-Lev <alonbl@gentoo.org> wrote:
> Thanks for adding digest, but:
>
> Calculating dependencies /!!! Digest verification failed:
> !!! /usr/portage/local/layman/openrc/sys-apps/openrc/openrc-9999.ebuild
> !!! Reason: Filesize does not match recorded size
> !!! Got: 3629
> !!! Expected: 3602
>
> On 1/1/08, Alon Bar-Lev <alonbl@gentoo.org> wrote:
> > Thanks!
> > Works!
> >
> > Roy, why didn't you digest and commit the files?
> >
> > On 1/1/08, Petteri Räty <betelgeuse@gentoo.org> wrote:
> > > Alon Bar-Lev kirjoitti:
> > > > Publish to layman?
> > > >
> > >
> > > Done. layman -a openrc after the web nodes have synced from CVS.
> > >
> > > Regards,
> > > Petteri
> > >
> > >
> > >
> >
>
éí¢‡^¾\a§¶Š(®	šŠX§‚X¬

Re: [gentoo-dev] OpenRC available for testing.

[Roy Marples]

On Thu, 2008-01-03 at 08:43 +0200, Alon Bar-Lev wrote:
> Again...
> !!! Digest verification failed:
> !!! /usr/portage/local/layman/openrc/sys-apps/openrc/openrc-9999.ebuild
> !!! Reason: Filesize does not match recorded size
> !!! Got: 3666
> !!! Expected: 3629

I knew there was a reason for not adding digests :)
I've removed them for now.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] OpenRC available for testing.

[Alon Bar-Lev]

On 1/3/08, Roy Marples <roy@marples.name> wrote:
> I knew there was a reason for not adding digests :)
> I've removed them for now.

Why remove?!?!?!
This way we cannot use layman in order to sync with your changes.

I don't know why you choose git for development, but the cost of it is
to readd every modification to commit.

Please maintain a digest on tree.

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

Re: [gentoo-dev] OpenRC available for testing.

[Roy Marples]

On Thu, 2008-01-03 at 12:02 +0200, Alon Bar-Lev wrote:
> On 1/3/08, Roy Marples <roy@marples.name> wrote:
> > I knew there was a reason for not adding digests :)
> > I've removed them for now.
> 
> Why remove?!?!?!
> This way we cannot use layman in order to sync with your changes.

Because Gentoo/Linux isn't my primary development platform and no-one
else volunteered to maintain ebuilds.

They will be put back in place when I can boot into a Gentoo based
platform to re-make the digests and Manifest.

The fact that it's git is irrelevant here.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] OpenRC available for testing.

[Thomas Pani]

Works fine here (x86). Having set both RC_{QUIET,VERBOSE}="no" it's a
little more verbose than what I'm used to (especially udev loading
madwifi) but that's early enough in the boot sequence not to bug me.

It took me some time to find /etc/conf.d/modules, but it's certainly
useful :).

Regards,
thomas

Roy Marples wrote:
> I'd appreciate a lot of testing, and just email this thread or me saying
> that it works or there's a bug. Hopefully we can get this into portage
> soonish.
> 
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] OpenRC available for testing.

[TimeBreach]

Thomas Pani a écrit :
> Works fine here (x86). Having set both RC_{QUIET,VERBOSE}="no" it's a
> little more verbose than what I'm used to (especially udev loading
> madwifi) but that's early enough in the boot sequence not to bug me.
> 
> It took me some time to find /etc/conf.d/modules, but it's certainly
> useful :).
> 
> Regards,
> thomas
> 
> Roy Marples wrote:
>> I'd appreciate a lot of testing, and just email this thread or me saying
>> that it works or there's a bug. Hopefully we can get this into portage
>> soonish.
>>

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] OpenRC available for testing.

[Roy Marples]

On Tue, 2008-01-01 at 20:16 +0100, Thomas Pani wrote:
> Works fine here (x86). Having set both RC_{QUIET,VERBOSE}="no" it's a
> little more verbose than what I'm used to (especially udev loading
> madwifi) but that's early enough in the boot sequence not to bug me.

That's a udev issue, not a baselayout one as far as I can tell.

> It took me some time to find /etc/conf.d/modules, but it's certainly
> useful :).

It also means all config files, with the exceptions of fstab and rc.conf
are in conf.d and not some random dir :)

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] OpenRC available for testing.

[Alon Bar-Lev]

On 1/1/08, Roy Marples <roy@marples.name> wrote:
> > It took me some time to find /etc/conf.d/modules, but it's certainly
> > useful :).
>
> It also means all config files, with the exceptions of fstab and rc.conf
> are in conf.d and not some random dir :)

Took me a while too... Some ChangeLog documentation should be available.

Also I think this is a regression:
# update-modules
/sbin/update-modules: line 118: KV_to_int: command not found
/sbin/update-modules: line 118: KV_to_int: command not found
/sbin/update-modules: line 263: is_older_than: command not found

And I think there is a circular dependency of:
openrc->init-module-tools->baselayout->openrc

I did not understand the comments in rc.conf regarding the external
dependency...
# It's possible to define extra dependencies for services like so
#rc_config="/etc/foo"
#rc_need="openvpn"
#rc_use="net.eth0"
#rc_after="clock"
#rc_before="local"

How can I add a specific service dependency using this mechanism? The
modified service name is missing...

I also notice that the timezone of clock is gone, any alternative?
Also the network dependency of stopping/starting services when network
is unavailable/available is gone, any alternative?

Thanks!
Alon.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] OpenRC available for testing.

[Roy Marples]

On Wed, 2008-01-02 at 16:39 +0200, Alon Bar-Lev wrote:
> On 1/1/08, Roy Marples <roy@marples.name> wrote:
> > > It took me some time to find /etc/conf.d/modules, but it's certainly
> > > useful :).
> >
> > It also means all config files, with the exceptions of fstab and rc.conf
> > are in conf.d and not some random dir :)
> 
> Took me a while too... Some ChangeLog documentation should be available.
> 
> Also I think this is a regression:
> # update-modules
> /sbin/update-modules: line 118: KV_to_int: command not found
> /sbin/update-modules: line 118: KV_to_int: command not found
> /sbin/update-modules: line 263: is_older_than: command not found

Those functions were removed from functions.sh as only update-modules
still uses them. udev does use KV_to_int though. I don't really want to
add those functions back. Although we could trivially add is_older_than
as a C applet built into rc.

> And I think there is a circular dependency of:
> openrc->init-module-tools->baselayout->openrc

Quite possibly. I'm sure some bright spark can actually say what's wrong
before it hits portage.

> 
> I did not understand the comments in rc.conf regarding the external
> dependency...
> # It's possible to define extra dependencies for services like so
> #rc_config="/etc/foo"
> #rc_need="openvpn"
> #rc_use="net.eth0"
> #rc_after="clock"
> #rc_before="local"
> 
> How can I add a specific service dependency using this mechanism? The
> modified service name is missing...

They're supposed to belong in /etc/conf.d/$SVCNAME
Maybe you could suggest better wording?

I suppose we could also allow
rc_$SVCNAME_$depend to work, for example

rc_clock_need="modules"

> I also notice that the timezone of clock is gone, any alternative?
> Also the network dependency of stopping/starting services when network
> is unavailable/available is gone, any alternative?

The timezone was variable was just a hack for the timezone ebuild to
update /etc/localtime if it's not a symlink. I'm striving to remove all
"Gentooisms" from it so that it really is platform neutral.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] OpenRC available for testing.

[Alon Bar-Lev]

On 1/2/08, Roy Marples <roy@marples.name> wrote:
> Those functions were removed from functions.sh as only update-modules
> still uses them. udev does use KV_to_int though. I don't really want to
> add those functions back. Although we could trivially add is_older_than
> as a C applet built into rc.

So who should take care of this?

> > How can I add a specific service dependency using this mechanism? The
> > modified service name is missing...
>
> They're supposed to belong in /etc/conf.d/$SVCNAME
> Maybe you could suggest better wording?
>
> I suppose we could also allow
> rc_$SVCNAME_$depend to work, for example
>
> rc_clock_need="modules"

Oh... This is good, just document it... :)

You did not reply regarding this one:

> > Also the network dependency of stopping/starting services when network
> > is unavailable/available is gone, any alternative?

Regards,
Alon.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] OpenRC available for testing.

[Roy Marples]

On Wed, 2008-01-02 at 17:15 +0200, Alon Bar-Lev wrote:
> On 1/2/08, Roy Marples <roy@marples.name> wrote:
> > Those functions were removed from functions.sh as only update-modules
> > still uses them. udev does use KV_to_int though. I don't really want to
> > add those functions back. Although we could trivially add is_older_than
> > as a C applet built into rc.
> 
> So who should take care of this?

update-modules maintainer which would be vapier.
I notified him on IRC about this a few months ago, but he never replied
one way or the other.

> > > How can I add a specific service dependency using this mechanism? The
> > > modified service name is missing...
> >
> > They're supposed to belong in /etc/conf.d/$SVCNAME
> > Maybe you could suggest better wording?
> >
> > I suppose we could also allow
> > rc_$SVCNAME_$depend to work, for example
> >
> > rc_clock_need="modules"
> 
> Oh... This is good, just document it... :)

Done!
re-emerge to test.

> You did not reply regarding this one:
> 
> > > Also the network dependency of stopping/starting services when network
> > > is unavailable/available is gone, any alternative?

It's not gone at all - just different. It's also no longer net specific,
and applies to any service that can be multiplexed. But lets use net as
the example as everyone understands that.

With rc_depend_strict=YES (which is the default)
If any services added to the current runlevel provide net then all those
services will be used. If none found, then check the boot runlevel and
use those. If none found then nothing provides net as such.

With rc_depend_strict=NO we check the following and abort at the first
match.
Check if any started service provide net - if so use them.
Check if any inactive services provide net - if so use them.
Check if any coldplugged services provide net - if so use them.
If nothing found then list ALL installed services that provide net.

Hopefully that makes things a little more clear.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] OpenRC available for testing.

[Mike Frysinger]

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

On Wednesday 02 January 2008, Roy Marples wrote:
> On Wed, 2008-01-02 at 16:39 +0200, Alon Bar-Lev wrote:
> > On 1/1/08, Roy Marples <roy@marples.name> wrote:
> > > > It took me some time to find /etc/conf.d/modules, but it's certainly
> > > > useful :).
> > >
> > > It also means all config files, with the exceptions of fstab and
> > > rc.conf are in conf.d and not some random dir :)
> >
> > Took me a while too... Some ChangeLog documentation should be available.
> >
> > Also I think this is a regression:
> > # update-modules
> > /sbin/update-modules: line 118: KV_to_int: command not found
> > /sbin/update-modules: line 118: KV_to_int: command not found
> > /sbin/update-modules: line 263: is_older_than: command not found
>
> Those functions were removed from functions.sh as only update-modules
> still uses them. udev does use KV_to_int though. I don't really want to
> add those functions back. Although we could trivially add is_older_than
> as a C applet built into rc.

while is_older_than is negotiable, removing KV_* is not.  those are pretty 
tight utility functions which duplication in $random-packages will only lead 
to problems (especially considering the history of making sure they were 
coded right).  they've weathered quite a long time and should be pretty much 
unchanged, so there is no good reason to omit them.  there is no overhead of 
having them available and maintaining them.

if you want a cleaner interface for is_older_than, then we could hammer that 
out, but if it's just a pass through to a C applet, then leaving it alone 
makes sense.

> > I also notice that the timezone of clock is gone, any alternative?
> > Also the network dependency of stopping/starting services when network
> > is unavailable/available is gone, any alternative?
>
> The timezone was variable was just a hack for the timezone ebuild to
> update /etc/localtime if it's not a symlink. I'm striving to remove all
> "Gentooisms" from it so that it really is platform neutral.

you view the purpose of TIMEZONE incorrectly.  it was a central script 
parasable location to store the system timezone.  every distribution out 
there does it somehow.  the way for OpenRC to do it is set the variable 
in /etc/conf.d/clock.  the fact that currently the timezone ebuild is the 
only one using it is irrelevant.
-mike

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

Re: [gentoo-dev] OpenRC available for testing.

[Roy Marples]

On Thu, 2008-01-03 at 10:49 -0500, Mike Frysinger wrote:
> while is_older_than is negotiable, removing KV_* is not.  those are pretty 
> tight utility functions which duplication in $random-packages will only lead 
> to problems (especially considering the history of making sure they were 
> coded right).  they've weathered quite a long time and should be pretty much 
> unchanged, so there is no good reason to omit them.  there is no overhead of 
> having them available and maintaining them.

KV_* only makes sense when dealing with Linux version numbers are
they're always numeric. The BSD's on the other hand include textual
elemants too.
uname -r on this machine is 7.0-RC1.

luckily, baselayout-2 as it stands in portage only exports the KV_to_int
function so that's the only one we should be dealing with.

So, the question is, do we want to maintain one massive KV_to_int that
has different code paths for uname -s output, or get function.sh to
include an OS specific file we supply just for this one function?

Or just put the function in modules-update and udev as they are the only
two applications that use it.

> if you want a cleaner interface for is_older_than, then we could hammer that 
> out, but if it's just a pass through to a C applet, then leaving it alone 
> makes sense.

Currently it's neither as it's been integrated into the librc dependency
code. Again, the only consumer of this function is now modules-update.

> > > I also notice that the timezone of clock is gone, any alternative?
> > > Also the network dependency of stopping/starting services when network
> > > is unavailable/available is gone, any alternative?
> >
> > The timezone was variable was just a hack for the timezone ebuild to
> > update /etc/localtime if it's not a symlink. I'm striving to remove all
> > "Gentooisms" from it so that it really is platform neutral.
> 
> you view the purpose of TIMEZONE incorrectly.  it was a central script 
> parasable location to store the system timezone.  every distribution out 
> there does it somehow.  the way for OpenRC to do it is set the variable 
> in /etc/conf.d/clock.  the fact that currently the timezone ebuild is the 
> only one using it is irrelevant.

Then I suggest that conf.d/clock is the wrong place for it as if it was
set there then it implies that `/etc/init.d/clock start` would change to
that timezone, which is clearly not the case.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: OpenRC available for testing.

[Steve Long]

Roy Marples wrote:
> So, the question is, do we want to maintain one massive KV_to_int that
> has different code paths for uname -s output, or get function.sh to
> include an OS specific file we supply just for this one function?
> 
> Or just put the function in modules-update and udev as they are the only
> two applications that use it.
>
I vote for option 1b, if that's how you've decided to implement it. I'd
rather it was just a simple function in the OS-specific function.sh though.

>> if you want a cleaner interface for is_older_than, then we could hammer
>> that out, but if it's just a pass through to a C applet, then leaving it
>> alone makes sense.
> 
> Currently it's neither as it's been integrated into the librc dependency
> code. Again, the only consumer of this function is now modules-update.
> 
OK, but that doesn't mean it won't be needed in the future. It's already
there, it might be handy later, leave it available imho.


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

Re: [gentoo-dev] OpenRC available for testing.

[Mike Frysinger]

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

On Thursday 03 January 2008, Roy Marples wrote:
> On Thu, 2008-01-03 at 10:49 -0500, Mike Frysinger wrote:
> > while is_older_than is negotiable, removing KV_* is not.  those are
> > pretty tight utility functions which duplication in $random-packages will
> > only lead to problems (especially considering the history of making sure
> > they were coded right).  they've weathered quite a long time and should
> > be pretty much unchanged, so there is no good reason to omit them.  there
> > is no overhead of having them available and maintaining them.
>
> KV_* only makes sense when dealing with Linux version numbers are
> they're always numeric. The BSD's on the other hand include textual
> elemants too.
> uname -r on this machine is 7.0-RC1.

that's incorrect ... linux uname's often have textual content as well 
(-mm, -git, -rc, -fooie).  the KV_* functions only parse out the relevant 
values and in the case of the linux kernel, that is:
major.minor.micro[.stable]

> luckily, baselayout-2 as it stands in portage only exports the KV_to_int
> function so that's the only one we should be dealing with.

i'm not so sure ... the other functions are trivial to implement and 
considering KV_to_int is implemented based on those ... no reason to cull the 
functions when they are certainly useful.

> So, the question is, do we want to maintain one massive KV_to_int that
> has different code paths for uname -s output, or get function.sh to
> include an OS specific file we supply just for this one function?

how you want to architect it in the backend is up to you, but the latter 
probably makes more sense.  my concern is for the frontend ("API") and that 
is that the functions need to be exported.

> Or just put the function in modules-update and udev as they are the only
> two applications that use it.

no, that is most certainly not where we want to go

> > if you want a cleaner interface for is_older_than, then we could hammer
> > that out, but if it's just a pass through to a C applet, then leaving it
> > alone makes sense.
>
> Currently it's neither as it's been integrated into the librc dependency
> code. Again, the only consumer of this function is now modules-update.

that may simply be because the only people who have been tracking the code 
closely are you and me ... considering the nature of the function, it sounds 
like a good function other things can leverage as it provides make-style 
timestamp tracking for conditionally updating of files.

> > > > I also notice that the timezone of clock is gone, any alternative?
> > > > Also the network dependency of stopping/starting services when
> > > > network is unavailable/available is gone, any alternative?
> > >
> > > The timezone was variable was just a hack for the timezone ebuild to
> > > update /etc/localtime if it's not a symlink. I'm striving to remove all
> > > "Gentooisms" from it so that it really is platform neutral.
> >
> > you view the purpose of TIMEZONE incorrectly.  it was a central script
> > parasable location to store the system timezone.  every distribution out
> > there does it somehow.  the way for OpenRC to do it is set the variable
> > in /etc/conf.d/clock.  the fact that currently the timezone ebuild is the
> > only one using it is irrelevant.
>
> Then I suggest that conf.d/clock is the wrong place for it as if it was
> set there then it implies that `/etc/init.d/clock start` would change to
> that timezone, which is clearly not the case.

that's fair.  i'd also add that forcing the value into conf.d/clock forces a 
reliance on openrc and prevents alternative init packages (which we've seen 
people use).  i know debian uses /etc/localtime, any one know what other 
distro conventions are in use out there ?
-mike

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

Re: [gentoo-dev] OpenRC available for testing.

[Chris Gianelloni]

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

On Wed, 2008-01-09 at 16:26 -0500, Mike Frysinger wrote:
> that's fair.  i'd also add that forcing the value into conf.d/clock
> forces a reliance on openrc and prevents alternative init packages
> (which we've seen people use).  i know debian uses /etc/localtime, any
> one know what other distro conventions are in use out there ?

Well, RH/RHEL/Fedora/CentOS/Mandrake/Mandriva all use /etc/localtime

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer

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

Re: [gentoo-dev] OpenRC available for testing.

[Mike Frysinger]

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

On Wednesday 09 January 2008, Chris Gianelloni wrote:
> On Wed, 2008-01-09 at 16:26 -0500, Mike Frysinger wrote:
> > that's fair.  i'd also add that forcing the value into conf.d/clock
> > forces a reliance on openrc and prevents alternative init packages
> > (which we've seen people use).  i know debian uses /etc/localtime, any
> > one know what other distro conventions are in use out there ?
>
> Well, RH/RHEL/Fedora/CentOS/Mandrake/Mandriva all use /etc/localtime

err, sorry, you're right of course.  every glibc guy uses /etc/localtime.  i 
meant /etc/timezone.
-mike

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

Re: [gentoo-dev] OpenRC available for testing.

[Mike Frysinger]

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

On Tuesday 01 January 2008, Roy Marples wrote:
> On Tue, 2008-01-01 at 20:16 +0100, Thomas Pani wrote:
> > It took me some time to find /etc/conf.d/modules, but it's certainly
> > useful :).
>
> It also means all config files, with the exceptions of fstab and rc.conf
> are in conf.d and not some random dir :)

it also means a deprecation notice needs to be added here and everywhere else 
that has changed.  perhaps create a small script that takes 
the /etc/modules.autoload.d/ directory and converts it into the 
corresponding /etc/conf.d/modules file.
-mike

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

Re: [gentoo-dev] OpenRC available for testing.

[Roy Marples]

On Thu, 2008-01-03 at 10:50 -0500, Mike Frysinger wrote:
> it also means a deprecation notice needs to be added here and everywhere else 
> that has changed.  perhaps create a small script that takes 
> the /etc/modules.autoload.d/ directory and converts it into the 
> corresponding /etc/conf.d/modules file.

I'll go with a conversion script in the ebuild I think.

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] OpenRC available for testing.

[Roy Marples]

On Thu, 2008-01-03 at 16:24 +0000, Roy Marples wrote:
> On Thu, 2008-01-03 at 10:50 -0500, Mike Frysinger wrote:
> > it also means a deprecation notice needs to be added here and everywhere else 
> > that has changed.  perhaps create a small script that takes 
> > the /etc/modules.autoload.d/ directory and converts it into the 
> > corresponding /etc/conf.d/modules file.
> 
> I'll go with a conversion script in the ebuild I think.

I've gone with a warning message instead as a converstion script will
take a little while. It should suffice for the time being.

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] OpenRC available for testing.

[Mike Frysinger]

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

On Thursday 03 January 2008, Roy Marples wrote:
> On Thu, 2008-01-03 at 16:24 +0000, Roy Marples wrote:
> > On Thu, 2008-01-03 at 10:50 -0500, Mike Frysinger wrote:
> > > it also means a deprecation notice needs to be added here and
> > > everywhere else that has changed.  perhaps create a small script that
> > > takes
> > > the /etc/modules.autoload.d/ directory and converts it into the
> > > corresponding /etc/conf.d/modules file.
> >
> > I'll go with a conversion script in the ebuild I think.
>
> I've gone with a warning message instead as a converstion script will
> take a little while. It should suffice for the time being.

we'll need a full review before going ~arch obviously ... i imagine 
modules/clock arent the only difference
-mike

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

Re: [gentoo-dev] OpenRC available for testing.

[Santiago M. Mola]

On Jan 1, 2008 1:41 PM, Roy Marples <roy@marples.name> wrote:
>
> I'd appreciate a lot of testing, and just email this thread or me saying
> that it works or there's a bug. Hopefully we can get this into portage
> soonish.
>

It's badly broken on my system (Gentoo Linux amd64). Compilation fails
without dying and the package ends installed without /sbin/rc... which
makes the reboot a wonderful experience ;-)

Here's src_compile output:

>>> Starting src_compile
make -j4 LIB=lib64 OS=Linux TERMCAP=ncurses PAM=pam CC=/usr/lib/ccache/bin/gcc
make[1]: Entering directory
`/var/tmp/paludis/sys-apps/openrc-9999/work/openrc-9999/conf.d'
make[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent
make rule.
make[1]: Leaving directory
`/var/tmp/paludis/sys-apps/openrc-9999/work/openrc-9999/conf.d'
make[1]: Entering directory
`/var/tmp/paludis/sys-apps/openrc-9999/work/openrc-9999/conf.d.Linux'
make[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent
make rule.
make[1]: Leaving directory
`/var/tmp/paludis/sys-apps/openrc-9999/work/openrc-9999/conf.d.Linux'
make[1]: Entering directory
`/var/tmp/paludis/sys-apps/openrc-9999/work/openrc-9999/doc.Linux'
make[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent
make rule.
make[1]: Leaving directory
`/var/tmp/paludis/sys-apps/openrc-9999/work/openrc-9999/doc.Linux'
make[1]: Entering directory
`/var/tmp/paludis/sys-apps/openrc-9999/work/openrc-9999/etc'
make[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent
make rule.
make[1]: Leaving directory
`/var/tmp/paludis/sys-apps/openrc-9999/work/openrc-9999/etc'
make[1]: Entering directory
`/var/tmp/paludis/sys-apps/openrc-9999/work/openrc-9999/etc.Linux'
make[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent
make rule.
make[1]: Leaving directory
`/var/tmp/paludis/sys-apps/openrc-9999/work/openrc-9999/etc.Linux'
make[1]: Entering directory
`/var/tmp/paludis/sys-apps/openrc-9999/work/openrc-9999/init.d'
make[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent
make rule.
make[1]: Leaving directory
`/var/tmp/paludis/sys-apps/openrc-9999/work/openrc-9999/init.d'
make[1]: Entering directory
`/var/tmp/paludis/sys-apps/openrc-9999/work/openrc-9999/init.d.Linux'
make[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent
make rule.
make[1]: Leaving directory
`/var/tmp/paludis/sys-apps/openrc-9999/work/openrc-9999/init.d.Linux'
make[1]: Entering directory
`/var/tmp/paludis/sys-apps/openrc-9999/work/openrc-9999/man'
make[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent
make rule.
make[1]: Leaving directory
`/var/tmp/paludis/sys-apps/openrc-9999/work/openrc-9999/man'
make[1]: Entering directory
`/var/tmp/paludis/sys-apps/openrc-9999/work/openrc-9999/net'
make[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent
make rule.
make[1]: Leaving directory
`/var/tmp/paludis/sys-apps/openrc-9999/work/openrc-9999/net'
make[1]: Entering directory
`/var/tmp/paludis/sys-apps/openrc-9999/work/openrc-9999/net.Linux'
make[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent
make rule.
make[1]: Leaving directory
`/var/tmp/paludis/sys-apps/openrc-9999/work/openrc-9999/net.Linux'
make[1]: Entering directory
`/var/tmp/paludis/sys-apps/openrc-9999/work/openrc-9999/runlevels'
make[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent
make rule.
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory
`/var/tmp/paludis/sys-apps/openrc-9999/work/openrc-9999/runlevels'
make[1]: Entering directory
`/var/tmp/paludis/sys-apps/openrc-9999/work/openrc-9999/runlevels.Linux'
make[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent
make rule.
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory
`/var/tmp/paludis/sys-apps/openrc-9999/work/openrc-9999/runlevels.Linux'
make[1]: Entering directory
`/var/tmp/paludis/sys-apps/openrc-9999/work/openrc-9999/sh'
make[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent
make rule.
make[1]: Leaving directory
`/var/tmp/paludis/sys-apps/openrc-9999/work/openrc-9999/sh'
make[1]: Entering directory
`/var/tmp/paludis/sys-apps/openrc-9999/work/openrc-9999/sh.Linux'
make[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent
make rule.
make[1]: Leaving directory
`/var/tmp/paludis/sys-apps/openrc-9999/work/openrc-9999/sh.Linux'
make[1]: Entering directory
`/var/tmp/paludis/sys-apps/openrc-9999/work/openrc-9999/src'
make[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent
make rule.
sed -n -e 's/^VERSION =[[:space:]]*\([^[:space:]]*\).*/#define VERSION
"\1\"/p' ../Makefile > version.h
/usr/lib/ccache/bin/gcc -DLIB=\"lib64\" -D_BSD_SOURCE
-D_XOPEN_SOURCE=500 -DHAVE_TERMCAP -march=nocona -O2 -pipe -O2 -pipe
-pedantic -std=c99 -Wall -Wunused -Wimplicit -Wshadow -Wformat=2
-Wmissing-declarations -Wno-missing-prototypes -Wwrite-strings
-Wbad-function-cast -Wnested-externs -Wcomment -Winline
-Wchar-subscripts -Wcast-align -Wno-format-nonliteral
-Wdeclaration-after-statement  -Wsequence-point  -Wextra  -fPIC -c
gcc: no input files
make[1]: *** [libeinfo.o] Error 1
make[1]: Leaving directory
`/var/tmp/paludis/sys-apps/openrc-9999/work/openrc-9999/src'
>>> Done src_compile

Using portage doesn't make any difference.

And here's my emerge --info
mangurrian openrc # emerge --info
Portage 2.1.3.19 (default-linux/amd64/2007.0/desktop, gcc-4.1.2,
glibc-2.6.1-r0, 2.6.23-gentoo-r5 x86_64)
=================================================================
System uname: 2.6.23-gentoo-r5 x86_64 Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz
Timestamp of tree: Tue, 01 Jan 2008 19:00:05 +0000
distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port
3632) [disabled]
ccache version 2.4 [disabled]
app-shells/bash:     3.2_p17-r1
dev-java/java-config: 1.3.7, 2.0.33-r1
dev-lang/python:     2.4.4-r6, 2.5.1-r4
dev-python/pycrypto: 2.0.1-r6
dev-util/ccache:     2.4-r7
sys-apps/baselayout: 2.0.0
sys-apps/sandbox:    1.2.18.1-r2
sys-devel/autoconf:  2.13, 2.61-r1
sys-devel/automake:  1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.18-r1
sys-devel/gcc-config: 1.4.0-r4
sys-devel/libtool:   1.5.24
virtual/os-headers:  2.6.23-r2
ACCEPT_KEYWORDS="amd64"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe -march=nocona"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config
/usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf
/etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/
/etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/
/etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c
/etc/udev/rules.d"
CXXFLAGS="-O2 -pipe -march=nocona"
DISTDIR="/var/distfiles"
FEATURES="collision-protect distlocks metadata-transfer
multilib-strict parallel-fetch sandbox sfperms splitdebug strict
unmerge-orphans userfetch"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/linux/distributions/gentoo"
LANG="es_ES.UTF-8"
LC_ALL="es_ES.UTF-8"
LDFLAGS="-Wl,-O1,--as-needed"
LINGUAS="es es_ES en"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times
--compress --force --whole-file --delete --delete-after --stats
--timeout=180 --exclude=/distfiles --exclude=/local
--exclude=/packages --filter=H_**/files/digest-*"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/var/pm/repos/paludis-extras
/home/coldwind/dev/sunrise/sunrise"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="X a52 aac aalib ace acl acpi aiglx alsa amd64 apache2 asf avahi
bash-completion berkdb bitmap-fonts bluetooth branding cairo cdda cddb
cdio cdr cli cracklib crypt cscope css cups d dbus dhcp dri dvd dvdr
dvdread dvi eds emboss encode evo expat fam festival ffmpeg fftw
firefox flac fltk fmod fortran ftp gd gdbm geoip gif gimp glitz glsa
gpm gstreamer gtk hal iconv ipod ipv6 irc irssi isdnlog jabber jack
javascript jingle jpeg jpeg2k kde kerberos kqemu lame ldap libcaca
libnotify mad matroska midi mikmod mjpeg mmx mng modplug mp3 mp4 mpeg
mplayer msn mudflap musicbrainz mysql ncurses nfs nls nptl nptlonly
ntfs offensive ogg openal opengl openmp pam pango pcmcia pcre pdf perl
php png pppd python qt3 qt3support qt4 quicktime rar readline
reflection ruby samba sdl session sid sndfile sockets softmmu spell
spl sqlite sse sse2 ssl startup-notification subtitles subversion svg
tcpd tga theora threads tiff truetype truetype-fonts type1-fonts
unicode usb v4l2 vcd vfat vim vim-syntax visualization vnc vorbis wma
wmf x264 xanim xcomposite xinerama xml xml2 xorg xosd xpm xrandr xsl
xv xvid zip zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem
bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801
hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx
via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix
dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat
linear meter mulaw multi null plug rate route share shm softvol"
APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon
authn_dbm authn_default authn_file authz_dbm authz_default
authz_groupfile authz_host authz_owner authz_user autoindex cache dav
dav_fs dav_lock deflate dir disk_cache env expires ext_filter
file_cache filter headers include info log_config logio mem_cache mime
mime_magic negotiation rewrite setenvif speling status unique_id
userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard
mouse synaptics joystick" KERNEL="linux" LCD_DEVICES="bayrad cfontz
cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="es
es_ES en" USERLAND="GNU" VIDEO_CARDS="none i810 vesa"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK,
PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

-- 
Santiago M. Mola
Jabber ID: cooldwind@gmail.com
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] OpenRC available for testing.

[Roy Marples]

On Wed, 2008-01-02 at 17:52 +0100, Santiago M. Mola wrote:
> On Jan 1, 2008 1:41 PM, Roy Marples <roy@marples.name> wrote:
> >
> > I'd appreciate a lot of testing, and just email this thread or me saying
> > that it works or there's a bug. Hopefully we can get this into portage
> > soonish.
> gcc: no input files
> make[1]: *** [libeinfo.o] Error 1
> make[1]: Leaving directory

Once either GNU Make optionally includes .depend by default OR FreeBSD
make can specify an optional include in the Makefile I can avoid the
trickery needed here.

We now force a `make depend` which sould solve this.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] OpenRC available for testing.

[Nathan Smith]

On Tue, 01 Jan 2008 12:41:00 +0000
Roy Marples <roy@marples.name> wrote:

> Hi List
> 
> 2008 is here and it's time for some change!
> 
> OpenRC is now ready for testing. There are no ebuilds in the tree, but
> some are available here [1] that offers a baselayout-2 shell that
> pulls in openrc-9999. I'll just offer a git ebuild for the time
> being, so bugs can be fixed fast without having to bump all the time.
> But it should be fairly smooth going.

I am wondering about the blocker on baselayout < 2.0 in your git
overlay ebuild for baselayout-2.  Is there some reason that the upgrade
path from baselayout-1 to -2 will not work for openrc?

-- 
Nathan Smith
ndansmith@gmail.com
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] OpenRC available for testing.

[Roy Marples]

On Wed, 2008-01-02 at 20:38 -0800, Nathan Smith wrote:
> On Tue, 01 Jan 2008 12:41:00 +0000
> Roy Marples <roy@marples.name> wrote:
> 
> > Hi List
> > 
> > 2008 is here and it's time for some change!
> > 
> > OpenRC is now ready for testing. There are no ebuilds in the tree, but
> > some are available here [1] that offers a baselayout-2 shell that
> > pulls in openrc-9999. I'll just offer a git ebuild for the time
> > being, so bugs can be fixed fast without having to bump all the time.
> > But it should be fairly smooth going.
> 
> I am wondering about the blocker on baselayout < 2.0 in your git
> overlay ebuild for baselayout-2.  Is there some reason that the upgrade
> path from baselayout-1 to -2 will not work for openrc?

File ownership of a few things changed from baselayout -> openrc. Enough
so that openrc is a self enclosed product, but relies on system files
that baselayout supplies.

A blocker is the only way I know of doing this so portage doesn't
complain about overwriting files owned by another package.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] OpenRC available for testing.

[Alon Bar-Lev]

At: default.mk, the  _SUBDIR loop is somehow incorrect, as it will not
pass subdir make result to rule.
So if rule fails the build still considered a success.

make[1]: *** [start-stop-daemon.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory
`/var/tmp/portage/sys-apps/openrc-9999/work/openrc-9999/src'
>>> Source compiled.

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

Re: [gentoo-dev] OpenRC available for testing.

[Roy Marples]

On Thu, 2008-01-03 at 10:58 +0200, Alon Bar-Lev wrote:
> At: default.mk, the  _SUBDIR loop is somehow incorrect, as it will not
> pass subdir make result to rule.
> So if rule fails the build still considered a success.
> 
> make[1]: *** [start-stop-daemon.o] Error 1
> make[1]: *** Waiting for unfinished jobs....
> make[1]: Leaving directory
> `/var/tmp/portage/sys-apps/openrc-9999/work/openrc-9999/src'
> >>> Source compiled.

What version of gnu make?
What MAKEOPTS do you have set?
Does it work outside of the ebuild?

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] OpenRC available for testing.

[Roy Marples]

On Thu, 2008-01-03 at 09:50 +0000, Roy Marples wrote:
> On Thu, 2008-01-03 at 10:58 +0200, Alon Bar-Lev wrote:
> > At: default.mk, the  _SUBDIR loop is somehow incorrect, as it will not
> > pass subdir make result to rule.
> > So if rule fails the build still considered a success.
> > 
> > make[1]: *** [start-stop-daemon.o] Error 1
> > make[1]: *** Waiting for unfinished jobs....
> > make[1]: Leaving directory
> > `/var/tmp/portage/sys-apps/openrc-9999/work/openrc-9999/src'
> > >>> Source compiled.
> 
> What version of gnu make?
> What MAKEOPTS do you have set?
> Does it work outside of the ebuild?

Never mind, I have this fixed now.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] OpenRC available for testing.

[Richard Brown]

On Jan 3, 2008 10:13 AM, Roy Marples <roy@marples.name> wrote:
> > What version of gnu make?
> > What MAKEOPTS do you have set?
> > Does it work outside of the ebuild?
>
> Never mind, I have this fixed now.

While this thread remains highly entertaining, I'm sure as a past
gentoo developer Roy remembers that we don't generally use gentoo-dev
to bug fix poorly written makefiles, we have a bugzilla where people
interested in fixing it can help, or perhaps upstream have a list
where they can discuss it.

Warmest Regards in the New Year,

-- 
Richard Brown
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] OpenRC available for testing.

[Roy Marples]

On Thu, 2008-01-03 at 10:18 +0000, Richard Brown wrote:
> While this thread remains highly entertaining, I'm sure as a past
> gentoo developer Roy remembers that we don't generally use gentoo-dev
> to bug fix poorly written makefiles, we have a bugzilla where people
> interested in fixing it can help, or perhaps upstream have a list
> where they can discuss it.

One of the "deals" was that whilst Gentoo would likely use OpenRC it
would still do the hosting. As Gentoo would be using it, it does pertain
to Gentoo development.

So either I host my own bug tracker (which I'm more than happy to do
btw), or Gentoo can get one hosted ASAP. Maybe a mailing list a well
(again, I can host this too).

The next Council meeting is next week, so I'll ask them the status then.

You'll not hear from me again on this list.

> Warmest Regards in the New Year,

Same to you :)

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] OpenRC available for testing.

[Santiago M. Mola]

On Jan 3, 2008 11:40 AM, Roy Marples <roy@marples.name> wrote:
> On Thu, 2008-01-03 at 10:18 +0000, Richard Brown wrote:
> > While this thread remains highly entertaining, I'm sure as a past
> > gentoo developer Roy remembers that we don't generally use gentoo-dev
> > to bug fix poorly written makefiles, we have a bugzilla where people
> > interested in fixing it can help, or perhaps upstream have a list
> > where they can discuss it.
>
> One of the "deals" was that whilst Gentoo would likely use OpenRC it
> would still do the hosting. As Gentoo would be using it, it does pertain
> to Gentoo development.
>
> So either I host my own bug tracker (which I'm more than happy to do
> btw), or Gentoo can get one hosted ASAP. Maybe a mailing list a well
> (again, I can host this too).

I'd go for filing bugs in bugs.gentoo.org like with any other piece of
software we have. If you want to host your own bug tracker for your
non-Gentoo users that's another story. You could also ask infra to
create an OpenRC mailing list if it's necessary...

>
> You'll not hear from me again on this list.
>

I'm sure most people here want to hear major announcements about OpenRC.

At the moment, I'm emailing my OpenRC issues directly to you ;-)

Best regards,
Santiago

-- 
Santiago M. Mola
Jabber ID: cooldwind@gmail.com
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: OpenRC available for testing.

[Steve Long]

Santiago M. Mola wrote:

> On Jan 3, 2008 11:40 AM, Roy Marples <roy@marples.name> wrote:
>> On Thu, 2008-01-03 at 10:18 +0000, Richard Brown wrote:
>> > While this thread remains highly entertaining, I'm sure as a past
>> > gentoo developer Roy remembers that we don't generally use gentoo-dev
>> > to bug fix poorly written makefiles, we have a bugzilla where people
>> > interested in fixing it can help, or perhaps upstream have a list
>> > where they can discuss it.
Perhaps you could have directed your comment to both Aron and Roy, since
Aron posted the bugreport and is I believe a current dev, not an ex-dev who
just got married etc.

>>
>> You'll not hear from me again on this list.
>>
> 
> I'm sure most people here want to hear major announcements about OpenRC.
>
I rather value Roy's input on all Gentoo issues: he was one of the smartest
and most productive devs you ever had. After all, if other ex-devs can spam
the list, I don't see why Roy's quiet contribution should be snubbed.

Please follow up to project; for some reason when I set that, no-one
argumentative takes the hint. Instead the more mature devs basically
apologise on your behalf (and one troll occasionally weighs in.)


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

Re: [gentoo-dev] OpenRC available for testing.

[Wulf C. Krueger]

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

On Thursday, 03. January 2008 11:18:19 Richard Brown wrote:
> While this thread remains highly entertaining, I'm sure as a past
> gentoo developer Roy remembers that we don't generally use gentoo-dev
> to bug fix poorly written makefiles, 

First of all, OpenRC is likely to become an integral part of Gentoo so its 
discussion is most likely on-topic here.

Furthermore, I prefer reading about "poorly written" Makefiles instead of 
poorly written mails, dear Richard.

You might want to remember that subscription to his mailinglist is no 
longer mandatory if technical discussions bother you so much.

-- 
Best regards, Wulf

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

Re: [gentoo-dev] OpenRC available for testing.

[Mike Frysinger]

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

On Thursday 03 January 2008, Wulf C. Krueger wrote:
> On Thursday, 03. January 2008 11:18:19 Richard Brown wrote:
> > While this thread remains highly entertaining, I'm sure as a past
> > gentoo developer Roy remembers that we don't generally use gentoo-dev
> > to bug fix poorly written makefiles,
>
> First of all, OpenRC is likely to become an integral part of Gentoo so its
> discussion is most likely on-topic here.
>
> Furthermore, I prefer reading about "poorly written" Makefiles instead of
> poorly written mails, dear Richard.

come guys, lesbie friends.  Richard has a point that discussing broken 
makefiles generally isnt on topic for the list, but it'd be hard to maintain 
separate threads properly (off-list/somewhere else about building, on-list 
about conventions/changes/etc...).  people miss things and the threads get 
fragmented and it's a mess.  so please just bear the brunt of the on/off 
topic pieces as in the end the winner clearly is us.

> You might want to remember that subscription to his mailinglist is no
> longer mandatory if technical discussions bother you so much.

this really wasnt needed.  he had a valid concern.  please give up some hugz.
-mike

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

Re: [gentoo-dev] OpenRC available for testing.

[Luca Barbato]

Richard Brown wrote:

> While this thread remains highly entertaining, I'm sure as a past
> gentoo developer Roy remembers that we don't generally use gentoo-dev
> to bug fix poorly written makefiles, we have a bugzilla where people
> interested in fixing it can help, or perhaps upstream have a list
> where they can discuss it.

OpenRC is an gentoo hosted project even if roy didn't feel to be a
gentoo developer anymore, so this thread is In Topic and we'd rather
discuss with him those details in order to keep baselayout one of the
most interesting features of gentoo.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] OpenRC available for testing.

[Alon Bar-Lev]

On 1/3/08, Roy Marples <roy@marples.name> wrote:
> On Thu, 2008-01-03 at 10:58 +0200, Alon Bar-Lev wrote:
> > At: default.mk, the  _SUBDIR loop is somehow incorrect, as it will not
> > pass subdir make result to rule.
> > So if rule fails the build still considered a success.
> >
> > make[1]: *** [start-stop-daemon.o] Error 1
> > make[1]: *** Waiting for unfinished jobs....
> > make[1]: Leaving directory
> > `/var/tmp/portage/sys-apps/openrc-9999/work/openrc-9999/src'
> > >>> Source compiled.
>
> What version of gnu make?
> What MAKEOPTS do you have set?
> Does it work outside of the ebuild?

I use sys-devel/make-3.81
With MAKEOPTS="-j2"

I think the issue is that the for loop returns true...

Take the following example:
all:
        @for a in a b c; do \
                echo $$a; \
                if [ $$a == b ]; then \
                        echo FAIL; \
                        false; \
                fi; \
        done

And the output is:

$ make
a
b
FAIL
c

And success!

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