Re: [gentoo-dev] Proposed change to base.eclass: EAPI-2 support
On Monday 03 November 2008, Donnie Berkholz wrote:
> This eclass needs to do the same thing as the other eclasses that got
> EAPI=2 patches and default EAPI to 0 when it's not defined,
> everywhere where it tests the value of EAPI.
Yes, that makes sense, though grepping for EAPI in eclass/ shows me that
not all chose that approach.
Updated patch attached.
--
/PA
--- /usr/portage/eclass/base.eclass 2008-07-17 12:06:27.0 +0200
+++ base.eclass 2008-11-03 06:57:10.0 +0100
@@ -2,32 +2,78 @@
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/base.eclass,v 1.34 2008/07/17 09:49:14 pva Exp $
# @ECLASS: base.eclass
# @MAINTAINER:
-# ???
+# Peter Alfredsen <[EMAIL PROTECTED]>
#
# Original author Dan Armak <[EMAIL PROTECTED]>
# @BLURB: The base eclass defines some default functions and variables.
# @DESCRIPTION:
# The base eclass defines some default functions and variables. Nearly
# everything else inherits from here.
+#
+# NOTE: You must define EAPI before inheriting from base, or the wrong functions
+# may be exported.
inherit eutils
+case "${EAPI:-0}" in
+ 2)
+ EXPORT_FUNCTIONS src_unpack src_prepare src_configure src_compile src_install
+ ;;
+ *)
+ EXPORT_FUNCTIONS src_unpack src_compile src_install
+ ;;
+esac
+
DESCRIPTION="Based on the $ECLASS eclass"
# @FUNCTION: base_src_unpack
# @USAGE: [ unpack ] [ patch ] [ autopatch ] [ all ]
# @DESCRIPTION:
# The base src_unpack function, which is exported. If no argument is given,
-# "all" is assumed.
+# "all" is assumed if EAPI!=2, "unpack" if EAPI=2.
base_src_unpack() {
debug-print-function $FUNCNAME $*
- [ -z "$1" ] && base_src_unpack all
+
+ if [ -z "$1" ]
+ then
+ case "${EAPI:-0}" in
+ 2)
+base_src_util unpack
+;;
+ *)
+base_src_util all
+;;
+ esac
+ else
+ base_src_util $1
+ fi
+}
+
+# @FUNCTION: base_src_prepare
+# @DESCRIPTION:
+# The base src_prepare function, which is exported when EAPI=2. Performs
+# "base_src_util autopatch".
+base_src_prepare() {
+
+ debug-print-function $FUNCNAME $*
+
+ base_src_util autopatch
+}
+
+# @FUNCTION: base_src_util
+# @USAGE: [ unpack ] [ patch ] [ autopatch ] [ all ]
+# @DESCRIPTION:
+# The base_src_util function is the grunt function for base src_unpack
+# and base src_prepare.
+base_src_util() {
+
+ debug-print-function $FUNCNAME $*
cd "${WORKDIR}"
while [ "$1" ]; do
@@ -57,28 +103,62 @@
done
fi
;;
all)
debug-print-section all
- base_src_unpack unpack autopatch
+ base_src_util unpack autopatch
;;
esac
shift
done
}
+# @FUNCTION: base_src_configure
+# @DESCRIPTION:
+# The base src_prepare function, which is exported when EAPI=2. Performs
+# "base_src_work configure".
+base_src_configure() {
+
+ debug-print-function $FUNCNAME $*
+
+ base_src_work configure
+}
+
# @FUNCTION: base_src_compile
# @USAGE: [ configure ] [ make ] [ all ]
# @DESCRIPTION:
# The base src_compile function, which is exported. If no argument is given,
-# "all" is asasumed.
+# "all" is assumed if EAPI!=2, "make" if EAPI=2.
base_src_compile() {
debug-print-function $FUNCNAME $*
- [ -z "$1" ] && base_src_compile all
+
+ if [ -z "$1" ]
+ then
+ case "${EAPI:-0}" in
+ 2)
+base_src_work make
+;;
+ *)
+base_src_work all
+;;
+ esac
+ else
+ base_src_work $1
+ fi
+}
+
+# @FUNCTION: base_src_work
+# @USAGE: [ configure ] [ make ] [ all ]
+# @DESCRIPTION:
+# The base_src_work function is the grunt function for base src_configure
+# and base src_compile.
+base_src_work() {
+
+ debug-print-function $FUNCNAME $*
cd "${S}"
while [ "$1" ]; do
@@ -91,11 +171,11 @@
debug-print-section make
emake || die "died running emake, $FUNCNAME:make"
;;
all)
debug-print-section all
- base_src_compile configure make
+ base_src_work configure make
;;
esac
shift
done
@@ -129,7 +209,5 @@
shift
done
}
-
-EXPORT_FUNCTIONS src_unpack src_compile src_install
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Proposed change to base.eclass: EAPI-2 support
On 20:49 Sun 02 Nov , Donnie Berkholz wrote:
> On 00:08 Mon 03 Nov , Peter Alfredsen wrote:
> > +case "${EAPI}" in
> > + 2)
> > + EXPORT_FUNCTIONS src_unpack src_prepare src_configure
> > src_compile src_install
> > + ;;
> > + *)
> > + EXPORT_FUNCTIONS src_unpack src_compile src_install
> > + ;;
> > +esac
> > +
>
> This eclass needs to do the same thing as the other eclasses that got
> EAPI=2 patches and default EAPI to 0 when it's not defined, everywhere
> where it tests the value of EAPI.
Yeah, I realize it might technically work, but it's just asking for
breakage in my opinion. Better to be explicit and have the '*' case be
for something unexpected instead of an expected case.
--
Thanks,
Donnie
Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com
pgpOp3iAdqqL7.pgp
Description: PGP signature
Re: [gentoo-dev] Proposed change to base.eclass: EAPI-2 support
On 00:08 Mon 03 Nov , Peter Alfredsen wrote:
> +case "${EAPI}" in
> + 2)
> + EXPORT_FUNCTIONS src_unpack src_prepare src_configure
> src_compile src_install
> + ;;
> + *)
> + EXPORT_FUNCTIONS src_unpack src_compile src_install
> + ;;
> +esac
> +
This eclass needs to do the same thing as the other eclasses that got
EAPI=2 patches and default EAPI to 0 when it's not defined, everywhere
where it tests the value of EAPI.
--
Thanks,
Donnie
Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com
pgpNlXoc32bCu.pgp
Description: PGP signature
Re: [gentoo-dev] Flags to punt (including: kerberos USE flag)
On Sat, Nov 1, 2008 at 1:39 PM, David Leverton <[EMAIL PROTECTED]> wrote: > On Saturday 01 November 2008 02:44:50 Josh Saddler wrote: >> emboss - Seriously. Who needs the European Biology Open Software Suite >> on a *desktop* oriented system? > > That flag is only used by a few sci-biology packages, so if you don't have any > of those installed, it doesn't matter whether the flag is on or off. IIRC > the argument for having it on was that the majority of people who /do/ use > those packages will want it. > > I suppose one could say that it should be set in IUSE or profile package.use > instead, but IMHO, if there are enough packages using it to justify making it > a global flag in the first place, and all of them need the same default, it > makes sense to set the default globally (*cough*ocamlopt*cough*). Why not use EAPI=1 for those ebuilds and turn the flag on by default? Same for the panel stuff for which +eds is good for integration? I think EAPI=1 +use should be used to de-pollute the desktop etc profiles :) IIRC, there are enough stable versions of portage with EAPI=1 support. -- ~Nirbheek Chauhan
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2008-11-02 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2008-11-02 23h59 UTC. Removals: x11-drivers/xf86-video-i810 2008-10-27 09:55:08 remi kde-base/phonon 2008-11-02 07:48:32 vapier kde-base/plasma 2008-11-02 19:16:30 jmbsvicetto kde-base/strigi-analyzer2008-11-02 19:17:20 jmbsvicetto Additions: x11-apps/fusion-icon2008-10-27 00:48:37 jmbsvicetto sys-devel/crossdev-wrappers 2008-10-27 04:20:48 solar games-arcade/tuxanci2008-10-27 07:37:04 scarabeus dev-perl/HTTP-Response-Encoding 2008-10-27 11:26:46 tove dev-lang/cilk 2008-10-27 14:41:53 bicatali sci-libs/taucs 2008-10-27 14:59:18 bicatali sci-mathematics/cgal2008-10-27 15:17:24 bicatali dev-python/cgal-python 2008-10-27 15:31:27 bicatali dev-python/natgrid 2008-10-27 15:54:28 bicatali x11-apps/simple-ccsm2008-10-27 22:39:41 jmbsvicetto net-misc/miniupnpd 2008-10-27 22:42:43 gurligebis app-portage/porticron 2008-10-28 12:17:34 hollow net-misc/throttle 2008-10-29 13:34:02 grobian app-benchmarks/gtkperf 2008-10-29 14:23:50 leio dev-util/lsuio 2008-10-29 18:10:25 vapier sci-biology/iqpnni 2008-10-30 13:43:35 weaver virtual/perl-Archive-Tar2008-11-01 18:45:57 yuval virtual/perl-Class-ISA 2008-11-01 18:45:57 yuval virtual/perl-Compress-Raw-Zlib 2008-11-01 18:45:57 yuval virtual/perl-Compress-Zlib 2008-11-01 18:45:58 yuval virtual/perl-Digest-SHA 2008-11-01 18:45:58 yuval virtual/perl-ExtUtils-CBuilder 2008-11-01 18:45:58 yuval virtual/perl-ExtUtils-ParseXS 2008-11-01 18:45:58 yuval virtual/perl-IO-Compress-Base 2008-11-01 18:45:59 yuval virtual/perl-IO-Compress-Zlib 2008-11-01 18:45:59 yuval virtual/perl-IO-Zlib2008-11-01 18:45:59 yuval virtual/perl-Locale-Maketext-Simple 2008-11-01 18:45:59 yuval virtual/perl-Math-BigInt-FastCalc 2008-11-01 18:45:59 yuval virtual/perl-Module-Build 2008-11-01 18:46:00 yuval virtual/perl-Module-Pluggable 2008-11-01 18:46:00 yuval virtual/perl-Pod-Escapes2008-11-01 18:46:00 yuval virtual/perl-Pod-Simple 2008-11-01 18:46:00 yuval virtual/perl-Term-ANSIColor 2008-11-01 18:46:00 yuval virtual/perl-Time-Piece 2008-11-01 18:46:00 yuval virtual/perl-version2008-11-01 18:46:01 yuval x11-drivers/xf86-input-tslib2008-11-01 21:30:53 solar media-libs/iulib2008-11-02 06:58:28 vapier perl-core/Archive-Tar 2008-11-02 07:15:54 tove perl-core/Class-ISA 2008-11-02 07:16:47 tove perl-core/Compress-Raw-Zlib 2008-11-02 07:17:55 tove perl-core/Compress-Zlib 2008-11-02 07:19:04 tove perl-core/Digest-SHA2008-11-02 07:19:53 tove perl-core/ExtUtils-CBuilder 2008-11-02 07:20:59 tove perl-core/ExtUtils-ParseXS 2008-11-02 07:22:04 tove perl-core/IO-Compress-Base 2008-11-02 07:23:08 tove perl-core/IO-Compress-Zlib 2008-11-02 07:24:10 tove perl-core/IO-Zlib 2008-11-02 07:25:12 tove perl-core/Locale-Maketext-Simple2008-11-02 07:25:54 tove perl-core/Math-BigInt-FastCalc 2008-11-02 07:26:34 tove perl-core/Module-Build 2008-11-02 07:27:45 tove perl-core/Module-Pluggable 2008-11-02 07:28:37 tove perl-core/Pod-Escapes 2008-11-02 07:29:36 tove perl-core/Pod-Simple2008-11-02 07:30:37 tove perl-core/Term-ANSIColor2008-11-02 07:31:24 tove perl-core/Time-Piece2008-11-02 07:32:11 tove perl-core/version 2008-11-02 07:33:21 tove sci-mathematics/qtoctave2008-11-02 16:03:51 markusle -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: x11-drivers/xf86-video-i810,removed,remi,2008-10-27 09:55:08 kde-base/phonon,removed,vapier,2008-11-02 07:48:32 kde-base/plasma,removed,jmbsvicetto,2008-11-02 19:16:30 kde-base/strigi-analyzer,removed,jmbsvicetto,2008-11-02 19:17:20 Added Packages: x11-apps/fusion-icon,added,jmbsvicetto,2008-10-27 00:48:37 sys-devel/crossdev-wrappers,added,solar,2008-10-27 04:20:48 games-arcade/tu
Re: [gentoo-dev] Proposed change to base.eclass: EAPI-2 support
On Sunday 02 November 2008, Peter Alfredsen wrote: [...] Please just imagine that this is added to the end of the patch: - -EXPORT_FUNCTIONS src_unpack src_compile src_install /me had started hacking on this in-tree, and the first change was removing that line. -- /PA signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Proposed change to base.eclass: EAPI-2 support
The attached patch for bug 238753 makes base.eclass support EAPI 2
functions. None of the previous functionality of exported functions is
changed, so you can still do base_src_unpack autopatch. It's only the
default actions of base_src_compile and base_src_unpack that's affected
and only if EAPI=2. The case..esac for EXPORT_FUNCTIONS is borrowed
from kde4-base. I've not done tree-rebuilds with this, so please give
it a thorough review. I'm not entirely happy about the base_src_work
and base_src_util function names, so suggestions are welcome.
--
/PA
--- /usr/portage/eclass/base.eclass 2008-07-17 12:06:27.0 +0200
+++ base.eclass 2008-11-02 22:52:10.0 +0100
@@ -2,32 +2,78 @@
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/base.eclass,v 1.34 2008/07/17 09:49:14 pva Exp $
# @ECLASS: base.eclass
# @MAINTAINER:
-# ???
+# Peter Alfredsen <[EMAIL PROTECTED]>
#
# Original author Dan Armak <[EMAIL PROTECTED]>
# @BLURB: The base eclass defines some default functions and variables.
# @DESCRIPTION:
# The base eclass defines some default functions and variables. Nearly
# everything else inherits from here.
+#
+# NOTE: You must define EAPI before inheriting from base, or the wrong functions
+# may be exported.
inherit eutils
+case "${EAPI}" in
+ 2)
+ EXPORT_FUNCTIONS src_unpack src_prepare src_configure src_compile src_install
+ ;;
+ *)
+ EXPORT_FUNCTIONS src_unpack src_compile src_install
+ ;;
+esac
+
DESCRIPTION="Based on the $ECLASS eclass"
# @FUNCTION: base_src_unpack
# @USAGE: [ unpack ] [ patch ] [ autopatch ] [ all ]
# @DESCRIPTION:
# The base src_unpack function, which is exported. If no argument is given,
-# "all" is assumed.
+# "all" is assumed if EAPI!=2, "unpack" if EAPI=2.
base_src_unpack() {
debug-print-function $FUNCNAME $*
- [ -z "$1" ] && base_src_unpack all
+
+ if [ -z "$1" ]
+ then
+ case "${EAPI}" in
+ 2)
+base_src_util unpack
+;;
+ *)
+base_src_util all
+;;
+ esac
+ else
+ base_src_util $1
+ fi
+}
+
+# @FUNCTION: base_src_prepare
+# @DESCRIPTION:
+# The base src_prepare function, which is exported when EAPI=2. Performs
+# "base_src_util autopatch".
+base_src_prepare() {
+
+ debug-print-function $FUNCNAME $*
+
+ base_src_util autopatch
+}
+
+# @FUNCTION: base_src_util
+# @USAGE: [ unpack ] [ patch ] [ autopatch ] [ all ]
+# @DESCRIPTION:
+# The base_src_util function is the grunt function for base src_unpack
+# and base src_prepare.
+base_src_util() {
+
+ debug-print-function $FUNCNAME $*
cd "${WORKDIR}"
while [ "$1" ]; do
@@ -57,28 +103,62 @@
done
fi
;;
all)
debug-print-section all
- base_src_unpack unpack autopatch
+ base_src_util unpack autopatch
;;
esac
shift
done
}
+# @FUNCTION: base_src_configure
+# @DESCRIPTION:
+# The base src_prepare function, which is exported when EAPI=2. Performs
+# "base_src_work configure".
+base_src_configure() {
+
+ debug-print-function $FUNCNAME $*
+
+ base_src_work configure
+}
+
# @FUNCTION: base_src_compile
# @USAGE: [ configure ] [ make ] [ all ]
# @DESCRIPTION:
# The base src_compile function, which is exported. If no argument is given,
-# "all" is asasumed.
+# "all" is assumed if EAPI!=2, "compile" if EAPI=2.
base_src_compile() {
debug-print-function $FUNCNAME $*
- [ -z "$1" ] && base_src_compile all
+
+ if [ -z "$1" ]
+ then
+ case "${EAPI}" in
+ 2)
+base_src_work make
+;;
+ *)
+base_src_work all
+;;
+ esac
+ else
+ base_src_work $1
+ fi
+}
+
+# @FUNCTION: base_src_work
+# @USAGE: [ configure ] [ make ] [ all ]
+# @DESCRIPTION:
+# The base_src_work function is the grunt function for base src_configure
+# and base src_compile.
+base_src_work() {
+
+ debug-print-function $FUNCNAME $*
cd "${S}"
while [ "$1" ]; do
@@ -91,11 +171,11 @@
debug-print-section make
emake || die "died running emake, $FUNCNAME:make"
;;
all)
debug-print-section all
- base_src_compile configure make
+ base_src_work configure make
;;
esac
shift
done
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Malformed XML - Re: [gentoo-commits] gentoo-x86 commit in app-pda/barry: ChangeLog metadata.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin H. Johnson wrote: > Unclosed tag. How did you commit this? Repoman is supposed > to catch it. If repoman only warns, can we upgrade to critical for > malformed XML? Indeed, repoman treats it as a warning. I'll go ahead and make it fatal. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkOHnEACgkQ/ejvha5XGaM87gCgh9/elieal09hgtgw3oXDSdYf OvoAn0Fn2ZZFGbwXf1A3+yGshi6FwRAj =K/lX -END PGP SIGNATURE-
[gentoo-dev] Malformed XML - Re: [gentoo-commits] gentoo-x86 commit in app-pda/barry: ChangeLog metadata.xml
On Sun, Nov 02, 2008 at 05:08:28PM +, Jorge Manuel B. S. Vicetto (jmbsvicetto) wrote: > jmbsvicetto08/11/02 17:08:28 > > Modified: ChangeLog metadata.xml > Log: > Removing jsin as a maintainer since he was retired. > (Portage version: 2.2_rc12/cvs/Linux 2.6.27-gentoo x86_64) ... > === > RCS file: /var/cvsroot/gentoo-x86/app-pda/barry/metadata.xml,v > retrieving revision 1.1 > retrieving revision 1.2 > diff -u -r1.1 -r1.2 > --- metadata.xml 15 Sep 2007 19:00:02 - 1.1 > +++ metadata.xml 2 Nov 2008 17:08:28 - 1.2 > @@ -1,14 +1,11 @@ > > http://www.gentoo.org/dtd/metadata.dtd";> > > - app-pda > - > - [EMAIL PROTECTED] > - Jason Smathers (jsin) > - > - > - Barry is an Open Source Linux application that will > - allow synchronization, backup, restore, program > - management, and charging for BlackBerry devices. > - > +app-pda > + > + > + Barry is an Open Source Linux application that will > + allow synchronization, backup, restore, program > + management, and charging for BlackBerry devices. > + > Unclosed tag. How did you commit this? Repoman is supposed to catch it. If repoman only warns, can we upgrade to critical for malformed XML? -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpx4rSgMbriY.pgp Description: PGP signature
Re: [gentoo-dev] [PMS] Add RESTRICT="distcc" capability
On Sun, 2 Nov 2008 12:11:10 -0700 Gordon Malm <[EMAIL PROTECTED]> wrote: > > Have you conclusively established that they do build fine in > > parallel? If so, how? And why do they break in parallel only under > > distcc? Given how distcc works, this strikes me as somewhat > > implausible... > > Yes it builds in parallel. By compiling it in parallel. I don't > know why and don't care to investigate for you. It's not my package, > I'm not QA and my team is short staffed enough as it is. We have to > take care of our own backyard. Maybe you could investigate the > answers to your own questions? How about you at least feign attempt > at answering my questions for a change? If you think compiling it in parallel confirms that it builds in parallel, you're reaffirming my growing suspicion that you're entirely wrong about distcc being responsible for anything other than hardened brokenness... > > RESTRICT=distcc on kernel modules is unnecessary for the large > > proportion of users who don't use hardened. RESTRICTs can't be set > > dependent upon whether or not something like hardenened is enabled; > > other mechanisms are available that can be. So why aren't you > > considering those other mechanisms? > > I agree with the first sentence, never said otherwise. Who says I am > not considering them? In fact, I have stated that I am. They are > just more hackish than adding the ability to RESTRICT distcc, hence > my reason for soliciting such a feature. I'm surprised that you'd > suggest this after debasing a RESTRICT option on the same grounds. And that brings us to the other thing you don't understand: RESTRICT is a global, system independent, invariant metadata key. Things in RESTRICT are in RESTRICT because they have to be known in situations where those constraints are in effect. Things that do not have to be known at the metadata level shouldn't be in metadata. > > A macro is just a macro. All it does is affect the preprocessor > > stage. Hardened is trying to abuse it for something else entirely, > > which is why you're encountering problems. > > You can cry "abuse" all you want. You FAIL to offer any alternatives > or solutions. I'll ask again, how do you detect that you are > compiling code destined to be run in-kernel from within gcc without > checking for the __KERNEL__ macro? I think we both know the answer. I suggest you talk to hardened upstream and see what they have to say about it. What have they offered as justification for using -D in a way in which no-one else uses it? What are their objections to switching to an approach that doesn't break the preprocessor model? > Sorry to everyone who e-mailed me who thought RESTRICT=distcc would > be somewhat useful. Those people are mistaken. > > Uh, that's your answer to technical objections to a proposal? You > > aren't prepared to defend your proposal on its merits? > > Why are you assuming this point is *at all* related to my proposal? > It's not. It's about Gentoo. But I stand corrected, a bunch of > people rushed to tell me you don't actually determine anything. ;) So you don't care about whether your solution is right? You are proposing to add a metadata invariant option for a condition that isn't metadata invariant and that, by being made metadata invariant, means it's being disabled for everyone rather than by the small number of users who might need it. In addition, you can't demonstrate any cases where this option is genuinely useful, other than as a workaround for a hardened bug that you haven't contacted upstream about, and when used to work around said hardened bug the scope of the change isn't limited to hardened. You still haven't explained why you don't do something like: broken_hardened_compiler && export DISTCC_HOSTS=localhost -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [PMS] Add RESTRICT="distcc" capability
On Sunday, November 2, 2008 03:26:14 Ciaran McCreesh wrote: > On Sat, 1 Nov 2008 18:29:03 -0700 > > Gordon Malm <[EMAIL PROTECTED]> wrote: > > You're the one assuming the only purpose would be to mask parallel > > make problems. Apparently it does have a purpose though since > > avidemux builds fine in parallel but NOT via distcc. > > Have you conclusively established that they do build fine in parallel? > If so, how? And why do they break in parallel only under distcc? Given > how distcc works, this strikes me as somewhat implausible... Yes it builds in parallel. By compiling it in parallel. I don't know why and don't care to investigate for you. It's not my package, I'm not QA and my team is short staffed enough as it is. We have to take care of our own backyard. Maybe you could investigate the answers to your own questions? How about you at least feign attempt at answering my questions for a change? > > > Back to your most recent post > > > > > *If* there's a legitimate use for RESTRICT=distcc then I am > > > entirely in favour of it. But it looks like there isn't, with every > > > issue being either a parallelism issue (which RESTRICT=distcc won't > > > fix), a user configuration issue (which RESTRICT=distcc won't fix) > > > or a hardened toolchain bug (for which RESTRICT=distcc is massive > > > overkill, and thus the wrong solution). You've decided upon a > > > solution before you've worked out what the problem is. > > > > You assumed it is a parallelism issue that people are trying to > > solve. I haven't pointed to any user configuration issues. Using > > RESTRICT=distcc on kernel modules is hardly overkill. This isn't > > openoffice. I know exactly what the problem is, but since you have > > such a better grasp on it > > RESTRICT=distcc on kernel modules is unnecessary for the large > proportion of users who don't use hardened. RESTRICTs can't be set > dependent upon whether or not something like hardenened is enabled; > other mechanisms are available that can be. So why aren't you > considering those other mechanisms? I agree with the first sentence, never said otherwise. Who says I am not considering them? In fact, I have stated that I am. They are just more hackish than adding the ability to RESTRICT distcc, hence my reason for soliciting such a feature. I'm surprised that you'd suggest this after debasing a RESTRICT option on the same grounds. > > > We have to build using different specs sets for kernel code than > > userland. If we can't depend on the __KERNEL__ macro for detection, > > how else do you propose one detect if gcc is building kernel code or > > not? > > A macro is just a macro. All it does is affect the preprocessor stage. > Hardened is trying to abuse it for something else entirely, which is why > you're encountering problems. You can cry "abuse" all you want. You FAIL to offer any alternatives or solutions. I'll ask again, how do you detect that you are compiling code destined to be run in-kernel from within gcc without checking for the __KERNEL__ macro? I think we both know the answer. We can't just hack the eclass to pass -fno-PIE because a particular package might build more than just the kernel module itself. Patching kbuild in our sources doesn't address any modules that don't use in-tree kbuild and is stupid in so many ways anyway. That leaves patching every out-of-tree module in portage manually and maintain those patches forward which would be very time/effort intensive on an ongoing basis. Go ahead and forget about it though. I'm done with this discussion. Because we rely on the __KERNEL__ macro to determine which flags to apply, it only makes sense to patch in-portage distcc in the case of hardened to pass it. And that's exactly what I'll be doing. Problem solved and I like that option better anyway. Sorry to everyone who e-mailed me who thought RESTRICT=distcc would be somewhat useful. > > > I guess the larger question in all this is why does a third party who > > has demonstrated his anti-Hardened (and anti-Gentoo) slant on > > multiple occasions define what goes in our PMS? > > Uh, that's your answer to technical objections to a proposal? You > aren't prepared to defend your proposal on its merits? Why are you assuming this point is *at all* related to my proposal? It's not. It's about Gentoo. But I stand corrected, a bunch of people rushed to tell me you don't actually determine anything. ;) Gordon Malm (gengor) P.S. I've seen enough of these threads from you to know that you can't help but respond with another post that does a lot of objecting but offers no solutions. Go ahead and post again so you can feel like you had the last word, now is your chance, I won't be posting back.
Re: [gentoo-dev] [PMS] Add RESTRICT="distcc" capability
On Sat, 1 Nov 2008 18:29:03 -0700 Gordon Malm <[EMAIL PROTECTED]> wrote: > You're the one assuming the only purpose would be to mask parallel > make problems. Apparently it does have a purpose though since > avidemux builds fine in parallel but NOT via distcc. Have you conclusively established that they do build fine in parallel? If so, how? And why do they break in parallel only under distcc? Given how distcc works, this strikes me as somewhat implausible... > Back to your most recent post > > *If* there's a legitimate use for RESTRICT=distcc then I am > > entirely in favour of it. But it looks like there isn't, with every > > issue being either a parallelism issue (which RESTRICT=distcc won't > > fix), a user configuration issue (which RESTRICT=distcc won't fix) > > or a hardened toolchain bug (for which RESTRICT=distcc is massive > > overkill, and thus the wrong solution). You've decided upon a > > solution before you've worked out what the problem is. > > You assumed it is a parallelism issue that people are trying to > solve. I haven't pointed to any user configuration issues. Using > RESTRICT=distcc on kernel modules is hardly overkill. This isn't > openoffice. I know exactly what the problem is, but since you have > such a better grasp on it RESTRICT=distcc on kernel modules is unnecessary for the large proportion of users who don't use hardened. RESTRICTs can't be set dependent upon whether or not something like hardenened is enabled; other mechanisms are available that can be. So why aren't you considering those other mechanisms? > We have to build using different specs sets for kernel code than > userland. If we can't depend on the __KERNEL__ macro for detection, > how else do you propose one detect if gcc is building kernel code or > not? A macro is just a macro. All it does is affect the preprocessor stage. Hardened is trying to abuse it for something else entirely, which is why you're encountering problems. > What makes it any better than a simple option to RESTRICT distcc? You still appear to be confusing "RESTRICT distcc" and "provide a mechanism for selectively disabling distcc". They are entirely different things. > I guess the larger question in all this is why does a third party who > has demonstrated his anti-Hardened (and anti-Gentoo) slant on > multiple occasions define what goes in our PMS? Uh, that's your answer to technical objections to a proposal? You aren't prepared to defend your proposal on its merits? -- Ciaran McCreesh signature.asc Description: PGP signature
