Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo

2010-08-24 Thread Joshua Saddler
On Tue, 24 Aug 2010 22:57:46 -0500 Nathan Zachary wrote: > I don't think that the documentation changes should be a determining > factor in switching to OpenRC. If we are going to endorse using OpenRC, > the more relevant issues are the ones regarding its future development. > The documentati

Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo

2010-08-24 Thread Nathan Zachary
On 24/08/10 22:21, Joshua Saddler wrote: On Tue, 24 Aug 2010 19:18:56 +0200 Christian Faulhammer wrote: Hi, Joshua Saddler: The big issue with the docs is that IF OpenRC/baselayout-2 are marked stable, it will require massive changes to hundreds of our other doc files. Is there a list of

Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo

2010-08-24 Thread Joshua Saddler
On Tue, 24 Aug 2010 19:18:56 +0200 Christian Faulhammer wrote: > Hi, > > Joshua Saddler : > > The big issue with the docs is that IF OpenRC/baselayout-2 are marked > > stable, it will require massive changes to hundreds of our other doc > > files. > > Is there a list of the needed changes? Re

Re: [gentoo-dev] New eclass: scons.eclass

2010-08-24 Thread Michał Górny
On Tue, 24 Aug 2010 17:30:32 -0400 Mike Frysinger wrote: > On Tuesday, August 24, 2010 14:40:56 Michał Górny wrote: > > 3e30e1f Rename to scons-utils.eclass. > > funny, i thought "scons.eclass" was appropriate. but whatever. Maciej complained about not exporting all ever possible buildsystem-

Re: [gentoo-dev] New eclass: scons.eclass

2010-08-24 Thread Mike Frysinger
On Tuesday, August 24, 2010 14:40:56 Michał Górny wrote: > 3e30e1f Rename to scons-utils.eclass. funny, i thought "scons.eclass" was appropriate. but whatever. -mike signature.asc Description: This is a digitally signed message part.

Re: [gentoo-dev] Re: New eclass: scons.eclass

2010-08-24 Thread Mike Frysinger
On Monday, August 23, 2010 11:42:49 Michał Górny wrote: > On Sun, 22 Aug 2010 17:06:22 -0400 Mike Frysinger wrote: > > > local varname=${2:-${flag}} > > > > should be stripping possible leading ! so that people can do > > `use_scons !foo moo` just like they can today with `use_with $foo moo` >

[gentoo-dev] Last Rites: dev-python/boostpythongenerator

2010-08-24 Thread Dominik Kapusta
# Dominik Kapusta (24 Aug 2010) # Replaced by dev-python/shiboken # # Removal on 2010-09-23 dev-python/boostpythongenerator signature.asc Description: This is a digitally signed message part.

Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo

2010-08-24 Thread Thilo Bangert
Mike Frysinger said: > On Tuesday, August 24, 2010 08:57:45 Thilo Bangert wrote: > > > , efficient, known-good solution > > > that does what you'd expect it to do and replace it with a new > > > thingy that doesn't provide all the features, is harder to debug > > > etc. etc.? I just don't see any

Re: [gentoo-dev] New eclass: scons.eclass

2010-08-24 Thread Michał Górny
r4, ChangeLog: 3e30e1f Rename to scons-utils.eclass. 6477004 Remove exported phase functions. 41784fc Implement a cache in scons_clean_makeopts(). 9b3ce5d Clarify doc on SCONSOPTS. ac9f7ed Call scons_clean_makeopts() inline instead of exporting SCONSOPTS. ae6afd9 Fix SCONSOPTS check in esc

Re: [gentoo-dev] New eclass: scons.eclass

2010-08-24 Thread Maciej Mrozowski
On Tuesday 24 of August 2010 10:30:12 Michał Górny wrote: > On Mon, 23 Aug 2010 19:36:50 +0200 > > Maciej Mrozowski wrote: > > If SCons is unpredictable, then don't provide *any* phases and only > > functions and rename it to scons-utils to match its purpose. > > It is as predictable as the buil

[gentoo-dev] Re: The future of sys-apps/openrc in Gentoo

2010-08-24 Thread Christian Faulhammer
Hi, Joshua Saddler : > The big issue with the docs is that IF OpenRC/baselayout-2 are marked > stable, it will require massive changes to hundreds of our other doc > files. Is there a list of the needed changes? V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/l

Re: [gentoo-dev] [RFC ECLASS PATCH] Include exact Hg revision data for repeatability from logs.

2010-08-24 Thread Robin H. Johnson
On Tue, Aug 24, 2010 at 09:18:02AM +0200, Dirkjan Ochtman wrote: > I'd leave out the HG_REV_NUM, it doesn't mean much anyway (since it is > local to a repository, it can easily change). Ok, dropped that and committed the rest. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructur

Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo

2010-08-24 Thread Joshua Saddler
On Tue, 24 Aug 2010 10:30:20 -0400 Richard Freeman wrote: > Looking at the tracker bug, I see all of three issues blocking openrc > from going stable. One is documentation, > It seems like we should just make the next bugday "OpenRC Cleanup Day" > or something like that. Everybody can take 1

Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo

2010-08-24 Thread Mike Frysinger
On Tuesday, August 24, 2010 08:57:45 Thilo Bangert wrote: > > , efficient, known-good solution > > that does what you'd expect it to do and replace it with a new thingy > > that doesn't provide all the features, is harder to debug etc. etc.? I > > just don't see any *advantage* from it apart from s

Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo

2010-08-24 Thread Richard Freeman
On 08/24/2010 08:57 AM, Thilo Bangert wrote: given how long, so far, it has taken openrc to reach stable, it is no wonder people start lobbying for systemd today. ;-) Perhaps, but if we want to move in that direction perhaps we should consider at least getting openrc stable first. That doesn'

Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo

2010-08-24 Thread Thilo Bangert
> Or you just let a shell handle it. Does most of the things > automatically, has a pretty low memory and startup overhead, and it > tends to be quite human-readable. > > ... why would I want to remove a > stable the biggest complaint about openrc is that its not in stable - go figure. > , eff

[gentoo-dev] QA last rites for net-fs/samba-libs; net-fs/samba-client; net-fs/samba-server

2010-08-24 Thread Diego E . Pettenò
# Diego E. Pettenò (24 Aug 2010) # on behalf of QA team # # Split samba ebuilds that are no longer relevant as the # un-split 3.5 is stable already. Quick removal. # # Removal on 2010-09-08 net-fs/samba-libs net-fs/samba-client net-fs/samba-server

Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo

2010-08-24 Thread Patrick Lauer
On 08/23/10 19:26, Olivier Crête wrote: > On Mon, 2010-08-23 at 17:05 +0200, Gilles Dartiguelongue wrote: >> Le lundi 05 juillet 2010 à 08:57 +, Duncan a écrit : >> [lots of stuff about bashisms and posix] >>> So let's stabilize OpenRC and be done with it, and /then/ we can debate >>> where we

Re: [gentoo-dev] The future of sys-apps/openrc in Gentoo

2010-08-24 Thread Luca Barbato
On 08/23/2010 11:07 PM, Mike Frysinger wrote: > On Monday, August 23, 2010 16:21:44 Luca Barbato wrote: >> I'd put openrc on freedesktop btw. > > we've sort of already settled into the places ... jumping to another place > doesnt gain us much. current infrastructure also already enables all the

Re: [gentoo-dev] New eclass: scons.eclass

2010-08-24 Thread Michał Górny
On Mon, 23 Aug 2010 19:36:50 +0200 Maciej Mrozowski wrote: > If SCons is unpredictable, then don't provide *any* phases and only > functions and rename it to scons-utils to match its purpose. It is as predictable as the buildsystem meeting the default phase functions requirements -- we can confi

Re: [gentoo-dev] New eclass: scons.eclass

2010-08-24 Thread Michał Górny
On Mon, 23 Aug 2010 19:27:22 -0400 Mike Frysinger wrote: > then keep it simple and separate: > escons() { > debug-print-function ${FUNCNAME} "$...@}" > > set -- scons $(scons_clean_makeopts) ${SCONSOPTS} > ${EXTRA_ESCONS} "$...@}" echo "$...@}" >&2 > "$...@}" > } > > now you d

Re: [gentoo-dev] [RFC ECLASS PATCH] Include exact Hg revision data for repeatability from logs.

2010-08-24 Thread Dirkjan Ochtman
On Mon, Aug 23, 2010 at 23:23, Robin H. Johnson wrote: > Index: mercurial.eclass > === > RCS file: /var/cvsroot/gentoo-x86/eclass/mercurial.eclass,v > retrieving revision 1.12 > diff -p -w -b -B -u -r1.12 mercurial.eclass > --- mercur