Re: [gentoo-dev] [RFC ECLASS PATCH] Include exact Hg revision data for repeatability from logs.
On Mon, Aug 23, 2010 at 23:23, Robin H. Johnson robb...@gentoo.org 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
--- mercurial.eclass 2 Apr 2010 18:29:39 - 1.12
+++ mercurial.eclass 23 Aug 2010 21:20:41 -
@@ -116,12 +116,20 @@ function mercurial_fetch {
fi
# Checkout working copy:
- einfo Creating working directory in ${WORKDIR}/${module} (revision:
${EHG_REVISION})
+ einfo Creating working directory in ${WORKDIR}/${module} (target
revision: ${EHG_REVISION})
hg clone \
${EHG_QUIET_CMD_OPT} \
--rev=${EHG_REVISION} \
${EHG_STORE_DIR}/${EHG_PROJECT}/${module} \
${WORKDIR}/${module} || die hg clone failed
+ # An exact revision helps a lot for testing purposes, so have some
output...
+ # id num branch
+ # fd6e32d61721 6276 default
+ local HG_REVDATA=($(hg identify -n -b -i ${WORKDIR}/${module}))
+ local HG_REV_ID=${HG_REVDATA[0]}
+ local HG_REV_NUM=${HG_REVDATA[1]}
+ local HG_REV_BRANCH=${HG_REVDATA[2]}
+ einfo Work directory: ${WORKDIR}/${module} global id: ${HG_REV_ID}
branch: ${HG_REV_BRANCH}
}
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).
Cheers,
Dirkjan
Re: [gentoo-dev] New eclass: scons.eclass
On Mon, 23 Aug 2010 19:27:22 -0400
Mike Frysinger vap...@gentoo.org wrote:
then keep it simple and separate:
escons() {
debug-print-function ${FUNCNAME} $...@}
set -- scons $(scons_clean_makeopts) ${SCONSOPTS}
${EXTRA_ESCONS} $...@} echo $...@} 2
$...@}
}
now you dont have to worry about changes between invocations and the
developer has a clear path -- if they need to force a serial build
for example, they can either append MAKEOPTS, SCONSOPTS, or pass it
straight to escons. no cache confusion or desync between the vars.
Ok, but will use ${SCONSOPTS-$(scons_clean_makeopts)} instead.
The point is that the user can decide to have different SCONSOPTS set
in his/her make.conf, and he/she couldn't magically drop MAKEOPTS for
SCons ebuilds then.
Additionally, I will implement the cache in scons_clean_makeopts().
That should work just fine.
--
Best regards,
Michał Górny
http://mgorny.alt.pl
xmpp:mgo...@jabber.ru
signature.asc
Description: PGP signature
Re: [gentoo-dev] New eclass: scons.eclass
On Mon, 23 Aug 2010 19:36:50 +0200 Maciej Mrozowski reave...@gmail.com 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 configure it, compile it but no way of knowing what should be done in 'install' for sure. What I hate is deliberately introduced inconsistency in ebuild API's. What I hate is replicating bad practices just because someone else did that before. If I'm wrong, then please point me the relation between a particular buildsystem and patching. -- Best regards, Michał Górny http://mgorny.alt.pl xmpp:mgo...@jabber.ru signature.asc Description: PGP signature
Re: [gentoo-dev] The future of sys-apps/openrc in Gentoo
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 Gentoo devs who wish to contribute (git/http/xml/bugzilla/etc...). -mike I'd do like enlightenment does. People wandering around fdo will notice and maybe help a bit. We want more acceptance and hopefully have other users beside ourselves. (I'm sick of having stuff shoved down our throat just because they are apparently standard) lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo
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 want to go from there. YES, let's get it stable. However please consider not re-adding bashisms and/or not make it less POSIX shell compliant than it already is at light speed. It is a great thing that openrc tries to achieve and allows more use of openrc than basic desktop/server gentoo usage (think embedded and other distros). At least one other distro did this move a while ago (debian) and I don't think they will go back. Seeing they are also moving to a dependency based init system, they probably could just run a fork of openrc (for their init scripts are not exactly compatible with what we do). Other distributions are going one step further and are going for shell-free boot. We should follow that lead. That sounds like a really confused bad idea to me. At some point you will have to execute a program with a pre-setup environment and passing some arguments. You could, of course, hack that together manually. It tends to be quite a bit of work to get everything set up right and it's lots of code you'll have to maintain. 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, 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 saying OMG HAZ NEW FEATRUES :) (and OpenRC is by far the fastest init script manager I've seen. Performance is really not a good argument against it in this case ...)
[gentoo-dev] QA last rites for net-fs/samba-libs; net-fs/samba-client; net-fs/samba-server
# Diego E. Pettenò flamee...@gentoo.org (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
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. , 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 saying OMG HAZ NEW FEATRUES :) one feature of systemd is, that it has an active upstream. no, i dont think it would be a good idea to switch to systemd, just yet. but like the original baselayout was breaking new ground back when it first was developed, so is systemd. it does things differently and may not have all features yet, but from the outset it appears to be vastly superior to sysv-style inits, upstart and openrc. granted, systemd is currently able to attract enthusiastic supporters. reducing these to mere fanboys, however, is ignoring the technical solution that systemd proposes. yes, openrc works great - and yes, systemd is a better solution when looking at the overall problem. given how long, so far, it has taken openrc to reach stable, it is no wonder people start lobbying for systemd today. ;-) kind regards Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo
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't mean making it perfect, or feature-complete. However, right now we have two different baselayouts, and if we start talking about systemd then we'll have three. Do we really want to start on seriously supporting a third one, without first getting rid of one of the other two? Alternatively we could dump openrc and move everybody back to baselayout-1, but I don't see that happening anytime soon. Looking at the tracker bug, I see all of three issues blocking openrc from going stable. One is documentation, one is getting an evms upgrade stable on a few minor archs, and one is some kind of mdadm upgrade with a few issues. It seems like we should just make the next bugday OpenRC Cleanup Day or something like that. Everybody can take 15 minutes to contribute to a wiki on getting started with openrc, or blog about it, or whatever. the docs team can glean the best of that and get the docs in order. The evms/mdadm/arch maintainers could make a push to finish up, and others can help them with patches. If we made a real push to get OpenRC stable I'm sure that those bugs would get taken care of quickly. Right now I'm guessing that it just isn't on anybody's radar. Or, is the situation with OpenRC less stable than is apparent in the tracker? Rich
Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo
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 saying OMG HAZ NEW FEATRUES :) one feature of systemd is, that it has an active upstream. ... and so does openrc no, i dont think it would be a good idea to switch to systemd, just yet. but like the original baselayout was breaking new ground back when it first was developed, so is systemd. it does things differently and may not have all features yet, but from the outset it appears to be vastly superior to sysv-style inits, upstart and openrc. nothing is stopping you or anyone else from making systemd work under Gentoo -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo
On Tue, 24 Aug 2010 10:30:20 -0400 Richard Freeman ri...@gentoo.org 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 15 minutes to contribute to a wiki on getting started with openrc, or blog about it, or whatever. the docs team can glean the best of that and get the docs in order. Oh heck no. We're not about to wade through a hundred blog entries/wiki articles in a desparate attempt to assemble a coherent guide. Besides, Doug, Roy, and I wrote a migration guide a few years ago that I've been constantly updating: http://www.gentoo.org/doc/en/openrc-migration.xml 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. signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC ECLASS PATCH] Include exact Hg revision data for repeatability from logs.
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 Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpSzkWL20riX.pgp Description: PGP signature
[gentoo-dev] Re: The future of sys-apps/openrc in Gentoo
Hi, Joshua Saddler nightmo...@gentoo.org: 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 URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] New eclass: scons.eclass
On Tuesday 24 of August 2010 10:30:12 Michał Górny wrote: On Mon, 23 Aug 2010 19:36:50 +0200 Maciej Mrozowski reave...@gmail.com 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 configure it, compile it but no way of knowing what should be done in 'install' for sure. What I hate is deliberately introduced inconsistency in ebuild API's. What I hate is replicating bad practices just because someone else did that before. If I'm wrong, then please point me the relation between a particular buildsystem and patching. Ideologically there's none, but practically build system may need patching in eclass to fit Gentoo needs. And it's better to do it officially in eclass src_prepare phase than hack around elsewhere. Either provide all buildsystem related phases or none - I'm already tired of playing guess which phase from which eclass takes precedence when multiple inheritance is used game. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] New eclass: scons.eclass
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 escons().
--
Best regards,
Michał Górny
http://mgorny.alt.pl
xmpp:mgo...@jabber.ru
scons-utils.eclass
Description: Binary data
diff --git a/scons.eclass b/scons-utils.eclass
similarity index 85%
rename from scons.eclass
rename to scons-utils.eclass
index d29299c..bc91f96 100644
--- a/scons.eclass
+++ b/scons-utils.eclass
@@ -20,8 +20,8 @@
# @ECLASS-VARIABLE: SCONSOPTS
# @DESCRIPTION:
# The default set of options to pass to scons. Similar to MAKEOPTS,
-# supposed to be set in make.conf. If unset, will be generated from
-# MAKEOPTS.
+# supposed to be set in make.conf. If unset, escons() will use cleaned
+# up MAKEOPTS instead.
# @DEFAULT-UNSET
# @ECLASS-VARIABLE: EXTRA_ESCONS
@@ -47,30 +47,6 @@ else
DEPEND=dev-util/scons
fi
-# -- exported phase functions --
-
-case ${EAPI:-0} in
- 1|0) EXPORT_FUNCTIONS src_compile;;
- *) EXPORT_FUNCTIONS src_configure src_compile;;
-esac
-
-# @FUNCTION: scons_src_configure
-# @DESCRIPTION:
-# A blank src_configure() for SCons packages not using explicit
-# configure phase.
-scons_src_configure() {
- debug-print-function ${FUNCNAME} $...@}
-}
-
-# @FUNCTION: scons_src_compile
-# @DESCRIPTION:
-# The exported src_compile() implementation. Simply calls escons().
-scons_src_compile() {
- debug-print-function ${FUNCNAME} $...@}
-
- escons || die 'escons failed.'
-}
-
# -- public functions --
# @FUNCTION: escons
@@ -81,12 +57,8 @@ scons_src_compile() {
escons() {
debug-print-function ${FUNCNAME} $...@}
- # if SCONSOPTS are _unset_, create them from MAKEOPTS
- if [[ -n ${SCONSOPTS+1} ]]; then
- export SCONSOPTS=$(scons_clean_makeopts)
- fi
-
- set -- scons ${SCONSOPTS} ${EXTRA_ESCONS} $...@}
+ # if SCONSOPTS are _unset_, use cleaned MAKEOPTS
+ set -- scons ${SCONSOPTS-$(scons_clean_makeopts)} ${EXTRA_ESCONS} $...@}
echo $...@} 2
$...@}
}
@@ -104,13 +76,23 @@ scons_clean_makeopts() {
debug-print-function ${FUNCNAME} $...@}
if [[ ${#} -eq 0 ]]; then
- debug-print Using MAKEOPTS: ${MAKEOPTS}
+ debug-print Using MAKEOPTS: [${MAKEOPTS}]
set -- ${MAKEOPTS}
else
# unquote if necessary
set -- ${*}
fi
+ # empty MAKEOPTS give out empty SCONSOPTS
+ # thus, we do need to worry about the initial setup
+ if [[ ${*} = ${_SCONS_CACHE_MAKEOPTS} ]]; then
+ set -- ${_SCONS_CACHE_SCONSOPTS}
+ debug-print Cache hit: [${*}]
+ echo ${*}
+ return
+ fi
+ export _SCONS_CACHE_MAKEOPTS=${*}
+
while [[ ${#} -gt 0 ]]; do
case ${1} in
# clean, simple to check -- we like that
@@ -167,8 +149,10 @@ scons_clean_makeopts() {
shift
done
- debug-print New SCONSOPTS: ${new_makeopts}
- echo ${new_makeopts}
+ set -- ${new_makeopts}
+ export _SCONS_CACHE_SCONSOPTS=${*}
+ debug-print New SCONSOPTS: [${*}]
+ echo ${*}
}
# @FUNCTION: use_scons
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo
Mike Frysinger vap...@gentoo.org 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 *advantage* from it apart from saying OMG HAZ NEW FEATRUES :) one feature of systemd is, that it has an active upstream. ... and so does openrc presumably you are referring to this: http://www.gentoo.org/proj/en/base/openrc/ ? Thats great news. Thanks. signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last Rites: dev-python/boostpythongenerator
# Dominik Kapusta a...@gentoo.org (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: New eclass: scons.eclass
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`
Could you explain that better? Calling 'use_scons !foo moo' would cause
varname to contain 'moo' anyway.
yeah, in that case it wouldnt matter
If you meant calling just 'use_scons !foo' instead, I can do that but
not sure if it'd be really useful. I guess packages don't tend to use
some kind reverse logic for booleans, and would rather have
the particular var prefixed by 'NO' or something like that then.
whether the upstream logic should be fixed is something to address there. the
extended `use_xxx` interfaces should support all the underlying features of
`use` and work just as well as the existing ones.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] New eclass: scons.eclass
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] New eclass: scons.eclass
On Tue, 24 Aug 2010 17:30:32 -0400 Mike Frysinger vap...@gentoo.org 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- -unrelated functions like other non-utils-named eclasses tend to do. -- Best regards, Michał Górny http://mgorny.alt.pl xmpp:mgo...@jabber.ru signature.asc Description: PGP signature
Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo
On Tue, 24 Aug 2010 19:18:56 +0200 Christian Faulhammer fa...@gentoo.org wrote: Hi, Joshua Saddler nightmo...@gentoo.org: 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? Read the OpenRC guide, then read all our other guides. That's the list. It will require a line-by-line code scan to figure all this stuff out. Creating such a list would probably take almost as long as actually fixing the docs. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo
On 24/08/10 22:21, Joshua Saddler wrote: On Tue, 24 Aug 2010 19:18:56 +0200 Christian Faulhammerfa...@gentoo.org wrote: Hi, Joshua Saddlernightmo...@gentoo.org: 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? Read the OpenRC guide, then read all our other guides. That's the list. It will require a line-by-line code scan to figure all this stuff out. Creating such a list would probably take almost as long as actually fixing the docs. 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 documentation can be updated in due time. Of course, that's just my opinion.
Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo
On Tue, 24 Aug 2010 22:57:46 -0500 Nathan Zachary nathanzach...@gentoo.org 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 documentation can be updated in due time. Of course, that's just my opinion. It's not really a determining factor in whether or not we adopt it as our default system. It's just one of the big tasks to complete if we do. I'm not arguing against using OpenRC just because the docs will require significant rewrites. signature.asc Description: PGP signature
