[gentoo-dev] Re: [PMS] Add RESTRICT=distcc capability
Ciaran McCreesh wrote: 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? Yes it builds in parallel. By compiling it in parallel. 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... Well my understanding of parallel make is that it would show some issues but not all. I'd hope you were trying to say: Build it via distcc with N virtual hosts or sth along those lines. 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. More why hasn't he proposed them already. 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. those constraint are in effect isn't a good way of explaining that imo. Things that do not have to be known at the metadata level shouldn't be in metadata. Yeah, stuff that always applies, no matter what. Sorry to everyone who e-mailed me who thought RESTRICT=distcc would be somewhat useful. Well a user could always turn off FEATURES externally, which isn't hard to automate[2]; developers are notoriously bad at defining use-cases. 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? I think those two bits go nicely together. It's not supposed to be a fight, btw. 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? *sigh* 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. I agree this case isn't the best one, nor am I in favour of this RESTRICT. I'm totally neutral on it as a solution. I can envisage wanting to restrict compilation to the local machine, but I'm not bothered about how it gets done. My instinct would be to err toward giving the control to the ebuild maintainer, with a clear QA policy, perhaps around making it something that had to be reviewed on every bump (QA script to watch ebuild as long it has the RESTRICT, unless it's proprietary.) Much as we might want perfect builds, they don't always happen, nor do we always have time to fix upstream bugs, however minor they turn out to be. You still haven't explained why you don't do something like: broken_hardened_compiler export DISTCC_HOSTS=localhost Still it would have been easier on the reader if you'd just mentioned this first. [1] http://hardened.gentooexperimental.org/trac/secure/ [2] http://forums.gentoo.org/viewtopic-t-546828.html
[gentoo-dev] Re: Proposed change to base.eclass: EAPI-2 support
Peter Alfredsen wrote:
debug-print-function $FUNCNAME $*
You should be using $@ not unquoted $*.
Seems like the FUNCNAME bit should just be rolled into the function
with ${FUNCNAME[1]} which could be done tree-wide quite easily.
Re: [gentoo-dev] [PMS] Add RESTRICT=distcc capability
В Вск, 02/11/2008 в 12:11 -0700, Gordon Malm пишет: 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. Gordon, as far as I see our linux-mod.eclass builds each kernel module separately and it is possible to modify it to pass CFLAGS you wish for kernel modules only and as such avoid using __KERNEL__ macro for this... -- Peter.
Re: [gentoo-dev] Re: Proposed change to base.eclass: EAPI-2 support
On Monday 03 November 2008, Steve Long wrote:
Peter Alfredsen wrote:
debug-print-function $FUNCNAME $*
You should be using $@ not unquoted $*.
Fixed. Also fixed base_src_unpack and base_src_compile calling their
grunt functions with $1, when clearly it should have been [EMAIL PROTECTED]
Seems like the FUNCNAME bit should just be rolled into the function
with ${FUNCNAME[1]} which could be done tree-wide quite easily.
I guess that function was written before bash-3 when FUNCNAME was turned
into an array.
--
/PA
--- /usr/portage/eclass/base.eclass 2008-07-17 12:06:27.0 +0200
+++ base.eclass 2008-11-03 20:45:44.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
+ debug-print-function $FUNCNAME $@
+
+ if [ -z $1 ]
+ then
+ case ${EAPI:-0} in
+ 2)
+base_src_util unpack
+;;
+ *)
+base_src_util all
+;;
+ esac
+ else
+ base_src_util $@
+ 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
+ debug-print-function $FUNCNAME $@
+
+ if [ -z $1 ]
+ then
+ case ${EAPI:-0} in
+ 2)
+base_src_work make
+;;
+ *)
+base_src_work all
+;;
+ esac
+ else
+ base_src_work $@
+ 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
@@ -107,11 +187,11 @@
# @DESCRIPTION:
# The base src_install function, which is exported. If no argument is given,
# all is assumed.
base_src_install() {
- debug-print-function $FUNCNAME $*
+ debug-print-function $FUNCNAME $@
[ -z $1 ] base_src_install all
cd ${S}
while [ $1 ]; do
@@ -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] Flags to punt (including: kerberos USE flag)
On Monday 03 November 2008 04:29:34 Nirbheek Chauhan wrote: Why not use EAPI=1 for those ebuilds and turn the flag on by default? Well, as I said, it seems more sensible to me to set the default once, instead of once for each ebuild. I don't particularly care, though, just making sure people know why it was there in the first place, and if they still want to change it, so be it.
[gentoo-dev] Packages up for grabs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Following this month processing of the retirement batch, the following packages have been reassigned to maintainer-needed and can take some love. You know the drill, so if you want to maintain any of them please add yourself to the metadata.xml. package former maintainer app-admin/killproc eradicator app-text/code2html leonardop dev-db/mergeant leonardop dev-python/PyQrcodecjmglov media-gfx/grender eradicator media-gfx/maya eradicator media-gfx/pixie eradicator media-libs/aaliberadicator media-libs/libexif eradicator media-libs/liboggz zaheerm net-nds/yp-toolseradicator net-nds/ypbind eradicator net-nds/ypserv eradicator x11-misc/habak lucass x11-terms/sakurajmglov x11-themes/fvwm-crystal lucass x11-wm/stumpwm jmglov - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / SPARC / KDE -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkPusoACgkQcAWygvVEyAIcqQCffNyWPnN5fHhZcJZ0nPNns0ZN GUoAniQz/OOy+eaRBaYpYPJ4wvzNCRa9 =lPCv -END PGP SIGNATURE-
Re: [gentoo-dev] Packages up for grabs
On Tue, Nov 04, 2008 at 02:00:27AM -0100, Jorge Manuel B. S. Vicetto wrote: media-libs/libexiferadicator Unless anybody else makes more serious use of it than I do, I just use it off and on. x11-wm/stumpwmjmglov Maybe. I'm seeing if the upstream author is interested in having me proxy-commit, because I know him in real life. -- Robin Hugh Johnson Gentoo Linux Developer Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpuIOJ5SZvi9.pgp Description: PGP signature
Re: [gentoo-dev] [PMS] Add RESTRICT=distcc capability
On Monday, November 3, 2008 02:22:12 Peter Volkov wrote:
В Вск, 02/11/2008 в 12:11 -0700, Gordon Malm пишет:
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.
Gordon, as far as I see our linux-mod.eclass builds each kernel module
separately and it is possible to modify it to pass CFLAGS you wish for
kernel modules only and as such avoid using __KERNEL__ macro for this...
Peter, with much respect, this doesn't really address the question. Here is
the relevant snippet of hardened's gcc specs:
%(cc1_cpu) %{profile:-p} %{!D__KERNEL__: %{!static: %{!fno-PIC: %{!fno-pic:
%{!shared: %{!nostdlib: %{!nostartfiles: %{!fno-PIE: %{!fno-pie: %{!nopie:
%{!fPIC:
%{!fpic:-fPIE}}} } } } } } } } } %{!nostdlib: %{!fno-stack-protector:
-fstack-protector %{!D_LIBC: %{!D_LIBC_REENTRANT: %{!fno-stack-protector-all:
-fstack-protector-all} } } } } }
As you can see the __KERNEL__ macro is checked to decide which gcc specs to
apply any time hardened's gcc compiles anything. Patching linux-mod.eclass
isn't going to do anything to break our reliance on the __KERNEL__ macro.
What patching linux-mod.eclass *would* allow us to do is not patch distcc to
pass -D__KERNEL__ (which I have already done in the case of USE=hardened,
so really this is solved). The limitations of the linux-mod.eclass patching
approach is that it wouldn't work for any modules that use a standalone build
system (dumb as it that might be) instead of kbuild or any module being
compiled outside of portage (kbuild or not).
The linux-mod.eclass hacking could get pretty ugly. I haven't looked deeply
into it but KBUILD_CFLAGS is not yet defined at the time emake is called that
I can tell, so I don't think it will be as simple as adding something like
KBUILD_CFLAGS=${KBUILD_CFLAGS} -fmy -fflags -fhere. If I'm wrong please
let me know, I'd be grateful. :)
There's potentially a lot of conditionals involved as well as far as what
flags to add for a diversity of ARCHes, what the available out-of-tree
modules want for themselves, etc. Overall, linux-mod.eclass could start to
look really nasty and I think it would take quite awhile (for me alone at
least) to figure out a workable solution, if even possible. When accounting
that this would only address the problem for modules using Kbuild and built
within portage - I don't think its worth it for a partial solution.
Patching KBUILD_CFLAGS in the kernel sources themselves works, but if we don't
do that for every kernel portage we restrict users to using hardened-sources
when running a hardened toolchain w/o the hardened kernel is a perfectly
valid configuration. They wouldn't be able to use a non-gentoo provided
kernel without patching it as well. Plus, we're just *not* going to have
every kernel in the tree have a patch conditional on USE=hardened (ick :).
Best regards,
Gordon Malm (gengor)
[gentoo-dev] www.gentoo.org minor downtime due to migration
Just a heads up for everybody. You might see some minor blips in www.gentoo.org service tonight, while I'm switching it to other hosting so that I can do heavy maintenance on the existing www boxes. -- Robin Hugh Johnson Gentoo Linux Developer Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpN2DYg6cY6t.pgp Description: PGP signature
