Re: [gentoo-dev] [rfc] repo_name/layman-global.txt overlay name mismatches
Fabian Groffen wrote: So alternative, what if we extend the layman-global.txt (which is xml in reality...) file with an extra property per overlay which holds the contents of it's repo_name? Good idea. I'll try to create a map for all overlays in layman-global.txt as a next step. Layman and shell tools should help with that. Sebastian
Re: [gentoo-dev] [rfc] repo_name/layman-global.txt overlay name mismatches
Sebastian Pipping wrote: I'll try to create a map for all overlays in layman-global.txt as a next step. Layman and shell tools should help with that. Believe it or not: discs space issues disallow me to have an answer already. The code is there, I just cannot checkout all overlays at the same time :-( Maybe anybody else could run below commands before I find time to fix the disc space thing. High level view: - Checkout the mismatch detector script - Backup the set of names of your current overlays - Add all overlays - Run the script - Remove all overlays - Restore the set of original overlays Low level view: # git clone git://git.goodpoint.de/smolt-gentoo.git # cd smolt-gentoo # git checkout -b gentoo origin/gentoo # cd client/distros/gentoo # layman -l my_active_overlays.txt # sudo layman -f # sudo layman -a ALL # python _mismatch.py | tee repo_name_analysis.txt # sudo layman -d ALL # sed 's|^[^ ]* \([^ ]\+\).*$|\1|' my_active_overlays.txt | \ xargs -n 1 sudo layman -a The output produces line like MISMATCH gentoo-china (layman-global) versus china (repo_name) Please share the resulting repo_name_analysis.txt with us. I guess it all sounds a bit odd, but maybe it's fun to you and we have an answer faster. I have 17 mismatches here already. Sebastian
Re: [gentoo-dev] Please unmask app-emulation/emul-linux-x86-*-20081109
El dom, 05-07-2009 a las 14:14 +0200, Pacho Ramos escribió: I sent months ago: http://bugs.gentoo.org/show_bug.cgi?id=254577 but I didn't get any reply yet. emul packages seem to be a bit unmaintained, also, there are no updates since months, guide for making emul packages is outdated (http://www.gentoo.org/proj/en/base/amd64/emul/index.xml ) and I have no idea about what amd64 plans to do on this area. But, at least, 20081109 emul packages fixes some important bugs that are currently affecting to people using stable. Can anybody take a look on it? Thanks a lot Sorry for getting this up again but current stable emul packages have some problems (fixed in 20081109) and I haven't get any reply. I also tried to contact in the past with kingtaco and amd64 team without success (as the few people that replied from amd64 team weren't familiarized with emul packages) Regards
Re: [gentoo-dev] [rfc] repo_name/layman-global.txt overlay name mismatches
On Sunday 12 July 2009, Fabian Groffen wrote: since I assume you can't reliably use the checked out version of the overlay (by e.g. layman), can you try to retrieve the repo_name file from the overlay? Probably a lot of efforts. So alternative, what if we extend the layman-global.txt (which is xml in reality...) file with an extra property per overlay which holds the contents of it's repo_name? Would be optimal, since you're fetching this file anyway to check it. Alternative is to use another file somewhere on the interweb that you keep up to date automatically, by having all overlays checked out and recording their repo_name ... I think it should be a requirement that repo_name == layman name for an overlay to be added to layman. If that file changes later, we should see a warning *somewhere*. It is a perfect opportunity to revisit the overlays+metadata cache idea presented by patrick a while ago (and do other overdue changes!). Since writing down stuff into an IDEAS file in my $HOME does not get anything implemented, and I'm still looking for a way to have a wiki-like lightweight GLEP (which I prefer for collecting ideas), here's what I have so far: Background: Overlays are useful, fast-moving playground for inclusion of new ebuilds and distributed community effort. layman-global.txt is the central list of overlays Issues: 1. In layman-global.txt: 1. has no DTD/xml validation schema 2. overlays have only a contact address, no real name 3. overlay name in xml file might not be overlay's repo_name 4. Exactly one overlay URL, no mirrors possible 2. overlays.g.o website: 1. Feed is out of date 2. Only lists dev and proj overlays, not third-party 3. Has no overlay content index 4. Has no overlay search 3. Overlays do not have metadata 4. Overlays are not natively supported by package manager, but through an external app and a 'source' in make.conf Ideas: 1. Revamp layman-global.txt, keep it as authority file: 1. Move file to overlays.xml (but keep a compatibility copy) 2. Create XML DTD/schema to make it validatable 3. Change 'official' attribute to differentiate between 'dev', 'proj' and '3rdparty/unofficial' 4. Add value for overlay RSS feed if available 5. Add real name for owner 6. Have multiple overlay URIs with checkout priorities 2. Write script to generate planet config from overlays.xml 3. Have copies of the overlays on official gentoo.org infra, generate metadata for them and export them via rsync (the bonsaikitten proposal at http://thread.gmane.org/gmane.linux.gentoo.devel/62025/ ) 4. Validate repo_name vs. XML file (needs 3.) 5. Move search and browse features to overlays.g.o website, see: 1. http://git.exherbo.org/summer/ 2. http://gpo.zugaina.org/ 3. http://gentoo-overlays.zugaina.org/ 6. Extend layman to use one of many overlay URIs or allow user select Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Wanted: Stats collection (not submission!) testimonials
On Sunday 12 July 2009, Tobias Klausmann wrote: Interestingly, my cross-compile alpha setup (created using crossdev) is noticed as a secret package - I presume that is on purpose? That's an interesting phenomenon that pops up with both g-cpan and crossdev, because they generate new ebuilds. I don't know how crossdev works in detail, but g-cpan will create ebuilds in the first overlay in PORTAGE_OVERLAYS -- if that is a public overlay, the stats client will report them. If it has a private or no repo_name, the stats client will not do that. I would assume crossdev generared the ebuilds in a private overlay? Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [rfc] repo_name/layman-global.txt overlay name mismatches
Robert Buchholz wrote: 1. has no DTD/xml validation schema I'd like to be part of the schema creation process but feel that having pre-mature schema's on the list and it's archives is not a good idea. If we had a schema file: where would we store it? Sebastian
Re: [gentoo-dev] Wanted: Stats collection (not submission!) testimonials
Hi! On Sun, 12 Jul 2009, Robert Buchholz wrote: On Sunday 12 July 2009, Tobias Klausmann wrote: Interestingly, my cross-compile alpha setup (created using crossdev) is noticed as a secret package - I presume that is on purpose? That's an interesting phenomenon that pops up with both g-cpan and crossdev, because they generate new ebuilds. I don't know how crossdev works in detail, but g-cpan will create ebuilds in the first overlay in PORTAGE_OVERLAYS -- if that is a public overlay, the stats client will report them. If it has a private or no repo_name, the stats client will not do that. I would assume crossdev generared the ebuilds in a private overlay? Crossdev creates ebuilds on the fly, too, in this vein for a cross-compiler with target alpha: cross-alpha-unknown-linux-gnu/binutils cross-alpha-unknown-linux-gnu/gcc cross-alpha-unknown-linux-gnu/glibc cross-alpha-unknown-linux-gnu/insight cross-alpha-unknown-linux-gnu/linux-headers It also adds to package.keywords/.mask/.unmask to give you exactly the version you want. The ebuilds end up in /usr/local/portage/ for me, but that might be configurable. Regards, Tobias -- printk (KERN_DEBUG Somebody wants the port\n); linux-2.6.6/drivers/parport/parport_pc.c
Re: [gentoo-dev] Wanted: Stats collection (not submission!) testimonials
Tobias, thanks for taking the time to test my code! Tobias Klausmann wrote: /home/klausman/tmp/smolt-gentoo/client/distros/gentoo/globaluseflags.py:22: DeprecationWarning: the sets module is deprecated I'm looking for advice how to best handle this. @all If you read this and know how please contact me! Sebastian
Re: [gentoo-dev] Wanted: Stats collection (not submission!) testimonials
On Sun, 12 Jul 2009 04:30:49 +0200 Sebastian Pipping webmas...@hartwork.org wrote: Hello! As the collection part of my bring stats to Gentoo project is complete by now, it's a good point in time to do a bit more testing. If you can contribute a few minutes to it that would rock, please read on. The idea is that you as a human (not machine) with a system different from mine can find stuff that needs better (or different) handling quite well. The task is: Let the current collector script run on your machine, have a critical look at it's (hopefully self-explaining) output, and report back what you found. Here are precise commands you need to run: # git clone git://git.goodpoint.de/smolt-gentoo.git # cd smolt-gentoo # git checkout -b gentoo origin/gentoo # cd client/distros # python gentoo.py | less Again, no data is submitted, just locally collected and presented. Please send your feedback to the list; collected data better goes to sebast...@pipping.org if you are willing to share it. Thanks in advance for your help! Great project, I just had seen two issues: 1. Local overlays are not taken into account, the output is like follows: Active overlays: Names: [] Paths: [] Total: 1 Known: 0 Secret: 1 2. Package mask shows no output (assuming you are taking it from /etc/portage/package.keywords) package.mask: Total: 0 Known: 0 Secret: 0 Regards, Víctor
Re: [gentoo-dev] Wanted: Stats collection (not submission!) testimonials
Hi! On Sun, 12 Jul 2009, Sebastian Pipping wrote: Tobias Klausmann wrote: /home/klausman/tmp/smolt-gentoo/client/distros/gentoo/globaluseflags.py:22: DeprecationWarning: the sets module is deprecated I'm looking for advice how to best handle this. @all If you read this and know how please contact me! You could make that import conditional on sys.version_info. I.e. only import it if you need it (neither Python 2.5.4 nor later versions need that import to make sets work, the specifics are documented on python.org). Regards HTH, Tobias -- printk (KERN_DEBUG Somebody wants the port\n); linux-2.6.6/drivers/parport/parport_pc.c
Re: [gentoo-dev] [rfc] repo_name/layman-global.txt overlay name mismatches
On Sunday 12 July 2009, Sebastian Pipping wrote: Robert Buchholz wrote: 1. has no DTD/xml validation schema I'd like to be part of the schema creation process but feel that having pre-mature schema's on the list and it's archives is not a good idea. It's probably wise not to discuss the specifics of that file on this list, but keep experimentation in a smaller group. I wonder if a new mailing list is needed or whether we just do this over the overlays alias. If we had a schema file: where would we store it? Possibly here: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/dtd/ Robert signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Please stop requesting keywords for arches you don't have
Hi guys, Since there is always new people joining Gentoo, many of these people tend to open keyword requests for a lot of arches on a package they maintain or they are interested in until me or any other member of alternative arches scream to them :) . As a member of many of the alternative arches(alpha/arm/ia64/s390/sh/sparc) and considering the members of the other arches(hppa, mips, ppc*) also concur with me, i'd like to remind that opening such bugs is not fun for us. Why? Simple, we're mainly undermanned arches, some of them are slow, some of them have more basic problems(latest glibc breaks system and stuff), we have a small userbase compared with amd64/x86, and we(i'm talking about my arches now) prefer to keyword something if an user of our arch has tested it(which saves us some work) and it's going to be useful for him or for new users of that arch(for example the ARM architecture). If we keyword your package and maybe later stabilize it, you're going to be mad at us when you request a new version marked stable, or when you need rekeywording, because we'll be slow in doing so. Just file bugs when a package is going to be a dependency of a package we already have keyworded. Also, *STOP* dropping keywords when a new dependency isn't keyworded without filing a bug for that architecture. Thank you
Re: [gentoo-dev] Wanted: Stats collection (not submission!) testimonials
Victor, thanks for participating! Victor Ostorga wrote: 1. Local overlays are not taken into account, the output is like follows: Active overlays: Names: [] Paths: [] Total: 1 Known: 0 Secret: 1 Does it have a profiles/repo_name file? Can you share the output of # emerge --info --verbose | grep OVERLAY ? 2. Package mask shows no output (assuming you are taking it from /etc/portage/package.keywords) package.mask: Total: 0 Known: 0 Secret: 0 It's from /etc/portage/package.mask . Is that non-empty for you? Sebastian
Re: [gentoo-dev] Wanted: Stats collection (not submission!) testimonials
On Sun, 12 Jul 2009 18:25:05 +0200 Sebastian Pipping webmas...@hartwork.org wrote: Victor, thanks for participating! Victor Ostorga wrote: 1. Local overlays are not taken into account, the output is like follows: Active overlays: Names: [] Paths: [] Total: 1 Known: 0 Secret: 1 Does it have a profiles/repo_name file? Can you share the output of # emerge --info --verbose | grep OVERLAY $ emerge --info --verbose | grep OVERLAY PORTDIR_OVERLAY=/usr/local/portage It is a local overlay which I use to do some tests. 2. Package mask shows no output (assuming you are taking it from /etc/portage/package.keywords) package.mask: Total: 0 Known: 0 Secret: 0 It's from /etc/portage/package.mask . Is that non-empty for you? you are right, I dont have that file Víctor.
Re: [gentoo-dev] Wanted: Stats collection (not submission!) testimonials
Victor Ostorga wrote: 1. Local overlays are not taken into account, the output is like $ emerge --info --verbose | grep OVERLAY PORTDIR_OVERLAY=/usr/local/portage It is a local overlay which I use to do some tests. That overlay is ignored to protect your privacy. A good way to include it in the collection process would be: - Find a good name for it - echo that name to profiles/repo_name - Publish the repo somewhere on the web, say using Git and Github.com - Send a mail to rbu requesting addition to layman-global.txt How about that? Sebastian
Re: [gentoo-dev] Please stop requesting keywords for arches you don't have
Raúl Porcel wrote: Hi guys, Since there is always new people joining Gentoo, many of these people tend to open keyword requests for a lot of arches on a package they maintain or they are interested in until me or any other member of alternative arches scream to them :) . Seems like you should come up with a new quiz question. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Please stop requesting keywords for arches you don't have
On Sun, Jul 12, 2009 at 9:36 PM, Raúl Porcelarmi...@gentoo.org wrote: Also, *STOP* dropping keywords when a new dependency isn't keyworded without filing a bug for that architecture. Towards reducing arch load, I say that new packages should not be added to ~arch if some of it's new dependencies are not keyworded. Add p.masked or keyword-less till dependencies are keyworded. *Then* add to ~arch carrying over keywords. Although I'm not an arch tester myself, I empathize with the huge amount of work they have to do. This will reduce workload for arch teams greatly Example: http://bugs.gentoo.org/show_bug.cgi?id=268529 -- libsoup keywords dropped because of new dependency libproxy. This led to a cascade of packages with dropped keywords -- http://bugs.gentoo.org/showdependencytree.cgi?id=268529 This could've been worse, and likely will be worse with GNOME 2.28 and 3.0 :) -- ~Nirbheek Chauhan
Re: [gentoo-dev] [rfc] repo_name/layman-global.txt overlay name mismatches
So here's the current result of my analysis: == Format: repo_name, # layman-global.txt Entries: maekke's overlay, # maekke kde, # kde-testing ERROR: Overlay lordvan lacks repo_name entry ERROR: Overlay rox lacks repo_name entry ERROR: Overlay rion lacks repo_name entry ERROR: Overlay gnash-cvs lacks repo_name entry ERROR: Overlay php-4 lacks repo_name entry ERROR: Overlay rostov lacks repo_name entry ERROR: Overlay roslin lacks repo_name entry ERROR: Overlay postgresql-testing lacks repo_name entry ERROR: Overlay pd-overlay lacks repo_name entry geki-overlay, # openoffice-geki mpd-portage, # mpd tante_overlay, # tante ERROR: Overlay stuart-desktop lacks repo_name entry ERROR: Overlay d lacks repo_name entry gentoo-lisp-overlay, # lisp ERROR: Overlay chtekk-syscp lacks repo_name entry soor, # soor-overlay dev-jokey, # jokey Falco's git overlay, # falco kde4-experimental, # kde ERROR: Overlay hanno-xgl lacks repo_name entry ERROR: Overlay sipx lacks repo_name entry ERROR: Overlay cell lacks repo_name entry ERROR: Overlay pchrist lacks repo_name entry digital-trauma.de, # trauma ERROR: Overlay genscripts lacks repo_name entry ERROR: Overlay powerpc lacks repo_name entry gcj-overlay, # java-gcj-overlay steev_github, # steev pcsx2-overlay, # pcsx2 vdr-xine-overlay, # vdr-xine china, # gentoo-china ERROR: Overlay marineam-xen lacks repo_name entry gentoo-haskell, # haskell ERROR: Overlay openmoko lacks repo_name entry ERROR: Overlay tove lacks repo_name entry ERROR: Overlay stuart-server lacks repo_name entry ERROR: Overlay deathwing00 lacks repo_name entry ERROR: Overlay trapni lacks repo_name entry ERROR: Overlay gnr lacks repo_name entry webapp-experimental, # webapps-experimental ERROR: Overlay eclipse lacks repo_name entry proaudio, # pro-audio ERROR: Overlay seemant lacks repo_name entry ERROR: Overlay pythonhead lacks repo_name entry ERROR: Overlay initng lacks repo_name entry ERROR: Overlay gentoojp not found majeru, # oss-overlay ERROR: Overlay plan9 lacks repo_name entry ERROR: Overlay m68k lacks repo_name entry ERROR: Overlay iwlwifi lacks repo_name entry bangert-ebuilds, # bangert suka's dev overlay - experimental stuff of all sorts, # suka ERROR: Overlay stuart-perforce lacks repo_name entry ERROR: Overlay break-my-gentoo-main lacks repo_name entry ERROR: Overlay ramereth lacks repo_name entry leio-personal, # leio ERROR: Overlay aross lacks repo_name entry ogo-lu_zero, # lu_zero ERROR: Overlay mysql-testing lacks repo_name entry scarabeus_local_overlay, # scarabeus ERROR: Overlay liquidx lacks repo_name entry ERROR: Overlay lila-theme lacks repo_name entry == That means quite a lot to do. Shall I make the script send e-mails to the overlay contacts? :-) I have added the mismatched repo_names to a whitelist in Gentoo Smolt, so packages installed before a repo_name fix should be collectable, too. Sebastian
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2009-07-12 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2009-07-12 23h59 UTC. Removals: net-im/ekg2 2009-07-09 17:10:24 ssuominen media-sound/bossogg 2009-07-09 17:12:28 ssuominen media-plugins/gmpc-autoplaylist 2009-07-09 17:13:58 ssuominen media-plugins/gmpc-serverstats 2009-07-09 17:13:58 ssuominen media-sound/kamix 2009-07-09 17:15:25 ssuominen media-sound/sonik 2009-07-09 17:15:26 ssuominen dev-perl/X102009-07-10 16:04:30 tove Additions: gnustep-apps/gshisen2009-07-06 08:03:43 voyageur dev-java/neuroph2009-07-06 09:10:27 ali_bush dev-java/jung 2009-07-06 10:04:20 ali_bush dev-java/swing-worker 2009-07-06 10:18:12 ali_bush dev-java/appframework 2009-07-06 10:36:09 ali_bush media-fonts/nanumfont 2009-07-06 16:34:29 matsuu app-emulation/vmware-vix2009-07-06 17:16:01 vadimk gpe-base/gpe-calculator 2009-07-06 19:31:03 miknix gpe-base/gpe-gallery2009-07-06 20:13:14 miknix dev-java/easyneurons2009-07-06 20:34:51 ali_bush sci-biology/shrimp 2009-07-07 17:35:31 weaver sci-biology/mothur 2009-07-07 18:09:18 weaver media-gfx/smile 2009-07-07 23:05:21 hwoarang sci-biology/allpaths2009-07-07 23:09:24 weaver sci-biology/vaal2009-07-08 03:52:35 weaver sci-geosciences/osm2pgsql 2009-07-08 12:55:19 tupone mail-client/claws-mail-bsfilter 2009-07-08 18:59:46 fauli mail-client/claws-mail-fancy2009-07-08 19:06:31 fauli sys-apps/ccs-tools 2009-07-09 00:19:54 matsuu sci-biology/infernal2009-07-09 14:33:31 weaver sci-libs/nlopt 2009-07-10 19:27:20 bicatali net-analyzer/lilac 2009-07-10 21:13:43 dertobi123 media-libs/lastfmlib2009-07-11 21:11:17 hwoarang media-sound/aacplusenc 2009-07-12 00:06:44 ssuominen dev-python/mkpythonproj 2009-07-12 13:34:57 neurogeek -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: net-im/ekg2,removed,ssuominen,2009-07-09 17:10:24 media-sound/bossogg,removed,ssuominen,2009-07-09 17:12:28 media-plugins/gmpc-autoplaylist,removed,ssuominen,2009-07-09 17:13:58 media-plugins/gmpc-serverstats,removed,ssuominen,2009-07-09 17:13:58 media-sound/kamix,removed,ssuominen,2009-07-09 17:15:25 media-sound/sonik,removed,ssuominen,2009-07-09 17:15:26 dev-perl/X10,removed,tove,2009-07-10 16:04:30 Added Packages: gnustep-apps/gshisen,added,voyageur,2009-07-06 08:03:43 dev-java/neuroph,added,ali_bush,2009-07-06 09:10:27 dev-java/jung,added,ali_bush,2009-07-06 10:04:20 dev-java/swing-worker,added,ali_bush,2009-07-06 10:18:12 dev-java/appframework,added,ali_bush,2009-07-06 10:36:09 media-fonts/nanumfont,added,matsuu,2009-07-06 16:34:29 app-emulation/vmware-vix,added,vadimk,2009-07-06 17:16:01 gpe-base/gpe-calculator,added,miknix,2009-07-06 19:31:03 gpe-base/gpe-gallery,added,miknix,2009-07-06 20:13:14 dev-java/easyneurons,added,ali_bush,2009-07-06 20:34:51 sci-biology/shrimp,added,weaver,2009-07-07 17:35:31 sci-biology/mothur,added,weaver,2009-07-07 18:09:18 media-gfx/smile,added,hwoarang,2009-07-07 23:05:21 sci-biology/allpaths,added,weaver,2009-07-07 23:09:24 sci-biology/vaal,added,weaver,2009-07-08 03:52:35 sci-geosciences/osm2pgsql,added,tupone,2009-07-08 12:55:19 mail-client/claws-mail-bsfilter,added,fauli,2009-07-08 18:59:46 mail-client/claws-mail-fancy,added,fauli,2009-07-08 19:06:31 sys-apps/ccs-tools,added,matsuu,2009-07-09 00:19:54 sci-biology/infernal,added,weaver,2009-07-09 14:33:31 sci-libs/nlopt,added,bicatali,2009-07-10 19:27:20 net-analyzer/lilac,added,dertobi123,2009-07-10 21:13:43 media-libs/lastfmlib,added,hwoarang,2009-07-11 21:11:17 media-sound/aacplusenc,added,ssuominen,2009-07-12 00:06:44 dev-python/mkpythonproj,added,neurogeek,2009-07-12 13:34:57 Done.
[gentoo-portage-dev] [PATCH] config_root variables in pym/portage/const.py
In Prefix, there is a distinction between variables used with
config_root and target_root. Quoting from prefix' const.py:
# We have a most confusing situation here, which is most of all pretty
# weak for protecting us from making mistakes.
# First there is a config_root (PORTAGE_CONFIGROOT) which can be a path
# somewhere, from which all paths need to be relative (e.g.
# etc/portage), hence those constants do NOT have EPREFIX, because
# config_root contains EPREFIX by default -- overriding it loses the
# EPREFIX as one would expect.
# Second there is target_root (ROOT) which is to install somewhere
# completely else, in Prefix of limited use. Because this is an offset
# always given, the EPREFIX should always be applied in it. Those
# constants (like VDB_PATH) DO have EPREFIX.
# Unfortunately this file is ordered quite horrible in this respect.
The attached patch makes all variables against config_root relative (by
removing the leading '/'), with the result that all lstrip(os.sep) calls
in the code can be removed. Please note that all but two occurences did
use config_root. For one (pym/portage/__init__.py; sandbox stuff) I've
added it, for the other (in pym/portage/output.py) I don't know how to
get config_root, so substituted '/', which breaks Prefix by design.
How about this patch, and if it is a good idea, how about grouping all
of these config_root variables such that it's easier to see what is
what? I actually ran into this because Sebastian was hitting it with
his smolt-gentoo tool.
--
Fabian Groffen
Gentoo on a different level
Index: pym/portage/__init__.py
===
--- pym/portage/__init__.py (revision 13819)
+++ pym/portage/__init__.py (working copy)
@@ -1309,7 +1309,7 @@
if not config_profile_path:
config_profile_path = \
- os.path.join(config_root,
PROFILE_PATH.lstrip(os.path.sep))
+ os.path.join(config_root, PROFILE_PATH)
if os.path.isdir(config_profile_path):
self.profile_path = config_profile_path
else:
@@ -1325,7 +1325,7 @@
self.module_priority= [user,default]
self.modules= {}
self.modules[user] = getconfig(
- os.path.join(config_root,
MODULES_FILE_PATH.lstrip(os.path.sep)))
+ os.path.join(config_root, MODULES_FILE_PATH))
if self.modules[user] is None:
self.modules[user] = {}
self.modules[default] = {
@@ -1389,7 +1389,7 @@
self.profiles = []
if local_config and self.profiles:
custom_prof = os.path.join(
- config_root,
CUSTOM_PROFILE_PATH.lstrip(os.path.sep))
+ config_root, CUSTOM_PROFILE_PATH)
if os.path.exists(custom_prof):
self.user_profile_dir = custom_prof
self.profiles.append(custom_prof)
@@ -1465,7 +1465,7 @@
del rawpuseforce
make_conf = getconfig(
- os.path.join(config_root,
MAKE_CONF_FILE.lstrip(os.path.sep)),
+ os.path.join(config_root, MAKE_CONF_FILE),
tolerant=tolerant, allow_sourcing=True)
if make_conf is None:
make_conf = {}
@@ -1561,7 +1561,7 @@
self.configdict[defaults]=self.configlist[-1]
self.mygcfg = getconfig(
- os.path.join(config_root,
MAKE_CONF_FILE.lstrip(os.path.sep)),
+ os.path.join(config_root, MAKE_CONF_FILE),
tolerant=tolerant, allow_sourcing=True,
expand=expand_map)
if self.mygcfg is None:
self.mygcfg = {}
@@ -1610,8 +1610,7 @@
self.pkeywordsdict = {}
self._plicensedict = {}
self.punmaskdict = {}
- abs_user_config = os.path.join(config_root,
- USER_CONFIG_PATH.lstrip(os.path.sep))
+ abs_user_config = os.path.join(config_root,
USER_CONFIG_PATH)
# locations for categories and arch.list files
locations = [os.path.join(self[PORTDIR], profiles)]
@@ -1838,7 +1837,7 @@
(sandbox in self.features or usersandbox in
self.features):
Re: [gentoo-portage-dev] [PATCH] config_root variables in pym/portage/const.py
Fabian Groffen wrote: The attached patch makes all variables against config_root relative (by removing the leading '/'), with the result that all lstrip(os.sep) calls in the code can be removed. Please note that all but two occurences did use config_root. For one (pym/portage/__init__.py; sandbox stuff) I've added it, for the other (in pym/portage/output.py) I don't know how to get config_root, so substituted '/', which breaks Prefix by design. Your patch is in svn r13821. I've added a comment in output.py that we can use ObjectProxy to implement lazy initialization of codes and _styles, and add an init(config_root=/) function that can be called in order adjust the location that color.map is read from. How about this patch, and if it is a good idea, how about grouping all of these config_root variables such that it's easier to see what is what? I actually ran into this because Sebastian was hitting it with his smolt-gentoo tool. Yes, please go ahead and group the variables if you like. Feel free to commit it yourself. -- Thanks, Zac
