Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild
Steve Long wrote:
insinto /usr/share/doc/${P}/examples
Is there any chance we can start using correctly quoted filenames across the
board?
Since when is ${P} allowed to have spaces?
Besides being faster (quote the whole thing)
Have you done a benchmark certifying that "/usr/share/doc/${P}/examples"
is faster than /usr/share/doc/${P}/examples?
more useful error messages in the case of a dev/user slip-up
Could you elaborate?
They also highlight better in a capable editor.[1]
Please elaborate.
Cheers,
-jkt
--
cd /local/pub && more beer > /dev/mouth
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms
On Mon, 13 Oct 2008 06:16:01 +0100 Steve Long <[EMAIL PROTECTED]> wrote: > Unless someone can say what using PROPERTIES=prefix would break, I'd > go with that. It's a /classic/ usage of that variable, as it's simply > a boolean; PROPERTIES is well-defined and I'm hoping all the manglers > support it. It'd be great to see the prefix branch finally merged so > we all get to play with it. It would break. Prefix ebuilds won't work unless ED is set, and a non PROPERTIES aware or non-prefix-property aware package manager won't set ED. Unless prefix is reimplemented to require no package manager changes for the install to / case, PROPERTIES is out. -- Ciaran McCreesh signature.asc Description: PGP signature
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: fox.eclass update
Matti Bickel kirjoitti: > Hi folks, > > While fixing bug #240060 I touched fox.eclass. > In the process, I updated the eclass to > * use versionator > * cut support for fox-1.0 (loong outdated) > * cut support for fox-1.5 > * use eautomake instead of =automake-1.4* > * use emake instead of make > * use elog instead of einfo > * apply more variable quoting > > I'm sure, I missed one or the other issue. That's why I'm posting it > here for public review. If you have requests or comments to make, please > reply to this thread. > Could you also send a diff next time. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: fox.eclass update
On 13:56 Mon 13 Oct , Petteri Räty wrote: > Could you also send a diff next time. Or this time, even. +1 on that. One easy thing to do is move what comments exist to the eclass-manpages format. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpE4dFNeVYYH.pgp Description: PGP signature
Re: [gentoo-dev] EAPI change: Call ebuild functions from trusted working directory
On 21:03 Thu 09 Oct , Robert Buchholz wrote: > I would like: > * everyone to comment on the change and propose changes to the wording > * council to vote on this change to EAPI-0, -1 and -2. It seems to me that this is an EAPI=0 change. Since EAPI=1 and EAPI=2 are just differences to EAPI=0, they wouldn't be voted on. Since EAPI=0 isn't actually approved yet, council wouldn't vote either. As it's a draft standard, this would be resolved amongst package-manager developers and PMS editors. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpXNU4KZgRYa.pgp Description: PGP signature
Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms
On 13-10-2008 15:27:10 +0100, Ciaran McCreesh wrote:
> On Mon, 13 Oct 2008 06:16:01 +0100
> Steve Long <[EMAIL PROTECTED]> wrote:
> > Unless someone can say what using PROPERTIES=prefix would break, I'd
> > go with that. It's a /classic/ usage of that variable, as it's simply
> > a boolean; PROPERTIES is well-defined and I'm hoping all the manglers
> > support it. It'd be great to see the prefix branch finally merged so
> > we all get to play with it.
>
> It would break. Prefix ebuilds won't work unless ED is set, and a non
> PROPERTIES aware or non-prefix-property aware package manager won't set
> ED. Unless prefix is reimplemented to require no package manager
> changes for the install to / case, PROPERTIES is out.
Just to comment on this possibility; I see an option, given the
definition of ED and EROOT to do Prefix without them, by e.g. using
${D}${EPREFIX} instead of ${ED} as shorthand. When ${EPREFIX} would be
unset, this would result in simple ${D}, which is "backwards
compatible". This is not all what is necessary, but a big deal of it.
Question here, however, is whether this is worth it. Personally, I
prefer the shorthands, as they give a lot of readability.
--
Fabian Groffen
Gentoo on a different level
Re: [gentoo-dev] EAPI change: Call ebuild functions from trusted working directory
On Monday, 13. October 2008 19:42:21 Donnie Berkholz wrote: > Since EAPI=0 isn't actually approved yet, council wouldn't vote > either. As it's a draft standard, this would be resolved amongst > package-manager developers and PMS editors. So, EAPI-2 had to be approved before it could be used in the tree. EAPI-0 isn't "actually approved yet", though, so it must not be used in the tree, right? ;-) And since EAPI-1 builds upon EAPI-0, that's not acceptable in the tree either. (And, btw, the former council decided there wouldn't be any new EAPIs before EAPI-0 wasn't approved.) While I agree with your intention of letting people decide upon the stuff they have to work with mostly on their own and with each other, I think your argument, Donnie, is rather "interesting". :-) Best regards, Wulf signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: fox.eclass update
Donnie Berkholz <[EMAIL PROTECTED]> wrote:
> On 13:56 Mon 13 Oct , Petteri Räty wrote:
> > Could you also send a diff next time.
>
> Or this time, even. +1 on that.
Here you are. It's attached.
> One easy thing to do is move what comments exist to the eclass-manpages
> format.
I also included some eclass-manpage foo now, thanks for the hint.
--
Regards, Matti Bickel
Signed/Encrypted email preferred (key 4849EC6C)
--- gentoo-x86/eclass/fox.eclass2008-10-12 14:31:36.0 +0200
+++ fox-proposed.eclass 2008-10-13 20:27:05.0 +0200
@@ -1,8 +1,12 @@
# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/eclass/fox.eclass,v 1.8 2008/10/12 12:31:36
mabi Exp $
+# $Header: /var/cvsroot/gentoo-x86/eclass/fox.eclass,v 1.7 2007/01/15 20:27:06
mabi Exp $
-# fox eclass
+# @ECLASS: fox.eclass
+# @MAINTAINER: [EMAIL PROTECTED]
+# @BLURB: Common build and install functions for fox-related apps and library
+# @DESCRIPTION: Used by the x11-libs/fox library and all applications that come
+# with the upstream source tarball.
#
# This eclass allows building SLOT-able FOX Toolkit installations
# (x11-libs/fox: headers, libs, and docs), which are by design
@@ -19,26 +23,18 @@
# are API unstable; changes are made to the apps, and likely need to be
# bumped together with the library.
#
-# Here are sample [R]DEPENDs for the fox apps
-# fox versions that do not use this eclass are blocked in INCOMPAT_DEP below
-# 1.0: '=x11-libs/fox-1.0*'
-# 1.2: '=x11-libs/fox-1.2*'
+# Some concepts borrowed from gst-plugins and gtk-sharp-component eclasses
+#
+# @EXAMPLE: Here are sample [R]DEPENDs for the fox apps
# 1.4: '=x11-libs/fox-1.4*'
# 1.5: '~x11-libs/fox-${PV}'
# 1.6: '=x11-libs/fox-${FOXVER}*'
-#
-# Some concepts borrowed from gst-plugins and gtk-sharp-component eclasses
-
-inherit eutils libtool versionator
+inherit autotools eutils libtool versionator
FOX_PV="${FOX_PV:-${PV}}"
-PVP=(${FOX_PV//[-\._]/ })
-FOXVER="${PVP[0]}.${PVP[1]}"
-
-if [ "${FOXVER}" != "1.0" ] ; then
- FOXVER_SUFFIX="-${FOXVER}"
-fi
+FOXVER=$(get_version_component_range 1-2)
+FOXVER_SUFFIX="-${FOXVER}"
DESCRIPTION="C++ based Toolkit for developing Graphical User Interfaces easily
and effectively"
HOMEPAGE="http://www.fox-toolkit.org/";
@@ -46,44 +42,28 @@
IUSE="debug doc profile"
-# from fox-1.0
-FOX_APPS="adie calculator pathfinder"
-# from fox-1.2+
-if [ "${FOXVER}" != "1.0" ] ; then
- FOX_APPS="${FOX_APPS} shutterbug"
- FOX_CHART="chart"
-fi
+# @ECLASS-VARIABLE: FOX_APPS
+# @DESCRIPTION: all applications that come with the fox toolkit source
+FOX_APPS="adie calculator pathfinder shutterbug chart"
if [ "${PN}" != fox ] ; then
FOX_COMPONENT="${FOX_COMPONENT:-${PN}}"
fi
-if [ "${FOXVER}" != "1.0" ] && [ -z "${FOX_COMPONENT}" ] ; then
- DOXYGEN_DEP="doc? ( app-doc/doxygen )"
-fi
-
if [ "${PN}" != reswrap ] ; then
RESWRAP_DEP="dev-util/reswrap"
fi
-# These versions are not compatible with new fox layout
-# and will cause collissions - we need to block them
-INCOMPAT_DEP="!=sys-devel/automake-1.4
>=sys-apps/sed-4"
S="${WORKDIR}/fox-${FOX_PV}"
fox_src_unpack() {
unpack ${A}
- cd ${S}
+ cd "${S}"
ebegin "Fixing configure"
@@ -103,14 +83,14 @@
done
# use the installed reswrap for everything else
- for d in ${FOX_APPS} ${FOX_CHART} tests ; do
+ for d in ${FOX_APPS} tests ; do
sed -i -e 's:$(top_builddir)/utils/reswrap:reswrap:' \
${d}/Makefile.am || die "sed ${d}/Makefile.am error"
done
# use the installed headers and library for apps
for d in ${FOX_APPS} ; do
- if version_is_at_least "1.6.34" ${PV} ; then
+ if version_is_at_least "1.6.34" ${PV}; then
sed -i \
-e "s:-I\$(top_srcdir)/include
-I\$(top_builddir)/include:-I\$(includedir)/fox${FOXVER_SUFFIX}:" \
-e 's:$(top_builddir)/src/libFOX:-lFOX:' \
@@ -124,19 +104,13 @@
${d}/Makefile.am || die "sed ${d}/Makefile.am
error"
fi
done
-
- # Upstream often has trouble with version number transitions
- if [ "${FOXVER}" == "1.5" ] ; then
- sed -i -e 's:1.4:1.5:g' chart/Makefile.am
- fi
-
eend
ebegin "Running automake"
- automake-1.4 -a -c || die "automake error"
+ eautomake || die "automake error"
eend
- elibtoolize
+ #elibtoolize
}
fox_src_compile() {
@@ -150,21 +124,21 @@
$(use_with profile profiling) \
|| die "configure error"
- cd ${S}/${FOX_COMPONENT}
+ cd "${S}/${FOX_COMPONENT}"
emake || die "compile error"
# build class reference docs (FOXVER >=
Re: [gentoo-dev] EAPI change: Call ebuild functions from trusted working directory
On Mon, 13 Oct 2008 10:42:21 -0700 Donnie Berkholz <[EMAIL PROTECTED]> wrote: > It seems to me that this is an EAPI=0 change. Since EAPI=1 and EAPI=2 > are just differences to EAPI=0, they wouldn't be voted on. Since > EAPI=0 isn't actually approved yet, council wouldn't vote either. As > it's a draft standard, this would be resolved amongst package-manager > developers and PMS editors. It's a retroactive change to EAPI 0 that requires changes from package managers and has security implications... Robert isn't requesting that we specify and mandate existing behaviour here, so it's not really something that should be left up to PMS to decide and enforce. I mean, if the Council's comfortable with PMS being used to force package manager changes for things that aren't obviously bugs, we could do it without asking, but that looks a lot like a slippery slope... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI change: Call ebuild functions from trusted working directory
On 20:20 Mon 13 Oct , Wulf C. Krueger wrote: > On Monday, 13. October 2008 19:42:21 Donnie Berkholz wrote: > > Since EAPI=0 isn't actually approved yet, council wouldn't vote > > either. As it's a draft standard, this would be resolved amongst > > package-manager developers and PMS editors. > > So, EAPI-2 had to be approved before it could be used in the tree. EAPI-0 > isn't "actually approved yet", though, so it must not be used in the tree, > right? ;-) EAPI=0 was grandfathered in, it's unlike any new set of features. > And since EAPI-1 builds upon EAPI-0, that's not acceptable in the tree > either. > > (And, btw, the former council decided there wouldn't be any new EAPIs > before EAPI-0 wasn't approved.) I think that was done under the assumption that EAPI=0 would actually be finished sometime soon. It's now been 8 months since that discussion. I disagree with halting forward progress on something directly relevant to all ebuild developers (important future ebuild features) to specify existing behavior. I think specifications are useful but are not a blocker. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgp9nkEXXJhrr.pgp Description: PGP signature
Re: [gentoo-dev] System packages in (R)DEPEND?
On Sun, Oct 12, 2008 at 12:04 PM, Thomas Sachau <[EMAIL PROTECTED]> wrote: > I see packages like bison, flex, perl or sed in the system set. And i also > see ebuilds depending on > them. I also heard from Peter Volkov (pva) that there where discussions about > removing different > packages from the system set. So now my question is: > > Should we depend on all system packages? Should we depend on some packages, > because they could be > removed? If yes, which ones? Or should we leave the system packages out > completly? In my quick 30 seconds of searching I found at least one bug on this very issue. You may find more if you look for them. ;) https://bugs.gentoo.org/show_bug.cgi?id=221311 Please provide reasons/justifications for the proposal of removing packages from the system set or from the ebuilds instead of just raising random questions (which end up with no results and hence just "noise"). -Jeremy
[gentoo-dev] Stabilize ebuilds which use EAPIs only supported by ~arch PMs
Hi all: Reading a random discussion in our dev mailling list, I came with a doubt about our new EAPI policy and its procedures. I couldn't find it documented nor discussed anywhere so I bringing it here. Supposing that anyone can currently add an ebuild using EAPI-2 under the testing branch: what are we going to do if an EAPI-2 ebuild (which are only managed by ~arch package managers) needs to go stable due to some kind of major reason like security? Hypothetical case: foo-1 (eapi-0) marked as stable and foo-2 (eapi-2) with new features marked as testing. A security problem appears affecting both. UPSTREAM release foo-3 to solve the security issue. There are some others sceneries but are not so common as the one presented could be. Any decent solution for this case? -- Jose Luis Rivero <[EMAIL PROTECTED]> Gentoo/Doc Gentoo/Alpha
Re: [gentoo-dev] Stabilize ebuilds which use EAPIs only supported by ~arch PMs
On 02:03 Tue 14 Oct , Jose Luis Rivero wrote: > Hi all: > > Reading a random discussion in our dev mailling list, I came with a > doubt about our new EAPI policy and its procedures. I couldn't find it > documented nor discussed anywhere so I bringing it here. > > Supposing that anyone can currently add an ebuild using EAPI-2 under the > testing branch: what are we going to do if an EAPI-2 ebuild (which are > only managed by ~arch package managers) needs to go stable due to some > kind of major reason like security? > > Hypothetical case: foo-1 (eapi-0) marked as stable and foo-2 (eapi-2) > with new features marked as testing. A security problem appears > affecting both. UPSTREAM release foo-3 to solve the security issue. > > There are some others sceneries but are not so common as the one presented > could be. Any decent solution for this case? There are only a few obvious ones, you'll have to pick which one you like best. Most of the other options basically duplicate these in some way or add more work to them for negligible gain: - Backport the ebuild from EAPI=2 to EAPI=0 - Backport the security patch to the EAPI=0 ebuild - Stabilize portage quickly -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpPRRDlntCoO.pgp Description: PGP signature
[gentoo-dev] Re: Stabilize ebuilds which use EAPIs only supported by ~arch PMs
Hi, Jose Luis Rivero <[EMAIL PROTECTED]>: > Hypothetical case: foo-1 (eapi-0) marked as stable and foo-2 (eapi-2) > with new features marked as testing. A security problem appears > affecting both. UPSTREAM release foo-3 to solve the security issue. Backport the fix or create an EAPI=0 ebuild, as the package manager will mask EAPIs it cannot understand, so you cannot emerge it anyway. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://www.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild
On Mon, 13 Oct 2008 03:59:00 +0100
Steve Long <[EMAIL PROTECTED]> wrote:
> Thomas Sachau wrote:
>
> > what about this:
> > insinto /usr/share/doc/${P}/examples
> Is there any chance we can start using correctly quoted filenames
> across the board?
This is correctly quoted, so, yep.
--
gcc-porting, by design, by neglect
treecleaner, for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
signature.asc
Description: PGP signature
