[gentoo-dev] Why arch-specific make.conf files?
Hi, Was just about to finally commit the elog related config stuff into make.conf just to notice (again) that there are 14 (in words: fourteen) different make.conf files there, with almost all of them just differing in CFLAGS and CHOST (only exception is make.conf.mac which isn't used anymore in any way AFAICT). From my POV those vars should be set in the profiles instead, and a quick scan shows that indeed most (maybe all? didn't count them) profiles set them already, so there isn't really a point in having them in make.conf too, except to make it easy for users to change them. For CHOST this seems to be a bad idea, not sure about CFLAGS. So what's the general opinion about this? Having all these different files makes it harder to add config changes, not by much but noticably, so personally I'd like to get rid of them, but if there is a good reason for them to stay I can live with that. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] Why arch-specific make.conf files?
On Tuesday 15 November 2005 20:19, Marius Mauch wrote: From my POV those vars should be set in the profiles instead, and a quick scan shows that indeed most (maybe all? didn't count them) profiles set them already, so there isn't really a point in having them in make.conf too, except to make it easy for users to change them Little note: with Gentoo/FreeBSD I tried avoiding providing CHOST in make.conf, as to change to non-i686 CHOST you need to rebuild everything, as the stage is currently i686-centric, I'm sorry of that, I'll try to automatize a more complete building when I'll have time. The problem of this is that distcc-config looks inside make.conf for CHOST instead of using portageq envvar CHOST, so it just breaks :P I think other things might do the same assumption of finding CHOST in make.conf, and beside being plainly wrong, I'm not sure if I want to break everything ;) -- Diego Flameeyes Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpOgH3adXZH5.pgp Description: PGP signature
Re: [gentoo-dev] Why arch-specific make.conf files?
On Tue, 2005-11-15 at 20:19 +0100, Marius Mauch wrote: Hi, Was just about to finally commit the elog related config stuff into make.conf just to notice (again) that there are 14 (in words: fourteen) different make.conf files there, with almost all of them just differing in CFLAGS and CHOST (only exception is make.conf.mac which isn't used anymore in any way AFAICT). Where are these files that you're even talking about? From my POV those vars should be set in the profiles instead, and a quick scan shows that indeed most (maybe all? didn't count them) profiles set them already, so there isn't really a point in having them in make.conf too, except to make it easy for users to change them. For CHOST this seems to be a bad idea, not sure about CFLAGS. Well, the stages have a make.conf that is catalyst generated. So what's the general opinion about this? Having all these different files makes it harder to add config changes, not by much but noticably, so personally I'd like to get rid of them, but if there is a good reason for them to stay I can live with that. Without knowing which files these are, I cannot comment further. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Why arch-specific make.conf files?
On Tue, 2005-11-15 at 20:26 +0100, Diego 'Flameeyes' Pettenò wrote: On Tuesday 15 November 2005 20:19, Marius Mauch wrote: From my POV those vars should be set in the profiles instead, and a quick scan shows that indeed most (maybe all? didn't count them) profiles set them already, so there isn't really a point in having them in make.conf too, except to make it easy for users to change them Little note: with Gentoo/FreeBSD I tried avoiding providing CHOST in make.conf, as to change to non-i686 CHOST you need to rebuild everything, as the stage is currently i686-centric, I'm sorry of that, I'll try to automatize a more complete building when I'll have time. The problem of this is that distcc-config looks inside make.conf for CHOST instead of using portageq envvar CHOST, so it just breaks :P I think other things might do the same assumption of finding CHOST in make.conf, and beside being plainly wrong, I'm not sure if I want to break everything ;) CHOST doesn't have to match what is in the profile. In fact, I can think of a lot of cases where it does not. While I agree that it shouldn't be required to have CHOST in make.conf, it *is* currently a requirement, and has been for as long as I can remember. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Why arch-specific make.conf files?
On Tue, Nov 15, 2005 at 02:52:28PM -0500, Chris Gianelloni wrote: On Tue, 2005-11-15 at 20:19 +0100, Marius Mauch wrote: Was just about to finally commit the elog related config stuff into make.conf just to notice (again) that there are 14 (in words: fourteen) different make.conf files there, with almost all of them just differing in CFLAGS and CHOST (only exception is make.conf.mac which isn't used anymore in any way AFAICT). Where are these files that you're even talking about? before catalyst started nuking make.conf, they were the standard /etc/make.conf files ... now though, you can find them at /etc/make.conf.example -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Why arch-specific make.conf files?
On Tue, 2005-11-15 at 20:01 +, Mike Frysinger wrote: On Tue, Nov 15, 2005 at 02:52:28PM -0500, Chris Gianelloni wrote: On Tue, 2005-11-15 at 20:19 +0100, Marius Mauch wrote: Was just about to finally commit the elog related config stuff into make.conf just to notice (again) that there are 14 (in words: fourteen) different make.conf files there, with almost all of them just differing in CFLAGS and CHOST (only exception is make.conf.mac which isn't used anymore in any way AFAICT). Where are these files that you're even talking about? before catalyst started nuking make.conf, they were the standard /etc/make.conf files ... now though, you can find them at /etc/make.conf.example Ahh... and there's different ones installed based on some criteria, rather than a single example? Now it makes sense. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Why arch-specific make.conf files?
On Tue, Nov 15, 2005 at 04:01:07PM -0500, Chris Gianelloni wrote: On Tue, 2005-11-15 at 20:01 +, Mike Frysinger wrote: On Tue, Nov 15, 2005 at 02:52:28PM -0500, Chris Gianelloni wrote: On Tue, 2005-11-15 at 20:19 +0100, Marius Mauch wrote: Was just about to finally commit the elog related config stuff into make.conf just to notice (again) that there are 14 (in words: fourteen) different make.conf files there, with almost all of them just differing in CFLAGS and CHOST (only exception is make.conf.mac which isn't used anymore in any way AFAICT). Where are these files that you're even talking about? before catalyst started nuking make.conf, they were the standard /etc/make.conf files ... now though, you can find them at /etc/make.conf.example Ahh... and there's different ones installed based on some criteria, rather than a single example? Now it makes sense. congrats, the last horse just came in -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Why arch-specific make.conf files?
On Tue, 15 Nov 2005 14:54:01 -0500 Chris Gianelloni [EMAIL PROTECTED] wrote: On Tue, 2005-11-15 at 20:26 +0100, Diego 'Flameeyes' Pettenò wrote: On Tuesday 15 November 2005 20:19, Marius Mauch wrote: From my POV those vars should be set in the profiles instead, and a quick scan shows that indeed most (maybe all? didn't count them) profiles set them already, so there isn't really a point in having them in make.conf too, except to make it easy for users to change them Little note: with Gentoo/FreeBSD I tried avoiding providing CHOST in make.conf, as to change to non-i686 CHOST you need to rebuild everything, as the stage is currently i686-centric, I'm sorry of that, I'll try to automatize a more complete building when I'll have time. The problem of this is that distcc-config looks inside make.conf for CHOST instead of using portageq envvar CHOST, so it just breaks :P I think other things might do the same assumption of finding CHOST in make.conf, and beside being plainly wrong, I'm not sure if I want to break everything ;) CHOST doesn't have to match what is in the profile. In fact, I can think of a lot of cases where it does not. While I agree that it shouldn't be required to have CHOST in make.conf, it *is* currently a requirement, and has been for as long as I can remember. The portageq way would scan all make.* files, so you *could* still set CHOST in make.conf if you want to. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] Why arch-specific make.conf files?
On Tue, 15 Nov 2005 14:52:28 -0500 Chris Gianelloni [EMAIL PROTECTED] wrote: On Tue, 2005-11-15 at 20:19 +0100, Marius Mauch wrote: Hi, Was just about to finally commit the elog related config stuff into make.conf just to notice (again) that there are 14 (in words: fourteen) different make.conf files there, with almost all of them just differing in CFLAGS and CHOST (only exception is make.conf.mac which isn't used anymore in any way AFAICT). Where are these files that you're even talking about? http://viewcvstest.gentoo.org/viewcvs.py/portage/main/trunk/cnf/ Installed as make.conf.example by portage. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
[gentoo-portage-dev] PATCH: parallel-fetch
Yo. Continuing the pillaging of ebd, attached is an integration of parallel-fetch. The modification is pretty straight forward offhand; the notable difference this time around is rather then extending portage_exec to have the capability to 'spawn' python funcs (something I always found ugly), this handles the fork itself. Debatable on that one, so feedback welcome. ~harring Index: bin/emerge === --- bin/emerge (revision 2309) +++ bin/emerge (working copy) @@ -1821,6 +1824,42 @@ self.pkgsettings[FEATURES]=string.join(myfeat) + if parallel-fetch in myfeat and not (--ask in myopts or --pretend in myopts or --fetchonly in myopts): + if distlocks not in myfeat: + print red(!!!) + print red(!!!)+ parallel-fetching requires the distlocks feature enabled + print red(!!!)+ you have it disabled, thus parallel-fetching is being disabled + print red(!!!) + elif len(mymergelist) 1: + print parallel-fetching is in the hizzay + pid = os.fork() + if not pid: + sys.stdin.close() + sys.stdout.close() + sys.stderr.close() + sys.stdout = open(/dev/null,w) + sys.stderr = open(/dev/null,w) + os.dup2(sys.stdout.fileno(), 1) + os.dup2(sys.stdout.fileno(), 2) + for x in (autoaddcvs, cvs): + try:myfeat.remove(x) + except ValueError: pass + self.pkgsettings[FEATURES] = .join(myfeat) + print child + ret = 0 + for x in mymergelist: + if x[0] != ebuild: + continue + try: + ret = portage.doebuild(portage.portdb.findname(x[2]), fetch, x[1], self.pkgsettings, + cleanup=0, fetchonly=True, tree=porttree) + except SystemExit: + raise + except Exception: + ret = 1 + sys.exit(0) + portage.portage_exec.spawned_pids.append(pid) + mergecount=0 for x in mymergelist: mergecount+=1 pgp7U7HSghoAe.pgp Description: PGP signature
Re: [gentoo-portage-dev] going to need a 2.0.53-rc8
On Mon, 14 Nov 2005 09:42:56 -0600 Brian Harring [EMAIL PROTECTED] wrote: On Mon, Nov 14, 2005 at 04:32:35PM +0100, Marius Mauch wrote: On Monday 14 November 2005 00:46, Jason Stubbs wrote: Replace 2.1.0 with 2.2.0 and I'll agree. Skipping 2.1 accomplishes what? Avoid any possible confusion about what 2.1 is. People asking, whoah there, it's a later version then 2.1, where's the 2.1 functionality? will still occur. I don't think so. *cough* this is why alpha/feature releases should be date tagged against the branch point instead of the potential version. :) sorry, I don't understand this sentence. How would you have named the alpha snapshot? Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
[gentoo-portage-dev] Savior Plugins Backport
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This patch should cover the backport of 3.0's plugin framework. Mostly needed to backport a few utils, which were stuck in portage_util.py. A few extra files ( portage_plugins and portage_modules ) were taken wholesale. Also a small addition to portage_data and portage_const was needed. After applying the patch, register_plugins.py needs an execute bit to run ;) Please test these as well. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQ3q8DWzglR5RwbyYAQK1Hw/+Lod7ufd+TdSvTlFz2ehhUEewfW3uvJ11 5MVFS0scOfgmKpZOlCd8UzkJS6/Stiuyr3dC+EEw1YnGDbr2Luvv2y7l1JUVrm0M ogBBDb0MtFvurDg/S0fAAS91L3U5xHyC3R52MslTzwhsasjXq7oHWSxZVgN+nAvW zmOGHj5+GMtDTvd34RgdXZbM7Ja6slvBZwYYYLWKcqC3pTKpIMIUUNZ7OUuol1Wa 6RCpHklvVMUA4ooGJHJkM/E9BvMLp0p1VufHyznoX1bo2yvQSR6lEYeSlnFIEm/X ZirjieZPSbSxDZsz6SwJLa/YOOXou0lYZAn4ZRjTJ2HwrUewUdxirGKbyFriNGXe VF1ZKvTIBNvu17CmwxGDi2esdllW3pha4ioStIYfrvp9ZR5R74R6tUSNPSIIV0CZ XxleA4RRjAo5OyXHfoOr9N2dlEHVQ3F+BOWZwAlAkd3R3EdVcFhIeCTv8Wi6xuhp sl5++d+Cj8YnX/bqZlHbWm8loSjZ2gJlXvBcdjGTsvwXQbZw48l31B++HqTUIfTP NpZvS35QGvB0hVvTiHE7BkcRaZum/gFnSEnqUC6qMUWfffAJROmlaiUrvmjiT0Yc IUDloJzmwUeUGm2w0JwQ8RqezMSe4jFEq3k7LNw4vDoE43UDdrdniD84tY/zCWPg 04Ssv5ecSbU= =vXbb -END PGP SIGNATURE- diff -Nru --exclude portage-plugins-backport.patch --exclude '*.pyc' --exclude '*.pyo' /usr/lib/portage/bin/register_plugin.py ./bin/register_plugin.py --- /usr/lib/portage/bin/register_plugin.py 1969-12-31 19:00:00.0 -0500 +++ ./bin/register_plugin.py2005-11-15 23:13:04.961017280 -0500 @@ -0,0 +1,81 @@ +#!/usr/bin/python +# Copyright: 2005 Gentoo Foundation +# Author(s): Brian Harring ([EMAIL PROTECTED]) +# License: GPL2 +# $Id:$ + +import portage_plugins +from portage_modules import load_attribute +import sys + +def set(ptype, magic, version, namespace): + load_attribute(namespace) + # loaded. + portage.plugins.register(ptype, magic, version, namespace, replace=True) + +def cleanse(ptype, magic, version): + portage.plugins.deregister(ptype, magic, version) + +def get_list(ptype=None): + return portage.plugins.query_plugins(ptype) + +if __name__ == __main__: + args = sys.argv[1:] + ret = 0 + if -l in args: + args.pop(args.index(-l)) + if len(args) == 0: + args = [None] + for x in args: + print querying %s % str(x) + try: + i = get_list(x).items() + if x is not None: + i = [(x, dict(i))] + for k,v in i: + print + try: + l = max(map(lambda y: len(y), v.keys())) + 4 + print %s = % k + for y in v.keys(): + print %s:%s, %s % (y.rjust(l), v[y][namespace], v[y][version]) + except ValueError: + print %s = no plugins found % k + print + except Exception, e: + print caught exception %s querying % e + ret = 1 + elif -s in args: + args.pop(args.index(-s)) + if len(args) != 4: + print need 4 args- ptype magic version namespace + sys.exit(1) + print registering namespace(%s) as type(%s) constant(%s), ver(%s) % (args[3], args[0], args[1], args[2]) + set(*args) + elif -r in args: + args.pop(args.index(-r)) + if len(args) != 3: + print need 3 args- ptype magic version + sys.exit(1) + print deregistering type(%s) constant(%s) ver(%s) % (args[0], args[1], args[2]) + cleanse(*args) + elif -p in args: + args.pop(args.index(-p)) + if len(args) != 0: + print no args allowed currently + sys.exit(1) + for ptype, v in get_list(None).iteritems(): + for magic, vals in v.iteritems(): + print %s -s %s %s %s %s % (sys.argv[0], ptype, magic, vals[version], vals[namespace]) + else: + if --help not in args: + print command required + print + print options available: -s, -r, -l + print -s ptype magic ver namespace + print -r ptype magic ver + print -l [ptype] + print + if
[gentoo-portage-dev] Plugin backport PATCH (1/2)/(2/2)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian asked me to split this up, and the first patch had some
cruft...and I broke things, both from old messing around. So I started
with a clean installed of rc7, hopefully these are a bit better.
One patch is for the backend stuff, portage_modules, portage_plugins,
portage_file additions, portage_lock additions, portage_const additions
and portage_data additions.
The second patch is the addition of register_plugin.py.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQIVAwUBQ3rcxWzglR5RwbyYAQIZMRAAjOwrr3oRl2JPwTKOd6bYySmlPlaIjY9P
fnKSVX0sndQYvlybKqbXlPqCsBz4ZiNdnuqKBNAQMPcP0MtViy0/CsXn6FzUt2n8
zih8wtQ78/JrcWbMfmCIKakok0LT1+htsnBdb4SY5sKZF5unlGJsoFENxre88lBY
mblJ3qAF5fU8QuMYQFPv3HkcHxZ+ncLUODGmFnxcM9miAa324URvAN5l+96cFW6I
e8FXMCvIgkqmtLfGPQvJcBhwQa3DovO7WsW+ya2UvMC3+mC0V5XbMqWmzOuvBgw7
C1SBJRmIYfxwnItDK0wq9ai2VFSPcZNVBoF3hYO7MY4LrN0UPwP13PazkdP8DhUi
0jub4aWHyHvvS3uNPW5XfdYDdFb/vdDLyyidpmlJHNpTbMVJCU5jFMUHxzVqKsFJ
RiNEu79l2F379pBGT8vli6uwyGwC2giyu9OPqPXC5n6qrF4MFAsgZdDG+FmNovrp
3zs/dH/4gLLB23Rg+Mprn/d7QR/VvVgT9EaS25RebDhxqJFRrIuzj12VLTEDymKs
h3FbWwzJJpZh6jjjatuIaZl+1Nz7rNEpO6k1GjieBEl5HrZE2NJxG0sz9fWeyTdy
XzJdkzjvzLCP/js+/loGl8cUYNAzxIsXvW/XayuwSCROjskbmvH5XVDOHXXDLGGH
B1hxUM7Jg+w=
=p6CR
-END PGP SIGNATURE-
diff -Nru --exclude '*.patch' --exclude '*.pyc' --exclude '*.pyo'
/usr/lib/portage/pym/portage_const.py ./pym/portage_const.py
--- /usr/lib/portage/pym/portage_const.py 2005-11-15 23:42:27.0
-0500
+++ ./pym/portage_const.py 2005-11-16 01:56:54.353722456 -0500
@@ -44,6 +44,7 @@
STICKIES=[KEYWORDS_ACCEPT,USE,CFLAGS,CXXFLAGS,MAKEOPTS,EXTRA_ECONF,EXTRA_EINSTALL,EXTRA_EMAKE]
EAPI = 0
+PLUGINS_DIR= /var/lib/portage/plugins
# ===
# END OF CONSTANTS -- END OF CONSTANTS -- END OF CONSTANTS -- END OF CONSTANT
diff -Nru --exclude '*.patch' --exclude '*.pyc' --exclude '*.pyo'
/usr/lib/portage/pym/portage_data.py ./pym/portage_data.py
--- /usr/lib/portage/pym/portage_data.py2005-11-15 23:42:27.0
-0500
+++ ./pym/portage_data.py 2005-11-16 01:57:03.153384704 -0500
@@ -43,6 +43,7 @@
uid=os.getuid()
wheelgid=0
+root_uid=0
if uid==0:
secpass=2
diff -Nru --exclude '*.patch' --exclude '*.pyc' --exclude '*.pyo'
/usr/lib/portage/pym/portage_file.py ./pym/portage_file.py
--- /usr/lib/portage/pym/portage_file.py2005-11-15 23:42:27.0
-0500
+++ ./pym/portage_file.py 2005-11-16 01:56:19.157073160 -0500
@@ -8,6 +8,7 @@
import portage_data
import portage_exception
from portage_localization import _
+import stat
def normpath(mypath):
newpath = os.path.normpath(mypath)
@@ -48,15 +49,78 @@
os.umask(old_umask)
raise
portage_util.writemsg(_(Failed to chown:
%(path)s to %(uid)s:%(gid)s\n) % {path:mypath,uid:uid,gid:gid})
-
os.umask(old_umask)
-
-
-
-
-
-
-
-
-
-
+
+def ensure_dirs(path, gid=-1, uid=-1, mode=0777, minimal=False):
+ ensure dirs exist, creating as needed with (optional) gid, uid, and
mode
+ be forewarned- if mode is specified to a mode that blocks the euid from
accessing the dir, this
+ code *will* try to create the dir
+
+ try:
+ st = os.stat(path)
+ except OSError:
+ base = os.path.sep
+ try:
+ um = os.umask(0)
+ # if the dir perms would lack +wx, we have to force it
+ force_temp_perms = ((mode 0300) != 0300)
+ resets = []
+ apath = normpath(os.path.abspath(path))
+ sticky_parent = False
+ creating = False
+
+ for dir in apath.split(os.path.sep):
+ base = os.path.join(base,dir)
+ try:
+ st = os.stat(base)
+ # something exists. why are we doing
isdir?
+ if not stat.S_ISDIR(st.st_mode):
+ return False
+
+ # if it's a subdir, we need +wx at least
+ if apath != base:
+ if ((st.st_mode 0300) !=
0300):
+ try:
os.chmod(base, (st.st_mode | 0300))
+ except OSError: return
False
+
