Re: [gentoo-dev] Re: perl-module.eclass -- review - 2
On Tuesday 03 March 2009 12:13:34 Peter Volkov wrote: Could you just use dosed here? dosed needs to die. Why? Because it's utterly pointless and exists only for legacy reasons. Few packages use it anyway. -- Bo Andresen
Re: [gentoo-dev] Re: perl-module.eclass -- review - 2
On Monday 02 March 2009 08:24:35 Torsten Veller wrote:
find ${D}/${VENDOR_LIB} -type f -a \( -name .packlist \
-o \( -name '*.bs' -a -empty \) \) -delete
find ${D}/${VENDOR_LIB} -depth -mindepth 1 -type d -empty -delete
I'm curious how portable the find () construct is. Do you know?
It was established well over a year ago that find in the ebuild environment
must be GNU find. Using portable find is not worth the pain.
[...]
Could you just use dosed here?
dosed needs to die.
[...]
BTW: After I looked up the devmanual part about find above, I wonder:
| find ${S} -type f | while read f ; do
| [...]
| for f in $(find ${S} -type f) ; do
| [...]
| Warning
| In both cases, files with weird characters or spaces in their names may
| cause serious problems.
The while loop breaks with leading or trailing spaces in the path. If the
spaces are anywhere else in the path it works. The for loop breaks with spaces
regardless of where they are. And you can of course come up with weird
characters that break them both.
If you really want to do better use:
find ${S} -print0 | while read -rd '' f; do
if file ${f} ...
done
You also really should provide proper die messages.
--
Bo Andresen
Re: [gentoo-dev] virtualx eclass
On Thursday 16 October 2008 23:54:32 Donnie Berkholz wrote: I'm not sure whether this would work, but one idea would be to handle dependencies depending on what's in IUSE of the ebuild inheriting. That would require ebuilds to set IUSE before inheriting the eclass. -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: fox.eclass update
--- gentoo-x86/eclass/fox.eclass 2008-10-12 14:31:36.0 +0200
+++ fox-proposed.eclass 2008-10-13 20:27:05.0 +0200
[...]
-inherit eutils libtool versionator
+inherit autotools eutils libtool versionator
You should probably be setting WANT_AUTO* before inheriting autotools.
[...]
+ if ( ! use doc ) [ -d ${D}/usr/share/doc/${PF}/html ] ; then
Get rid of the pointless subshell.
if use !doc ...
--
Bo Andresen
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: bzr.eclass into Portage
On Monday 13 October 2008 04:43:48 Steve Long wrote:
EBZR_OPTIONS=${EBZR_OPTIONS:-} (and similar variants)
doesn't do anything (beyond waste lex and yacc time.)
It gets listed in the generated man page.
[...]
The same consideration applies to all those constant values 'and indeed'
${foo} as opposed to $foo, though first time I raised that I got sworn at,
so not expecting miracles here.
Are you for real?
--
Bo Andresen
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets
On Monday 29 September 2008 01:37:03 Zac Medico wrote: Why the need for multiple solutions at all? PROPERTIES=set is too weird and involves too much nonsensical behaviour to be useful. I don't see the PROPERTIES=set approach as being worse than any other approach for package set definition. It has lots of advantages because of the way that it fits into the existing ebuild framework like virtual ebuilds do [1], allowing it to leverage all of the existing features of the framework (including package.use) and also allowing it to leverage the tools that have been designed to work with the framework. [1] http://www.gentoo.org/proj/en/glep/glep-0037.html I really don't see the advantages of fitting 'into the existing ebuild framework like virtual ebuilds do'. Can you name any real advantages to it? Having virtuals as ebuilds makes sense because ebuilds need to depend upon them. But I can see no decent use case for letting a non-set ebuild depend upon a set. As far as I'm concerned sets are merely a convenience for users. It allows them to install, reinstall (mostly of interest for scm ebuilds), keyword, unmask, set use flags for or uninstall a set of packages. -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/audacity: ChangeLog audacity-1.3.5-r1.ebuild
On Monday 29 September 2008 10:27:51 Alexis Ballier wrote: Maybe it would be worth adding repoman warnings/errors for econf calls in eapi2 src_compile. Or make econf warn when run outside src_configure/src_compile depending upon EAPI. -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI
On Wednesday 24 September 2008 07:28:07 Alec Warner wrote: Now figure out the four flaws in the above code. Why not be helpful and point them out? I would call your comment 'UnGentooey', if I may use a work term. I don't think saying there are flaws in a given piece of code is really helpful to anyone. Because in this case it's so remarkably obvious that anybody who has the slightest clue about bash and who thought about it for more than three seconds should be able to see it on their own? Also for those who still couldn't see it just testing it would have caught three of the flaws.. -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Making built_with_use die by default with EAPI 2
On Monday 22 September 2008 22:25:20 Petteri Räty wrote: If you mean something like built_with_use cat/foo coolfeature || ewarn bar will be more useful if you rebuild cat/foo with USE=coolfeature then you can use has_version 'cat/foo[coolfeature]' || ... instead. What does this report if cat/foo does not have coolfeature use flag in some version? Meaning can this support cases which need --missing true. False. If for instance coolfeature was made optional in =pv you can use logic like: if has_version '=cat/foo-pv' ! has_version 'cat/foo[coolfeature]'; then ewarn '...' fi -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Making built_with_use die by default with EAPI 2
On Tuesday 23 September 2008 22:44:35 Alexis Ballier wrote: False. If for instance coolfeature was made optional in =pv you can use logic like: if has_version '=cat/foo-pv' ! has_version 'cat/foo[coolfeature]'; then ewarn '...' fi I think this should cover all the current functionality with built_with_use. This is just an ugly hack. Think about a package that has coolfeature useflag removed and enabled by default for a couple of releases because it wouldn't build without it and once upstream sorted out everything the useflag is coming back. Missing useflags that are assumed to be enabled have nothing to do with the package version being greater than a given number. If it is needed that often we should add support for stating the state of the use flag in dependencies. With the currently planned eapi 2 you get dependencies such as: DEPEND=|| ( =cat/foo-pv[coolfeature] cat-foo-pv ) too. Doing the same with has_version is only consistent with that. If we add support for it in dependency syntax it will work with has_version too... -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI
On Tuesday 23 September 2008 21:39:52 Thomas Sachau wrote:
default_src_install() {
if [ -f Makefile -o -f GNUmakefile -o -f makefile ]; then
if emake DESTDIR=${D} install || einstall ; then
die install failed
else
if [[ -n ${DOCS} ]]; then
dodoc ${DOCS} || die dodoc failed
fi
fi
fi
}
Any more comments? Good? Bad? Interested?
Now figure out the four flaws in the above code.
--
Bo Andresen
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] One-Day Gentoo Council Reminder for September
On Thursday 11 September 2008 17:42:25 Zac Medico wrote: Ebuilds that used this approach were easily fixed by moving the has_version calls to pkg_preinst and storing the results in environment variables. Which breaks with any portage old enough to not properly support storing environment variables between phases (2.1.4.4?). -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] EAPI 2 Draft
On Friday 05 September 2008 00:58:05 Zac Medico wrote: * Default phase function implementations for older EAPIs are accessible via functions having names that start with 'eapi', followed by the EAPI value. Based on the lack of use cases or further responses to [1] I would suggest removing this feature from eapi 2. [1] http://archives.gentoo.org/gentoo-dev/msg_419885810c399b4cebbc62bd96081f87.xml -- Bo Andresen signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Retirement
My retirement is probably long overdue as I haven't really been active for several months. It is now clear to me that Gentoo is not moving in the direction I had wished for and the last council election indicates that most current Gentoo developers appear to be satisfied with this current direction. Therefore farewell. If anybody wants to reach me I can be reached at bo.andresen at zlin.dk. -- Bo Andresen Former Gentoo KDE Dev signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-irc/quassel: ChangeLog quassel-9999-r1.ebuild quassel-0.2.0_rc1.ebuild quassel-0.2.9999.ebuild
On Thursday 03 July 2008 01:06:17 Diego 'Flameeyes' Pettenò wrote: -r1 has this values: P=quassel- PN=quassel PV= PF=quassel--r1 PVR=-r1 (was this the right variable name? I sincerely forgot) PVR is right. You only forgot PR=r1. http://devmanual.gentoo.org/ebuild-writing/variables/index.html -- Bo Andresen Gentoo KDE Dev signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] When the version scheme changes
On Saturday 28 June 2008 17:03:13 Marijn Schouten (hkBst) wrote:
PV=${PV/0./}
to that new ebuild. This is the cleanest way to do it and doesn't require
any variable name changes or any other changes to the ebuild regardless of
what it does. Unfortunately it is also illegal per current PMS as PV is a
read-only variable. Right now I feel that the gain of having PV read-only
(catch a few bugs?) is much lower than the pain (extensive ebuild-dependend
changes when the version scheme changes). Please comment.
I don't really see how making PV not read-only is any easier than using MY_PV.
Did you expect changing PV to magically change P, PVR and PF too?
--
Bo Andresen
Gentoo KDE Dev
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Tuesday 10 June 2008 18:26:55 Doug Goldstein wrote: Let's try to aim to do an EAPI=2 sometime soonish since Portage now has USE flag depends in version 2.2 which is looming on the horizon. It'd be nice to hit the ground running with supporting these. I know it'll be trivial for the Paludis and pkgcore guys to make this work since they already support USE flag depends. I would like the portage devs to comment upon which of the following features they think could easily be implemented before portage 2.2 goes stable. There's still some time since it hasn't left package.mask yet, so I'd rather they exclude the features that will take too long to implement than anybody else doing that... Already implemented: - Use dependencies, it's not clear to me whether we all agree entirely upon the syntax yet though (bugs #2272 and #174406) Things I believe should be trivial to implement: - Custom output names in SRC_URI, also called arrows (bug #177863) - Guarantee trailing slashes (bug #174408) - Limit values in $USE (bug #176467) - doins support for symlinks (bug #179932) - Enable FEATURES=test by default (bug #184812) - GLEP 42 - news items Bigger features I'm interested in: - Making do* die on failure by default (without changing their behaviour for previous eapis). Possibly adding either nonfatal or try_do* for cases where this isn't desired. (bug #138792) - More phases - src_prepare, for applying patches and running autotools etc. - src_configure, for running configure scripts (bug #197859) - pkg_pretend (bug #177860 - could also be used to fix bug #75936) - maint_*, it's not clear to me if this has been fleshed out in sufficient detail yet (bug #185567) - default_*, allows an ebuild to redefine phases to add more functionality and then call default_$phase. Currently the default phases are lost when redefining the phases. - default for src_install (bug #33544) - Ranged dependencies (bug #4315) Of course I'd like GLEPs 54 and 55 too but since the council still hasn't made a decision about them I'll leave them out.. -- Bo Andresen Gentoo KDE Dev signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wednesday 11 June 2008 01:03:47 Marius Mauch wrote: I would like the portage devs to comment upon which of the following features they think could easily be implemented before portage 2.2 goes stable. There's still some time since it hasn't left package.mask yet, so I'd rather they exclude the features that will take too long to implement than anybody else doing that... Well, actually I would rather not add any new features between pre8 and rc1 to not further delay 2.2. And generally I'm also not in favor of adding new features during the rc phase as it's there to eliminate remaining bugs and for refinement of existing features, not to add new unknowns. Ok. Things I believe should be trivial to implement: - Custom output names in SRC_URI, also called arrows (bug #177863) This I'd definitely delay as it probably affects a number of things. Such as? - Limit values in $USE (bug #176467) Also requires little actual work, question is only if this should be enabled for EAPI=0/1 as well, and how it relates to USE_EXPAND and ARCH. If it should be done for existing EAPIs as well could be considered as bugfix. - doins support for symlinks (bug #179932) If someone implements it it can be included (do you want an EAPI bump for that?) Listed those here because they block the EAPI tracker bug. - Enable FEATURES=test by default (bug #184812) Only if 99% of the stable and ~arch tree and all potential system packages build with it (IOW: no) Err.. Maybe this could have been phrased better but then I did expect you would look at the bug before commenting. The idea is to enable tests by default in EAPI 2 and beyond and let them stay off by default in EAPI 0 and 1. This way devs who want to use EAPI 2 will either have to fix their tests or RESTRICT them. Doing it this way avoids the issue of having to fix the whole tree all at once. Users can still choose not to go with the default. - GLEP 42 - news items Already implemented. And not really an EAPI issue. Hence I shouldn't have mentioned it here. ;) - default_*, allows an ebuild to redefine phases to add more functionality and then call default_$phase. Currently the default phases are lost when redefining the phases. Should be trivial to implement off-hand (just converting the existing defaults to wrappers) So that's a candidate for EAPI 2. - default for src_install (bug #33544) Should also not be terribly difficult, though I'd rather wait until after 2.2 final. -- Bo Andresen Gentoo KDE Dev signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Nominations open for the Gentoo Council 2008/2009
On Thursday 05 June 2008 02:00:21 Łukasz Damentko wrote: Nominations for the Gentoo Council 2008/2009 are open now and will be open for the next two weeks (until 23:59 UTC, 18/06/2008). I would like to nominate Piotr Jaroszyński (peper). -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Nominations open for the Gentoo Council 2008/2009
On Thursday 05 June 2008 20:26:03 Alex Howells wrote: 2008/6/5 Ali Polatel [EMAIL PROTECTED]: I want to nominate: Fernando J. Pereda -- ferdy Bo Ørsted Andresen -- zlin I accept. Is there a method for objecting to a nomination, kinda like the opposite of seconding it? :P It would appear so. Just as useless too. -- Bo Andresen Gentoo KDE Dev signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Eclass for gnome-python* split
On Saturday 24 May 2008 00:01:20 Arun Raghavan wrote:
http://gitorious.org/projects/g-py-split/repos/mainline/blobs/g-py-split/eclass/gnome-python-common.eclass
Comments to quoted parts of the eclass below...
G_PY_BINDINGS=${G_PY_BINDINGS:-${PN%-*}}
From the comments above it I get the impression that the wildcard is
unnecessary:
G_PY_BINDINGS=${G_PY_BINDINGS:-${PN%-python}}
RDEPEND=[...]
=dev-python/${G_PY_PN}-base-${PV}
This should probably at least be ~dev-python/${G_PY_PN}-base-${PV} so you don't
have to change the eclass whenever you do a revision bump to the base package.
if hasq examples ${USE}; then
This should certainly be:
if hasq examples ${IUSE} use examples; then
It's not clear to me whether you intended to add examples to IUSE for all
ebuilds in which case IUSE=examples should be added to the eclass too...
Otherwise all ebuilds that use it must add it to IUSE manually.
python_mod_optimize
/usr/$(get_libdir)/python${PYVER}/site-packages/gtk-2.0
Ideally this code would make you inherit multilib explicitly too.
--
Bo Andresen
Gentoo KDE Dev
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] What are blocks used for?
On Wednesday 16 April 2008 09:56:04 Mateusz A. Mierzwiński wrote: My Prof from US used to say - if something is working good why we should replace it? When we do that we can be sent to the tree with bananas straighting proposition by OS. I think it has been made quite clear in this thread that the current solution isn't working good. Look at the cases where people mistakenly uninstalled coreutils instead of mktemp. Not to mention the fact that uninstalling mktemp before upgrading coreutils is indeed the wrong solution. -- Bo Andresen Gentoo KDE Dev signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] What are blocks used for?
On Wednesday 16 April 2008 10:15:16 Mateusz A. Mierzwiński wrote: So why not to send on screen info about what to do rather then ERROR? Please reread this entire thread. That's exactly what is being proposed. [...] I think this is good idea. I think this is a terrible idea. -- Bo Andresen Gentoo KDE Dev signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
On Thursday 03 April 2008 14:55:43 Patrick Lauer wrote: But if you don't trust anyone there is no reason why you would even try to interact with Gentoo. So at some point you will have to decide to arbitrarily trust a few entities, be it devs or servers or cryptographic keys ... Uh huh, which is what my original reply to Mike was all about. We're way ahead of you here... Or so you think. So now that you've tried to label me as a dimwit I think you managed that quite well on your own. we're past that stage and can now return to actually discussing the set of issues and how to handle them, ja? The point of this subthread was that limiting developers' access to only the parts of the tree they are going to work on accomplishes nothing from a security point of view and only makes things harder when they occasionally need to do tree wide changes from any other point of view. There is no technical solution that can fix that. -- Bo Andresen Gentoo KDE Dev signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] explicit -r0 in ebuild filename
On Monday 31 March 2008 02:29:10 Brian Harring wrote:
Going to reiterate this one more time; the proposal is simple enough;
if it's an implicit 0 via cpv parsing, it should *not* be explicitly
specified on disk. 'diffball-1.0_alpha0.ebuild' can just as easily be
specified as 'diffball-1.0_alpha.ebuild', 'diffball-1.0-r0.ebuild' can
just as easily be specified as 'diffball-1.0.ebuild'.
Reiterating the gain: consistancy on disk, consistancy in dealing with
PV/PVR. As you keep point out, PV does vary- having the results of
ebuild execution change depending on whether or not you name your
ebuild 'diffball-1.0_alpha0.ebuild' or 'diffball-1.0_alpha.ebuild' is
*not* a feature, it is what you would classically call a design
misfeature. PVR for 'diffball-1.0-r0.ebuild' being '1.0' instead of
'1.0-r0' is yet another argument for punting explicit -r0 on disk-
it's a gotcha, design flaw in the format.
It's a simple tweak, with no real loss of functionality (lots of
claims, no single hard proof thus far). As spanky has stated, there
*is* a loss of ease of use in a small subset of ebuilds- worst case,
.06% ebuilds. Personally, I don't consider that minority worth
preserving since preserving that means leaving open several gotchas in
ebuild writing, and complicates interactions (both pm and dev).
So... there it is. Would be rather nice to have ebuild devs weight in
on this one, rather then just package manager monkeys also (they're
the ones bound most by the change after all). Laid out the advantages
to this- kindly lay out the disadvantages, where this makes things
worse if you're looking for a response.
I struggle to see the technical gain of banning -r0 while allowing _alpha0 and
002 which have the exact same technical issue. Forcing people to hard code
versions or use sucky substitutions such as ${PV/_alpha/_alpha0} or whatever
you'd use to convert cpufrequtils-2 to cpufrequtils-002 is clearly a loss of
feature.
I agree that explicit -r0 on disk isn't really useful given the current Gentoo
policy on revision bumps. But I think we established on bug #166522 [1] that
we don't want to make restrictions based on what is useful. Otherwise we
should ban _alpha_beta_pre_p too...
[1] https://bugs.gentoo.org/show_bug.cgi?id=166522
--
Bo Andresen
Gentoo KDE Dev
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Major changes to the Gnome2 Eclasses
On Tuesday 18 March 2008 00:42:02 Gilles Dartiguelongue wrote:
Now, basically, if the portage metadata or QA people could tell me a way
to figure *all* the ebuilds that inherit gnome2 *and* have a
pkg_preinst() function somewhere (either in the ebuild or in an eclass
somewhere) I'd really appreciate it, as I really don't want to read
through thousands of ebuilds to figure it out.
Here is my brute force method:
Wow.. :p
$ # extract the list of package defining custom pkg_preinst()
$ egrep -r ^.*?_pkg_preinst /usr/portage/eclass/* |cut -f1 -d: |sed \
s:/usr/portage/eclass/::g;s:.eclass::g |sort|uniq| tee \
export-preinst.list
$ grep -l 'EXPORT_FUNCTIONS.*pkg_preinst' $(portageq portdir)/eclass/*.eclass |
\
while read eclass; do
basename $eclass .eclass
done | tee export-preinst.list
$ # extract the list of ebuilds inheriting gnome2 eclass
$ find /usr/portage/ -name *.ebuild -exec egrep -H gnome2 {} \; | \
cut -f1 -d: |uniq| tee gnome-inherit.list
$ inquisitio --repository gentoo --all-versions --compact --keys INHERITED \
--matcher exact gnome2 | cut -d' ' -f2 | tee gnome2-inherited.list
[...]
of course YMMV and there might be simpler/faster solutions but oh
well... it gave me an output of 62 packages.
While inquisitio may not be faster it is certainly more reliable. Another option
is to rely on the metadata cache in an rsync tree where INHERITED is the tenth
line in each entry.
--
Bo Andresen
Gentoo KDE Dev
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] FYI clarifications to skel.ebuild EAPI usage
On Friday 14 March 2008 03:29:26 Petteri Räty wrote: solar reported that he had ebuild submissions blindly using EAPI=1 so we hopefully made the text better reflect that it should not be used unless absolutely needed. 'Absolutely' is far too strong a word. A better wording would be 'unless useful', or 'unless it would improve the quality of the ebuild'. For non-system packages, the only thing stopping people from using EAPI 1 where useful is ludditism. -- Bo Andresen Gentoo KDE Dev signature.asc Description: This is a digitally signed message part.
[gentoo-dev] subversion.eclass
For quite a while the KDE herd has had a modified version of subversion.eclass
in the kde overlay. During that time we have added the following features to
the eclass which we would like to put back in gentoo-x86 soon. Since the
changes are fairly extensive we decided to send it to this list for review
first.
1) ESVN_REVISION (before this people had to use ESVN_OPTIONS for this
purpose).
2) ESVN_OFFLINE which disables svn up.
3) ESVN_UP_FREQ which uses GNU find to determine if the specified number of
hours has passed and only do svn up if it has. This is currently used in the
kde4svn-meta eclass for split kde ebuilds that use the same checkout of each
module.
4) ESCM_LOGDIR for logging which revisions packages get installed with. See
[1]. Users need to explicitly enable this feature to use it.
Other than this the eclass has been documented for use with eclass-manpages.
[1] http://thread.gmane.org/gmane.linux.gentoo.devel/54233
--
Bo Andresen
Gentoo KDE dev
--- /var/repositories/gentoo/eclass/subversion.eclass 2007-07-03 10:36:11.0 +0200
+++ /home/bo/git/genkde4svn-dev/eclass/subversion.eclass 2008-02-15 23:27:36.0 +0100
@@ -1,56 +1,52 @@
-# Copyright 1999-2007 Gentoo Foundation
+# Copyright 1999-2008 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/eclass/subversion.eclass,v 1.44 2007/07/03 08:27:40 peper Exp $
+# $Header: $
-## --- #
-# Author: Akinori Hattori [EMAIL PROTECTED]
+# @ECLASS: subversion.eclass
+# @MAINTAINER:
+# ???
+#
+# Original author: Akinori Hattori [EMAIL PROTECTED]
+# @BLURB: The subversion eclass is written to fetch software sources from subversion repositories
+# @DESCRIPTION:
+# The subversion eclass provides functions to fetch, patch and bootstrap
+# software sources from subversion repositories.
#
-# The subversion eclass is written to fetch the software sources from
-# subversion repositories like the cvs eclass.
-#
-#
-# Description:
-# If you use this eclass, the ${S} is ${WORKDIR}/${P}.
-# It is necessary to define the ESVN_REPO_URI variable at least.
-#
-## --- #
+# You must define the ESVN_REPO_URI variable before inheriting this eclass.
inherit eutils
ESVN=subversion.eclass
-EXPORT_FUNCTIONS src_unpack
+EXPORT_FUNCTIONS src_unpack pkg_preinst
DESCRIPTION=Based on the ${ECLASS} eclass
-
-## -- add subversion in DEPEND
-#
DEPEND=dev-util/subversion
-
-## -- ESVN_STORE_DIR: subversion sources store directory
-#
-ESVN_STORE_DIR=${PORTAGE_ACTUAL_DISTDIR-${DISTDIR}}/svn-src
-
-
-## -- ESVN_FETCH_CMD: subversion fetch command
-#
+# @ECLASS-VARIABLE: ESVN_STORE_DIR
+# @DESCRIPTION:
+# subversion sources store directory
+ESVN_STORE_DIR=${PORTAGE_ACTUAL_DISTDIR:-${DISTDIR}}/svn-src
+
+# @ECLASS-VARIABLE: ESVN_FETCH_CMD
+# @DESCRIPTION:
+# subversion fetch command
ESVN_FETCH_CMD=svn checkout
-## -- ESVN_UPDATE_CMD: subversion update command
-#
+# @ECLASS-VARIABLE: ESVN_UPDATE_CMD
+# @DESCRIPTION:
+# subversion update command
ESVN_UPDATE_CMD=svn update
-
-## -- ESVN_OPTIONS:
-#
+# @ECLASS-VARIABLE: ESVN_OPTIONS:
+# @DESCRIPTION:
# the options passed to checkout or update.
-#
-: ${ESVN_OPTIONS=}
-
+ESVN_OPTIONS=${ESVN_OPTIONS:=}
-## -- ESVN_REPO_URI: repository uri
+# @ECLASS-VARIABLE: ESVN_REPO_URI
+# @DESCRIPTION:
+# repository uri
#
# e.g. http://foo/trunk, svn://bar/trunk
#
@@ -59,11 +55,19 @@
# https://
# svn://
# svn+ssh://
-#
-: ${ESVN_REPO_URI=}
-
+ESVN_REPO_URI=${ESVN_REPO_URI:=}
-## -- ESVN_PROJECT: project name of your ebuild (= name space)
+# @ECLASS-VARIABLE: ESVN_REVISION
+# @DESCRIPTION:
+# svn revision to fetch
+#
+# Note that if you're specifying a revision to fetch in ESVN_OPTIONS while
+# setting ESVN_REVISION, you will get an error message.
+ESVN_REVISION=${ESVN_REVISION:=}
+
+# @ECLASS-VARIABLE: ESVN_PROJECT
+# @DESCRIPTION:
+# project name of your ebuild (= name space)
#
# subversion eclass will check out the subversion repository like:
#
@@ -82,45 +86,62 @@
# ESVN_PROJECT=commons/logging
#
# default: ${PN/-svn}.
-#
-: ${ESVN_PROJECT:=${PN/-svn}}
-
+ESVN_PROJECT=${ESVN_PROJECT:=${PN/-svn}}
-## -- ESVN_BOOTSTRAP:
-#
+# @ECLASS-VARIABLE: ESVN_BOOTSTRAP
+# @DESCRIPTION:
# bootstrap script or command like autogen.sh or etc..
-#
-: ${ESVN_BOOTSTRAP=}
-
+ESVN_BOOTSTRAP=${ESVN_BOOTSTRAP:=}
-## -- ESVN_PATCHES:
-#
-# subversion eclass can apply pathces in subversion_bootstrap().
+# @ECLASS-VARIABLE: ESVN_PATCHES
+# @DESCRIPTION:
+# subversion eclass can apply patches in subversion_bootstrap().
# you can use regexp in this variable like *.diff or *.patch or etc.
# NOTE: patches will be applied before ESVN_BOOTSTRAP is processed.
#
# Patches are searched both in / and ${FILESDIR}, if not found in both locations,
# the installation dies.
-#
-: ${ESVN_PATCHES=}
-
Re: [gentoo-dev] subversion.eclass
On Saturday 16 February 2008 00:40:31 Doug Klima wrote: For quite a while the KDE herd has had a modified version of subversion.eclass in the kde overlay. During that time we have added the following features to the eclass which we would like to put back in gentoo-x86 soon. Since the changes are fairly extensive we decided to send it to this list for review first. 1) ESVN_REVISION (before this people had to use ESVN_OPTIONS for this purpose). ESVN_REPO_URI is a standard subversion URI and as such supports @HEAD, @BASE, @COMMITTED, @PREV and @REV. So this is unnecessary. The idea is that users can set ESVN_REVISION in the environment without having to modify the ebuilds. This isn't really possible with appending it to ESVN_REPO_URI. 2) ESVN_OFFLINE which disables svn up. Isn't this a bit of a hack? The point is for it to run svn up. Now I've added support in a local refactor that I had started today that if the working copy's revision matches the requested revision, that no svn up is performed. Obviously the situation when you have a live SVN ebuild would still result in an svn up, but then again live SVN ebuilds are frowned upon and if the person is trying to emerge a live SVN ebuild I would expect them to always get the latest version. Same as above. It's a convenience for users of live ebuilds which enables them to rebuild a package even when they don't have network without having to look up the revision of every packages that is currently available. 3) ESVN_UP_FREQ which uses GNU find to determine if the specified number of hours has passed and only do svn up if it has. This is currently used in the kde4svn-meta eclass for split kde ebuilds that use the same checkout of each module. This would be handled by the feature above. How? 4) ESCM_LOGDIR for logging which revisions packages get installed with. See [1]. Users need to explicitly enable this feature to use it. This seems like it belongs in a generic SCM framework/eclass that all SCM eclasses can support. Not opposed to that. But what would that scm eclass do exactly? [...] -- Bo Andresen Gentoo KDE dev signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: adding support for running eautoconf to base.eclass
On Wednesday 13 February 2008 20:30:30 Petteri Räty wrote: How can I use PATCHES without quoting issues? Attached is a patch that fixes this. So is someone going to fix epatch too? Otherwise it is rather moot. -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Friday 21 December 2007 05:25:00 Zhang Le wrote: The question is really simple. Whether we should have two different place to define EAPI? We need two places because it wasn't implemented properly in the first place and we want to retain backwards compatibility for people who use old versions of portage. The whole point is to keep a sane upgrade path available indefinitely for people with old versions of portage. Proponents are trying to prove that we should at least need it be in file name. We need the file name to change because otherwise old versions of portage will try to source the ebuild when the EAPI is unknown. This either blocks new useful features that will make old versions of portage fail to source them or results in more bug reports with zillions of dupes (like the bugs in [1]) because people with ancient versions of portage feel the need to report bug reports when portage fails after a sync. At the very least it means waiting for a year between a release with a version of portage that supports this and an EAPI that takes advantage of it. So now that leaves the question whether we want to change the file name once and hope that we won't need to do it again or whether we want to use the technically more flexible way where the file name changes whenever a new EAPI gets agreed upon. Or alternatively whether we want to limit ourselves by using an inferior solution that limits or delays progress considerably and results in more bug reports with zillions of dupes... [1] http://www.gentoo.org/proj/en/portage/doc/common-problems.xml -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thursday 20 December 2007 17:14:52 Thomas Pani wrote: Are we Debian now? A new feature gets implemented (obviously because we *need* it) and we can make use of it in a *year*? No, we're not Debian, thank god. I thought the wait 1+ year policy changed? Again citing Ciaran: That was only the case because previously, using new features that Portage didn't support would cause horrible breakage. Now, instead, the ebuilds show up as being masked. [2] It has changed as long as you don't introduce features that makes old versions of portage fail to source the ebuild. EAPI=1 didn't do that. -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Friday 21 December 2007 05:46:35 Josh Saddler wrote: Who cares? Gentoo uses the ebuild/bash-with-shebang format. If you're trying to shove in something outside of that, that would be a package manager-specific format. Like XML-stuff (that can't include the shebang or EAPI=foo at the top) specifically for, say, Paludis. GLEP means Gentoo Linux Enhancement Proposal. It was proposed to enhance Gentoo... Paludis already supports this kind of thing for usage outside gentoo-x86. That has no relevance to Gentoo unless the GLEP gets approved... -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thursday 20 December 2007 20:01:55 Zhang Le wrote: IMO, we can not have more than two EAPI's simultaneously. That defeats the whole purpose of having EAPIs. Which is to keep a sane upgrade path... -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thursday 20 December 2007 22:33:25 Joe Peterson wrote: Technical reasons to avoid the filename are: 2) Having the same info in more than one place is bad (requiring extra repoman checks and the potential for ambiguity). As opposed to adding checks to make sure that obtaining the EAPI from the contents of the file doesn't require bash? 3) It uses the extension in a way that goes against common use in computers. What? It uses the extension to determine the format of the contents? -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thursday 20 December 2007 11:09:44 Donnie Berkholz wrote: Looking at my kernel config, ext3 and reiser explicitly support xattrs, and I see jfs and xfs have acls and security labels, which might be usable. [...] The idea of the sqlite-based fallback is what's interesting here. I thought some of the other ideas were pretty bad... Guess I was wrong... This is the worst idea I have ever heard. -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thursday 20 December 2007 13:48:31 Steve Long wrote: (optimising early here seems silly tbh, given that paludis now requires ruby.) Eh? Now what're you on about? http://bugs.gentoo.org/show_bug.cgi?id=198864 So here you're showing that you don't know what a USE flag is? -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Tuesday 18 December 2007 01:36:51 Thomas de Grenier de Latour wrote: Why can't it be in the file but readable without sourcing? For instance, it could be mandatory that EAPI=X, if present, must be the first non-blank and non-comment line of the ebuild (and it would then be checked after sourcing, if the ebuild is sourced, to bug on cases where it's redefined or unset afterwards). This would also mean we had to wait for ages before taking advantage of it because old versions of portage still would try to source the ebuild when the EAPI is unknown. The nice thing about .ebuild-EAPI is that old versions of Portage will ignore it. -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in www-servers/resin: ChangeLog resin-3.0.25.ebuild resin-3.1.4.ebuild
On Sunday 16 December 2007 08:03:37 Donnie Berkholz wrote:
chmod 755 ${S}/configure
fperms means you don't need S or quotes.
fperms works on D. Not S.
--
Bo Andresen
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-video/undvd: undvd-0.3.0.ebuild metadata.xml ChangeLog Manifest
On Sunday 16 December 2007 08:13:49 Donnie Berkholz wrote:
On 17:46 Fri 14 Dec , Greg Kroah-Hartman (gregkh) wrote:
pkg_setup() {
einfo Checking mplayer for USE flags we need...
for f in encode dvd x264 mp3; do
if ! built_with_use media-video/mplayer $f; then
eerror $f
die mplayer merged without $f USE flag
fi
done
Does this actually work as you want? I'd be surprised. Quoting the whole
thing should treat it as a single flag with spaces and only run through
the loop once.
It should only coincidentally work because built_with_use() takes any
number of flags and loops through them, but I doubt it prints the single
missing flag as you intend.
Indeed it works because $f isn't quoted and built_with_use handles a list just
fine. Just the for loop is pointless. Fixing it to check only one use flag at
a time, however, is a horrible idea because it risks telling the user to
recompile mplayer four times each adding another use flag. There really is no
reason not to just show the full list of required flags if one of them is
missing but if you really want to at least move the die out of the loop.
--
Bo Andresen
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-video/undvd: undvd-0.3.0.ebuild metadata.xml ChangeLog Manifest
On Monday 17 December 2007 00:48:12 Duncan wrote: I think it's valuable to show the flags that actually need to be changed rather than a full list of all required flags. ++ I had a USE blocker give me a list, recently, and it was mildly irritating to have to sort out which of the several USE flags were wrong. You don't need to know. Just put all of them in package.use. -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libevent: ChangeLog libevent-1.3e.ebuild
On Wednesday 14 November 2007 01:33:54 Jan Kundrát wrote: Steve Long wrote: Is [[:alpha:]] locale-safe? Yes, all POSIX character classes listed here are: http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html Thanks for a nice link. If I read section 7.3.1 correctly, [[:alpha:]] always contains those letters, but might contain more, depending on the locale. So it's probably very minor point, but as long as the script runs with user-provided locale, one should be explicit here. Or am I missing something here? If you think [a-zA-Z] is being explicit then you are clearly missing something. E.g. if you google for the estonian alphabet you'll see a lot of ansi letters are after z in that alphabet. So on estonian locales those letters won't be included in [a-z] but they will be included in [:alpha:]. -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] repoman and checking for correct quoting
On Sat, Nov 10, 2007 at 11:51:37AM +0100, Krzysiek Pawlik wrote:
It's purpose is to remove the ${D} from makefile, additionally ${D} is in
single
quotes, so it will not be expanded - is it a bug in repoman check?
What ${D} ? I see none in that makefile. Which is why I think a patch would be
better in this case. A patch would actually tell you when half of the
substitutions don't match anything... I think this is a point worth making even
if it doesn't change your point.
--
Bo Andresen
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] More general interface to use flags
On Friday 02 November 2007 17:10:29 Roy Marples wrote: and the answer is still the same. POSIX conversions are irrelevant until you can propose solutions for the things bash can do but POSIX cannot. you can only provide workarounds or hacks, so any further attempt on the topic is half way conversions that lead to ugly inconsistencies. Please point to the ugly inconsistent POSIX hacks in this thread? Please explain why you hijack this thread to discuss POSIX vs. bash when it's supposed to be about the API for ebuilds. -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] More general interface to use flags
On Friday 02 November 2007 17:52:13 Roy Marples wrote: On Fri, 2007-11-02 at 17:30 +0100, Bo Ørsted Andresen wrote: Please explain why you hijack this thread to discuss POSIX vs. bash when it's supposed to be about the API for ebuilds. I dislike the gratuitous use of bash for no good reason - and in the code he gave there is no good reason for using bashisms. So your approach to getting it your way is to hijack every thread that shows use of bashisms until people start using your inferior workarounds? -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-misc/note: ChangeLog note-1.3.3.ebuild
On Monday 15 October 2007 09:42:50 Donnie Berkholz wrote:
On 07:40 Mon 15 Oct , Christian Faulhammer (opfer) wrote:
1.1 app-misc/note/note-1.3.3.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-misc/note/note-1.3.3.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-misc/note/note-1.3.3.ebuild?rev=1.1content-type=text/plain
for v in mysql text dbm general; do
if ! use ${v}; then
for u in `find ${D} -type f -name *${v}.*pm`; do
rm ${u}
Looks like 'u' could have spaces in it, since it's based on D.
Written like this u certainly can't since the output of the find expression is
subjected to word splitting before u gets set. Hence this will fail if ${D}
contains spaces even if ${u} gets quoted. The best way to solve this is to use
find ... -print0 | xargs -0 rm. Unfortunately that solution means using GNU
extensions that I'm not sure are guaranteed to be available in the ebuild
environment. If they aren't maybe they should be.
--
Bo Andresen
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-fs/openafs: ChangeLog openafs-1.4.5_pre1.ebuild
On Sunday 14 October 2007 10:39:53 Donnie Berkholz wrote:
On 14:25 Sat 13 Oct , Stefaan De Roeck (stefaan) wrote:
1.1 net-fs/openafs/openafs-1.4.5_pre1.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-fs/openafs/openafs-1.4.5_pre1.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-fs/openafs/openafs-1.4.5_pre1.ebuild?rev=1.1content-type=text/plain
PATCHDIR=${WORKDIR}/gentoo/patches/$(get_version_component_range 1-2)
CONFDIR=${WORKDIR}/gentoo/configs
SCRIPTDIR=${WORKDIR}/gentoo/scripts
Repoman won't catch these, but they still need quotes.
Actually they don't in assignments like these. In the rest of the ebuild
${PATCHDIR}, ${CONFDIR} and ${SCRIPTDIR} need quotes though (the same applies
to variables such as ${oldafsconfdir}, ${newafsconfdir} etc.). This ebuild also
contains a lot of [ ... ] tests that should either be converted to [[ ... ]] or
have all variables inside them quoted.
--
Bo Andresen
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-kids/gcompris: ChangeLog gcompris-8.4.ebuild
On Monday 08 October 2007 06:47:05 Donnie Berkholz wrote:
src_unpack() {
[SNIP]
Shouldn't this respect ROOT != / ? I can see how that would be a bit of
an unusual use case for games, though.
Use of $ROOT in src_* would be illegal (which is why there a bunch of bug
reports with abusing ROOT in the summary field...).
--
Bo Andresen
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [RFC] Planning for the transition to EAPI=1 support
On Friday 05 October 2007 04:26:50 Marius Mauch wrote: Problem is that nobody feels responsible for eselect anymore, so nobody takes care of bug #179064 (and I'm not going to play catchup games with externally hosted code). eselect isn't externally hosted. The code is available from svn at: http://sources.gentoo.org/viewcvs.py/eselect/ -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] controlling src_test
On Friday 05 October 2007 01:14:32 Marius Mauch wrote: (btw, the /etc/portage/env trick only works because the default src_test in ebuild.sh has the otherwise redundant FEATURES check which was discussed a few days ago in one of the commit reviews) src_test() is not called in dyn_test() unless test is in FEATURES. Therefore the FEATURES check in the default src_test() is redundant. -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-scheme/bigloo: ChangeLog bigloo-3.0b_p2.ebuild
On Tuesday 25 September 2007 12:47:35 Marijn Schouten (hkBst) wrote:
# make test does something weird so default src_test() in
/usr/lib/portage/bin/ebuild.sh fails the following test
# elif emake -j1 test -n /dev/null; then
# so copy straight from default src_test() all the stuff which depends on
that test passing
src_test() {
vecho Test phase [test]: ${CATEGORY}/${PF}
if ! emake -j1 test; then
hasq test $FEATURES die Make test failed. See above for
details.
hasq test $FEATURES || eerror Make test failed. See above for
details.
fi
}
I'm a bit confused about what's going on here. Isn't src_test() only
supposed to run when 'test' is in FEATURES?
I'm not sure, but as the comment says, I copied this straight from
/usr/lib/portage/bin/ebuild.sh and it goes:
[SNIP]
Some of that code is unreachable since src_test is never called when test is
not in FEATURES. Also there is some dispute as to whether testing the FEATURES
variable at all is permitted in ebuilds (bug #174335). In either case it's not
needed here. if `emake -j1 test -n` really fails for some reason even though
`emake -j1 test` generally works your src_test should just be:
src_test() {
emake -j1 test || die Make test failed
}
--
Bo Andresen
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-dotnet/libgdiplus: ChangeLog libgdiplus-1.2.5-r1.ebuild
On Monday 24 September 2007 21:56:49 Donnie Berkholz wrote:
if [[ $(gcc-major-version) -gt 3 ]] || \
( [[ $(gcc-major-version) -eq 3 ]] [[ $(gcc-minor-version)
-gt 3 ]] )
Code block { } might be good here instead of a subshell, or perhaps it
could use logic that's less convoluted such as if..then. Also don't need
the double quotes.
Or it could be as simple as:
if [[ $(gcc-major-version) -gt 3 || \
( $(gcc-major-version) -eq 3 $(gcc-minor-version) -gt 3 ) ]]
[[ allows grouping of conditions without spawning subshells.
--
Bo Andresen
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-video/mplayer: ChangeLog mplayer-1.0_rc1_p20070824.ebuild
On Monday 24 September 2007 21:53:14 Donnie Berkholz wrote:
- use video_cards_mga || myconf=${myconf} --disable-mga
- ( use X use video_cards_mga ) || myconf=${myconf} --disable-xmga
+ use video_cards_mga myconf=${myconf} --enable-mga
+ ( use X use video_cards_mga ) myconf=${myconf} --enable-xmga
Subshells are gross, can you try a code block { } instead?
A code block isn't even required since this grouping does the same as without
it. More importantly, though, why isn't this ebuild using use_enable? It
seems that:
use X myconf=$myconf $(use_enable video_cards_mga xmga)
myconf=$myconf $(use_enable video_cards_mga mga)
would do the same?
In another example from the ebuild:
use bl myconf=${myconf} --enable-bl
if USE=bl is disabled --disable-bl isn't passed to the configure script which
means the default is picked. There's a good chance that this kind of
behaviour results in automagic deps...
http://www.gentoo.org/proj/en/qa/automagic.xml
--
Bo Andresen
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] gentoo-x86 commit in sys-cluster/csync2: ChangeLog csync2-1.34.ebuild
On Thursday 20 September 2007 19:54:16 Donnie Berkholz wrote: econf has default econf failed die message. The following would be sufficient: econf \ --localstatedir=/var \ --sysconfdir=/etc/csync2 Is that so ... when did that appear? Does it happen for all of the package managers? Which functions do this? Where is it documented? The currect PMS draft documents it (for econf only). All three package managers conform to it. -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] missing herd tag in metadata.xml
On Thursday 10 May 2007 19:38:13 Thilo Bangert wrote: /me goes back to reading up on some history: missing metadata.xml - 2006-11-22 http://thread.gmane.org/gmane.linux.gentoo.devel/44407 -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Ideas for projects...
On Friday 12 January 2007 05:43, Richard Fish wrote: My idea would be to extend emaint to check package.keywords and package.use for obsolete flags, unnecessary atoms (like foo-1.2 in keywords when foo-1.3 is stable), atoms that don't match any current ebuild, and so on. app-portage/eix already does a lot of this with --test-non-matching and --test-obsolete. -- Bo Andresen pgpxLeKmkecCN.pgp Description: PGP signature
Re: [gentoo-dev] Re: Versioning the tree
On Wednesday 29 November 2006 09:37, Stuart Herbert wrote: Gcc 4.1.1 wasn't a last minute change. I can't agree with you there. It doesn't matter how many months of planning and work you guys put into getting gcc-4.1 fit for stable. If you're doing it off in your own little corner of the world, and then springing it on the rest of us just days before the release happens, then to the much larger dev community, it comes as a last minute change. It was announced two months before 2006.1 was released. http://thread.gmane.org/gmane.linux.gentoo.devel/39848 -- Bo Andresen pgp1vg97DV5SS.pgp Description: PGP signature
Re: [gentoo-dev] Re: Versioning the tree
On Wednesday 29 November 2006 18:11, Stuart Herbert wrote: Except it was announced before we even made the snapshot, Sorry, I've looked, but the only announcement I found on gentoo-dev was posted two days before gcc-4.1 was stabilised [1]. I must have missed the earlier announcement? Maybe you should read the replies you got the first time you made this claim on this list [1]. I've stated my opinion on the matter once at the gentoo-user mailing list [2] so I'll refrain from doing so here. Also just for completeness I repeat the link to the original announce [3] two months prior to the release. [1] http://thread.gmane.org/gmane.linux.gentoo.devel/41923/focus=41944 [2] http://thread.gmane.org/gmane.linux.gentoo.user/169041/focus=169455 [3] http://thread.gmane.org/gmane.linux.gentoo.devel/39848 -- Bo Andresen pgpg6IgkTv7zc.pgp Description: PGP signature
Re: [gentoo-dev] [treecleaner] Last rites: media-sound/alsaplayer
On Monday 21 August 2006 14:59, Abhay Kedia wrote: I use alsaplayer to play KDE sounds as it works well with dmix and I can keep aRts disabled. All KDE sounds are ogg files and when I play them with mpg321, it just exits without producing any sound. I guess the only thing left for me to use is mplayer? I don't really recall setting this but it appears I'm using playsound with KDE. It works too. $ equery belongs playsound [ Searching for file(s) playsound in *... ] media-libs/sdl-sound-1.0.1-r2 (/usr/bin/playsound) -- Bo Andresen pgpbjPDnNKTXq.pgp Description: PGP signature
Re: [gentoo-dev] GPL and Source code providing
On Wednesday 28 June 2006 16:28, Mivz wrote: How free is free software if you need a lawyer and a expensive server just to be able to publish your addition under your own name? There is nothing preventing you from just publishing a patch with your name. The problem arises only if you distribute a binary without either source or an offer to provide source on request... -- Bo Andresen pgpDZsYJU0GvH.pgp Description: PGP signature
Re: [gentoo-dev] Re: Did portage 2.1 change default use flags?
On Wednesday 14 June 2006 14:42, Alec Warner wrote: * autouse (use.defaults) has been deprecated by specifying USE_ORDER in make.defaults. Users may still turn this back on by specifying USE_ORDER=env:pkg:conf:auto:defaults in make.conf. Interested in figuring out what use flags were turned off? Check out /usr/portage/profiles/base/use.defaults and other use.defaults files that correspond to your profile. I'm sorry, but that doesn't make a lot of sense. use.defaults hasn't been deprecated. The January GWN [1] specified this much more clearly. Also checking out the use.defaults files won't tell you what was turned off unless you have an old version to diff it against. 'emerge -uvpDN world' will, however. [1] http://www.gentoo.org/news/en/gwn/20060116-newsletter.xml -- Bo Andresen pgp8UyshCu0GR.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Did portage 2.1 change default use flags?
On Wednesday 14 June 2006 18:40, Alec Warner wrote: There is no comparison, use.defaults IS the file. Look at it. [SNIP] and so on. If package is installed, the corresponding flag is turned on automatically hence autouse. This no longer occurs in 2.1. Ah, now I get it. I didn't realize that. The FAQ question you mentioned on the project page would be a good idea, if you get the time. And thanks for adding it. :) -- Bo Andresen pgpmie6bTp5Dc.pgp Description: PGP signature
Re: [gentoo-dev] Did portage 2.1 change default use flags?
On Monday 12 June 2006 12:57, Bo Ørsted Andresen wrote: On Monday 12 June 2006 12:42, Peter wrote: All of a sudden, emerge -uD --newuse world is showing dozens of ebuild that are replaced due to removed use flags. Did someone change the default use flags? Upgraded yesterday to portage 2.1. Look at the first section of [1]. Just so you know it this could have been answered on -user too. [1] http://www.gentoo.org/news/en/gwn/20060116-newsletter.xml As far as I can see this is not mentioned in either this weeks GWN [1], the portage 2.1 release notes [2] or the 2.1 news page [3]. I'm sure a lot of people running stable don't remember the GWN from January. Shouldn't this be mentioned somewhere now? [1] http://www.gentoo.org/news/en/gwn/20060612-newsletter.xml [2] http://sources.gentoo.org/viewcvs.py/portage/main/trunk/RELEASE-NOTES?view=markup [3] http://sources.gentoo.org/viewcvs.py/portage/main/trunk/NEWS?view=markup -- Bo Andresen pgpaAvpXftUMy.pgp Description: PGP signature
Re: [gentoo-dev] Did portage 2.1 change default use flags?
On Monday 12 June 2006 12:42, Peter wrote: All of a sudden, emerge -uD --newuse world is showing dozens of ebuild that are replaced due to removed use flags. Did someone change the default use flags? Upgraded yesterday to portage 2.1. Look at the first section of [1]. Just so you know it this could have been answered on -user too. [1] http://www.gentoo.org/news/en/gwn/20060116-newsletter.xml -- Bo Andresen pgpCxuJCXJaQE.pgp Description: PGP signature
