[gentoo-portage-dev] Re: [gentoo-dev] Re: Proposal: pre-emerge advisories
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
R Hill wrote:
Craig Lawson wrote:
Comments?
This subject has also been brought up on the forum[1] very recently.
There have been some interesting ideas and alternatives posed that seem
workable. I was hoping some of the developers, if they have a moment,
could consider and critique these suggestions so we can come up with a
final solution that works for everybody.
--de.
[1] http://forums.gentoo.org/viewtopic-t-360192.html
A small discussion was had on #gentoo-portage about issues relating to
this. I had issues with the com_err upgrade slaughtering sshd and
denying remote logon; although I got the e-mail from my script telling
me what to do to upgrade cleanly I could not log in remotely to do it
causing a short trek across campus to sit at the console and perform the
fix.
So, in at least this case ( and many others ) an upgrade path is
provided. They know there is breakage, and they usually provide some
knowledge of how to fix it. Thus the content we are looking for exists,
but often times is missed or ends up getting to us at the wrong time (
after the fact, instead of prior ).
In order to receive this helpful data we basically need 4 or 5 things.
RESTRICT=Warning
pkg_warn()
Features=Warning
PORTAGE_WARNLEVEL={0-5} ( in make.conf )
EBUILD_WARNLEVEL={1-5} ( in the ebuild )
patches to portage
Developer awareness and use ( QA++ ).
1. If RESTRICT=Warning is set, and EBUILD_WARNLEVEL is less than or
equal to PORTAGE_WARNLEVEL then pkg_warn() is called, otherwise it is
skipped.
2. If Features=Warning is set, pkg_warn() will die pending some
action ( to be determined, offhand I'd say put pkg_warn() after
src_unpack() and have emerge --warning-disable CPV touch
$WORKDIR/.warning ) If $WORKDIR/.warning exists then continue the build
and assume that the admin has read the content of pkg_warn().
If you do not care about breakage, you can set PORTAGE_WARNLEVEL=0 which
means that EBUILD_WARNLEVEL will always greater than PORTAGE_WARNLEVEL
and pkg_warn() will never get called.
If you care about extreme breakage only, you can set PORTAGE_WARNLEVEL=1
and only system critical breakage will be reported and halted.
As PORTAGE_WARNLEVEL increases less critical breakage will be reported
and halted by pkg_warn().
Why the suggestion is so complex:
Aim high, and whittle away crap that people don't like ;) I originally
planned on not having warnlevels, but figured developers would use the
RESTRICT and pkg_warn() to warn about silly things and everyone's emerge
globs would halt every 3 seconds with a WARNING error. Thus the crazy
guy that actually cares when xmms breaks ( think the module split-off )
can have his WARNING and halted emerge while those of us who only care
when critical packages have upgrade issues can set PORTAGE_WARNLEVEL to
1 and just get the big ones.
Needs:
The suggestion could definately benefit from per-package FEATURES (
already in bugzilla ) so I can create a whitelist of things to halt on
upgrade problems ( think base-system ) and I can then ignore everything
else, even if it's WARNLEVEL is less or equal to the config
specification ( remember pkg_warn() only halts with FEATURES=Warning).
Suggestions, critiques, laughing at over-engineering welcome ;)
- -Ajec
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQIVAwUBQuHW5WzglR5RwbyYAQJxVQ//czHIcTkeLySoijE7TdQObdD11Cms9G5N
hhP83qgU8kq7XIGmh33l+W4IT5Viq0lfnRYtMtFSGuMyVrPJDONOKK6WMg3412xd
6Bc2DBdBeJoX2OTrlMTMpFSwSp4qXOz+yFk/rpy7A+wId1uWQjDAC1HUtht6ydmZ
+4q/FBeuDiAOPadCybAZcRuUinV+QbqwaizrAYNPPEuUyeGxnmpfkt3DH/tcZboC
eACSpB0srH+SwOlfw+52L91R7UIimn0wj9CQ+2qN7iv97/FNcyn7A+n4kXifikUn
MdfaKJxjgLCftqTlWr6TWTqxDpt7MRi8n5gGIUgG0SUfmk9J/KOerD+TusruQ41c
41kb4+C/q3Zn7DRreTeh7NgX1yOXqb5OAOFGjjfr1ROdWuqmbtNgA4hNXtsDyTG6
uoDkzmbUesLZ1eDW0aJNb6FJRHx3JdiayzOQ1siKus4uWmQVfZuirtjdkwajVkwV
K2QvHlPZ82VKo0zd6u1sXZa4rUUJHRU8DhnHv5p9qAcwC0h63pgFaNcuZ/h+I2jX
vu7/IozmAMQAcl2YTtfZTCOFEOGDr/aErco9+c1E7pG5BRIvljXhrPYuvaovykzS
r42YzZ5YlUep1aKQwEthCYlnx7T8IyKywwtLYouC95BCXIYFt5mMgjELlWnp/uY4
hI5pTlHrRw0=
=1s8S
-END PGP SIGNATURE-
--
gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] PATCH: gentoolkit: Make portage.config object a global object
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason Stubbs wrote: On Saturday 17 September 2005 01:59, Paul Varner wrote: http://bugs.gentoo.org/show_bug.cgi?id=90680 Author: Paul Varner The current implementation of gentoolkit creates a portage.config object for every package object that it creates. While this is the correct thing to do from an object-oriented programming point of view, this implementation consumes an excessive amount of memory and CPU. The proposed patch changes the portage.config object for each package object to point to a single global object. If no one sees any serious issues with the patch, I will be placing it into gentoolkit. I tried doing this once before locally, but found some issue with it. Unfortunately, I can't remember what that issue was. If you are calling setcpv() for every call to the package object that utilizes the config object and no utilizing packages (in gentoolkit or otherwise) are utilizing threading, it should theoretically be okay. Actually, I think it was the threading issue that delayed the fix. I can't remember the model for this, but there is some logic along the lines of intercepting config object writes with setattr and then cloning the config object. That way if the config is read-only only 1 is instantiated, but if you attempt to modify it, the config would clone itself, then proceed with the modification and return the cloned copy. Not sure how easy that would be to implement, perhaps some sort of wrapper class? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQytkOmzglR5RwbyYAQKDvw//Wz/TpPF35sf+yhz5dyQ09qN5Ug9qiTec qDnf364k+lzUSXzzNEjhpgSpyyKcEv30CjZWTn+g3IoH7aQ2v2mIIF+5V0C/9kxP JH0a+ibh+Mvzv28tteEE+VX4yTykNz8L5b6twwQO/53GfY8Dj/l19AqOrjgHOfGf /nvslpqEiFmAzc0RdxMuOAiFHdcfZgZyQpHsHboTZ7kQQpFTX4h1nShNAkGiceBI ucfIs/Fp0RunDUYK2pfIedbLKsfRKyySaUOXXPUrTiwufO7zbyvRZI/+mBLJlL6v Ud49wak10G8dFNZA9J3LgWRoy2Dqxrp6Eu7gTp5U4ONKLSJo3CSVa+1P2eACmerl RqlAaVxtz+lpaXoiTSNoFKzjrIgidT00d7kG0v/gbI0vsqVy31nEuaSqWgAwjBit GeDV8A9Tnxe+UNyUkd4BpBX3p8bX4EyDUNqfv0OChuCXbozbc1yizksSps8+Y3iQ uG29o90/ExvsRQVAFKhWBjc9aYgghMhTO8yrKGkp4eI+ewa82QhLnlhgdQRMLSqY ox+IRPxClIVRLzUZ4m3BsITy3QdSqvVhrB7ITofIFjXSY0OPQivA0HSebnPDptlU mPreE6NzWs7KGhjhBvatqKnM7CuzW9JogolXkk+vT/pvSWlAoPc48mAW77CmKO5G q3754DSKb3A= =uzjq -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
Brian Harring wrote: On Wed, Oct 05, 2005 at 11:31:32PM +0100, Ciaran McCreesh wrote: On Wed, 5 Oct 2005 16:13:06 -0500 Brian Harring [EMAIL PROTECTED] wrote: | A) would like to hear what you think is required planning wise | compared to the previous haubi prototype patch. There has been no serious discussion on how *ebuilds* will use the prefix system. Hacking econf and expecting PREFIX to be sufficient is naive from a tree-perspective. econf isn't the only change required; the point is that whatever is decided, would have to be added to econf thus covering a good chunk of ebuilds in the tree that don't require fancy voodoo. The basic proposal of haubi's glep (ignoring the portage innard modifications) came down to addition of a prefix var, that would be required slipped in for any fs installation paths (--prefix=$PREFX fex). Beyond that, there is the shebang issue which can be addresses via a combination of automated scans/fixes, and fixing bugs as it's hit. Hardcoded vars in scripts for the path to a binary are an issue also, although again, scans can be done to at least check for it. Leaves mangling the build process so that the build framework of the package uses the prefix offset files, rather then / . For c/c++ source, usual trick from fink afaik involves a mangling of cflags with -I tacked in. Kinda ugly, although I'd expect there is a better route. Packages that pull include/compile settings/args from a utility (thinking python configuration tools, and pkgconfig) shouldn't be too horrid to change, since it's a matter of modifying it in one place (theoretically :). ~harring I guess in the end trying to do something like this is a difficult process. I am wary of anyone who wants to just jump into an application like portage and just magically write in this kind of support. In the end one could just try and go step by step, but nothing guarantee's you won't miss something, or because it works with packages x,y,z that it will work for all packages. If you have two weeks to do it in, I wish you the best of luck. Maybe you are good enough at learning portage internals to get it done, but even after portage support is done there are still plenty of other factors. In the end I side with Ciaran on this one. You need to know all the bases to cover here in order to make this work well. Going ahead with no plan is stupid IMHO. -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
m h wrote: Thanks for the warning Alec. Since I already have very limited knowledge of the internals, I figure this will be a good trial by fire (learn sort of the portage internals and issues with prefixed installs). If it works, perhaps I will be able to devote more time to it and do more than a simple prototype (which might involve writing a spec, talking to Fink people and seeing how they resolved these sorts of issues and all that fun stuff). Right now, I'm not very qualified to write a spec, but I figure when I get my hands into it I'll start seeing a lot more of the issues one is bound to run into. If it's so hard that's it's impossible then maybe I should just give up now What sort of plan do you suggest? On 10/5/05, Alec Warner [EMAIL PROTECTED] wrote: Brian Harring wrote: On Wed, Oct 05, 2005 at 11:31:32PM +0100, Ciaran McCreesh wrote: On Wed, 5 Oct 2005 16:13:06 -0500 Brian Harring [EMAIL PROTECTED] wrote: | A) would like to hear what you think is required planning wise | compared to the previous haubi prototype patch. There has been no serious discussion on how *ebuilds* will use the prefix system. Hacking econf and expecting PREFIX to be sufficient is naive from a tree-perspective. econf isn't the only change required; the point is that whatever is decided, would have to be added to econf thus covering a good chunk of ebuilds in the tree that don't require fancy voodoo. The basic proposal of haubi's glep (ignoring the portage innard modifications) came down to addition of a prefix var, that would be required slipped in for any fs installation paths (--prefix=$PREFX fex). Beyond that, there is the shebang issue which can be addresses via a combination of automated scans/fixes, and fixing bugs as it's hit. Hardcoded vars in scripts for the path to a binary are an issue also, although again, scans can be done to at least check for it. Leaves mangling the build process so that the build framework of the package uses the prefix offset files, rather then / . For c/c++ source, usual trick from fink afaik involves a mangling of cflags with -I tacked in. Kinda ugly, although I'd expect there is a better route. Packages that pull include/compile settings/args from a utility (thinking python configuration tools, and pkgconfig) shouldn't be too horrid to change, since it's a matter of modifying it in one place (theoretically :). ~harring I guess in the end trying to do something like this is a difficult process. I am wary of anyone who wants to just jump into an application like portage and just magically write in this kind of support. In the end one could just try and go step by step, but nothing guarantee's you won't miss something, or because it works with packages x,y,z that it will work for all packages. If you have two weeks to do it in, I wish you the best of luck. Maybe you are good enough at learning portage internals to get it done, but even after portage support is done there are still plenty of other factors. In the end I side with Ciaran on this one. You need to know all the bases to cover here in order to make this work well. Going ahead with no plan is stupid IMHO. -- gentoo-portage-dev@gentoo.org mailing list My point was not to scare you so much as to make you aware of the problems you will face. Most of them are not portage problems. Most of the problems are ebuild problems, found in each piece of software that will be used in this manner. All of the ebuilds are written for one domain, and now they are being used in another. Ciaran has already given a few examples of the trouble. In this case Getting it to work is easy. Getting it to work for all packages = a ton of work. -Alec PS: Nothing I say should stop you, I am by no means an expert. PSS: Good Luck. -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
Ciaran McCreesh wrote: On Wed, 5 Oct 2005 21:39:49 -0500 Brian Harring [EMAIL PROTECTED] wrote: | So bluntly, shut up and let those who you think are being retarded, | be retarded. Discussions on this list regarding those attempts | shouldn't be heckled unless you're contributing to those efforts (and | I truly mean *contributing*, not trying to punch holes in embryonic | efforts that are trying to get off the ground addressing the major | issues up front). Pfff. By contributing to the design by showing what *won't* work, I'm saving a heck of a lot of wasted man hours that will otherwise be spent writing a non-working solution. A contribution of code is worthless if the code is completely wrong, no matter how much effort was spent producing it. But then, we all know how this goes. When the code's 'done', it gets merged, and then you start claiming If you had any issues with it you should have brought them up at the design stage. It's too late now!. So really, it's a no win situation. Point out gaping design flaws at the start and you're accused of shooting holes in things that don't exist yet. Point out gaping design flaws when it's first merged and you're accused of shooting holes in things upon which people have spent lots of time. Point out gaping design flaws after it goes live and you're told it's too late. Then I suggest you file this e-mail away and when the time comes that the code is to be merged and it sucks ( and by sucks I mean more than it doesn't meet Ciaran's software engineering standards ) you can waive the mail in everyone's face. No project, specs or not, is ever written right the first time. At the very least someone can take his code and improve on it in the future. -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] branches/2.0 moved to trunk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Frysinger wrote: On Sun, Nov 06, 2005 at 05:40:26PM +0900, Jason Stubbs wrote: I've moved trunk/ to branches/2.1-experimental/ and branches/2.0 to trunk/. Make sure to update before doing any changes... i thought 2.1 / trunk was dead ? why not just punt it and be done ? -mike IIRC, people are still backporting things... I was going to look at confcache and porting it to 2.0... if I ever find the time and subsequent motivation ;) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQ266+WzglR5RwbyYAQJ8QA//TvHlyjct0mwXDjqm0jRjFQfUuyyQ46UC vR2CMnYgUMwnljsx3bbhecNczy5o6cwLMvsPEq4MthDJm3AUmlHNkLrj/+ZySpDM IC0/ZzJcFIf9kOXzNOV7lWCJUU/118UIM6I/eaxj5LJCENJZ2BzVTRTgozFJuoaX xKgOr1M6JCd0sMGFfclnwdoI8qjIFxV+gYS9qzhAhWN4T/NtdTFfbyNIso0pgVtD OG8T0pKetsrz/5WU/YuUs0EqEC+KaZH8H0n8YFAF+q90NnjRwJjAefrU0AhgYeml ZX8ZUhFMXVCfs7iXaPLNwcYp5HA5mbTBp8Oi5H6vjkJFl6bZ5CQE91SqseyW6ZZR T+cgxzO7WG5bJ72FQJbzjXgGHrtZfODoolgQPE1+uO+Z6bKWH0EK3hQpvXOFX680 oqAZGnzD42Yi5t8EVF7yHRPNU3r99EnbZBGl1xKnRWJnBIHd6tqRizubuoxkolwP aQjWN6OwLnVJ/t5JSe7axVJJlggS7Dr1+1Fi7Cx5EIxviJbbxmwjc0bgl/s8mVJZ ew8dFuyXTBqBc+qPC9phRnhisp/xH0R9OzoiTp/4Da7bR49AU5AWUEEwhiUzziiq N6XNQKVpD0db41gKhvXDUNs2czXhfeKpUz/woAPr2+QUkHVHGFFtedVlh4Y1Cxyg Zy48JG1SWUM= =TWpq -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Savior Wiki
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Goal one of the wiki is to document everything in dev-notes; right now it is just myself and marienz doing this. Feel free to join in. Some portions of the code are still being worked on, and there are bugs throughout. IMHO this is a document-as-you-go project, so since it's brand new no one has written any ;) Mostly looking at non-devs providing input, as any dev could just add things to dev-notes in svn. Common pitfalls, code comments, patches ( you can attach stuff too :) ), Help on getting people started with poking around in it. This is not meant to be official documentation, although my hope is that the wiki may later help to fluff up the docs, kind of like the User Comments section in php documentation :) Alec Warner (antarus) Marco Morales wrote: where in the page is the savior portage code related stuff?... On Sat, Nov 12, 2005 at 07:16:27PM -0500, Alec Warner wrote: Thanks to some help from Patrick ( bonsaikitten ) we now have a wiki at gentooexperimental. For now it can be accessed by hitting up http://gentooexperimental.com/~antarus/ In a bit I hope to have something like portagewiki.gentooexperimental.org for a subdomain, but it will take a bit longer for that. Please register a name for yourself and mail me about it so that I can grant you editing previlages. Note: You may get an error saying it couldn't mail you your password. There is no MTA ( cruft! ), so don't forget your password :) If you do you can mail me to nuke your wiki account credentials. Note: After making your account you still don't have edit rights to prevent random people from making accounts and spamming the wiki (right, like that will happen). Please mail me after you make your account so that I can change it so you can add ( and remove! ) stuff. Note: Please don't use any kind of important passwords, they are md5 hashed, but are easily broken and I don't believe there is ssl involved. - -- gentoo-portage-dev@gentoo.org mailing list -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQ3esJGzglR5RwbyYAQL5zg//fQRdmQoE0l6VJDKwCPKQfLqnojnYSF5L JX+krApFadYnT8o+83SeDEDmxNtf0ybY2pow0jI/EcIfCVoj+IXP7mpnUkbfHROn N5PsYCKxMo3TgKerSDCPIXe/0L78qVnZkhSa7c3DniyTHoxVXz7VJlIDV2jpIIrV EW6Ui6czdxWxejzVzL+CZm5c9rMf/GT9QWkdWKueAFyJy61kpiq5eh0Otcq5CIGx KvPu+URX2XkAmzG+q9Br87tMEKgYTp60yrf8VraU22PjMj+h8rD53xLNJAdvo8kt xze8AKZkSibSMDdpD40VRegGW9sO/rykDmxCFIKscgSOYQldKcAl7bu4OYMJZSEz mCQKuopvKJL4UaxMt/gbm9m/5eEBGklVL/tNdgbKgsc+8ewf7NFhka99bpPi/Zh+ yq995K0U7I+VpQDifEh+hxXgOAGR70JYpu6k7LF8UxVllZuckq+IeLa8ITkn4pWD iIoiF5C43gayqSLFT6IIxfx6Axu3JhRsuCuW80w7mAqGUjf1SNKedLJ0gTMLpDIq VML9Id518K1YaZnbfupCdXdQB0hf5DH2hydiNCVfC51S8y4BB55ERsxWgjbM/r9l 2FtD5ufczhLOrljigSnxzHC6BtPauyDsds40UlUHQlIBF1n1j+N8qGUYAY8bxqLF Nv2lyvWEw2U= =lg/a -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
[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
+
Re: [gentoo-portage-dev] .53, .54 and beyond...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Fri, 25 Nov 2005 19:00:07 -0500 Ned Ludd [EMAIL PROTECTED] wrote: | Why introduce a feature which is crippled? It would be almost as | easy to allow ebuilds to mess with their 'real' runtime dependency | value as appropriate rather than forcing an incorrect | auto-generated list onto everyone. Talking on solar about this confirmed my suspicions, the ELF data can't be wrong, otherwise things won't link properly. Thus if we were just to use ELF NEEDED entries, how could the list of reverse runtime deps be incorrect as you imply above? The only assumption here is that ELF is supported on that platform/arch. | | Please go back to trolling on dev We are trying to get work done here | and solve real problems. Sure. You're inventing some arbitrary problem which has no reflection upon reality and then solving some other arbitrary problem which has no reflection upon either reality or what you say you're solving. End result is more unnecessary complexity, more unnecessary mess and, once you realise your solution is inadequate, no doubt yet another incomplete hack on top of that. So in regards to reverse dependency tracking, do you have a solution/advice or just useless criticism? Please attempt to be constructive here. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQ4evCWzglR5RwbyYAQKXlw//YqvAsDkbt3PYmCII6LELOs5qEo8iUPI9 IZuauacBt6uqoVY7UyP36Wt2ky9rqnO2fFlON6i39MjdfN3XsyVIRqVwf4agwWFM QuH19h3wQfCsum5vMKZMej8qfskdpozj4VeTeU2f/NxS6g19LW8vzH7MTDY13tr3 bmY1unyQK7rx6bN+qtV/l22Doq4WnFBDWrY68L00wqHBGzn/VNl9Gh6JTVMTO/AL +yEMma4b0+feCcfrSyxgiliSnaZS+ghJyLPyY4P/gVxDlOP577ufzKxPHgaOh9FN hGaiSaS69Xf4XMcawcdmsE/Tp9Kp1uWXfJibaDCSw4xlmRwm7J26s97NaBu6YsWh keJ1nnMl1O9fjuVCiERVJGMQCYJNAP7up+YAwC62FwNqJSOk5PMS8jz/+uPbWwSW FRTZZCxTDe6JSbZ1RAPLY8xzQFtfdeU4T/wEiWj61w8yRqV132bHiay/lsVNq6P9 GWCvU7pphfe7cNDlk1cHT8eQOE91bVfmKdZBZ+eUgPQk6esMuMCh1MIj38s1lJOi XGxIe3pECS7NPinv8n9ujaYoY7y7Uw+AQTbfFJjdRyldfciqbOpjiv4DfwgVIeiN BE3bio08ybIT7Hb1g9GwPIkycbTbpT4JlBgAKrH3BIBs1d2Syae8DOR3P6WlJDZ/ lD1dIhX5JQ8= =GkJo -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] .53, .54 and beyond...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Fri, 25 Nov 2005 19:42:14 -0500 Alec Warner [EMAIL PROTECTED] wrote: | Ciaran McCreesh wrote: | On Fri, 25 Nov 2005 19:00:07 -0500 Ned Ludd [EMAIL PROTECTED] | wrote: | | Why introduce a feature which is crippled? It would be almost as | | easy to allow ebuilds to mess with their 'real' runtime | | dependency value as appropriate rather than forcing an incorrect | | auto-generated list onto everyone. | | Talking on solar about this confirmed my suspicions, the ELF data | can't be wrong, otherwise things won't link properly. Thus if we were | just to use ELF NEEDED entries, how could the list of reverse runtime | deps be incorrect as you imply above? It can be incomplete. Of course, finding the ELF NEEDED entries is not a sufficient solution to the initial problem, nor is it a sufficient solution to the real problem here. Well I bought this bug-spray and it only kills 99% of the bugs in my home, so I guess I should scrap it and work on something better that kills 100% of bugs? If this helps stem system breakage by repairing a number of broken library deps, how is that bad? Because it doesn't adhere to Ciaran's ideal feature standards? | So in regards to reverse dependency tracking, do you have a | solution/advice or just useless criticism? Please attempt to be | constructive here. Sure. My advice is to scrap the current idea and redo it to take into account things which are not just ELF-related. Bricklayers build walls, one brick at a time. - -Alec Warner (antarus) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQ4e5yGzglR5RwbyYAQJJWQ/+KdAbQKfUg6HWzzrNRlMJWjKau+PLuW6x gvT/vRU6lYz6612lVbrAmXxir0UdkYjZIe5AXXEz+bTg9K78xL0HuvBb2/fyYihy +pAhkpOhI5eE7dc8fn5vV1dIEOtnBco+UZakSfi9Eai4+PqmaLWwOtiyMnNw3veM yby6Pm/H0VXVzJS5aVQXdPI4PDyyRO3dbLrbuMR9BOPn/qDsZIaB+A+Loy3TajKY BVPsPicGG1OsTnEL8YCgQ4Tl03aepLVuQDomV5vIje4rKfk80fi5UjhMCdHRzFrR Ej2cyyTexQqfNK2IXGh/0R0vgeJCfyMLhCK6b9PkVLSPfv38sJPxWOZuyBd5t8Qu jzJIz0Fhqqg1spfo9rOeFyuW/oOe86hGmFqj+QCrnGhKG0kmyzWeC4IFXClk1PJz P5Kt65uOJU8xOUUZKiUrQ+BnmK0KEYW0InBHmSCCGIjbwC9QCII9gLFlzwqzEd+8 xmnisEa2O5qiX0dSgQoUkenZR9ZvMAWYXkwa9REPiI2uappcagADDL6rR4YIRCOX E96sTByTji7fqu1FsOuARIasdp1PvGoxOr2M5dxoPV/ENcZG0X+NHaw6eUqq13dT ed30XQq/nYxTUcxDKAsWEpOMfMIkzlqxnIL6mN5rjoUZLXnQYDhCJlC3QCmS3uGW eH6ypTlY/9s= =gApf -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] .53, .54 and beyond...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason Stubbs wrote: On Tuesday 06 December 2005 11:17, Ned Ludd wrote: On Mon, 2005-12-05 at 23:06 +0900, Jason Stubbs wrote: Okay, new suggestion. Postpone the cache rewrite from above. Have only the minimal mods necessary to fix the PORT_LOGDIR/tee bug. Include the other two as is. That would be 2.0.54 as per the attached patch. Get that out soon and get trunk out masked at around the same time. As soon as 2.0.54 goes stable put trunk into ~arch. However, instead of ~arch meaning regression fixes only we could just limit it to minor changes only (ie. no big refactorings, rewrites or similar high risk changes) until it is time to stable it. I think it would be wise to reconsider the cache fixes. I know you have been away from irc for a while now and have missed the daily events, but most of the people we have interacted with are expecting the cache updates in .54 (alot of people complaining about the hanging at 50%) Call me wrong, but I'm feeling that the constant pulling and pushing on IRC causes many misjudgements. -- Jason Stubbs No I agree with you here, I just wanted reasoning because now I have this ML thread to refer people to :p - -Alec Warner (Antarus) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQ5WGIGzglR5RwbyYAQKUyw/8DzLWhxIUX8fwp0UdbGq1nlX7PQw/InBx GZxA9xZOEMdIff72vZCWEbJBkIQVC5eHS/okO9Cs9xZhrBLKEh1xudJZZqFiDwkF C8Au59k8YNtjjL7bHwDd+Z1gXMBfLj70YI1F4GnCrsWbaGp1k+lBOrPBeYLqxK5P GZS1Z2jIeDXGQCHj3gbL98fCe26p3OGby9VCQIrmA0Mm+y9GAftnr/7kaz+EZpxX HRvza1x2oIsNPPkIs7nqDT0RKqOsE3OvoKtcCQGLXpjIEoGHbghxX0FmqxFDSq7K lUk5SSskvaL6AVzqcQ99ietrhVZqCraBx/r8a/9U50czd+rpUs1cACVQM6TEwAu9 A+dv+84QubOQzhe3jPmkag5G7NEsTMjvp55NYnXXqg4ACT4gvvODEAPShlDUmYHu vPDlj4PXkF+jPAmhoUGfHvY0belCeVo9bV00yGBaTHzS40xK/TSP2Zpy0E6zbets pHtg7aU2OoC3DWOUn3tbbc1l3GY6adiRI2v5vYTNhQlzHdKFwLKPaw2GNu81Pq3t p2y5ZmIDLD5k4FAvnTiXTi2T/emqlD8QPPrxG7LbCqofFUd9K0DJlPhZZyub4H2f Eq8iPVKgUNwVg5g5HftYYa9RhAEur4ble9ZtFKp23ulplpaVV6JhXj/3aDcqZvp3 ozJyFy6Xtrc= =85d5 -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] ACCEPT_KEYWORDS depreciation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 CC'ing [EMAIL PROTECTED] because they like getting mail, and are relevant to the discussion :) I've been trying to sit in #gentoo more often ( I figured insanity would be a good excuse for my crummy grades ) and I am scared by the fact that people still walk in and try using ACCEPT_KEYWORDS=~blar to emerge things. We all know why this is bad, and it's been bad for quite some time. Opinions on adding a warning when users have set this in their environment? Is it anything more complicated than: antarus is there some funky way we can detect people using ACCEPT_KEYWORDS and yell at them? :) zmedico if ACCEPT_KEYWORDS in os.environ: print dumbass Any reasons/opinions against adding something like this? - -Alec Warner (antarus) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQ6EAi2zglR5RwbyYAQLechAAlyJLiGGNEMgjsGjHY9oPfHDrF+v1i+rd oBqHeKJdsWX1lxAQwdbbs0y+nFSfIpWXL9UaRSB9jbzJan0FIDBtbGh6v/VRTnHA AZRuzE/Cv5B0JN4S1msAKHOZiE9ye19Ii2TxoM/rhc2EaQBiJSA/ODjLrLGNaPIV SPh+BiFYCRLl5TE9f7MF/bMQDn76nFhnGN5e9kn9jY5eVyAKTzupSVr/cTx+bx9s dkXi3FsRbCSm+AT9kjDv+Rdprg0M5CFLxFIx4EEREooGUor+Ilyvo1JY2EATnfm5 9X2gMdxXRANxCCHYEtrNvtpXNzyRKedPglwdmqirMsM5B7pDnNxA7o6mQbI9USsD VNuKwibLNZnoYg5JBONsAaWmPFt58Hr80JMqAf+urifqOvSWjaP0h/qiUJTh3UX+ tGO4sJO3erxpJrXyUfzWIGpbZ29WqIoZ+mwh1zka/1ovOxFla9I/9cKEpNhdnhkV qnmH95EqBPgb51/UgGg4QhzV8niR3jDiCXKFEFIZL0UZrXSSZkmNW1Lyf2vG0XtA 2Tzn3AG7nQzaafkcCWIme3Sbcbaw4MIfN2lwb7gWYgJqf0RBqPt0DxMgPQZDknc3 Hho4oTRvQX692dmDyr6wWQdqjlYTjkGaUbU4xLexpeJnO9p2T/Zd49BNrC9mDv5Z p7eWTW2DLuI= =Jt4/ -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] default USE flags in IUSE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Disclaimer: This is nowhere near done, mostly looking to start a conversation with people about stuff it's missing, and ways to improve, mostly it was a proof of concept. However please try it out and play with it a bit, find issues, etc.. included is a patch against 2.1_pre3-r1. Also included is the ebuild I used to test fun things with. The ebuild doesn't pass QA, I know :P -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQ7mWq2zglR5RwbyYAQIXEg/+Mk70jBVZzdgEUhuOTh3MxWUB+ELk72J3 ZW6h2FBp+q7vBs0T350ZWQh+HbBNFStf1eBH1FxXdb84QcMnWxiERWfqfQ0zDv2F Ov3URqwtdiyrLcCsBWUWwH4KCJToX6ujBWpWHrnZTfEp8yJJl844qMX4VZPryboR KeRJKaTf1K1xTtJ9FY6hOuID5guBhMW6prd7Boa9spK8HK+VNaZks+jzAUMl3gK1 7/4nSakFBAFwr/PXFT+CiA4D5O5ONDhS+7axXgdr8I52FYKpV40QdMfltnbbKTrY Gw8m6pwwDq15Zlj9x6cRV1f49V5b86NE+KK78gPAJCSeL7Ta5V42VWp4gOYjjaFz oLJz+SVRhbzacvqxuHzjZc4+ydSr5F240UDZ9k8wfhYJ2FxO+LFIz9cnoSHAGHNS Fk2y9BjBMmHNjVc6j1JLa+akcUwDwxVY4h6LRFZ2H13vHAlqenyqDfkzTuGlvutt yfrD/Gf9a8ItuyfwWwSeessQ++ajjyzglXwhMRj4EuwTKduH0uW9x39sleAmlq87 jBDfr6qIG0EXDoVwuvQQB0VDHjtBz9e6XOtCvde89Q6o0vgT9Db3b0Q4vUZdV4uv zuIYeMGB6swPDOxxiA3ejFpHqRc9PfcU4/mrW1S47F08uONL8HVoWlTdUY6AOMSQ PKmwerHX/wk= =2Y/q -END PGP SIGNATURE- # Copyright 1999-2005 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: $ DESCRIPTION=This is a sample skeleton ebuild file # Homepage, not used by Portage directly but handy for developer reference HOMEPAGE=http://foo.bar.com/; # Point to any required sources; these will be automatically downloaded by # Portage. SRC_URI= # License of the package. This must match the name of file(s) in # /usr/portage/licenses/. For complex license combination see the developer # docs on gentoo.org for details. LICENSE= SLOT=0 KEYWORDS=x86 IUSE=+python -debug +doc +bar foo -nocxx DEPEND=python? dev-python/twisted doc? sys-apps/portage RDEPEND= --- emerge.orig 2006-01-02 14:43:57.624036128 -0500 +++ emerge 2006-01-02 15:57:50.190183648 -0500 @@ -964,8 +964,26 @@ if myuse == None: self.pkgsettings.setcpv(mykey) myuse = self.pkgsettings[USE].split() - self.applied_useflags[mykey] = myuse + self.applied_useflags[mykey] = myuse + # Add the code here. + if mytype == binary: + iuses = portage.db[/][bintree].dbapi.aux_get(mykey, [IUSE])[0].split() + else: + iuses = portage.db[/][porttree].dbapi.aux_get(mykey, [IUSE])[0].split() + + conf_use = self.pkgsettings.configdict[conf][USE] + + for flag in iuses: + if flag.startswith(+): + if '-' + flag[1:] not in conf_use: + if flag[1:] not in self.applied_useflags[mykey]: + self.applied_useflags[mykey].append(flag[1:]) + elif flag.startswith(-): + if flag[1:] not in conf_use: + if flag[1:] in self.applied_useflags[mykey]: + self.applied_useflags[mykey].remove(flag[1:]) + merging=1 if addme: # this is where we add the node to the list of packages to merge @@ -1625,10 +1643,18 @@ cur_iuse = portage.unique_array(cur_iuse) cur_iuse = [flag for flag in cur_iuse if flag not in portage.settings.usemask] + result = [] + # Strip the +- default USE flag in IUSE stuff out of IUSE + for flag in cur_iuse: + if flag.startswith(+) or flag.startswith(-): + result.append(flag[1:]) + else: + result.append(flag) + cur_iuse = result cur_iuse.sort() + cur_use = self.applied_useflags[x[2]] cur_use = [flag for flag in cur_use if flag in cur_iuse] - if myoldbest: pkg = myoldbest else: @@ -1636,6 +1662,14 @@ if portage.db[/][vartree].dbapi.cpv_exists(pkg):
[gentoo-portage-dev] r2522 commit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Author: ferringb Date: 2006-01-04 08:57:07 + (Wed, 04 Jan 2006) New Revision: 2522 Modified: main/trunk/pym/portage_dep.py Log: el buggo pointed out via spyderous. || ( a ( x? ( b ) y? ( c ) ) ) - -x -y , was resulting in || ( a () ) the main consumer of this, portage.dep_check is stupid, and was assuming () was valid. It's not, obviously. Long term bug, around in at least .51 . Should correct dep_check handling of it also, but no reason to be handing () in the result lists also. Sadly this breaks something else we apparently need and use ( or at least Ciaran tells me so :) ) DEPEND=|| ( ) which should evaluate to DEPEND= doesn't with this patch. It dies, which is bad, because while stupid, it should work. This of course is assuming that the tarball marienz sent me for trunk is correct ;P Please double check me here. This depend atom works in pre3-r1. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQ7yFYmzglR5RwbyYAQLUvw/9FWIOe6jPwPrh0aXcYr9dno9S2jYX9040 GuWYPOfHPUwREUE7Szg2JUJlhB7T3Z2rXOTtf4RMvqQrtUXQ7owCQozQvz+CSveJ JxlPq5ZqhduBpbMgUq4TNm59OIPf9mfQa3KxT6cTKf58kgxdn3q9YbMSLic0yxXp 4MA1Lq6/eOV7JQQuNP3YeX44jaVgmyKQKImrcFYbN35VprdgRmeXVrhXV9ham1F+ +klOxpZyLlal2MTsFw2034n3qOtNCWQHKGsiqE4X5m8SkvF4L/E3YQ8yUBIdcQf7 kyl/DtmiybH+7UAcCX28ZBmrw7OHbp+uu1iXuO8OnPQxyqA0BWs+ymYm2iToxe6k g2ZJfaXWibYBjy5bmqfPJqrhm4Ar0sS9x+qckGrouWbcZzXdL1aST6K8uvrJvCRQ QS8gDBPiinuNYV1aEh+z8ors6Bhk2GKSZB02Jo3TsaV281oEsChfOZ9lvskfaHn8 N89ZWA5kqQdX18vB8P3jWO2Umew0dPc9+WoMgKc5CwXBP1Jsxil9Em9lbMRo7UKt ejwBv73KbVcSK7IsOJPNsXRttV2BDjs1ANPPC/hqrilVdBAJlUeGb8+h4m/c31zs KmbiOtmLX/k7uISjT33wY93LPCDCM8PVeTBtnEEVhHNIwimKbUS0gBkezSBu6UFz OQO3Z6Blwsk= =Wwi8 -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] /etc/portage/profile/{pmask,arch.list, categories}
Apparently these weren't working ( not being read in ) due to a lack of /etc/portage/profile being in Locations in config in portage.py I split a patch for hte issue by simply adding the extra location and fixing the odd grabfile_package calls. It seems grabfile package was stripping the - so it wouldn't nuke existing entries in the pmask file. Comments welcome as usual. Alec Warner (antarus) pgpe9C7P88z5H.pgp Description: PGP signature
[gentoo-portage-dev] Fwd: /etc/portage/profile/{pmask,arch.list, categories}
My Apologies, KMail died, and when I restarted it it had the mail but stripped
the attachment ;)
-- Forwarded Message --
Subject: /etc/portage/profile/{pmask,arch.list, categories}
Date: Monday 09 January 2006 09:59
From: Alec Warner [EMAIL PROTECTED]
To: gentoo-portage-dev@gentoo.org
Apparently these weren't working ( not being read in ) due to a lack
of /etc/portage/profile being in Locations in config in portage.py
I split a patch for hte issue by simply adding the extra location and fixing
the odd grabfile_package calls. It seems grabfile package was stripping the
- so it wouldn't nuke existing entries in the pmask file.
Comments welcome as usual.
Alec Warner (antarus)
---
--- portage.py.ferringb 2006-01-05 03:55:17.169455112 -0500
+++ portage.py 2006-01-09 09:49:00.743795432 -0500
@@ -1108,7 +1108,7 @@
self.pkeywordsdict = {}
self.punmaskdict = {}
else:
-locations = [self[PORTDIR] + /profiles, USER_CONFIG_PATH]
+locations = [self[PORTDIR] + /profiles, USER_CONFIG_PATH,USER_CONFIG_PATH+/profile]
for ov in self[PORTDIR_OVERLAY].split():
ov = os.path.normpath(ov)
if os.path.isdir(ov+/profiles):
@@ -1165,13 +1165,16 @@
self.loadVirtuals('/')
#package.mask
- pkgmasklines = [grabfile_package(os.path.join(x, package.mask)) for x in self.profiles]
+
+ pkgmasklines = [grabfile(os.path.join(x, package.mask)) for x in self.profiles]
for l in locations:
-pkgmasklines.append(grabfile_package(l+os.path.sep+package.mask, recursive=1))
+pkgmasklines.append(grabfile(x+os.path.sep+package.mask, recursive=1))
pkgmasklines = stack_lists(pkgmasklines, incremental=1)
self.pmaskdict = {}
for x in pkgmasklines:
+if not isvalidatom(x):
+ writemsg(!!! Invalid atom %s in package.mask % x )
mycatpkg=dep_getkey(x)
if self.pmaskdict.has_key(mycatpkg):
self.pmaskdict[mycatpkg].append(x)
pgpP0rR57b22x.pgp
Description: PGP signature
[gentoo-portage-dev] [PATCH] portage config cleanup bits
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
config has two sets of environment + use stuff.
one is called configlist, the other configdict. They are essentially
copies of each other, and since for me dicts with named keys are easier,
plus the old code was written crappily and is hard for me to follow,
nuked that also.
Also nuked config.backupenv, since it's in configdict anyway.
Please test this, it works here, want to make sure there are no kinks,
specifically with backupenv.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQIVAwUBQ8njCWzglR5RwbyYAQLT5A//d6Fj4t+hj3B/G18W7ZzWUoNhVY1GCwJf
oMpGksi8Pj48cQTx6SUfl9tZz4E+ZSMkzMvdapekwWwQlfkvpzfE4Fi8QBVi38Sz
M89enKlWHi7sFTDey7tnwnPKdg/SWg+rZKXyxVD1j57oqaphbkkly1pGpJKGSN0Z
S9jZn0gw1uUwjs/W0S90vez6pyxvzktIScNjHjoARxWXd8nyC3ZsvnRyfO6FTNyY
fBJNFkwodIlbZN+KuSBAFbDg5eFMp9pBz69YpQ2/SHahOtYvF0a/lmqy3PWmKcPM
YeUN7sdLgfupKUIj6yr/L6c3BeKpiZ+qjbOuD6f3nqBoqsHUPjovNpxJDf+uB+RL
/XTr+thBzpZOo1ItSNjFPgwMijnpMHHfBqzGmM9O5rcO4mf9b8NQx8eqV56PDIpl
UNjoKPcTVuVFW2k3bC9L1KeDZ662X8prL1qIRt42IPyKJUIdLvjC8RzfjR5nlSkD
S2ZwHQx9slPEzt9djOTxnuHwQNyiYbG61j5g8VLpPe+wr2b8EtxKYWRMFfcxStRf
hHh7tAS8o2XXF3rneItqyl+lfjBBL29Byg8qC4yehtDkdyT2obptHb8VbpPGw7aZ
2ZQM6cmygRzllro9rMO+b90lDybCwWjKz9jTcSv/7hs1tr5pkfGb6oyh8RMOkaT+
yEryHsXLzZc=
=rrF9
-END PGP SIGNATURE-
--- portage.py 2006-01-15 00:08:06.170717008 -0500
+++ - 2006-01-15 00:22:00.597106000 -0500
@@ -931,17 +931,8 @@
self.use_defs = copy.deepcopy(clone.use_defs)
self.usemask = copy.deepcopy(clone.usemask)
- self.configlist = copy.deepcopy(clone.configlist)
- self.configlist[-1] = os.environ.copy()
- self.configdict = { globals: self.configlist[0],
- defaults: self.configlist[1],
- conf: self.configlist[2],
- pkg: self.configlist[3],
- auto: self.configlist[4],
- backupenv: self.configlist[5],
- env: self.configlist[6] }
+ self.configdict = copy.deepcopy(clone.configdict)
self.profiles = copy.deepcopy(clone.profiles)
- self.backupenv = copy.deepcopy(clone.backupenv)
self.pusedict = copy.deepcopy(clone.pusedict)
self.categories = copy.deepcopy(clone.categories)
self.pkeywordsdict = copy.deepcopy(clone.pkeywordsdict)
@@ -980,11 +971,8 @@
}
self.usemask=[]
- self.configlist=[]
- self.backupenv={}
# back up our incremental variables:
self.configdict={}
- # configlist will contain: [ globals, defaults, conf,
pkg, auto, backupenv (incrementals), origenv ]
# The symlink might not exist or might not be a symlink.
try:
@@ -1043,8 +1031,7 @@
writemsg(!!! Incorrect multiline literals can
cause this. Do not use them.\n)
writemsg(!!! Errors in this file should be
reported on bugs.gentoo.org.\n)
sys.exit(1)
- self.configlist.append(self.mygcfg)
- self.configdict[globals]=self.configlist[-1]
+ self.configdict[globals] = self.mygcfg
self.mygcfg = {}
if self.profiles:
@@ -1062,8 +1049,7 @@
writemsg(!!! not then please report
this to bugs.gentoo.org and, if possible, a dev\n)
writemsg(!!! on #gentoo
(irc.freenode.org)\n)
sys.exit(1)
- self.configlist.append(self.mygcfg)
- self.configdict[defaults]=self.configlist[-1]
+ self.configdict[defaults]=self.mygcfg
try:
# XXX: Should depend on root?
@@ -1078,28 +1064,32 @@
sys.exit(1)
- self.configlist.append(self.mygcfg)
- self.configdict[conf]=self.configlist[-1]
+ self.configdict[conf]=self.mygcfg
- self.configlist.append({})
- self.configdict[pkg]=self.configlist[-1]
+ self.configdict[pkg]={}
#auto-use:
- self.configlist.append({})
- self.configdict[auto]=self.configlist[-1]
+
Re: [gentoo-portage-dev] first pass at --debug-build
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Frysinger wrote: On Thursday 19 January 2006 19:39, Mike Frysinger wrote: here's what i was talking about when i mentioned the mutate() idea tested and it works for me ... binary is built properly and environment.bz2 contains the correct values to speed this along ... how do people care about the FEATURES=debug-build idea in general ? i could commit the first part which implements FEATURES=debug-build in general and then we can fight over how to implement `emerge --debug-build` -mike I'm stuck on this. Part of me wants to see more new features in portage and part of me screams horrible hack :P -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQ9V1cGzglR5RwbyYAQJKDQ/+O4nWZfn+SavwNEm7nxm0mAkRJbuz6Unl PFJfRgjN67p9IFUu5rcbCMxVFUX8TFbCc6skMNl9M1WXiIBYQai2TodHso3uGcfn CVLpl40tCorEvb54UtNN/J+m0QOpEbOgG2QnfAteWD+Di1jAVzEzNSIhbiiY56oH buTdG6YPlsJldKkzE7NAmcco1sjW2lY71DPIulChaENBR1N/WYLfEmM4+BbZpcrs Phel2ILDWqjwrb0Y/XZf5gRtF7KaYmOqZLDo5Ou2SoT9dRtZpGI7Mj4mtdB3WU2k lMmX4zPB4u500wvD6hjC8CqwEr5BWuUOJFgywy7jn6IgfEeD833oQBKslt0asD2R qRwZjg44xn/Ddf76/Fa/azIq0G4U2KWa2gY22pAfRQ++bgHiUQiHsK33VY1fv1Vu Ol/FQQlMvqxtbMRUx5YpLh1ULbEAd5J4IXLmlne1ySv1xadVOV0umu4RUL/tjLc2 ucOr7qNLgBbrECZ+YwW5HyvYgKbrOLlwb3t1mgMbkhjegibcIFCWY/Y+yNbxt/6S xRMUQts6vUb5ACVzrCSeoAYIRyTNUMiEINYkxdSqv8JY3H12c5nE9KVY/lLr79mo HVHMIpkF6Ld/3f1xrCjS1VG9YOUJ4wHY7LSVO+HfusipCYyQTsQ792Alj8dsZ+gX +K1MGtChnBU= =SwCk -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] confcache integration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Harring wrote: Yo. Looking to integrate confcache support into trunk some time in the near future- had users testing it for about 2 months (give or take), so far it's behaved pretty decently. A few packages eat themselves when ran with --cache (bad autotooling), hence the addition of restrict=confcache being added to the patch. Either way, patch is attached, looking for any complaints regarding it (or integrating confcache)- will be sending an email off to gentoo-dev in the next few days to get feedback from the general dev populace,, but sending this email to get feedback on the implementation in the meantime. ~harring I don't see a manpage/make.conf patch in there :) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQ9YzA2zglR5RwbyYAQKCTg/+NtqHZSIrApdkm6+TULFE2W2CIHQD9Vd8 VdLyKaDXOigsK460iZehY1pnxZRA8qes9Ed4H51kWL5HMCO/9FHyUZq2SAYHwQ/M moGMML+XyPanUc9Kvy2JREc/onzCbvPdYXkcJRNuE2XFhrfnKTXWin8JJBqyP7C/ 9S/NItRH+lAE6/1Az/6iJcSto0WscN/W18shwitCUB0igVUYcaBal4W3oJ6SvHEB NtX/xjL6zHTlS1iCsawVXAzgwcvFBNOSWilFobN6Qj2V1cn9a74Pio4axl33pEzK 6Mz4csL/UCZb/RisABOU03i3tTBEnehwgvKaD1BxHVfTUNwr8f9Oc1GdLJoZKlp8 H+4mZ7K82bhJ8CB0io9Zz5FZFUrp2cU2mQCh53vlVHZ2UlH+rAXaCLp2Lm0Fi1yQ 5cYyp0tH4eGNrYBrykZZ/gImaGYhIJ2RR8AETROltzRLk9bXq5dMgvWF2+38DdBI RqJKMYMmHSYJ/Ccp0kLs4G6xhOw5VXpRIdPMOFPOh76szdJX801s8S0ZHWAPcc7q /lkfnc9JwKcLSQIGth0IllEfhe3/OtaZoi+SDV0hIuOwJ0AgesUzNnUIa41pAfW5 npGTImc8kXYSp1JoDyflpUgsY6Cv2w48K96QUTWpj5oOPtu4l2t0wsof0boekFjP BR12OBv/wB4= =cCKG -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] RDEPEND = DEPEND
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yes, more mail from me, excited already aren't you? :) make repoman complain if DEPEND and RDEPEND are not set[1] This was discussed earlier on gentoo-dev and everyone seemed to agree that the check was not needed and that this behavior was good[2]. Then Swegener came out and said it was going away[3]. So I ask, which is it, and if the behavior is going away, why not the check in repoman now ;) - -Alec Warner [1] http://bugs.gentoo.org/show_bug.cgi?id=79337 [2] http://marc.theaimsgroup.com/?l=gentoo-devm=111750102823602w=2 [3] http://marc.theaimsgroup.com/?l=gentoo-devm=112069337425674w=2 [4] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=1#doc_chap5 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQ9rbAWzglR5RwbyYAQKx5w/8DSX7JTflEIHmWCUi2irW9YFnFIsch3IY 1tg6/S3Fzal6zOLMw4hVMSMHaIbfhh1BmYsmRScupW54IRnABtLID9GG9wWqpcYD kuMK9vILHS23v1KdJXQibe1K6BCuxN6A1IDmR7UzgYJgzLPfNLw4QWtTCqINTIri kA1YyF4SdDe927vA3kgLEcE45oiTUZAC+sPg51SF9RrB+oPUa/9MRbBwqTamZWS8 dqdOx6qIsND5pc0bFbayCwuoVIgcahptFy82SwgGTpzb6pGwqxRxiB3GBNtNzEkP 7YUfvMxsU8A2Bm6AVjr8/7rE6RGaZeCXUD5YZq5qO4Zx813N39Wt28+xcCHfhZen /MPsiXiCKCAR9OXWJGqmM+CAvctMdWmBx0X8P35FRu4jzAIKmxkXNUN+0j7D0Ovp TG0wfGawxyEt5Ku0Hu3qi09K6zILhPNJ0Oewk+hf9J3PiIVQgoe0q0Pg1CS9feDI I2xjpJGMfwsiVJvLo1Rmw21GNEbjwdZC9trXcXCYw1hwhMuBeqFTaErho8ndKOBU AsnhvbpVqd3D6pp+abPC9ueOSGlT8RgTNFwojcqItQ2bVeQArah7PHTs5bYJ066R /fo9Xge3d1c8hiLMKgN1I9HyIMg4gQbSzouencYuJOyoyHwd+QmSNhOWYqezKDJA zcPCXjSCFuc= =3b0O -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] --nospinner in emerge_default_opts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Gaffney wrote: William Hubbs wrote: I just ran a test with this again, and it does look like --nospinner is not allowed in emerge_default_opts. If this should be filed as a bug, let me know, or if it isn't a bug, would it be possible to allow this option? If in doubt, file one and if it isn't one we can always close it later. Just double check that you can reproduce the outcome. Is there a reason you can't just alias it? Er, if it's a bug it's a bug ;) Although that is probably a solution in the meantime :) - -Alec Warner (antarus) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQ9wn32zglR5RwbyYAQKMwBAAkMsuOiscuSnOH92/8hpbWljI+bCM2EWz 8RAGv7yJX3CohhmmZLTMWuimJFmrwHuu8eVddZlzVeBacv/oCuu2faP0HenKnejc iXmIW5pGMYDY7W/dy5bW7lPfrU610kV/ePhnnVjSXBL8kpTBVJu56bOcSVQBD0S9 3xDPfzk4Rj0PYJtv+pUtqKjcFsCku2hnEDIa4j1kYbJxJU6acFVrCbaD8VQ1F6Sz nGYbMpWnvv17vhie++i1/HkIZ2QXnyIVxzYudkbMjzYU+Dwyhkts4zvrOQixI3jN OzC8SdNUbjs2BMQ5932DgrroY63aLBKUjNbqKFdeS/sAhXe578kFfLZvI/HVSYK2 WC0ywoeuGZX/ZischYaHfCnOPAtRLwMeLab62/3+e0niuHaN4lvdGXjHTv+dzl4x jUVw5NEUZCgOCNK/aTYmVcx+0OUAQaskRIdINCBqNTuelAAmqo94XfdHqfJKLfve LVoPqS2dQQp9Wj4akQiEVZgihrPtNtaTQS7q7BA2BUJCcGpSyAVmOZ/hHmByd5nJ mSkEBuSr22hLl9xF+BMEZvldw2t7fi3uBczC4fUC81O4jd9fDjqlEpS/o6wdKtUP Q8Z3oanNoP4Ao2seL9ZWx6+H2RnwvwnqwQqRAmkH1BAljpNTtowDdxwooWc81NAW jVJsCbhFYRg= =81H2 -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] IUSE_DEFAULTS-v0.1
Paul de Vrieze wrote: On Tuesday 14 February 2006 13:44, Alec Warner wrote: Well that problem would be, no one wants to modify everything in app-portage/ :). If my portage EAPI is 1, but my tools don't support processing +- in IUSE, how does EAPI help me here? The support check is only for portage_const, so the tool remains fucked. Unless I'm missing something. Tools should also be EAPI aware. I know too many aren't, but that doesn't mean they shouldn't be. Paul I guess my point here is, last I checked we can't pass an EAPI less than portage_const.EAPI. In this example, say portage's EAPI is at 2, but my tool only handles EAPI 0, there is no way to set this in portage so I get EAPI 0 results. So perhaps we need this implemented as well. -Alec signature.asc Description: OpenPGP digital signature
[gentoo-portage-dev] Portage-2.1_pre5
Zac Medico has graciously done a pre5 release of the 2.1 tree and placed it in his dev space and on the mirrors. The ebuild is not currently in the portage tree, but please feel free to test it prior to it's actual release. The intent here is to hopefully catch any show stopping bug prior to it's 'actual' release. It is my estimation that a lot more users are running ~arch portage due to cache issues as well as added features ( confcache, parallel-fetch, etc ). The ebuild is at [1]. The tarball should be on the distfiles shortly, but if not the ebuild will fetch from Zac's devspace. Your testing is appreciated. [1]http://dev.gentoo.org/~zmedico/overlay/sys-apps/portage/portage-2.1_pre5.ebuild -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Portage-2.1_pre5
Paul Varner wrote: On Tue, 2006-02-21 at 20:07 -0500, Alec Warner wrote: Your testing is appreciated. I'll file a bug for this one, once I investigate further. 'genlop -t' doesn't get along with it very well. # genlop -t screen * app-misc/screen snip Thu Dec 15 23:10:28 2005 app-misc/screen-4.0.2-r4 merge time: 1 minute and 11 seconds. Wed Feb 22 13:11:30 2006 app-misc/screen-4.0.2-r4 merge time: 5 days, 14 hours, 2 minutes and 13 seconds. Wed Feb 22 13:16:04 2006 app-misc/screen-4.0.2-r4 merge time: 5 days, 14 hours, 6 minutes and 47 seconds. Wed Feb 22 13:16:47 2006 app-misc/screen-4.0.2-r4 merge time: 5 days, 14 hours, 7 minutes and 30 seconds. The last three emerges were done with 2.1_pre5 where I was testing the effects of enabling confcache I did make some minor grammar changes to the log output that could cause odd times. Other than that, no clue on this one. Regards, Paul -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] Config Cleanup Last Call
Please review for badness, otherwise I'll commit this soon ;)
--- portage.py 2006-01-15 00:08:06.170717008 -0500
+++ - 2006-01-15 00:22:00.597106000 -0500
@@ -931,17 +931,8 @@
self.use_defs = copy.deepcopy(clone.use_defs)
self.usemask = copy.deepcopy(clone.usemask)
- self.configlist = copy.deepcopy(clone.configlist)
- self.configlist[-1] = os.environ.copy()
- self.configdict = { globals: self.configlist[0],
- defaults: self.configlist[1],
- conf: self.configlist[2],
- pkg: self.configlist[3],
- auto: self.configlist[4],
- backupenv: self.configlist[5],
- env: self.configlist[6] }
+ self.configdict = copy.deepcopy(clone.configdict)
self.profiles = copy.deepcopy(clone.profiles)
- self.backupenv = copy.deepcopy(clone.backupenv)
self.pusedict = copy.deepcopy(clone.pusedict)
self.categories = copy.deepcopy(clone.categories)
self.pkeywordsdict = copy.deepcopy(clone.pkeywordsdict)
@@ -980,11 +971,8 @@
}
self.usemask=[]
- self.configlist=[]
- self.backupenv={}
# back up our incremental variables:
self.configdict={}
- # configlist will contain: [ globals, defaults, conf,
pkg, auto, backupenv (incrementals), origenv ]
# The symlink might not exist or might not be a symlink.
try:
@@ -1043,8 +1031,7 @@
writemsg(!!! Incorrect multiline literals can
cause this. Do not use them.\n)
writemsg(!!! Errors in this file should be
reported on bugs.gentoo.org.\n)
sys.exit(1)
- self.configlist.append(self.mygcfg)
- self.configdict[globals]=self.configlist[-1]
+ self.configdict[globals] = self.mygcfg
self.mygcfg = {}
if self.profiles:
@@ -1062,8 +1049,7 @@
writemsg(!!! not then please report
this to bugs.gentoo.org and, if possible, a dev\n)
writemsg(!!! on #gentoo
(irc.freenode.org)\n)
sys.exit(1)
- self.configlist.append(self.mygcfg)
- self.configdict[defaults]=self.configlist[-1]
+ self.configdict[defaults]=self.mygcfg
try:
# XXX: Should depend on root?
@@ -1078,28 +1064,32 @@
sys.exit(1)
- self.configlist.append(self.mygcfg)
- self.configdict[conf]=self.configlist[-1]
+ self.configdict[conf]=self.mygcfg
- self.configlist.append({})
- self.configdict[pkg]=self.configlist[-1]
+ self.configdict[pkg]={}
#auto-use:
- self.configlist.append({})
- self.configdict[auto]=self.configlist[-1]
+ self.configdict[auto]={}
#backup-env (for recording our calculated incremental
variables:)
- self.backupenv = os.environ.copy()
- self.configlist.append(self.backupenv) # XXX Why though?
- self.configdict[backupenv]=self.configlist[-1]
+ self.configdict[backupenv]=os.environ.copy() # XXX
Why though? ( ferringb? )
- self.configlist.append(os.environ.copy())
- self.configdict[env]=self.configlist[-1]
+ ### backupenv maybe required to be a clone, and not
just a reference
+ ### the old code did value copy we do a reference here
+ self.configdict[env]=self.configdict[backupenv]
# make lookuplist for loading package.*
- self.lookuplist=self.configlist[:]
- self.lookuplist.reverse()
+ # This may look like USE_ORDER, it has nothing to do
with it.
+ # Instead this is the way that __getitem__ lookups are
performed
+ # So env first, then backupenv, the auto, pkg, conf,
defaults...etc.
+ self.lookuplist=[self.configdict[env],
Re: [gentoo-portage-dev] Config Cleanup Last Call
Jason Stubbs wrote: On Saturday 25 February 2006 10:40, Alec Warner wrote: Please review for badness, otherwise I'll commit this soon ;) - self.backupenv = os.environ.copy() - self.configlist.append(self.backupenv) # XXX Why though? - self.configdict[backupenv]=self.configlist[-1] + self.configdict[backupenv]=os.environ.copy() # XXX Why though? ( ferringb? ) Kill this comment altogether. Reading it, my first thought is why what? It doesn't make the code clearer and so shouldn't be there. - self.configlist.append(os.environ.copy()) - self.configdict[env]=self.configlist[-1] + ### backupenv maybe required to be a clone, and not just a reference + ### the old code did value copy we do a reference here + self.configdict[env]=self.configdict[backupenv] Again, this comment doesn't make the code clearer and so shouldn't be there. Changing functionality in a cleanup patch is also bad form. As for the change itself, it's broken. Look at __setitem__() and reset() and then look at the usage of those two throughout the code. - mydbs=self.configlist[:-1] + #Abuse the order of lookuplist to emulate old behavior + mydbs=self.lookuplist[:-1] Same deal with this comment. A person seeing the code for the first time has no idea what the old behaviour was. In the old code, configlist starts with globals and ends with env. In the new (and old) code, lookuplist is the reverse of that. I don't see any further changes to account for this. - if 0 and match and mykey in [PORTAGE_BINHOST]: - # These require HTTP Encoding ... This shouldn't be in a cleanup patch either. Er, may I ask why it's in the code at all? :) -- Jason Stubbs signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] Questions regarding the new portage API (savior branch)
Marius Mauch wrote: Does that mean we should drop the SVN branch? Marius I've already removed it from the documentation and added links to Brian's current work on ge.org. As far as the actual repo, I think keeping it around a bit longer might be beneficial, but who knows. signature.asc Description: OpenPGP digital signature
[gentoo-portage-dev] ExtractKernelVersion
The kernel ( along with QA ) has reported that the portage generated $KV is sometimes quite horribly wrong. They would like us to retire the kernel generated $KV, ebuilds that need $KV should inherit linux-info, unless they are themselves a kernel-module, in which case they should inherit linux-mod. This also consolidates all the kernel version parsing nastiness into 1 place ( the eclass ) which means less work for us! The QA team will run testing against the tree to locate incorrect uses of $KV, granted the KV value is probably wrong right now for some users, we still need to migrate them over. We may need to retain the $KV variable for EAPI 0 portage, but I think that could actually depend on how bad the migration really is. -Antarus signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] Few things, which imho would make portage better
tvali wrote: Ok, i send a lot of them, but hopefully they're interesting :) I would like to build sql table-structure after getting the information and send it into this list here so that you could hek out if it has something missing or poorly optimized. PS. i dont like rules of database normalizing, so my strutures usually have some hacks in them -- i hope that noone complains about that; normalized structures are just dull and optimized only for dumb-user-human-readability, which is imho not the biggest virtue of software code. Uhhh you don't like normalizing your schemas? Normalizing does two things, reduces redundant data, and increases database speed as tables are designed in a manner that minimalizes merging time. Running with a schema you pulled out of your ass is likely to give poor database performance. -Alec Warner signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] DB and binary dependency
tvali wrote: Can someone tell me, which portage python commands should be used or which kind of file created, if i'm going to test this idea? -- in beginning, i would like to just add simple deps - are ebuilds the only place to change and is there any clear doc of them [as i wouldnt like to go through them all to be sure that there is no rarely used things i dont know]? Also, where i can find relations between useflags and c/c++ #defines? USE flags technically have anything to do with C++ defines; they can technically enable/disable any optional support ( docs, plugins, etc.. ) Usually USE flags interact with a packages build system (configure or whatnot) Dependencies are only in DEPEND, RDEPEND,PDEPEND. -- tvali Measuring programming progress by lines of code is like measuring aircraft building progress by weight. -Bill Gates For every complex problem there is an answer that is clear, simple, and wrong. -H L Mencken Theory is when you know something, but it doesn't work. Practice is when something works, but you don't know why. Programmers combine theory and practice: Nothing works and they don't know why. http://www.eskimo.com/~hottub/software/programming_quotes.html http://www.softwarequotes.com/ -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] Repoman Help Extraction
+# Alec Warner [EMAIL PROTECTED] 2006
+
+from output import *
+import string
+
+allowed_filename_chars=a-zA-Z0-9._-+:
+version=1.2
+
+ Repoman's short action modes
+shortmodes={ci:commit}
+
+ Help for each of Repoman's action modes
+modeshelp={
+scan : Scan directory tree for QA issues (default),
+fix: Fix simple QA issues (stray digests, missing digests),
+full : Scan directory tree for QA issues (full listing),
+help : Show this screen,
+commit : Scan directory tree for QA issues; if OK, commit via cvs,
+last : Remember report from last run,
+lfull : Remember report from last run (full listing)
+}
+
+ Repoman options
+repoman_options={
+--commitmsg : Adds a commit message via the command line,
+--commitmsgfile : Adds a commit message from the specified file,
+--help : Show this screen,
+--ignore-arches : Ignore arch-specific failures (where arch != host),
+--include-masked : Include masked packages in scans at category or tree
level,
+--pretend: Don't commit or fix anything; just show what would be
done,
+--quiet : Be less verbose about extraneous info,
+--verbose: Displays every package name while checking,
+--version: Show version info,
+--xmlparse : Forces the metadata.xml parse check to be carried out
+}
+
+ Repoman Short Options
+repoman_shortoptions={
+-h : --help,
+-i : --include-masked,
+-I : --ignore-arches,
+-m : --commitmsg,
+-M : --commitmsgfile,
+-p : --pretend,
+-q : --quiet,
+-v : --verbose,
+-V : --version,
+-x : --xmlparse
+}
+
+
+ Map short QA Error messages to associated string objects
+qahelp={
+ CVS/Entries.IO_error:Attempting to commit, and an IO error was
encountered access the Entries file,
+ digest.partial:Digest files do not contain all corresponding URI
elements,
+ digest.assumed:Existing digest must be assumed correct (Package
level only),
+ digestentry.unused:Digest/Manifest entry has no matching SRC_URI
entry,
+ digest.fail:Digest does not match the specified local file,
+ digest.stray:Digest files that do not have a corresponding ebuild,
+ digest.missing:Digest files that are missing (ebuild exists, digest
doesn't),
+ digest.disjointed:Digests not added to cvs when the matching ebuild
has been added,
+ digest.notadded:Digests that exist but have not been added to cvs,
+ digest.unmatch:Digests which are incomplete (please check if your
USE/ARCH includes all files),
+ ebuild.invalidname:Ebuild files with a non-parseable or
syntactically incorrect name (or using 2.1 versioning extensions),
+ ebuild.namenomatch:Ebuild files that do not have the same name as
their parent directory,
+ changelog.missing:Missing ChangeLog files,
+ ebuild.disjointed:Ebuilds not added to cvs when the matching digest
has been added,
+ ebuild.notadded:Ebuilds that exist but have not been added to cvs,
+ changelog.notadded:ChangeLogs that exist but have not been added to
cvs,
+ filedir.missing:Package lacks a files directory,
+ file.executable:Ebuilds, digests, metadata.xml, Manifest, and
ChangeLog do note need the executable bit,
+ file.size:Files in the files directory must be under 20k,
+ file.name:File/dir name must be composed of only the following
chars: %s % allowed_filename_chars,
+ file.UTF8:File is not UTF8 compliant,
+ KEYWORDS.missing:Ebuilds that have a missing or empty KEYWORDS
variable,
+ KEYWORDS.stupid:Ebuilds that use KEYWORDS=-* instead of
package.mask,
+ LICENSE.missing:Ebuilds that have a missing or empty LICENSE
variable,
+ DESCRIPTION.missing:Ebuilds that have a missing or empty DESCRIPTION
variable,
+ SLOT.missing:Ebuilds that have a missing or empty SLOT variable,
+ HOMEPAGE.missing:Ebuilds that have a missing or empty HOMEPAGE
variable,
+ DEPEND.bad:User-visible ebuilds with bad DEPEND settings (matched
against *visible* ebuilds),
+ RDEPEND.bad:User-visible ebuilds with bad RDEPEND settings (matched
against *visible* ebuilds),
+ PDEPEND.bad:User-visible ebuilds with bad PDEPEND settings (matched
against *visible* ebuilds),
+ DEPEND.badmasked:Masked ebuilds with bad DEPEND settings (matched
against *all* ebuilds),
+ RDEPEND.badmasked:Masked ebuilds with RDEPEND settings (matched
against *all* ebuilds),
+ PDEPEND.badmasked:Masked ebuilds with PDEPEND settings (matched
against *all* ebuilds),
+ DEPEND.badindev:User-visible ebuilds with bad DEPEND settings
(matched against *visible* ebuilds) in developing arch,
+ RDEPEND.badindev:User-visible ebuilds with bad RDEPEND settings
(matched against *visible* ebuilds) in developing arch,
+ PDEPEND.badindev:User-visible ebuilds with bad PDEPEND settings
(matched against *visible* ebuilds) in developing arch,
+ DEPEND.badmaskedindev:Masked ebuilds with bad DEPEND settings
(matched against *all* ebuilds) in developing arch
[Fwd: Re: [gentoo-portage-dev] 2.1 release candidate soon?]
Sorry, send with wrong address earlier. Original Message Subject: Re: [gentoo-portage-dev] 2.1 release candidate soon? Date: Thu, 06 Apr 2006 20:09:06 -0400 From: Alec Warner [EMAIL PROTECTED] To: gentoo-portage-dev@lists.gentoo.org References: [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, I think the current quality level of the 2.1 branch is good enough to make it a release candidate. From my perspective, it seems like a waste of everyone's time to roll a 2.0.55 release when 2.1 is a perfectly good replacement (with lots of bug fixes relative to 2.0.54). (Pardon if this looks weird, Thunderbird is doing all kinds of weird things to this E-mail) Vapier in particular has backported some changes into the 2.0.54 tree with I assume hopes to make a 2.0.55 release. The 2.1 release is a large change over the 2.0 series, I'd like to give people a bit more time on 2.0. For a while this may mean 2.0 and 2.1 stable at the same time, although there is no harm in that either. We haven't had a new 2.0 release in a while, and there are features worth backporting IMHO. Remember that while most of the development community runs portage-2.1 many of the users do not; and they have not seen a 2.0 release in some time. I think we can stable 2.0.55 faster than 2.1, as 2.1 will probably need a series of _rc releases before being considered stable. -Alec Warner (antarus) -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] 2.1 release candidate soon?
Zac Medico wrote: This kind of thing will be less of a problem if we shorten the period of the release cycle. If we shorted it to 2 months or so, then it won't matter much when something gets bumped to the next cycle. Also this isn't exactly news to you all as I sent my intentions already a while ago, and last I asked you all agreed with them, so is there any reason to rush this now? Like I've said above, I'm annoyed by the length of this release cycle. The gap between 2.0.x and 2.1 has grown so large that a 2.0.55 release seems (in my mind) like beating a dead horse. The way I see it, a shorter release cycle is needed so that bug fixes are released in _stable_ versions sooner. Zac See my problem is that some of the features proposed aren't two month testing features. Particularly when you rewrite decent portions of the application you need longer than two months to get decent testing coverage. Sure Unit Tests are helpful for that too, but they don't cover all cases and really the best testing platform is to let the people who play with portage do the testing and get some real results prior to release. The great thing about 2.1 is that *everyone* uses it. Of course they use it because it's better, which may not necessary be the case for future versions. We have a new cache format, confcache, parallel fetch, etc... The bonus is these features are already mature and relatively old ( a year + as of now ). -Alec -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] 2.1 release candidate soon?
Brian Harring wrote: On Fri, Apr 14, 2006 at 05:15:53PM +0200, Philipp Riegger wrote: On Apr 7, 2006, at 5:26 PM, Alec Warner wrote: We have a new cache format, confcache, parallel fetch, etc... The bonus is these features are already mature and relatively old ( a year + as of now ). Reading about confcache i have one question: When i saw, that this feature exists (in make.examples) i activated it. But it did not work because i had not emerged confcache. I think this check should be stricter, if i want confcache and have FEATURES=confcache and confcache is not emerged, i think emerge ... should die, not just say Ok, you said you want it but you don't have it, so i don't use it. What do you think about that? Precedent is against you in this case...sandbox is the same way (notify instead of bailing). Personally I prefer the if I told you to do something, bail if you can't approach, but for features portage has usually done the opposite. ~harring Meh, past behavior is not really a great excuse here. If the majority thinks it sucks, then it can always be changed. -Alec -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Outstanding decisions
Simon Stelling wrote: Hey all, I'm just wading through a list of ~200 bugs of which some need decisions what should be done, whether it should be done at all or simply whether it is a bug or not. Bug: SRC_URI: spaces not supported http://bugs.gentoo.org/show_bug.cgi?id=102607 Is this a 'NOTABUG' case? Need to check the SRC_URI documentation, if it's noted there, then close it, if its not noted in the docs, add that spaces are not allowed and close it ;) Bug: gpg: strict incorrectly takes priority over severe http://bugs.gentoo.org/show_bug.cgi?id=68906 What's the expected behaviour? Is it NOTABUG? Bug: Method to monitor a package without installing/upgrading it http://bugs.gentoo.org/show_bug.cgi?id=47456 Same thing. Do we want this? Alternative tool. Bug: Support for a pre-compile pkg_config http://bugs.gentoo.org/show_bug.cgi?id=99529 As Jason mentioned: Is this worth the effort? Effort is minimal, but I'm unsure of the real usefulness. Bug: per profile package.keywords http://bugs.gentoo.org/show_bug.cgi?id=55321 Voting seems to be a bit... incomplete ;) This is down to a design issue. package.keywords is a repository control measure, do we currently allow profiles to mess with repos? Only via use.mask at present. profile mangling of a repository is difficult when multiple repositories are brought in because we really don't have any type of repo binding in the current source. I personally think it's an important feature, but it's difficult to not implement it in a half assed manner. Bug: Wording These are the packages that I would merge, in order: http://bugs.gentoo.org/show_bug.cgi?id=112439 This needs a decision too. What wording do we prefer? Either way, the bug should be closed, the fix is trivial in case we want to change it. Ummm someone just make a decision, I don't think it's that big a deal. Bug: global exception handling http://bugs.gentoo.org/show_bug.cgi?id=28535 Should tracebacks be thrown in the users' face or not? Yes, Not saying you shouldn't write code that catches exceptions and all that but writing stupid code that catches any exception and then tries to print some useful info is...not as useful. I'd prefer to have documented a bit more what functions throw ( docstrings )? so that when users use portage functionality they know what to catch. Bug: /usr/lib/portage/bin/clean_locks documentation example could make use use DISTDIR http://bugs.gentoo.org/show_bug.cgi?id=116676 Call portageq or not? Voting time ;) nfc :0 That should be enough for the moment. More will probably follow, considering that I only checked the first 60 bugs or so :/ It would be nice if we could make the needed decision and then close the bugs where it is NOTABUG/INVALID/LATER. I hate stale bug listings ;) -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Outstanding decisions
Simon Stelling wrote: Next bunch of bugs that need a decision: Bug: portage: emerge unmerge ... should stop in case of an error http://bugs.gentoo.org/show_bug.cgi?id=118515 Another WONTFIX/WILLFIX issue Bug: need a way to package.unmask packages in profiles http://bugs.gentoo.org/show_bug.cgi?id=118440 Is this LATER? Alec mentioned a patch, but i couldn't find it when grepping through my archives, and nothing is attached to the bug. The patch was because it was thought to be broken; instead it's outright not allowed currently ;) It's another one of those should the profiles modify a repository and if so how do you bind the changes to a specific repository questions. Bug: emerge/ebuild - a bit more verbosity please http://bugs.gentoo.org/show_bug.cgi?id=67892 This obviously lacks any discussion. RFC :) I was poking at how to document bash without quite telling people, hey if you want to know what it does, read the source. However bash doesn't auto-document well ;) Bug: Support for src_test deps required http://bugs.gentoo.org/show_bug.cgi?id=69021 WONTFIX/WILLFIX? Bug: no documentation on the elog functions http://bugs.gentoo.org/show_bug.cgi?id=116018 AFAICS it's documented in make.conf.example and man make.conf, but the user requested a howto. Is a howto really needed? IMHO it's not that complex... Bug: Split CONFIG_PROTECT into separate installing and uninstalling options (nuke untouched files) http://bugs.gentoo.org/show_bug.cgi?id=8423 The classical one with a huge CC list. Whatever decision is made, this finally needs to get (fixed and) closed. -- gentoo-portage-dev@gentoo.org mailing list
Portage Features That Depend on Binaries [WAS: Re: [gentoo-portage-dev] Re: Re: 2.1 release candidate soon? ]
Philipp Riegger wrote:
On Apr 15, 2006, at 6:10 PM, Duncan wrote:
But i really think this is not about helping but about confusion. If i
post my emerge --info you don't know if i really use confcache even
if i
have FEATURES=confcache, because emerge --info does not say if i have
emerged confcache and, if i have emerged it, which version it is. I
think
this should also be listed in emerge --info.
Very good point.
Should i file a bug on this?
Philipp
Nope, lets bring it to -dev ( yay crossposting )
The issue for those on the -dev ML, is that portage has some features
that require binaries ( sandbox, ccache, confcache ) and so you need two
things for them to work. You need FEATURES={sandbox,ccache,confcache}
and you need each package installed. The FEATURES line is already
printed. sandbox is already in info_pkgs.
Is there any problem with adding dev-util/confcache and dev-util/ccache
to info_pkgs?
--
gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Re: r3200 - main/trunk/bin
Mike Frysinger wrote: On Sunday 23 April 2006 12:36, Alec Warner wrote: Modified: main/trunk/bin/sed Log: Make sed wrapper not executable. why ? it isnt hurting anything to be set executable -mike At present it is not in the pre9 tarball. However it is in SVN, so it will make it into the tarball eventually. Since it's in /bin it will get installed with all the other binaries. However it's a !GNU only sed wrapper, so in this case once it is added to the tarball it will be installed on all systems, but set +x only on non GNU systems. We can move it somewhere else if you like. We just had a couple of fun issues with people who use portage from SVN, so I figured I'd try to avoid those and plan towards the future ;P -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Re: Refactoring of emerge code
Is there any chance you can break this up? Mostly one patch for each * below? OTherwise it's rather large ( 1000 lines ) and is difficult to figure out what/when/where happened m h wrote: Upon further testing, I'm updating a line in the patch On 4/28/06, m h [EMAIL PROTECTED] wrote: Folks- I'm submitting a patch of a refactoring of the emerge code in 2.1_pre9-r5. This patch adds no features per se. But I believe it makes the code much more readable. This only addresses the /usr/lib/portage/bin/emerge file. It does the following: * attempts to remove all global variables (with the exception of the spinner animation) * breaks up the heinous 900 lines of code at the bottom of the file into: * a __main__ section that calls out to * do_SOMETHING where something is (depclean, search, info, config, etc) * removes any code that was dangling at the leftmost side of my editor and puts it under the __main__ section * removes an olddbapi variable that isn't used I've tested it with the sync, remove, search, update and it appears to work. Any feedback is welcome. I hope that this gets in for a few reasons. I'm helping out with doing some work on the PREFIX branch, having the code unstructured makes it really hard to follow (hopefully it can get into trunk so I don't need to patch prefix, everytime it's updated). One of my coworkers just started adding some functionality to emerge (he'll send his patches in soon), but this is really his first week using python, and I don't want this to leave a bad taste in his mouth ;) -matt -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Re: Refactoring of emerge code
I'm more concerned with the revamp of Global vars in one commit, and then the re-arrangement in the other. m h wrote: Yes, I can break it up, but it will probably be 3 one line changes and one big 1000 line change. The 1000 line change is pretty straightforward. The only real code changes per se are removing any default logic (and placing it under the __main__ section). Let me see what I can do... I also messed around with pylint and pychecker today and they both caught some dead code (imports/parameters/variables not being used). I'd like to make this another patch as well. I noticed that this patch won't apply to the new portage (pre10 broke it). Should I be working against that or different code (from the cvs tree perhaps)? (I'd like to get a patch in that people can try before it becomes outdated). On 4/29/06, Alec Warner [EMAIL PROTECTED] wrote: Is there any chance you can break this up? Mostly one patch for each * below? OTherwise it's rather large ( 1000 lines ) and is difficult to figure out what/when/where happened m h wrote: Upon further testing, I'm updating a line in the patch On 4/28/06, m h [EMAIL PROTECTED] wrote: Folks- I'm submitting a patch of a refactoring of the emerge code in 2.1_pre9-r5. This patch adds no features per se. But I believe it makes the code much more readable. This only addresses the /usr/lib/portage/bin/emerge file. It does the following: * attempts to remove all global variables (with the exception of the spinner animation) * breaks up the heinous 900 lines of code at the bottom of the file into: * a __main__ section that calls out to * do_SOMETHING where something is (depclean, search, info, config, etc) * removes any code that was dangling at the leftmost side of my editor and puts it under the __main__ section * removes an olddbapi variable that isn't used I've tested it with the sync, remove, search, update and it appears to work. Any feedback is welcome. I hope that this gets in for a few reasons. I'm helping out with doing some work on the PREFIX branch, having the code unstructured makes it really hard to follow (hopefully it can get into trunk so I don't need to patch prefix, everytime it's updated). One of my coworkers just started adding some functionality to emerge (he'll send his patches in soon), but this is really his first week using python, and I don't want this to leave a bad taste in his mouth ;) -matt -- gentoo-portage-dev@gentoo.org mailing list -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] Breakout etc-update, dispatch-conf
A bunch of bugs have been fixed with both of these lately, anyone against splitting them out, please speak up now, otherwise I will split them out later this week and portage will depend on some nasty virtual whose name I have not come up with yet ( new style virtual ). -Antarus -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] Stablizing portage 2.1
Per some discussion on IRC, I am bring stablizing 2.1 at the pre9 or pre10 branch to the table. Reasons for doing so include: 2006.1 - They say if 2.1 is to be in 2006.1, mid-july Xorg Modular - They cannot stable xorg modular until 2.1 is stable FreeBSD - Their entire port depends on features and bugfixes in the 2.1 series Feature use - People are already running/using features in 2.1 to the point where we have had to backport features and do -rX releases of a dead codebase ( 2.0.54 ) For these reasons I request we release pre9 as an rc canidate, set a feature freeze, and then stable it. During this a 2.2 branch can be created for future development with this codebase. Why Branch at 2.1_pre9? Manifest2 is already in the tree and needs refinement. Branching at pre7 is also a canidate, but i would rather press for keeping manifest2 in the tree and fixing up it's code instead. TimeLine: If all goes well, we can do an rc sometime this week: May 3rd : RC1 May 6th : RC2 May 9th : RC3 May 12th : RC4 May 15th : RC5 May 18th : RC6 May 21st : RC7 May 24th : RC8 May 27th : RC9 ( if needed ) May 30th : RC10 ( if needed ) June 5th : ~arch sys-apps/portage-2.1 July 6th : sys-apps/portage-2.1 Problems: We may miss the timeline and thats ok. Releng wants a working portage, not a bugging POS portage-2.1 that wasn't ready for release. This timeline is relatively tight and I think it's a nice goal to set, it's not imperative that we reach it. Comments, Questions, opinions? -Alec -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Stablizing portage 2.1
Zac Medico wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alec Warner wrote: Marius Mauch wrote: Alec Warner schrieb: Why Branch at 2.1_pre9? Manifest2 is already in the tree and needs refinement. Branching at pre7 is also a canidate, but i would rather press for keeping manifest2 in the tree and fixing up it's code instead. Why not pre10? Because pre10 seems to introduce repoman problems that haven't been solved and I've like to break out the RC's soon. Zmedico did a lot of things with usage of global variables, however I think that getting all that tested ( especially in scripts that we don't keep track of ) is detremental to getting portage stable. I agree that it's an important step; however it's just code cleanup. It is not necessary for 2.1. I'm looking at the diff from pre9 and pre10, and I will backport any bugfixes if that makes everyone happy. In my cleanup of globals I took special care to maintain backward compatibility. I have mr_bones_ and halcyon doing profiling to track down the cause of the repoman performance issue. It should be a simple fix when we find the problem. Zac As most people would expect you to, however there are no regression tests to prove you succeeded other than just having people test it. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEVopv/ejvha5XGaMRAhrRAJ9dReE2iwweLKxVo9Dfrju31TbWWQCg6BE1 7uPAXHMr/2zjezpMSTM1lrY= =RX9M -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] secpass=1 and wheel
# Portage has 3 security levels that depend on the uid and gid of the main # process and are assigned according to the following table: # # Privileges secpass uidgid # normal 0anyany # group 1anyportage_gid # super 20 any # # If the wheel group does not exist then wheelgid falls back to 0. # If the portage group does not exist then portage_uid falls back to wheelgid. if uid==0: secpass=2 try: wheelgid=grp.getgrnam(wheel)[2] if (not secpass) and (wheelgid in os.getgroups()): secpass=1 secpass=1 is for being in the portage group...what difference does wheel make? fex, permissions on /usr/portage/distfiles are drwxrwsr-x 4 root portage 20480 May 12 10:56 /usr/portage/distfiles/ so with secpass 1 I should be able to fetch, but can't because I'm in wheel and not portage. So I send this mail with the question am I missing something? -Alec -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [PATCH] Update www-apache/mod_jk to 1.2.15
Paul Dlug wrote: On 6/6/06, *Grant Goodyear* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Paul Dlug wrote: The following patch upgrades www-apache/mod_jk to 1.2.15 (current latest available version in portage is 1.2.13 which has numerous evil bugs). This is my first submission so I wasn't sure if attached patches are preferred to inline ones (or vice versa). Let me know if there's any other recommended submission techniques. Oops, this list is for portage (the package manager) development, not for the portage tree (the ebuilds, eclasses, etcetera found in /usr/portage). Issues with the latter (such as an update to mod_jk) should be filed on bugs.gentoo.org http://bugs.gentoo.org. (I know, it's a patch, not a bug, but we use bugzilla for all of those sorts of things.) Thanks for the info, I'll submit it in Bugzilla, someone should really correct the info on the portage page in the Submitting Patches section: http://www.gentoo.org/proj/en/portage/ Thank you for your input, I've updated the site to hopefully make it a bit more clear which patches go here, and which go on bugs.gentoo.org Another newbie question: is there an equivalent of the FreeBSD Porters Handbook for portage? Something that covers how to create ebuild files and general guidelines for USE flags? Thanks, Paul -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Manifest verification
Now I get it. So could somebody add a line to make.conf.example that says which features are on by default? I didn't notice strict was on. We can't tell you that, FEATURES are stacked, first make.defaults, and then from your profile setting; aka the default FEATURES are only known at runtime ;) Look at your emerge --info output. -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [PATCH] per-package use.mask (bug 96368)
Since you're sliding this in, why not slide it in using use dep syntax? No, not going to fight over this not being in package.mask, what I'm saying is this _is_ masking of a use dep atom, just use use dep syntax in the file instead. If y'all get use deps, it'll be a bit simpler for folks to support then the existing crappy format used imo. Plus, parsing it's easy. ~harring Because as you've noted a thousand times, use deps are hard, and this is easy and inevasive. -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] has_version and built_with_use ignore package.provided
Paul Bredbury wrote: Hi, I was directed to this list after my Portage patches were rejected. I'm hoping that someone *other* than the rejecter will look at the bug, and: See it as a valid bug, reopen it, and take SpanKY's keyboard away so he can't reject it again. The bug is: http://bugs.gentoo.org/show_bug.cgi?id=139842 Executive Summary: built_with_use returns the opposite answer to what it should, when the package referred to is not installed. I provided patches to stop that broken behaviour. People decided to talk about some mystical third state which doesn't exist in Boolean logic, and ended up convinced that black is white. And then proceeded to get themselves run over at the next Zebra crossing. As I said on irc, you need to chill out; being a dick here won't help you anymore than it did there. -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] has_version and built_with_use ignore package.provided
Paul Bredbury wrote: There is a third option. Reporting an error. But it is not an error. The answer is known to be False, through the application of logic. There are really 3 states here Either you have enough information to prove something true; OR you have enough information to prove something false; OR you don't have enough information to prove anything. In this case there is no USE information available for PROVIDE'd packages, which was your original complaint. Just because you can't prove that built_with_use provided pkg foo == true doesn't mean you have enough information to prove that built_with_use provided pkg foo == false Becauase there IS a third state, it's call the we don't have enough information to prove anything state, which is what we have here. The package may very well work fine, the package may not, there is no way to tell. Thats our whole point. Hell, SpanKY already filed the real bug, which is requesting support for provided packages so that you can provide a package with USE flags set, therefore solving this whole lack of information issue. Because you see, that is what the real issue is, a lack of information. -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [PATCH] use.force and package.use.force (bug #142853)
Zac Medico wrote:
Users can unforce them via /etc/portage/profile/{use.force,package.use.force}
in the usual -flag way.
Why new files? Why isn't this just pushed into the use stacking order
over-ridable by the user (default USE flags, and not forcing)?
Then they can over-ride it in package.use just like they do now?
Brian, default USE in IUSE is not a backwards compatable change and this
is easier ;)
/me runs
--
gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [PATCH] use.force and package.use.force (bug #142853)
Zac Medico wrote:
Alec Warner wrote:
Zac Medico wrote:
Users can unforce them via
/etc/portage/profile/{use.force,package.use.force} in the usual -flag
way.
Why new files? Why isn't this just pushed into the use stacking order
over-ridable by the user (default USE flags, and not forcing)?
Much like use.mask, which is for flags that almost certainly should _not_ be
enabled, use.force is for flags that almost certainly _should_ enable.
Then they can over-ride it in package.use just like they do now?
Again, it's akin to use.mask, and protects the user from accidentally doing
something that they almost certainly shouldn't do (though they have the
option to override it if absolutely necessary).
Zac
hrm, so not default use flags then.
--
gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] Portage Sets
So I have implemented merging of sets (more or less) in a local portage
branch. However there are some use cases for which the appopriate
action is ambiguous.
Use Case #1:
Set1 = { postfix, gentoolkit, lsof, bind-utils, vixie-cron }
A set of standard tools to be on a machine. Assume a new install (ie
none of the packages in Set1 are installed). Is it an error if one of
the packages in the set is masked or unavailable? In this case I would
say yes; if you instead just skip the masked package (say postfix in
this case because it's convenient ) vixie-cron will pull ssmtp instead
of postfix.
Of course this will also occur if postfix is after vixie-cron in the
set; but for our purposes we will assume the administrator put them in
this order such that postfix will get pulled in.
One could also say that the user should have used emerge -pv set1 and
noticed that ssmtp is being pulled in instead of postfix.
Use Case #2:
Set1 = cat /var/lib/portage/world (the world set)
Assume the world file has 100 packages in it, two which are masked, and
three of which there are no ebuilds in the tree for. If missing
packages cause an error (which in use case 1 they should imho) then the
user cannot update world without unmasking things properly. The
packages for which ebuilds are missing in the tree is in fact a portage
bug(I think), and will probably need to be fixed.
Other use cases for sets would be appreciated, as far as behavior. It
would probably be best to provide some sort of switch.
Unmerging sets is also a fun one, I'm not sure if it's entirely
appropriate yet.
--
gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [PATCH] Repoman SVN support
Fabian Groffen wrote: Hi all, Please find attached the patch of the prefix repoman sources against the current trunk. I hope I removed all hunks that have prefix-only changes. You realize I wrote generic SCM support into repoman over the summer right? :P It was never merged (afaik I slacked on it, but also because it uses Popen and you pesky OSX folks are stuck on python2.3, so I need to convert to portage.spawn). However the support was generic, so for pretty much any system that 'is kinda like cvs/svn' should work fine with a few tweaks to the exec mapping. biasThis of course excludes GIT, since it's a huge non-standard piece of crap./bias I may work on fixing that code up and putting it into HEAD before I retire. -Alec Warner [EMAIL PROTECTED] -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [PATCH] Repoman SVN support
Fabian Groffen wrote: On 25-11-2006 03:00:10 -0500, Alec Warner wrote: Fabian Groffen wrote: Hi all, Please find attached the patch of the prefix repoman sources against the current trunk. I hope I removed all hunks that have prefix-only changes. You realize I wrote generic SCM support into repoman over the summer right? :P It was never merged (afaik I slacked on it, but also because E no... probably because at that time I wasn't making my hands dirty on portage code. it uses Popen and you pesky OSX folks are stuck on python2.3, so I need to convert to portage.spawn). You can drop that, as I already require python 2.4, since portage needs at least 2.3.1 currently and I don't feel like checking with an older version to see if it breaks more. During bootstrapping I first install python 2.4. On a slightly related side note: you can also drop all your bash-2 code, as we end up running bash-3 too. Would only be nice if the basic functionally would work with bash-2, otherwise I need to bootstrap bash too. (Worth the time if it simplifies portage.) ZOMG, I love you long time. *shudders at python 2.3* However the support was generic, so for pretty much any system that 'is kinda like cvs/svn' should work fine with a few tweaks to the exec mapping. biasThis of course excludes GIT, since it's a huge non-standard piece of crap./bias Great! I feel that SVN won't be the only thing folks use, so I'm looking forward to your interface from a (hopefully) functional view point. I haven't actually tried the others, but the support should be trivial assuming they have similar commands and output (yay regex...oh wait, not quite yay :) ) I may work on fixing that code up and putting it into HEAD before I retire. E... what? The first is nice, the latter for sure isn't. We will see; I may stay on and do both, but I don't have a ton of time to work on stuff and it makes me feel guilty, hence trying to clean up loose ends around here. -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [PATCH] keyword anti-match (foo/-foo) overrides other matches
Zac Medico wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Barkalow wrote: If the configuration has keywords foo bar, and a package has -foo bar, mask the package (masked by -bar keyword). This is the sensible behavior if we ever make use of listing multiple keywords in the configuration, which is currently implemented but not used for anything. Personally, I'd prefer not to support -foo or -* in the KEYWORDS of an ebuild. For one thing, seems like it's trying to accomplish something similar to what package.mask is intended for. Another problem is that is uses -foo and -* in completely different ways than they are used elsewhere in portage (for negation of values in an incremental stack). Zac Didn't someone write a profile introspection tool to look at stuff like this? If it was as simple as emask profile package, and the tool took care of many of the details I think there would be less argument. As it is, setting -foo in the ebuild is trivial compared to the alternative (since profiles stack and you may need to edit 2 or 3 in some cases, means greater chance of screwing up). -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [RFC] Depending on active version
Marius Mauch wrote: Sometimes a package has to depend on a specific version of a slotted package being the active one to build correctly, like in the current tr1 discussion on -dev [1] or with packages that depend on the running kernel. Currently this isn't really possible, however I while ago I got an idea how to solve this. Keep in mind this is just a rough idea and I'm pretty sure some people can/will point out why it is a stupid idea, but anyway: The idea is to add a special category (let's call it active for now) that has the following properties: - this category doesn't exist in portdir or vdb (= no ebuilds) - when portage ($pkgmanager) encounters a active/foo atom in a dependency string it executes some special code (e.g. $PORTDIR/scripts/active-check/foo =active/foo-1) to determine if that atom is satisfied (and yes, this kinda goes with multi-repo/multi-format support) Marius I don't see why how this is any less complicated than just adding more functionality to || deps (runtime versus compile time) -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [RFC] Depending on active version
Stephen Bennett wrote: On Tue, 30 Jan 2007 17:06:51 +0100 Marius Mauch [EMAIL PROTECTED] wrote: The idea is to add a special category (let's call it active for now) that has the following properties: - this category doesn't exist in portdir or vdb (= no ebuilds) - when portage ($pkgmanager) encounters a active/foo atom in a dependency string it executes some special code (e.g. $PORTDIR/scripts/active-check/foo =active/foo-1) to determine if that atom is satisfied Given that in the general case the package manager can't change the active provider and will have to bail with an appropriate message that the user needs to change it themselves, the obvious solution to this is the previously-discussed-somewhere-I-can't-remember ebuild function, called on depgraph creation, to check that it will be able to compile in the current system environment. It's considerably simpler and more generally useful than subverting DEPEND to add weird special-case hacks to it. No one said subverting DEPEND was necessarily required. This stuff is essentially another visibility filter. Think for example along the ACCEPT_RESTRICT lines, but less fugly. User has FEATURES=sandbox ebuild has RESTRICT=sandbox Ebuild is not visible because it is incompatable with current environment. The only problem here being some visibility filters are 'soft' (like sandbox and USE vars) and some filters are hard (dependencies). USE flags can often be flippy flopped to get a solution (as with sandbox, which can be selectively turned off). -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [RFC] Depending on active version
Kevin F. Quinn wrote:
On Wed, 31 Jan 2007 12:27:10 -0500
Alec Warner [EMAIL PROTECTED] wrote:
Hmm; one could get the same benefit by introducing a new interface
(e.g. pkg_env_check()) which is defined to return true if the
environment is ok, false otherwise (with some text to stdout,
perhaps). The package manager would then run this function, after
building the depgraph and finding the candidate packages to merge,
for each candidate package - if any package fails is env_check,
none of the packages get emerged. Note this is then completely
independent of depgraph creation.
In the 'tr1' example, I'd imagine something like this:
use.local.desc: boost: Use boost library for tr1 rather than gcc's.
ebuild:
...
inherit ... toolchain-funcs versionator ...
...
DEPEND=... boost? ( dev-libs/boost ) ...
...
pkg_env_check() {
use boost return 0
version_is_at_least 4.1 $(gcc-version) return 0
echo Either USE boost, or switch to gcc later than 4.1
}
(with a default definition, pkg_env_check() { return 0; } )
In an ideal system you'd want this stuff in the metadata cache so that
the resolver can deal with it up front.
You're talking about the metadata on the host, rather than the stuff on
the rsync servers? I'm not sure you could cache the results even on
the host - you would need to know what could affect the results so as
to know when the cached information is out of date and has to be
recalculated. That would either have to checked on every emerge, or
made a separate switch (i.e. rely on the user to tell emerge when the
environment has changed).
I am talking about the host yeah; cache was a bad term on my part;
obviously you cannot cache stuff like this.
My concern about dynamic dependencies runs to use deps, as well :)
One could consider use-deps to be a special case of Marius' active
checks. how pkg P was built isn't so different from slot S of P is
active in terms of dep-graph creation; both are asking about the
state of host target systems, rather than the tree.
In the case of USE deps, things are saner because the data doesn't
change without the package manager knowing about it. Effectively the
depgraph becomes static w.r.t. the tree + installation record (rather
than just static w.r.t. the tree). With active checks implemented in
the depgraph, however, that is no longer the case - the depgraph can
change independently of the tree and the installation record.
I am unsure how fast these types of checks would or could be. I mean we
can add arbitrary key caching and arbitrary key matching, but then that
grows the cache substantially and probably slows down dependency
resolution. As you stated, some things just can't be cached properly
and still have value.
With that said, I'm not sure how easy it would be to rewrite that
code; and this is simpler in that it's just a few bash functions as
opposed to more resolver foo.
There's a lot to be said for keeping things simple, of course :) It's
easy enough to mess up things like dep-graphs in any case - introducing
these sorts of dynamic dependencies can render it substantially more
complex.
I think the complexity exists already though; currently we are just
hiding it, requiring people to find workarounds in an otherwise complex
playground of building packages.
Another way to look at it, is to consider how often this sort of thing
comes up. My understanding is that it is relatively rare; across the
10,000+ packages in the tree only a handful use 'built_with_use' fex.
That makes a strong case for having a simple solution in the near term,
and re-visit if it becomes commonplace.
I think your understanding is off then. A quick grep (qrep -H
built_with_use | wc -l) gives me 814 calls to 'built_with_use' (qgrep is
in portage-utils).
If you grep through eclasses you will also see 53 separate calls; so you
can imagine what the real usage could be (definately at least 1/20th the
tree, not something I'd call minor).
--
gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] Default Phase Hooks
In order to facilitate better ease of use with phase hooks, I propose a
paludis-style default phase hook. Basically ebuild.sh provides a default
hook that looks in PORTAGE_HOOKS_DIR/{pre,post}_${EBUILD_PHASE}/ for shell
scripts and sources them.
The patch to ebuild.sh only generates hooks 1 phase at a time. People
with existing hooks in bashrc will not be affected (the bashrc hooks will
over-ride these default hooks).
The motivation here is to have users create functionality in these hooks
and enable them to easily share hooks. 'hey drop this hook in location X'
is a lot easier than 'add this hook to bashrc...oh and make sure you don't
already have a post_pkg_prerm hook in there...oh and make sure if you do
have an existing hook you make it so that both run...' and so forth.
For people with no hooks the speed penalty is nil; for those with many
hooks, there is probably some small overhead per phase as the script
enumerates and sources the hooks.
Comments and Questions are welcome.
-Alec WarnerIndex: ebuild.sh
===
--- ebuild.sh (revision 5930)
+++ ebuild.sh (working copy)
@@ -69,6 +69,24 @@
source ${PORTAGE_BIN_PATH}/isolated-functions.sh /dev/null
+
+# Generate default hooks for EBUILD_PHASE
+# Users may over-ride these in their bashrc
+shopt -s nullglob
+for prefix in pre post
+do
+ eval ${prefix}_${EBUILD_PHASE}() {
+ for script in
\${PORTAGE_HOOKS_DIR}/${prefix}_${EBUILD_PHASE}/*.sh\
+ do
+ ebegin \Sourcing \$script\
+ qa_source \$script || die \Failed to source \$script\
+ eend
+ done
+ }
+done
+
+shopt -u nullglob
+
OCC=$CC
OCXX=$CXX
Re: [gentoo-portage-dev] Add a couple new warnings to QA check
Ryan Hill wrote: Hey all. I'd like to add two warnings to the QA GCC warning message reporter for GCC 4.2. The first is a new warning that is given when GCC makes an optimization assuming that overflow for operations on signed ints is undefined, as per the standard. Apparently a lot of code assumes that it will wrap instead. The reason for this warning is the new -fstrict-overflow flag that is enabled at = -O2. The warning will only appear with the -Wstrict-overflow flag set, but it is enabled by -Wall so it will be seen pretty often. The other is actually a warning already present in =4.1. 4.2 now forbids function casts and will actually generate a runtime abort in the code if they're used. This is bad because the code will compile fine but then segfault when executed :(. openssl is a good example (bug #158324). This warning is always reported, even without -Wall. I hope this check will help identify packages that might not be GCC 4.2 ready. If you expect these warnings to be *fixed* by developers please provide documentation to enable developers to do so. SpanKY has some docs in trunk/doc/ for this express purpose. As much as I love QA checks I really don't like forcing them on people (doubly so for a failure mode check like this) without giving people advice on how to fix them. Thanks, -Alec -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] Gentoolkit cleanup
I've gone ahead and ported the namespace changes for HEAD into gentoolkit so it can now import modules properly. If the new-style modules fail it will fall back to the old-n-busted import style, keeping backwards compatability for people with different portage versions. I also removed the string and types modules from the stuff in gentoolkit as both of them are very deprecated (since py 2.2/3?). -Alec -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] localization.py
There have been various efforts to add localization for errors and other portage messages. The codebase is not well designed for it though, and the people who want it done keep getting busy with other tasks, so it mostly lies unused. On 10/19/07, Arfrever Frehtes Taifersar Arahesis [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Does localization.py exist for a reason? - -- Arfrever Frehtes Taifersar Arahesis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHGM16/axNJ4Xo/ZERAsSGAJ9zzIxphOxnQW/g8LbTrXee5dE4gQCePrbA /zCemc3wwkb/fPvU76Hh+oo= =YD/c -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list -- [EMAIL PROTECTED] mailing list
Re: [gentoo-portage-dev] RFC: replacing packages
On 10/24/07, Marius Mauch [EMAIL PROTECTED] wrote: As package sets are mostly done now, I'm starting to think about something else. One of my pet peeves with portage is the packages file in profiles, for several reasons: 1) it has two completely independent purposes ok 2) it implements a redundant visibility filter as package.mask is also available in profiles ok 3) the syntax for defining the system set plain sucks not really relevant 4) the name doesn't really say anything about the purpose not really relevant. 3 and 4 are documentation problems, not necessarily problems within the current implementation. Another issue that isn't directly related, but covered by the proposed solution below, is the so called implicit system dependency in ebuilds, which doesn't really exist. It only an assumption by people that the system set is satisfied before an ebuild is processed, so its contents don't have to be listed in *DEPEND. If a user breaks that assumption by not regulary ensuring that system is satisfied bugs can occur. Another issue is the informal exception when system items are allowed to/must be listed in *DEPEND, IMO that should be formalized. I'm going to discuss a bit your implementation below, since you address what you are trying to solve here. My main problem is that given a tree (such as gentoo-x86) it may have one or more profiles with one or more sub-profiles (children). These profiles may contain a set of packages that make up 'system'. The ebuilds DEPEND (or RDEPEND or whatever) on this set of packages existing. The problem I see with your solution is that it doesn't address different system sets in different profiles. Now in practice this isn't much of a problem within gentoo-x86 (most profiles have similar system sets). However it places a certain onus on any profile in a given tree, it must have a system package 'similar' enough to other sets in functioning profiles; otherwise breakage is likely to occur. How would you address this in your system? To solve both issues I propose the following system: Profiles can contain the files system.depend and system.rdepend whose combined contents make up the system target. If any of those two files exists the packages file is ignored. The syntax should either be the same as package.mask or, if desired, also allow complex atoms (use-conditionals, any-of constructs). The second part would be that portage implicitly adds the content of the files to the DEPEND or RDEPEND setting of each ebuild unless it contains RESTRICT=system-deps. Obviously this would have to be tied to a new EAPI version. (an undefined cornercase here is if a profile does not contain the new files, not sure how that should be handled) Benefits: - we get rid of all the issues outlined at the top - should make it easier long-term to setup a no-compile system that only installs binary packages due to separation of build- and runtime deps in system Problems: - obviously it has to be implemented first - no obvious solution for stacking rules (e.g. child uses system.*, but parent profile only has packages) - some people might rely on the packages file So, comments? 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. -- [EMAIL PROTECTED] mailing list
[gentoo-portage-dev] Re: [gentoo-dev] Re: More general interface to use flags
On 11/4/07, Steve Long [EMAIL PROTECTED] wrote: Marijn Schouten (hkBst) wrote: the current interface to use flags, useq, usev, use_with, use_enable, as defined in /usr/lib/portage/bin/ebuild.sh lacks generality. The common thing is testing a use flag and possibly echoing a string, but there is no function that implements this common behaviour. I propose that we add such a function. Proposed name for the function is ifuse. I like the overall API that is enabled (and that it doesn't break anything.) I also propose to add the utility function ifv which is useful for writing concise and clean code. This one seems a bit light-weight to me, but if it makes your life easier, why not? One minor thing; -n is the default test, so: [[ $1 ]] is the same as [[ -n $1 ]] and: [[ ! $1 ]] is the same as [[ -z $1 ]] ''help test'' is very revealing, for those who haven't read it. ;-) Code Clarity over shortcuts. Use the explicit version. -- [EMAIL PROTECTED] mailing list
[gentoo-portage-dev] Re: [gentoo-qa] splitting up package.mask
On 3/14/08, Mike Frysinger [EMAIL PROTECTED] wrote: On Friday 14 March 2008, Alec Warner wrote: On 3/14/08, Mike Frysinger [EMAIL PROTECTED] wrote: On Thursday 13 March 2008, Steve Dibb wrote: Because package.mask in CVS for profiles is so huge, I think it might help it to get organized if we split it up a bit. halcyon had a good idea for the scheme: testing, broken, removal. That seems to sum up the main 3 reason that a package would be masked. Right now there are 679 entries in package.mask. The reason I came up with the idea was to find a way to make it easier for treecleaners to quickly see which ones they were working on. I'd like to take the discussion to -dev but wanted to get QA's thoughts first. I haven't looked into whether or not this is technically feasible at all. i think the real solution here is allowing masking in a package You want to add a metadata key and cache it you mean? i dont care terribly much about the logistics, just the results. as long as an ebuild can declare itself masked, it sounds good to me. this doesnt preclude the other ideas as there are often times where you want to have 1 global package mask piece (like large package set bumps ... so X or KDE or GNOME or ...). -mike [-gentoo-qa, +gentoo-portage-dev] Original thread was splitting up package.mask entries. Genone notes the code to do this already is basically in already (we just don't invoke it for $PORTDIR/profiles afaik). Genone, do we use existing code for package.mask (ie if we switch from a file to a dir will it break existing versions? I am unsure if we used the directory code for $PORTDIR/profiles/* If we do then I say that is the easiest method. MIke also mentioned a means for a single ebuild to mark itself masked. I think this is useless without the use of a metadata key and I'm still not sold on its usefullnessI could easily buy some sort of bash var that is read by a tool to generate package.mask entries though. Seems fragile though. -- gentoo-portage-dev@lists.gentoo.org mailing list
Re: [gentoo-portage-dev] [RFC] Label profiles with EAPI for compatibility checks
On Fri, Oct 3, 2008 at 5:09 PM, Zac Medico [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, Please consider a new eapi profile configuration file that will designate the EAPI to which any package atoms within a given layer of the profile stack must conform. This will allow package managers to bail out with an informative error message if the user accidentally selects a profile containing an EAPI that is not supported by the currently installed package manager. Long Long Ago there was a conversation about versioning profiles; is there some reason why you prefer the eapi method (which arguably has a smaller scope) over full profile api versioning (PAPI?) Arguably we could use both in the future as well. In order to allow mixed EAPIs in the profiles, and to avoid having to configure the EAPI in every single layer, each directory of the profile stack should be able to either override or inherit the EAPI value that may have been defined in a previous layer of the profile stack. If no EAPI has been previously defined then it can be assumed to be 0. The format of the configuration file can be very simple, containing only the EAPI value and nothing more. For example, a file containing just a single 0 character, followed by a newline, could be created at profiles/base/eapi in order to explicitly declare that atoms in the base profile conform to EAPI 0. However, this particular declaration would be redundant since the base profile does not inherit from any other profile and therefore it's EAPI would be assumed to be 0 anyway. Does this seem like a good approach? Are there any suggestions for improvements or alternative approaches? PAPI :) - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjmtEYACgkQ/ejvha5XGaNtSQCfXb2OQAYCEAe0Uuuu7Ou+DxyV QZsAn0VpUbKqHJP0XRZSg6mhFKeUNXui =qR8c -END PGP SIGNATURE-
Re: [gentoo-portage-dev] How to extract the version/revision of an installed package?
On Wed, Nov 26, 2008 at 3:13 AM, Amit Dor-Shifer [EMAIL PROTECTED] wrote:
Is there syntax in eix for querying: is package X installed with a version
X.Y or higher?
Amit
portageq has_version / ATOM
René 'Necoro' Neumann wrote:
Amit Dor-Shifer schrieb:
Thanks :)
Reason I thought this is relevant is: I'm basically looking for an API
to get an installed package's version/rev. I prefer that over making
syntactical assumptions on the way portage names packages.
Taking RPM for example, there's such an API: something like rpm -q
--queryformat '%{VERSION}|' PKG_NAME if I remember correctly.|
Amit
You could also use eix ... though I needed quite a time to figure it out
;)
# PRINT_SLOTS=false eix -e -I sys-devel/automake --pure-packages
--format installedversionsshort
1.9.6-r2 1.10.1-r1
Note however, that if you a package has multiple installed versions,
they are seperated by space. One could use
# PRINT_SLOTS=false eix -e -I sys-devel/automake --pure-packages
--format installedversionsshort:\n
But this prints an additional empty line at the beginning.
Andrew Gaffney wrote:
Amit Dor-Shifer wrote:
Given the following:
# qlist -Iv sys-apps/portage
sys-apps/portage-2.1.4.5
How do I safely extract the 2.1.4.5?
That's probably offtopic for this list, since it really has nothing to
do with portage itself. However, you probably want something like:
qlist -Iv sys-apps/portage | sed -e 's:^.*-\([0-9][^-_]*\).*$:\1:'
Re: [gentoo-portage-dev] Re: search functionality in emerge
On Tue, Dec 2, 2008 at 4:42 AM, Tambet [EMAIL PROTECTED] wrote: About zipping.. Default settings might not really be good idea - i think that fastest might be even better. Considering that portage tree contains same word again and again (like applications) it needs pretty small dictionary to make it much smaller. Decompressing will not be reading from disc, decompressing and writing back to disc as in your case probably - try decompression to memory drive and you might get better numbers. I ran gzip -d -c file.gz /dev/null, which should not write to disk. I tried again with gzip -1 and it still takes 29ms to decompress (even with gzip -1) where a bare read takes 26ms. (I have a 2.6Ghz X2 which is probably relevant to gzip decompression speed) I have personally used compression in one c++ application and with optimum settings, it made things much faster - those were files, where i had for example 65536 16-byte integers, which could be zeros and mostly were; I didnt care about creating better file format, but just compressed the whole thing. I'm not saying compression won't make the index smaller. I'm saying making the index smaller does not improve performance. If you have a 10 meg file and you make it 1 meg, you do not increase performance because you (on average) are not saving enough time reading the smaller file; since you pay it in decompressing the smaller file later. I suggest you to compress esearch db, then decompress it to memory drive and give us those numbers - might be considerably faster. gzip -d -c esearchdb.py.gz /dev/null (compressed with gzip -1) takes on average (6 trials, dropped caches between trials) takes 35.1666ms cat esearchdb.py /dev/null (uncompressed) takes on average of 6 trials, 24ms. The point is you use compression when you need to save space (sending data over the network, or storing large amounts of data or a lot of something). The index isn't going to be big (if it is bigger than 20 or 30 meg I'll be surprised), the index isn't going over the network and there is only 1 index, not say a million indexes (where compression might actually be useful for some kind of LRU subset of indexes to meet disk requirements). Anyway this is all moot since as you stated so well earlier, optimization comes last, so stop trying to do it now ;) -Alec http://www.python.org/doc/2.5.2/lib/module-gzip.html - Python gzip support. Try open of that and normal open on esearch db; also compress with the same lib to get right kind of file. Anyway - maybe this compression should be later added and optional. Tambet - technique evolves to art, art evolves to magic, magic evolves to just doing. 2008/12/2 Alec Warner [EMAIL PROTECTED] On Mon, Dec 1, 2008 at 4:20 PM, Tambet [EMAIL PROTECTED] wrote: 2008/12/2 Emma Strubell [EMAIL PROTECTED] True, true. Like I said, I don't really use overlays, so excuse my igonrance. Do you know an order of doing things: Rules of Optimization: Rule 1: Don't do it. Rule 2 (for experts only): Don't do it yet. What this actually means - functionality comes first. Readability comes next. Optimization comes last. Unless you are creating a fancy 3D engine for kung fu game. If you are going to exclude overlays, you are removing functionality - and, indeed, absolutely has-to-be-there functionality, because noone would intuitively expect search function to search only one subset of packages, however reasonable this subset would be. So, you can't, just can't, add this package into portage base - you could write just another external search package for portage. I looked this code a bit and: Portage's __init__.py contains comment # search functionality. After this comment, there is a nice and simple search class. It also contains method def action_sync(...), which contains synchronization stuff. Now, search class will be initialized by setting up 3 databases - porttree, bintree and vartree, whatever those are. Those will be in self._dbs array and porttree will be in self._portdb. It contains some more methods: _findname(...) will return result of self._portdb.findname(...) with same parameters or None if it does not exist. Other methods will do similar things - map one or another method. execute will do the real search... Now - for package in self.portdb.cp_all() is important here ...it currently loops over whole portage tree. All kinds of matching will be done inside. self.portdb obviously points to porttree.py (unless it points to fake tree). cp_all will take all porttrees and do simple file search inside. This method should contain optional index search. self.porttrees = [self.porttree_root] + \ [os.path.realpath(t) for t in self.mysettings[PORTDIR_OVERLAY].split()] So, self.porttrees contains list of trees - first of them is root, others are overlays. Now, what you have
Re: [gentoo-portage-dev] Re: equery refactorization
On Wed, Dec 3, 2008 at 1:03 AM, Douglas Anderson [EMAIL PROTECTED] wrote: On Wed, Dec 3, 2008 at 7:21 AM, Michael Smith [EMAIL PROTECTED] wrote: I had the same idea and even began working on a roadmap for it. Step 1: move gentoolkit to site-packages Step 2: move individual command classes to functionally-organized module-files Step 3: refactor and enhance docstrings to allow primary help/usage() function to construct from individual modules. (The goal here is to create a drop-in mechanism for adding new modules, so that usage() is automatically updated when a new module is added.) Step 4: Profit! Actually another approach would be to create a core __init__.py that handled the usage() and getopt functionality I outlined in Step 3 above, and then one-by-one modify the individual modules that are in the current equery so they could be dropped in. Thoughts? Michael On Dec 2, 2008, at 5:01 AM, Douglas Anderson wrote: Hi, I'm interesting in tinkering with equery and doing some refactorization in my spare time. I wrote a script that some people mentioned would be a good module for equery (emeta, it's on bugzilla), but as I was looking into that, I noticed that equery is written as a script, even though it would probably really benifit from being modularized. Again, this is just because I have some free time right now and a willingness to learn about Portage, but I thought I'd check with you guys first. If I'm willing to do it without bother you all too much, would it be something you're interested in me doing? My idea is to set it up more like a Python package than a script, like: /usr/lib/gentoolkit/pym/gentoolkit/equery/ /usr/lib/gentoolkit/pym/gentoolkit/equery/__init__.py /usr/lib/gentoolkit/pym/gentoolkit/equery/belongs.py /usr/lib/gentoolkit/pym/gentoolkit/equery/check.py /usr/lib/gentoolkit/pym/gentoolkit/equery/depends.py etc... I think it would increase startup time and make adding or upgraded modules easier in the future. Well, I have a few more questions but I'll wait and see if this would be a positive thing or not. Thanks for your time, -Doug Great, I'd like to give this a try, then. Michael, I was personally going to go for your other approach of having an __init__.py do all the setup and handle the input and send the local opts to the individual modules. If you're interested in working on it together, that would be great. I have a googlecodes repo that we can work out of, or whatever (same goes for anyone else) :) I'll also open up a bug for it when I have some work done. nitpick feel free to ignore me Don't put stuff in __init__.py. Make a file called equery (no .py) and do all the work in the modules you import; eg. from equery import driver if __name__ == __main__: driver.Run() Then put all this code in driver.py (option parsing, signal handling, etc...). Don't try to hide the code in __init__.py; it confuses people who are trying to figure out what the module is for (since __init__.py has very specific duties in declaring what is in the module when you inspect the query module). Putting the code in a file named 'driver.py' or similarly makes it pretty obvious (to me anyway) what the code in that file is for (to drive a program). Does that make sense or am I full of crap? /nitpick A little RFC: 1) Spaces or tabs? Python standard is spaces, Gentoo seems to be predominantly tabs. I personally like to use spaces when I'm writing Python, but if that would annoy everyone later on, I'll stick to tabs. Gentoo has no official coding standards. I'd personally prefer spaces (along with basically everything else in the Google Python Style Guide[1]), but I'm probably not going to nitpick. It is my opinion that tabs are used because that is what the tools were written in and it is annoying to change from tabs to spaces ;) [1] http://code.google.com/p/soc/wiki/PythonStyleGuide 2) Are there any other progs that depend on equery and gentoolkit that you know of? If there are, I can try and keep an eye on things and create as little hassle as possible. Any other ideas? -Doug
Re: [gentoo-portage-dev] equery: RFC and code review
On Tue, Feb 10, 2009 at 2:53 AM, Douglas Anderson d...@gendja.com wrote:
Hi all,
It's been a few months since we first discussed refactoring equery on
this list and I think made pretty good time and I'm reasonably happy
with it. So I'm throwing out to you all. I've tried to keep a running
list of visible changes as I went along, but I'm sure I've missed some
things. You can read that here:
http://code.google.com/p/genscripts/source/browse/equery/trunk/equery/CHANGELOG
My primary goals for the refactorization were:
* Modularize
* Clean up the UI
* Rewrite a more solid option handler
* Eliminate as much duplicated code as possible
* Clean up slop and bitrot, follow clean coding standards and style
guidelines wherever possible
* Break up large functions, write docstrings for all functions
* Get code set for Python 2.6 (tested in 2.5 and 2.6) and prepare
smooth upgrade for Py3k.
* Create a more consistent experience for the user.
This last point is surely where the most contention will stem from, so
let me argue my position. All modules except for list, check and size
display the help message when called without input (ex: equery uses).
This makes sense. It's what most other programs do. It's what emerge
does. It's what eselect does. It's the neighborly thing to do.
However these three exceptions go and start a time-consuming process
which is of very limited usefulness. With a cold cache, each process
takes at least 30 seconds. I imagine that 99 percent of people who
type 'equery list' do it by accident. And who needs to see the size of
every installed package? And checksum every installed package? Almost
useless except to a select few people who know what they're doing.
So I took the liberty of changing the default behavior of these three
modules to be more in line with the rest of equery and the world. Each
of the three displays deprecation warning explaining how to recreate
the old default behavior. I can't imagine anyone objecting outright to
this, considering there will always be more than one version of
gentoolkit in the tree (there are 6 now) so it'd be a long time before
anyone was forced into the new behavior.
That's it. For anyone interested, please read the link above and let
me know if you like it/hate it/want something else done.
For python programmers, I'd appreciate a quick code review and any
comments/criticism whatsoever (I really like criticism).
You Asked...
I think one of the major things that annoyed me when reading the code
is that you did add a new option parser...and you added it about a
dozen times...(regexp used to basically find the start of the same
code block over and over).
anta...@kyoto ~/code/checkouts/genscripts-read-only/equery $ grep
opts = .x *.py | wc -l
13
Now the option parsing is quite complicated so I'm not sure if a
complicated data structure to pass to a generic function is really a
good use of ones time. But it stands out.
None of your files has a copyright notice.
I pray pp.print_error prints to stderr and not stdout; otherwise tends
to be a big nitpick of mine when people write errors to stdout.
belongs.py has this gem:
q.append(('^' if query[0] == '/' else '/') + re.escape(query) + '$')
I realize it works; but honestly, not readable.
append_str =
if query[0] == '/' append_str += '^' else append_str += '/'
append_str += re.escape(query) + '$'
q.append(append_str)
Slightly better (if append_str has a shorter name, maybe). I don't
like 1 line if EXPR STATEMENT else STATEMENT but sometimes they are
shorter
Putting a conditional in the function call is horrible looking though.
You use # FOO comments often; sometimes too often. Explaining what
you are doing is typically better noted in a docstring for a function
and not necessarily right next to the code it pertains to. An example
would be meta.py in get_useflags. You have a 4 line comment block
describing what you are doing but it really interferes with the
reading of the code. Functions should typically be short enough that
referring to the docstring is no big deal (and the example I chose is
a very short function). In addition you have a lot of # do something
obvious here. If it is obvious; you don't need a comment. An
example of this would be meta.py around line 418.
in __init__.py your find_matches function is too long (180 lines or
4.5 of my screen heights). You've already split it up into convenient
sections by comments (which are fine by the way) but you can probably
make subroutines out of some of the subsections. Also most of the
code has nothing to do with finding matches and lots to do with query
preparation.
in __init__.py you have InvalidRegex with a TODO to move it to another
file. It seems like exceptions.py might be a worthy place.
I think there are a number of cases where I'd prefer to see string
interpolation instead of explicit addition:
'%s/%s' % (cat, package)
But thats just me being picky (and you use string
Re: [gentoo-portage-dev] [PATCH] missing-rebuild package set
On Fri, Aug 8, 2008 at 2:10 PM, Zac Medico zmed...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lucian Poston wrote: The following patchs add a library dependency rebuilder as a package set, @missing-rebuild, to portage-2.2_rc6. Similar to the --library flag in revdep-rebuild, the user can additionally emerge the set of packages containing consumers of libraries matched by a (python) regular expression; however, until a better solution is found, the regexp must be passed through the LIBRARY environment variable to enable that feature. Known issues: I expect some false positives. I've inserted hard coded directory/library masks for those I've found. I noticed a situation that required a second emerge due to a provider package satisfying 3 conditions: 1) the package is installed and an updated version is available in its slot, 2) the updated version is in the set due to a dependency of another package (or it may contains a broken binary), and 3) a consumer package of a library within the updated package is emerged before the updated dependency is emerged, causing a package to be compiled against the old library before the library version changes. I guess that if a package is already installed, it is not necessarily placed before its consumer packages in the merge order. Attached are patches for pym/portage/dbapi/vartree.py, pym/portage/sets/libs.py and /usr/share/portage/config/sets.conf. These can also be found in the project's repository: http://repo.or.cz/w/revdep-rebuild-reimplementation.git?a=tree;h=refs/heads/rc1;hb=refs/heads/rc1 Thanks, I've merged your LinkageMap changes. Side note: I suspect that we might be able to improve efficiency in LinkageMap path comparisons by comparing tuples of device and inode numbers instead of using realpath. We currently use the device/inode number approach to test identity of paths in dblink.isowner(). As it is time for gSoC 2009; I want to inquire at the status of this code integration. Looking at HEAD it seems there are some changes left to merge. Is this on the roadmap? -Alec I warmly welcome all feedback, in particular any suggestions to remove the necessity of directory and library masks in /etc/revdep-rebuild/*, which I've been unable to entirely avoid. Lucian I haven't merged the MissingLibraryConsumerSet yet since I'd like to see if we can improve it a bit first. I don't have any ideas right now but hopefully we can come up with something soon. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkicxEsACgkQ/ejvha5XGaNcyACfX7oKKCbYraRk8AwckkA9Reu6 cRkAoMa/vK5SXDTdw8+nYqpBAlUXz096 =zskl -END PGP SIGNATURE-
Re: [gentoo-portage-dev] Who's maintaining the Eclass HOWTO page nowdays?
My first guess is 'no one.' I'd try devmanual.gentoo.org over anything in /proj/en/devrel/, however developer relations owns stuff in /proj/en/devrel, so if there are incorrect things in it you probably want to file bugs at bugs.gentoo.org against devrel for changes. On Wed, Mar 11, 2009 at 12:15 AM, Amit Dor-Shifer ami...@oversi.com wrote: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=2 10x, Amit
Re: [gentoo-portage-dev] qfile assumes category names contain a hyphen
On Mon, Mar 16, 2009 at 9:34 AM, Amit Dor-Shifer ami...@oversi.com wrote:
Hi all.
While working on my overlay, I stumbled on an issue where qfile refused to
acknowledge an installed file as being part of my package.
Looking into q's implementation (portage-utils-0.1.29), I see:
amit0 portage-utils-0.1.29 # grep -A 2 next_entry ./libq/vdb_get_next_dir.c
next_entry:
ret = readdir(dir);
if (ret == NULL) {
--
goto next_entry;
if (strchr(ret-d_name, '-') == NULL)
if ((strcmp(ret-d_name, virtual)) != 0)
goto next_entry;
I encountered this since I used a new category, which only contained a
single word. Adding a hyphen and a 2nd token solved my issue, and now qfile
knows the file's association.
Is this assumption, that category should be stringA-stringB documented
somewhere?
It is a legacy assumption that we had prior to the introduction of the
'virtual' category into gentoo-x86.
10x,
Amit
Re: [gentoo-portage-dev] Conflicting RDEPENDS
On Fri, May 29, 2009 at 2:33 AM, René 'Necoro' Neumann li...@necoro.eu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Patrick Börjesson schrieb: # emerge -1av bacon These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild UD] app-test/eggs-1 [2] 0 kB [1] [ebuild N] app-test/bacon-1 0 kB [1] This second behavior looks wrong to me, as it downgrades the RDEPEND of spam and thus spam becomes unusable. Try: emerge -1av --complete-graph bacon Ok - this works ... IF spam is in world. If I installed spam with - --oneshot, it won't work either. So don't use --oneshot :) Unless --complete-graph is specified emerge won't pull in the entire dependency graph, thus won't notice the dependency-spec of app-test/spam. Using -D combined with the world set when updating your system yields the same result as that also pulls in the entire dependency graph. Unless the entire dependency graph is pulled in emerge only tries to satisfy the dependencies of the packages given on the commandline, and since there's no connection between app-test/spam and app-test/bacon, and emerge doesn't do reverse deps when adding something to the dep-graph, it doesn't notice that app-test/bacon and app-test/spam has conflicting dependencies Using --complete-graph is noticably slower since it slows down dependency calculations, but it should (IMHO) really be the default since these conflicts shows _before_ anything breaks. I agree. Regards, René -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkofq+sACgkQ4UOg/zhYFuBhsACdEUiXen0NriASzULe0Ak9Waiv 6v8An1OxTqmbnhlCk7sRG0pYxfHJad8Y =Haya -END PGP SIGNATURE-
Re: [gentoo-portage-dev] Re: Conflicting RDEPENDS
On Sun, May 31, 2009 at 4:21 AM, Marijn Schouten (hkBst)
hk...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Duncan wrote:
Patrick Börjesson psychoti...@lavabit.com posted
20090529201741.gb11...@nexon.nexus, excerpted below, on Fri, 29 May 2009
22:17:41 +0200:
Why exactly would you want to use --oneshot for a leaf package that is
not depended on by any other package in the world set? If spam IS
depended on by any other package (recursively) in the world set, it will
be pulled in by --complete-graph, but that's not the case here if i
understand it correctly, thus it's a package that you explicitly wanted
installed, thus it belongs in the world set, and you should thus not use
--oneshot for it.
I use -1 by default, here (via scriptlet), mainly so I don't have to
worry about cluttering up my world file while emerging individual
packages, just as I always use -NuD with my @system and @world runs.
But for leaf packages, it serves as a sort of test install as well.
Since I always do revdep-rebuild -p and emerge --depclean -p after every
update (typically 2-3 times a week), then rebuild and clean as I need to,
keeping the trial merges on the depclean list for a few days keeps me
aware of them. If I know it's something I want to keep, I run a
different scriptlet without the -1, but that's not often once a system is
up and running with the normal working set merged. Meanwhile, I
ultimately either emerge -C (or let depclean handle it) the trialware,
or emerge --noreplace, thus adding it to world.
But experimental installs and their deps typically sit in the --depclean
list for anything from a few minutes to a few days, until I decide
whether I want to keep or remove them.
If he was testing how the switches under discussion here worked and has a
similar policy, I could easily see him using -1 by habit, even if he
didn't explicitly reason that it was a test and therefore something he
didn't want in @world.
I think this is an interesting use-case. It would be very simple to handle it
by
introducing an additional file that the package manager would use to record
the
packages that are installed on trial-basis. This would make it possible to
include these packages in dep-calculations, while still distinguishing them
from
packages that are in @world. Of course you can also fake it by creating a
local
virtual/trialware package (or possibly a @trialware group) of which you edit
the
deps, but this would be less convenient. For my personal workflow using -1 for
trials is working well enough, atm.
Why is a custom set less convenient?
Marijn
- --
If you cannot read my mind, then listen to what I say.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkoiaCoACgkQp/VmCx0OL2yMRgCeKQ+bIh6RViaTiHKBc8bkREBo
yF0An2XXyngQ2cfuYwKHdUMBP5efcHrV
=Xfc/
-END PGP SIGNATURE-
Re: [gentoo-portage-dev] Re: Conflicting RDEPENDS
On Wed, Jun 3, 2009 at 4:05 AM, Marijn Schouten (hkBst)hk...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alec Warner wrote:
On Sun, May 31, 2009 at 4:21 AM, Marijn Schouten (hkBst)
hk...@gentoo.org wrote:
Duncan wrote:
Patrick Börjesson psychoti...@lavabit.com posted
20090529201741.gb11...@nexon.nexus, excerpted below, on Fri, 29 May 2009
22:17:41 +0200:
Why exactly would you want to use --oneshot for a leaf package that is
not depended on by any other package in the world set? If spam IS
depended on by any other package (recursively) in the world set, it will
be pulled in by --complete-graph, but that's not the case here if i
understand it correctly, thus it's a package that you explicitly wanted
installed, thus it belongs in the world set, and you should thus not use
--oneshot for it.
I use -1 by default, here (via scriptlet), mainly so I don't have to
worry about cluttering up my world file while emerging individual
packages, just as I always use -NuD with my @system and @world runs.
But for leaf packages, it serves as a sort of test install as well.
Since I always do revdep-rebuild -p and emerge --depclean -p after every
update (typically 2-3 times a week), then rebuild and clean as I need to,
keeping the trial merges on the depclean list for a few days keeps me
aware of them. If I know it's something I want to keep, I run a
different scriptlet without the -1, but that's not often once a system is
up and running with the normal working set merged. Meanwhile, I
ultimately either emerge -C (or let depclean handle it) the trialware,
or emerge --noreplace, thus adding it to world.
But experimental installs and their deps typically sit in the --depclean
list for anything from a few minutes to a few days, until I decide
whether I want to keep or remove them.
If he was testing how the switches under discussion here worked and has a
similar policy, I could easily see him using -1 by habit, even if he
didn't explicitly reason that it was a test and therefore something he
didn't want in @world.
I think this is an interesting use-case. It would be very simple to handle
it by
introducing an additional file that the package manager would use to record
the
packages that are installed on trial-basis. This would make it possible to
include these packages in dep-calculations, while still distinguishing them
from
packages that are in @world. Of course you can also fake it by creating a
local
virtual/trialware package (or possibly a @trialware group) of which you edit
the
deps, but this would be less convenient. For my personal workflow using -1
for
trials is working well enough, atm.
Why is a custom set less convenient?
Well, instead of emerge --trialware package you would first have to edit
your
@trialware set and then emerge @trialware. The same goes for when you want
to
remove some trialware.
Perhaps some generalization of --trialware along the lines of
- --add-to-set=trialware could be fleshed out as a useful extension of
portage.
I like sandwiches too, so perhaps we can have a
--sudo_make_me_a_sandwich option to emerge?
But seriously, this is linux. If users want do deal with a set of
packages that are like trialware then they should use the sets
functionality that emerge already ships with. emerge
--add-to-set=blah might be passable but IMSHO emerge has plenty of
options already and users can easy write their own wrappers for this
kind of thing. Emerge doesn't need every tiny feature built into it.
Marijn
- --
If you cannot read my mind, then listen to what I say.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkomWO8ACgkQp/VmCx0OL2wGHACfdlOdzvfLM3aUafiuOVQTlRnz
vvMAoMMeLUxnM2i8fpJhClxbsIqwMf3Z
=HSIG
-END PGP SIGNATURE-
Re: [gentoo-portage-dev] portageq doesn't clean-up generated tmp/ and var/
On Tue, Jul 7, 2009 at 1:40 AM, Amit Dor-Shiferami...@oversi.com wrote: amit0 ~ # ls -la /var/db/pkg/var ls: cannot access /var/db/pkg/var: No such file or directory amit0 ~ # ls -la /var/db/pkg/tmp ls: cannot access /var/db/pkg/tmp: No such file or directory amit0 ~ # portageq match /var/db/pkg portage Just FYI, you are probably misinterpreted what root means here; which is why you are confused later on. amit0 ~ # find /var/db/pkg/var /var/db/pkg/tmp /var/db/pkg/var /var/db/pkg/var/tmp /var/db/pkg/var/lib /var/db/pkg/var/lib/portage /var/db/pkg/var/cache /var/db/pkg/var/cache/edb /var/db/pkg/tmp Of course it wouldn't; those directories are not at all designed to be temporary. /var/cache/edb is a metadata cache. /var/lib/portage holds cached config entries, --resume stuff, world files, and the preserved libs registry. Deleting those every time portageq runs would be crazy. amit0 ~ # emerge -Op portage !!! Invalid db entry: /var/db/pkg/var/tmp !!! Invalid db entry: /var/db/pkg/var/lib !!! Invalid db entry: /var/db/pkg/var/cache These are the packages that would be merged, in order: !!! Invalid db entry: /var/db/pkg/var/tmp !!! Invalid db entry: /var/db/pkg/var/lib !!! Invalid db entry: /var/db/pkg/var/cache [ebuild U ] sys-apps/portage-2.1.6.11 [2.1.6.7] !!! Invalid db entry: /var/db/pkg/var/tmp !!! Invalid db entry: /var/db/pkg/var/lib !!! Invalid db entry: /var/db/pkg/var/cache match root atom Returns a \n separated list of category/package-version. When given an empty string, all installed packages will be listed. root is: ROOT = [path] Use ROOT to specify the target root filesystem to be used for merging packages or ebuilds. This variable can be set via the --root option or in make.conf(5) (the command line overrides other settings). Defaults to /. You probably want portageq has_version / 'sys-apps/portage' ? maybe Zac can make has_version take atoms?
[gentoo-portage-dev] Fwd: Random patch
Ugh I hate this list name ;p
-- Forwarded message --
From: Alec Warner anta...@gentoo.org
Date: Mon, Oct 19, 2009 at 12:38 AM
Subject: Random patch
To: gentoo-dev-port...@gentoo.org
Get rid of if True...True is always true in CPython.
replace icky:
'foo' + \
'bar'
constructs with implicit string concat:
('foo'
'bar)
repoman-string-concat-plus-if-true-fixes.patch
Description: Binary data
Re: [gentoo-portage-dev] A question regarding portage GFS2
On Mon, Mar 15, 2010 at 2:44 AM, Mikko Rinne mikko.ri...@tnnet.fi wrote: Hey, It's my first time I'm mailing to this list so be warned. I have a problem with GFS2. In the past there's been sys-fs/gfs2 ebuild available in the portage, but for now it's been removed as one of it's dependencies (openais) was removed. You may get more relevant advice from emailing gentoo-user, as this list is primarily focussed on development of sys-apps/portage. Normally I wouldn't mind about it, but as I had the original sys-fs/gfs2 already built in the system and after running emerge --sync emerge --update, I found out that it actually managed to broke down mkfs.gfs2, which is pretty essential part when you have GFS2 set up. The whole error is; mkfs.gfs2: error while loading shared libraries: libvolume_id.so.0: cannot open shared object file: No such file or directory So the question remains; As GFS2 was removed as sys-fs/gfs2, has it been moved to any other main streamline package? If so, where. Basicly all I need atm is the mkfs.gfs2, but any info about this is much appreciated. Thanks. You are free to go to http://sources.gentoo.org, click on 'gentoo-x86' and find the ebuild for sys-fs/gfs2 and use it (and its associated files) to build a new mkfs.gfs2. You should probably put this ebuild in an overlay -A Best Regards, -- Mikko Rinne Technical department +358-10-3091334 TNNet Oy http://www.tnnet.fi http://www.avatar.fi
Re: [gentoo-portage-dev] portage docbook documentation - why not asciidoc ?
On Sat, Nov 27, 2010 at 6:53 AM, Zac Medico zmed...@gentoo.org wrote: On 11/27/2010 01:25 AM, Sebastian Pipping wrote: On 11/26/10 21:18, Zac Medico wrote: The asciidoc format seems nice, but personally, I think I prefer docbook since the SGML/XML approach seems more flexible and extensible. Are you making use of that flexibility anywhere at the moment? If not is such use planned for something specific? Honestly, I don't know. In case DocBook is keeping contributions down than cutting away certain flexibility to increase contributions could be a good trade-off, too. I'm not sure that docbook represents a significant barrier in this respect. It's hard to speculate. Maybe if we had a survey sampling the opinions of a broad spectrum of open-source developers, then we'd have more to go on. In general I don't see docbook as a problem. If I file a portage bug and say something needs to be changed or documented then attaching plain text additions is usually sufficient for inclusion. The bigger problem portage faces is that very few people actually know enough about how it works and this leaves only a few people who can actually write (or verify) that documentation is correct. As it is, I'm fairly comfortable with docbook. Now you want me to learn a new format, with possible drawbacks, in order to try and draw in some contributions that may never happen? Here is where I would look for data. Are there pending contributions? I have not seen anyone on this list specifically say I'd write some documentation if it was not in docbook. I have had issues (years ago) getting vapier to write documentation; but I assumed that was because he hated writing docs and he contributed documentation after a while. -- Thanks, Zac
Re: [gentoo-portage-dev] portage docbook documentation - why not asciidoc ?
On Sat, Nov 27, 2010 at 1:50 PM, Mike Frysinger vap...@gentoo.org wrote: On Saturday, November 27, 2010 16:39:04 Alec Warner wrote: On Sat, Nov 27, 2010 at 6:53 AM, Zac Medico wrote: As it is, I'm fairly comfortable with docbook. Now you want me to learn a new format, with possible drawbacks, in order to try and draw in some contributions that may never happen? Here is where I would look for data. Are there pending contributions? I have not seen anyone on this list specifically say I'd write some documentation if it was not in docbook. I have had issues (years ago) getting vapier to write documentation; but I assumed that was because he hated writing docs and he contributed documentation after a while. not sure where you're going with this, but i'm the one who started the doc/ dir and introduced the docbook system. obviously i have no problem with it and would rather see real examples of people who are being impeded by it rather than yet another omg we need to switch to this awesome new format because it is so awesome. -mike I'm saying you should write more docs! But we agree on the other point ;)
Re: [gentoo-portage-dev] [PATCH 1/4] Manifest2 hash: Whirlpool
On Sat, Oct 1, 2011 at 11:08 AM, Mike Frysinger vap...@gentoo.org wrote: On Thursday, September 29, 2011 21:27:39 Robin H. Johnson wrote: Provide public-domain implementation of the Whirlpool hash algorithm to be used as new Manifest2 hash. Signed-off-by: Robin H. Johnson robb...@gentoo.org --- pym/portage/checksum.py | 4 + pym/portage/util/whirlpool.py | 788 + 2 files changed, 792 insertions(+), 0 deletions(-) create mode 100644 pym/portage/util/whirlpool.py shouldn't we add pycryptoplus to the tree and depend on that rather than copying pasting their code into portage ? -mike It is ironic with all the gentoo devs complaining about bundled libs. I think part of the problem is the maintenance issue (upgrades from EAPI0, extra deps, etc..)
Re: [gentoo-portage-dev] [GLEP59v2 5/5] GLEP59: Change live Manifest2 hashes to SHA256, SHA512, WHIRLPOOL
On Sun, Oct 2, 2011 at 1:39 PM, Zac Medico zmed...@gentoo.org wrote: On 10/02/2011 05:46 AM, Robin H. Johnson wrote: On Sat, Oct 01, 2011 at 09:40:13PM -0700, Zac Medico wrote: If we control these hashes via metadata/layout.conf, then we can toggle it atomically for all commiters. Otherwise, we'll have an annoying period of time where different committers are committing different sets of hashes, depending on their portage version. How do you suggest doing it via layout.conf? I've kept SHA256 in both sets for now, but if you could enforce new signatures including both WHIRLPOOL and SHA256, that would be great. How about if we put something like this in gentoo-x86/metadata/layout.conf now: Reminds me, I was going to do an analysis on -commit mails to track portage versions; I'll do that now. manifest2-sha1 = true manifest2-whirlpool = false Then we'll patch portage so that by default it will disable SHA1 and enable WHIRLPOOL, and the above settings will override the defaults. After the patched portage is marked stable in a month or so, we'll send an announcement to gentoo-announce, and remove the above settings from layout.conf. -- Thanks, Zac
Re: [gentoo-portage-dev] [PATCH] portageq: add colormap helper
On Sat, Mar 10, 2012 at 8:15 PM, Mike Frysinger vap...@gentoo.org wrote:
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
bin/isolated-functions.sh | 2 +-
bin/portageq | 8
pym/portage/output.py | 6 ++
pym/portage/package/ebuild/doebuild.py | 8 ++--
4 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/bin/isolated-functions.sh b/bin/isolated-functions.sh
index 9321ad5..98be41e 100644
--- a/bin/isolated-functions.sh
+++ b/bin/isolated-functions.sh
@@ -431,8 +431,8 @@ set_colors() {
BAD=$'\e[31;01m'
HILITE=$'\e[36;01m'
BRACKET=$'\e[34;01m'
+ NORMAL=$'\e[0m'
fi
- NORMAL=$'\e[0m'
}
RC_ENDCOL=yes
diff --git a/bin/portageq b/bin/portageq
index 5ecbb21..fcdb9d9 100755
--- a/bin/portageq
+++ b/bin/portageq
@@ -44,6 +44,7 @@ del pym_path
from portage import os
from portage.eapi import eapi_has_repo_deps
from portage.util import writemsg, writemsg_stdout
+from portage.output import colormap
portage.proxy.lazyimport.lazyimport(globals(),
'subprocess',
'_emerge.Package:Package',
@@ -685,6 +686,13 @@ def distdir(argv):
print(portage.settings[DISTDIR])
+def colormap(argv):
+
+ Display the color.map as environment variables.
+
+ print(portage.output.colormap())
+
+
def envvar(argv):
variable+
Returns a specific environment variable as exists prior to ebuild.sh.
diff --git a/pym/portage/output.py b/pym/portage/output.py
index 43d7503..98bec81 100644
--- a/pym/portage/output.py
+++ b/pym/portage/output.py
@@ -325,6 +325,12 @@ def style_to_ansi_code(style):
ret += codes.get(attr_name, attr_name)
return ret
+def colormap():
+ mycolors = []
+ for c in (GOOD, WARN, BAD, HILITE, BRACKET, NORMAL):
+ mycolors.append(%s=$'%s' % (c, style_to_ansi_code(c)))
+ return \n.join(mycolors)
+
def colorize(color_key, text):
global havecolor
if havecolor:
diff --git a/pym/portage/package/ebuild/doebuild.py
b/pym/portage/package/ebuild/doebuild.py
index c45aa03..4ff3eea 100644
--- a/pym/portage/package/ebuild/doebuild.py
+++ b/pym/portage/package/ebuild/doebuild.py
@@ -50,7 +50,7 @@ from portage.exception import DigestException,
FileNotFound, \
IncorrectParameter, InvalidDependString, PermissionDenied, \
UnsupportedAPIException
from portage.localization import _
-from portage.output import style_to_ansi_code
+from portage.output import colormap
I assume style_to_ansi_code is unused?
from portage.package.ebuild.prepare_build_dirs import prepare_build_dirs
from portage.util import apply_recursive_permissions, \
apply_secpass_permissions, noiselimit, normalize_path, \
@@ -300,11 +300,7 @@ def doebuild_environment(myebuild, mydo, myroot=None,
settings=None,
mysettings[PORTAGE_CONFIGROOT], EBUILD_SH_ENV_DIR)
# Allow color.map to control colors associated with einfo, ewarn,
etc...
- mycolors = []
- for c in (GOOD, WARN, BAD, HILITE, BRACKET):
- mycolors.append(%s=$'%s' % \
- (c, style_to_ansi_code(c)))
- mysettings[PORTAGE_COLORMAP] = \n.join(mycolors)
+ mysettings[PORTAGE_COLORMAP] = colormap()
if COLUMNS not in mysettings:
# Set COLUMNS, in order to prevent unnecessary stty calls
--
1.7.8.5
Re: [gentoo-portage-dev] tools-portage packages
On Tue, Jul 17, 2012 at 10:48 PM, Paul Varner fuzzy...@gentoo.org wrote:
All:
(Apologies if you get this twice. I never saw my initial send of the
message hit the mailing list)
Sending this here before I send to the gentoo-dev list. Below is the
list of packages that are managed by the tools-portage herd and their
maintainer (if any). I know we have several packages in the herd that
are not being maintained and I would like to either get a maintainer or
last rite the package. I've included comments on what I know about the
packages.
$ equery meta -m $(fgrep tools-portage /usr/portage/*/*/metadata.xml |
awk -F'/' '{printf(%s/%s\n, $4, $5)}')
* app-portage/deltup [gentoo]
None specified
-- I don't know anything about this package.
* app-portage/eclass-manpages [gentoo]
vap...@gentoo.org
-- Actively maintained by Mike.
* app-portage/elogv [gentoo]
fuzzy...@gentoo.org (Paul Varner)
sp...@gentoo.org (Sebastian Pipping)
-- Being maintained more by Sebastian than myself.
* app-portage/elogviewer [gentoo]
fuzzy...@gentoo.org (Paul Varner)
-- Effectively unmaintained, I can't find the upstream repository and I
haven't done anything with it recently.
* app-portage/epm [gentoo]
None specified
-- Old perl script that mimics rpm. I've done some ebuild cleanup, but
otherwise unmaintained.
* app-portage/esearch [gentoo]
None specified
I used to maintain this; but I don't see a compelling reason to use it
over eix, so I recommend removal.
-A
-- Actively maintained by myself and Brian. Upstream repository is on
Github
* app-portage/etc-proposals [gentoo]
dol...@gentoo.org (Brian Dolbec)
-- Actively maintained by Brian
* app-portage/euses [gentoo]
j...@gentoo.org (Jeroen Roovers)
-- Actively maintained by Jeroen
* app-portage/genlop [gentoo]
None specified
-- Not actively being maintained although fixes have been made in the
upstream gentoo-perl repository on Github. it might be appropriate to
transfer this to the gentoo-perl herd.
* app-portage/gentoolkit-dev [gentoo]
None specified
-- Actively maintained by Christian.
* app-portage/gentoolkit [gentoo]
None specified
-- Actively maintained by Paul and Brian
* app-portage/gpytage [gentoo]
dol...@gentoo.org (Brian Dolbec)
-- Brian took over maintenance. Not sure of active status
* app-portage/layman [gentoo]
dol...@gentoo.org (Brian Dolbec)
-- Brian is actively maintaining
* app-portage/maintainer-helper [local]
None specified
-- Not actively maintained, it really needs a maintainer or be dropped
from the tree.
* app-portage/mirrorselect [gentoo]
None specified
-- Actively maintained by various people.
* app-portage/porthole [gentoo]
dol...@gentoo.org (Brian Dolbec)
Upstream Maintainer (please CC on bugs)
-- Actively maintained by Brian
* app-portage/splat [gentoo]
None specified
-- I don't know anything about this package. Upstream URL is dead.
* app-portage/udept [local]
fuzzy...@gentoo.org
-- Effectively last rited, due to dead upstream. Still in tree in hard
masked status due to no replacement. However, in the time that it has
been hard masked, there has not been anyone to step up and either fork
or create a replacement.
* app-portage/ufed [gentoo]
None specified
-- Not being maintained since Harald retired and needs a maintainer.
Repository is on overlays.g.o
* dev-util/bdelta [gentoo]
sly...@gentoo.org (Sergei Trofimovich)
Primary Maintainer
-- I don't know anything about this package. Based on the ChangeLog,
Sergei is actively maintaining it.
Re: [gentoo-portage-dev] tools-portage packages
On Wed, Jul 18, 2012 at 8:09 PM, Christian Ruppert id...@gentoo.org wrote:
On 07/17/12 at 03:48PM -0500, Paul Varner wrote:
All:
(Apologies if you get this twice. I never saw my initial send of the
message hit the mailing list)
Sending this here before I send to the gentoo-dev list. Below is the
list of packages that are managed by the tools-portage herd and their
maintainer (if any). I know we have several packages in the herd that
are not being maintained and I would like to either get a maintainer or
last rite the package. I've included comments on what I know about the
packages.
$ equery meta -m $(fgrep tools-portage /usr/portage/*/*/metadata.xml |
awk -F'/' '{printf(%s/%s\n, $4, $5)}')
* app-portage/deltup [gentoo]
None specified
-- I don't know anything about this package.
* app-portage/eclass-manpages [gentoo]
vap...@gentoo.org
-- Actively maintained by Mike.
* app-portage/elogv [gentoo]
fuzzy...@gentoo.org (Paul Varner)
sp...@gentoo.org (Sebastian Pipping)
-- Being maintained more by Sebastian than myself.
* app-portage/elogviewer [gentoo]
fuzzy...@gentoo.org (Paul Varner)
-- Effectively unmaintained, I can't find the upstream repository and I
haven't done anything with it recently.
* app-portage/epm [gentoo]
None specified
-- Old perl script that mimics rpm. I've done some ebuild cleanup, but
otherwise unmaintained.
* app-portage/esearch [gentoo]
None specified
-- Actively maintained by myself and Brian. Upstream repository is on
Github
* app-portage/etc-proposals [gentoo]
dol...@gentoo.org (Brian Dolbec)
-- Actively maintained by Brian
* app-portage/euses [gentoo]
j...@gentoo.org (Jeroen Roovers)
-- Actively maintained by Jeroen
* app-portage/genlop [gentoo]
None specified
-- Not actively being maintained although fixes have been made in the
upstream gentoo-perl repository on Github. it might be appropriate to
transfer this to the gentoo-perl herd.
* app-portage/gentoolkit-dev [gentoo]
None specified
-- Actively maintained by Christian.
I'll keep maintaining it so far, mostly echangelog.
* app-portage/gentoolkit [gentoo]
None specified
-- Actively maintained by Paul and Brian
* app-portage/gpytage [gentoo]
dol...@gentoo.org (Brian Dolbec)
-- Brian took over maintenance. Not sure of active status
* app-portage/layman [gentoo]
dol...@gentoo.org (Brian Dolbec)
-- Brian is actively maintaining
* app-portage/maintainer-helper [local]
None specified
-- Not actively maintained, it really needs a maintainer or be dropped
from the tree.
* app-portage/mirrorselect [gentoo]
None specified
-- Actively maintained by various people.
I guess I will still try to fix bugs (mostly major ones) when there are some.
I will fix bugs in the script if someone does the ebuild work or proxies for me.
-A
* app-portage/porthole [gentoo]
dol...@gentoo.org (Brian Dolbec)
Upstream Maintainer (please CC on bugs)
-- Actively maintained by Brian
* app-portage/splat [gentoo]
None specified
-- I don't know anything about this package. Upstream URL is dead.
* app-portage/udept [local]
fuzzy...@gentoo.org
-- Effectively last rited, due to dead upstream. Still in tree in hard
masked status due to no replacement. However, in the time that it has
been hard masked, there has not been anyone to step up and either fork
or create a replacement.
* app-portage/ufed [gentoo]
None specified
-- Not being maintained since Harald retired and needs a maintainer.
Repository is on overlays.g.o
* dev-util/bdelta [gentoo]
sly...@gentoo.org (Sergei Trofimovich)
Primary Maintainer
-- I don't know anything about this package. Based on the ChangeLog,
Sergei is actively maintaining it.
--
Regards,
Christian Ruppert
Gentoo Linux developer, Bugzilla administrator and Infrastructure member
Fingerprint: EEB1 C341 7C84 B274 6C59 F243 5EAB 0C62 B427 ABC8
Re: [gentoo-portage-dev] Try to specify how to get that a USE flag is present in current ebuild
On Sat, Sep 22, 2012 at 7:22 PM, Pacho Ramos pa...@gentoo.org wrote:
El sáb, 22-09-2012 a las 13:54 -0400, Mike Frysinger escribió:
On Friday 21 September 2012 15:08:20 Pacho Ramos wrote:
In that one, we try to use the following:
has vala ${IUSE//+/} ! use vala return 0
inherit eutils
use_if_iuse vala
-mike
I am aware of that one also, but Ciaran also wants to forbid it for the
same reason :S
Well I assume Ciaran wants to forbid it because he is attempting to
write a PMS compliant PM; but in order to use these ebuilds properly
he has to emulate the unspecified behavior that the ebuilds rely on
upon. His claim is that the council is supposed to forbid this
behavior (presumably to make his job less horrible) but I don't see
them beating down your door to change it (and the behavior is not
new.)
-A
Re: [gentoo-portage-dev] [PATCH] econf: update configure/config.{sub,guess} atomically to avoid races
LGTM
On Tue, Dec 17, 2013 at 4:26 PM, Brian Dolbec dol...@gentoo.org wrote:
On Tue, 2013-12-17 at 18:28 -0500, Mike Frysinger wrote:
Use $BASHPID which will be unique even in subshells.
URL: https://bugs.gentoo.org/487478
---
bin/phase-helpers.sh | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/bin/phase-helpers.sh b/bin/phase-helpers.sh
index ec48c94..1a7ae03 100644
--- a/bin/phase-helpers.sh
+++ b/bin/phase-helpers.sh
@@ -469,6 +469,7 @@ unpack() {
econf() {
local x
+ local pid=${BASHPID}
if ! ___eapi_has_prefix_variables; then
local EPREFIX=
@@ -501,18 +502,22 @@ econf() {
if [[ -n $CONFIG_SHELL \
$(head -n1 $ECONF_SOURCE/configure) =~
^'#!'[[:space:]]*/bin/sh([[:space:]]|$) ]] ; then
# preserve timestamp, see bug #440304
- touch -r $ECONF_SOURCE/configure
$ECONF_SOURCE/configure._portage_tmp_.$$ || die
- sed -e
1s:^#![[:space:]]*/bin/sh:#!$CONFIG_SHELL: -i $ECONF_SOURCE/configure
|| \
- die Substition of shebang in
'$ECONF_SOURCE/configure' failed
- touch -r
$ECONF_SOURCE/configure._portage_tmp_.$$ $ECONF_SOURCE/configure || die
- rm -f $ECONF_SOURCE/configure._portage_tmp_.$$
+ touch -r ${ECONF_SOURCE}/configure
${ECONF_SOURCE}/configure._portage_tmp_.${pid} || die
+ sed -i \
+ -e
1s:^#![[:space:]]*/bin/sh:#!$CONFIG_SHELL: \
+ ${ECONF_SOURCE}/configure \
+ || die Substition of shebang in
'${ECONF_SOURCE}/configure' failed
+ touch -r
${ECONF_SOURCE}/configure._portage_tmp_.${pid}
${ECONF_SOURCE}/configure || die
+ rm -f
${ECONF_SOURCE}/configure._portage_tmp_.${pid}
fi
if [ -e ${EPREFIX}/usr/share/gnuconfig/ ]; then
find ${WORKDIR} -type f '(' \
-name config.guess -o -name config.sub ')' -print0
| \
while read -r -d $'\0' x ; do
__vecho * econf: updating
${x/${WORKDIR}\/} with ${EPREFIX}/usr/share/gnuconfig/${x##*/}
- cp -f
${EPREFIX}/usr/share/gnuconfig/${x##*/} ${x}
+ # Make sure we do this atomically incase
we're run in parallel. #487478
+ cp -f
${EPREFIX}/usr/share/gnuconfig/${x##*/} ${x}.${pid}
+ mv -f ${x}.${pid} ${x}
done
fi
Sorry, my bash skills are not enough to review this stuff. Others will
have to reply :)
--
Brian Dolbec dol...@gentoo.org
Re: [gentoo-portage-dev] [PATCH] econf: update configure/config.{sub,guess} atomically to avoid races
On Tue, Dec 17, 2013 at 5:41 PM, Greg Turner g...@malth.us wrote:
On Tue, Dec 17, 2013 at 3:28 PM, Mike Frysinger vap...@gentoo.org wrote:
+ sed -i \
+ -e
1s:^#![[:space:]]*/bin/sh:#!$CONFIG_SHELL: \
+ ${ECONF_SOURCE}/configure \
+ || die Substition of shebang in
'${ECONF_SOURCE}/configure' failed
Shouldn't we take the same copy, ${pid}-suffix, move approach, here
that we've done with config.{sub,guess}? Otherwise, what's to stop
these sed's from trampling each other's work-in-progress (the fact
that ebuilds don't crash left and right does suggest that some
mechanism actually does prevent this, already -- but it's a mystery to
me, and I worry it could be some kind of linux-specific filesystem
quirk).
Sed is already atomic
antarus@goats5 /tmp/test $ cat foo
Debian Rocks!
antarus@goats5 /tmp/test $ strace -e trace=file sed -i -e
's/Debian/Gentoo/g' foo
execve(/bin/sed, [sed, -i, -e, s/Debian/Gentoo/g, foo], [/* 39
vars */]) = 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or
directory)
open(/etc/ld.so.cache, O_RDONLY|O_CLOEXEC) = 3
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
open(/lib/x86_64-linux-gnu/libselinux.so.1, O_RDONLY|O_CLOEXEC) = 3
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
open(/lib/x86_64-linux-gnu/libc.so.6, O_RDONLY|O_CLOEXEC) = 3
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
open(/lib/x86_64-linux-gnu/libdl.so.2, O_RDONLY|O_CLOEXEC) = 3
statfs(/selinux, {f_type=EXT2_SUPER_MAGIC, f_bsize=4096,
f_blocks=5419717, f_bfree=920598, f_bavail=645285, f_files=1379040,
f_ffree=885151, f_fsid={-495840576, 2082046975}, f_namelen=255,
f_frsize=4096}) = 0
open(/proc/filesystems, O_RDONLY) = 3
open(/usr/lib/locale/locale-archive, O_RDONLY|O_CLOEXEC) = 3
open(//lib/charset.alias, O_RDONLY) = -1 ENOENT (No such file or
directory)
open(/usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache, O_RDONLY) = 3
open(foo, O_RDONLY) = 3
open(/proc/filesystems, O_RDONLY) = 4
open(./sedfDxBxl, O_RDWR|O_CREAT|O_EXCL, 0600) = 4
rename(./sedfDxBxl, foo)= 0
-A
-gmt
Re: [gentoo-portage-dev] [PATCH] econf: update configure/config.{sub,guess} atomically to avoid races
On Tue, Dec 17, 2013 at 6:53 PM, Greg Turner g...@malth.us wrote: On Tue, Dec 17, 2013 at 5:58 PM, Alec Warner anta...@gentoo.org wrote: Sed is already atomic antarus@goats5 /tmp/test $ cat foo Debian Rocks! antarus@goats5 /tmp/test $ strace -e trace=file sed -i -e 's/Debian/Gentoo/g' foo [snip] open(foo, O_RDONLY) = 3 open(/proc/filesystems, O_RDONLY) = 4 open(./sedfDxBxl, O_RDWR|O_CREAT|O_EXCL, 0600) = 4 rename(./sedfDxBxl, foo)= 0 Nice demonstration! Been wondering about that... I originally opened the source code and tried to find the actual rename code...but gave up after about 2 minutes figuring strace would be quicker. I was right ;) -A -gmt
Re: [gentoo-portage-dev] New proposed modular sync system
On Thu, Jan 9, 2014 at 9:33 AM, Brian Dolbec dol...@gentoo.org wrote: First off, I know many of you think portage needs to do everything on it's own. NO outside dependencies. BUT! Please hear me out. While working on many of gentoo's tools gentoolkit's equery, eclean, enalyze, Layman, mirrorselect, etc.. I have found that there was a lot of needless code duplication. Both within the apps themselves and copying/re-inventing the nearly identical code in other apps. I want to move many of gentoo's core applications to using some more shared libraries. But that in itself is not a topic to discuss in this thread. Please, do not sidetrack this thread. The above is only for background info leading to this proposed change. This proposal follows along that thinking. Many years ago after re-writing ecleans code I began re-writing portage's emaint code so that it could be imported and used internally in eclean to re-generate the Packages binpkg index file. In that code I found a todo which said make a plug-in system so we don't have to keep modifying this code or something along those lines. So I did. It took 4 years+, rebasing many times and migrating vcs's, but Zac finally merged it. It has been used in portage for more than a year. That plug-in system I designed to be very flexible and basic. It can be used for many areas of portage to simplify it's code and the maintenance required to keep current with changes in repository types, and transfer methods. I have started a Proposals sub-page under the Portage project page in the wiki. It has a link to a diagram I made showing how the plug-in system is laid out. This thread will be used to discuss the proposal and the details needed for the module_spec dictionary that is used to provide the manager with the details of what a module provides, options, etc.. For a working example of the system in action, just try out emaint -h, and some other actions it provides. Then move one of it's modules out of the the emaint/modules/ directory and re-try emaint -h. You will see the options for that module and it's actions are no longer available. No code editing was required, no errors occurred,... Put it back, retry... The modular sync system I propose would re-use that plug-in manager to interface the sync manager code with the modules that perform the sync actions. This sytem is easily extended with new modules for different transfer methods or VCS specific modules. This also makes it possible for other gentoo applications like layman to install a layman specific module which syncs all layman overlays that it installs. All this done with out effort on the part of the portage team either for maintenance or code changes to support it's addition. The same can be said for Funtoo, if our git module is not suiotable, they just install their own custom sync module. Done :) These add-on sync modules can also be installed via their own ebuild. For example: Zac has for years had a custom script that syncs the portage tree and makes a squashfs version of it which he uses for his PORTDIR. it is faster than a normal one. He, or someone else could make a app-portage/squashfs-sync ebuild that installs a module for that purpose. The user then just needs to edit his repos.conf file and change the sync-type to squashfs. Then emerge --sync will do it automatically without user intervention and auxiliary scripts run manually or cron job. This system would also make it possible to modify emerge-s cli to accept target repos to sync. and not any others also installed. Similarly to layman -s some-overlay, emerge --sync some-overlay I think the opposition to this idea primarily falls on reliability. There have been a number of hacks to portage over the years to keep it functioning during upgrades of itself, even down to the non-standard place where its .py files are stored (/usr/lib/portage/pym?) So the real question is when we move to a plug-in architecture, how do we add, remove, upgrade the plugins without breaking the actual package manager? -A P.S. sorry for such a long email -- Brian Dolbec dol...@gentoo.org
Re: [gentoo-portage-dev] [PATCH 1/3] Have repoman check if the packages to unpack rare archive formats from SRC_URI are present in DEPEND (bug #205909).
On Wed, Jan 15, 2014 at 4:07 PM, Tom Wijsman tom...@gentoo.org wrote:
---
bin/repoman | 53 +
man/repoman.1 | 4
2 files changed, 57 insertions(+)
I urge you to not author new checks like this. /usr/bin/repoman is already
a mess.
Write these checks as functions, put them in a different file, and just
call them from the giant messy loop. At least that way the checks are self
contained (great for avoiding things like variable re-use or shadowing).
-A
diff --git a/bin/repoman b/bin/repoman
index d1542e9..9b703dc 100755
--- a/bin/repoman
+++ b/bin/repoman
@@ -36,6 +36,9 @@ pym_path =
osp.join(osp.dirname(osp.dirname(osp.realpath(__file__))), pym)
sys.path.insert(0, pym_path)
import portage
portage._internal_caller = True
+
+from portage._sets.profiles import PackagesSystemSet
+system_set_atoms = PackagesSystemSet(portage.settings.profiles).getAtoms()
portage._disable_legacy_globals()
try:
@@ -300,6 +303,7 @@ qahelp = {
inherit.missing: Ebuild uses functions from an eclass but does
not inherit it,
inherit.unused: Ebuild inherits an eclass but does not use it,
java.eclassesnotused: With virtual/jdk in DEPEND you must
inherit a java eclass,
+ unpack.DEPEND.missing: A rare archive format was used in
SRC_URI, but its package to unpack it is missing in DEPEND.,
wxwidgets.eclassnotused: Ebuild DEPENDs on x11-libs/wxGTK
without inheriting wxwidgets.eclass,
KEYWORDS.dropped: Ebuilds that appear to have dropped KEYWORDS
for some arch,
KEYWORDS.missing: Ebuilds that have a missing or empty KEYWORDS
variable,
@@ -399,6 +403,7 @@ qawarnings = set((
metadata.warning,
portage.internal,
repo.eapi.deprecated,
+unpack.DEPEND.missing,
usage.obsolete,
upstream.workaround,
LIVEVCS.stable,
@@ -479,6 +484,25 @@ ruby_deprecated = frozenset([
ruby_targets_ree18,
])
+# TODO: Add functionality to support checking for deb2targz on platforms
where
+# GNU binutils is absent; see PMS 5, section 11.3.3.13.
+archive_formats = {
+ \.7[zZ]:app-arch/p7zip,
+ \.(bz2?|tbz2):app-arch/bzip2,
+ \.jar:app-arch/unzip,
+ \.(LH[aA]|lha|lzh):app-arch/lha,
+ \.lzma:app-arch/lzma-utils,
+ \.(rar|RAR):app-arch/unrar,
+ \.(tar(\.(bz2?|gz|Z))?|tbz2|t[bg]z)?:app-arch/tar,
+ \.(gz|tar\.Z|t[bg]z|[zZ]):app-arch/gzip,
+ \.(zip|ZIP):app-arch/unzip,
+}
+
+archive_formats_eapi_3_to_5 = {
+ \.tar.xz:app-arch/tar,
+ \.xz:app-arch/xz-utils,
+}
+
metadata_xml_encoding = 'UTF-8'
metadata_xml_declaration = '?xml version=1.0 encoding=%s?' % \
(metadata_xml_encoding,)
@@ -1559,6 +1583,7 @@ for x in effective_scanlist:
fetchlist_dict = portage.FetchlistDict(checkdir, repoman_settings,
portdb)
myfiles_all = []
src_uri_error = False
+ needed_unpack_depends = {}
for mykey in fetchlist_dict:
try:
myfiles_all.extend(fetchlist_dict[mykey])
@@ -1573,7 +1598,22 @@ for x in effective_scanlist:
stats[SRC_URI.syntax] += 1
fails[SRC_URI.syntax].append(
%s.ebuild SRC_URI: %s % (mykey,
e))
+
+ # Compare each SRC_URI entry against archive_formats; if
one of the
+ # extensions match, we remember which archive depends are
needed to
+ # check them later on.
+ needed_unpack_depends[mykey] = []
+ for file_extension in archive_formats or \
+ ((re.match('[345]$', eapi) is not None) \
+ and file_extension in
archive_formats_eapi_3_to_5):
+ for entry in fetchlist_dict[mykey]:
+ if re.match('.*%s$' % file_extension,
entry) is not None:
+ format =
archive_formats[file_extension]
+
+ if format not in
needed_unpack_depends[mykey]:
+
needed_unpack_depends[mykey].append(format)
del fetchlist_dict
+
if not src_uri_error:
# This test can produce false positives if SRC_URI could
not
# be parsed for one or more ebuilds. There's no point in
@@ -2010,6 +2050,17 @@ for x in effective_scanlist:
atoms = None
badsyntax.append(str(e))
+ if atoms and mytype == 'DEPEND':
+ # We check whether the needed archive
dependencies are present
+ # in DEPEND, which were determined from
SRC_URI.
+ for entry in needed_unpack_depends[catdir
+ '/' + y]:
+ if entry not in system_set_atoms
and entry \
+
Re: [gentoo-portage-dev] Signing off patches
On Thu, Jan 16, 2014 at 5:20 AM, Alexander Berntsen alexan...@plaimi.netwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 We have quite a few dedicated developers now. To ensure that good taste is exercised, and that best practices are followed, patches should be signed. I'm confused, are you proposing all patches have all of these fields? Or we should simply cherry-pick the fields we think are useful? My proposals: Signed-off-by: Wrote (a substantial portion of) the patch Reviewed-by: Reviewed the patch thoroughly Tested-by: Tested the patch thoroughly Acked-by: Approved the concept but did not read the patch in detail (typically used by the maintainer of a specific portion, or our lead) Suggested-by: Designed the implementation Reported-by: Reported the bug/feature request These suggestions all stem from the Linux project. - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLX3JsACgkQRtClrXBQc7VhEQD9FKmFbyf9zxl+hLylkhQN/kv6 o3DSM4xBr9fH4+1eokYA/3MbFLtDpli311d6ZqGD17kGLfz5wNj+5kPRATbiC256 =cJNe -END PGP SIGNATURE-
Re: [gentoo-portage-dev] [PATCH 3/3] pym/portage/package/ebuild/fetch.py: Factor out _get_uris
On Sat, Jan 18, 2014 at 7:07 PM, W. Trevor King wk...@tremily.us wrote:
The current fetch() function is quite long, which makes it hard to
know what I can change without adverse side effects. By pulling this
logic out of the main function, we get clearer logic in fetch() and
more explicit input for the config extraction.
This block was especially complicated, so I also created the helper
functions _get_file_uri_tuples and _expand_mirror. I'd prefer if
_expand_mirror iterated through URIs instead of (group, URI) tuples,
but we need a distinct marker for third-party URIs to build
third_party_mirror_uris which is used to build primaryuri_dict which
is used way down in fetch():
if checksum_failure_count == \
checksum_failure_primaryuri:
# Switch to primaryuri mode in order
# to increase the probablility of
# of success.
primaryuris = \
primaryuri_dict.get(myfile)
if primaryuris:
uri_list.extend(
reversed(primaryuris))
I don't know if this is useful enough to motivate the uglier
_expandmirror return values, but I'll kick that can down the road for
now.
---
pym/portage/package/ebuild/fetch.py | 197
+---
1 file changed, 117 insertions(+), 80 deletions(-)
diff --git a/pym/portage/package/ebuild/fetch.py
b/pym/portage/package/ebuild/fetch.py
index bd572fa..a617945 100644
--- a/pym/portage/package/ebuild/fetch.py
+++ b/pym/portage/package/ebuild/fetch.py
@@ -15,9 +15,9 @@ import sys
import tempfile
try:
- from urllib.parse import urlparse
+ from urllib.parse import urlparse, urlunparse
except ImportError:
- from urlparse import urlparse
+ from urlparse import urlparse, urlunparse
import portage
portage.proxy.lazyimport.lazyimport(globals(),
@@ -297,6 +297,118 @@ def _get_fetch_resume_size(settings, default='350K'):
return v
+def _get_file_uri_tuples(uris):
+ Return a list of (filename, uri) tuples
+
As mike noted on another thread:
Return a list of (filename, uri) tuples.
+ file_uri_tuples = []
+ # Check for 'items' attribute since OrderedDict is not a dict.
+ if hasattr(uris, 'items'):
+ for filename, uri_set in uris.items():
+ for uri in uri_set:
+ file_uri_tuples.append((filename, uri))
+ if not uri_set:
+ file_uri_tuples.append((filename, None))
+ else:
+ for uri in uris:
+ if urlparse(uri).scheme:
+ file_uri_tuples.append(
+ (os.path.basename(myuri), myuri))
+ else:
+ file_uri_tuples.append(
+ (os.path.basename(myuri), None))
+ return file_uri_tuples
+
+
+def _expand_mirror(uri, custom_mirrors=(), third_party_mirrors=()):
+ Replace the 'mirror://' scheme in the uri
Sentence should end in a period.
+
+ Returns an iterable listing expanded (group, URI) tuples,
+ where the group is either 'custom' or 'third-party'.
+
+ parsed = urlparse(uri)
+ mirror = parsed.netloc
+ path = parsed.path
+ if path:
+ # Try user-defined mirrors first
+ if mirror in custom_mirrors:
+ for cmirr in custom_mirrors[mirror]:
+ m_uri = urlparse(cmirr)
+ yield ('custom', urlunparse((
+ cmirr.scheme, cmirr.netloc, path) +
+ parsed[3:]))
+
+ # now try the official mirrors
+ if mirror in third_party_mirrors:
+ uris = []
+ for locmirr in third_party_mirrors[mirror]:
+ m_uri = urlparse(cmirr)
+ uris.append(urlunparse((
+ cmirr.scheme, cmirr.netloc, path) +
+ parsed[3:]))
+ random.shuffle(uris)
+ for uri in uris:
+ yield ('third-party', uri)
+ else:
+ writemsg(_(Invalid mirror definition in SRC_URI:\n),
+noiselevel=-1)
+ writemsg( %s\n % (uri), noiselevel=-1)
Is this a py3k thing? You should be able to write:
writemsg( %s\n % uri, noiselevel=-1)
The tuple is only needed for multiple arguments in py2k.
+
+
+def _get_uris(uris, settings, custom_mirrors=(), locations=()):
I want you to be careful here. This is bad style when you are constructing
mutable objects in parameter defaults:
def func(a=[]):
... a.append(5)
...
del func
def func(a=[]):
...
Re: [gentoo-portage-dev] [PATCH v2 1/3] pym/portage/package/ebuild/fetch.py: Factor out _get_checksum_failure_max_tries
On Sun, Jan 19, 2014 at 2:44 PM, Alec Warner anta...@gentoo.org wrote:
On Sun, Jan 19, 2014 at 2:14 PM, W. Trevor King wk...@tremily.us wrote:
The current fetch() function is quite long, which makes it hard to
know what I can change without adverse side effects. By pulling this
logic out of the main function, we get clearer logic in fetch() and
more explicit input for the config extraction.
---
pym/portage/package/ebuild/fetch.py | 59
+
1 file changed, 34 insertions(+), 25 deletions(-)
diff --git a/pym/portage/package/ebuild/fetch.py
b/pym/portage/package/ebuild/fetch.py
index 5316f03..6f46572 100644
--- a/pym/portage/package/ebuild/fetch.py
+++ b/pym/portage/package/ebuild/fetch.py
@@ -240,6 +240,38 @@ _size_suffix_map = {
'Y' : 80,
}
+
+def _get_checksum_failure_max_tries(settings, default=5):
+
+ Get the maximum number of failed download attempts
+
+ Generally, downloading the same file repeatedly from
+ every single available mirror is a waste of bandwidth
+ and time, so there needs to be a cap.
+
+ v = default
+ try:
+ v = int(settings.get(PORTAGE_FETCH_CHECKSUM_TRY_MIRRORS,
+ default))
+ except (ValueError, OverflowError):
+ writemsg(_(!!! Variable
PORTAGE_FETCH_CHECKSUM_TRY_MIRRORS
+contains non-integer value: '%s'\n) % \
+ settings[PORTAGE_FETCH_CHECKSUM_TRY_MIRRORS],
+ noiselevel=-1)
+ writemsg(_(!!! Using PORTAGE_FETCH_CHECKSUM_TRY_MIRRORS
+ default value: %s\n) % default,
+ noiselevel=-1)
+ v = default
+ if v 1:
+ writemsg(_(!!! Variable
PORTAGE_FETCH_CHECKSUM_TRY_MIRRORS
+contains value less than 1: '%s'\n) % v,
noiselevel=-1)
+ writemsg(_(!!! Using PORTAGE_FETCH_CHECKSUM_TRY_MIRRORS
+ default value: %s\n) % default,
+ noiselevel=-1)
+ v = default
+ return v
+
+
This function and the next function you wrote are identical. How about
making a single function?
def getValueFromSettings(settings, key, default, validator):
try:
return validator(settings.get(key, default))
except ValidationError as e:
# writemsg the exception, it will contain the juicy bits.)
def getIntValueFromSettings(settings, key, default):
def validator(v):
try:
v = int(v)
except (ValueError, OverflowError) as e:
raise ValidationError( bla bla bla not an int, we picked the
default.)
if v 1:
v = default
raise ValidationError(bla bla bla less than one we used the
defualt.)
return getValueFromSettings(settings, key, default, validator)
Note, don't actually use these function names, they are terrible.
-A
Then we are not necessarily writing a bunch of the same functions over and
over. The defaults we can stick in a config file, or in python, or at the
call site.
-A
def fetch(myuris, mysettings, listonly=0, fetchonly=0,
locks_in_subdir=.locks, use_locks=1, try_mirrors=1,
digests=None,
allow_missing_digests=True):
@@ -263,31 +295,8 @@ def fetch(myuris, mysettings, listonly=0,
fetchonly=0,
print(_( \mirror\ mode desired and
\mirror\ restriction found; skipping fetch.))
return 1
- # Generally, downloading the same file repeatedly from
- # every single available mirror is a waste of bandwidth
- # and time, so there needs to be a cap.
- checksum_failure_max_tries = 5
- v = checksum_failure_max_tries
- try:
- v =
int(mysettings.get(PORTAGE_FETCH_CHECKSUM_TRY_MIRRORS,
- checksum_failure_max_tries))
- except (ValueError, OverflowError):
- writemsg(_(!!! Variable
PORTAGE_FETCH_CHECKSUM_TRY_MIRRORS
-contains non-integer value: '%s'\n) % \
- mysettings[PORTAGE_FETCH_CHECKSUM_TRY_MIRRORS],
noiselevel=-1)
- writemsg(_(!!! Using PORTAGE_FETCH_CHECKSUM_TRY_MIRRORS
- default value: %s\n) %
checksum_failure_max_tries,
- noiselevel=-1)
- v = checksum_failure_max_tries
- if v 1:
- writemsg(_(!!! Variable
PORTAGE_FETCH_CHECKSUM_TRY_MIRRORS
-contains value less than 1: '%s'\n) % v,
noiselevel=-1)
- writemsg(_(!!! Using PORTAGE_FETCH_CHECKSUM_TRY_MIRRORS
- default value: %s\n) %
checksum_failure_max_tries,
- noiselevel=-1)
- v = checksum_failure_max_tries
- checksum_failure_max_tries = v
- del v
+ checksum_failure_max_tries
Re: [gentoo-portage-dev] [PATCH 0/3] Initial fetch() refactoring
On Sun, Jan 19, 2014 at 2:45 PM, Alexander Berntsen alexan...@plaimi.netwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 19/01/14 22:22, Sebastian Luther wrote: The usual doc string style used in portage is: text Please use that for new functions. Also make sure you don't use spaces to indent the last . As mentioned by Mike in another thread, we should use PEP 257[0]. I will convert old code to conform to this... sometime... soon... (I promise!) So if new patches could just do that right away, that would be neat. Does pylint or pyflakes point out if you mess it up? Automation for the win. -A [0] http://www.python.org/dev/peps/pep-0257/ - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLcVaAACgkQRtClrXBQc7XjTwD/UsCQo+SJdiCX/QsMC8jFDPic k0jEAN6DA5xML6/nJYQA/36FszMfVMZ/vzg5VF9FS6BDWwGm/Qy2whyqLiF3FOrX =+5Yy -END PGP SIGNATURE-
Re: [gentoo-portage-dev] [PATCH 0/3] Initial fetch() refactoring
On Sun, Jan 19, 2014 at 2:50 PM, Alexander Berntsen alexan...@plaimi.netwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 19/01/14 23:46, Alec Warner wrote: Does pylint or pyflakes point out if you mess it up? Not very successfully in my experience. I'm very against add a bunch of extra rules that have to be enforced by hand. I want to make it easy to contribute, not more difficult. If bob can run a tool that tells him all the things that are wrong with his patch, that avoids us having like 1/3rd of the conversations on list ;) -A - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLcVrsACgkQRtClrXBQc7XZcQD9GD8lV8HpZbQjpqu8ggNh4vOo /fvFsCI2PaWiEsC4ISUA/iYRiXAYD7SEF4a3R/t6vOdmEQSHyvZcxH9NDwI4/biQ =RMJ0 -END PGP SIGNATURE-
Re: [gentoo-portage-dev] [PATCH 0/3] Initial fetch() refactoring
On Sun, Jan 19, 2014 at 3:51 PM, Alexander Berntsen alexan...@plaimi.netwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 19/01/14 23:54, Alec Warner wrote: I'm very against add a bunch of extra rules that have to be enforced by hand. I want to make it easy to contribute, not more difficult. If bob can run a tool that tells him all the things that are wrong with his patch, that avoids us having like 1/3rd of the conversations on list ;) Feel free to write a tool for this, or to contribute to any of the numerous linters and/or editor plug-ins. It would be much appreciated. I already prefer pylint, and I think it does cover most of what I want. I am working a pylintrc patch. As for the difficulty of PEP 257... I have higher hopes for Portage contributors than getting stuck at that. If I write a patch that makes most of the docstrings follow it, then they can infer 99% of the extra rules by just looking at the other functions and methods. If they fail to comply, we can just mention it. If the docstring formatting is the biggest issue with their patch, I doubt they'll have a hard time fixing it. I'm not saying its hard, I'm saying it is a giant waste of time for the list to tell people 'hey your docstrings are wrong' when they can just run a tool to do it ;) -A - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLcZPQACgkQRtClrXBQc7XizAD/Y/Gxc7N6VkgNFWRgP5lmQ84r UwSne2xaqJYphY9x1TcBAIRpjBHB580edLz/8zpT14lqhW3oOmeMz0pNMB8ssW5d =+zp5 -END PGP SIGNATURE-
Re: [gentoo-portage-dev] [PATCH 1/3 v2] Have repoman check if the packages to unpack rare archive formats from SRC_URI are present in DEPEND (bug #205909).
On Sun, Jan 19, 2014 at 6:23 PM, Tom Wijsman tom...@gentoo.org wrote:
On Sun, 19 Jan 2014 04:38:31 -0500
Mike Frysinger vap...@gentoo.org wrote:
On Friday 17 January 2014 18:03:57 Tom Wijsman wrote:
---
please shorten your commit summary and move more content to the body
Right, I'm used to writing this on the command line; I'll try to look
into setting up an editor or a GUI (gitg, ...) to do my commit messages.
+getNonSystemArchiveDepends.archivers = {
it is super weird to attach to the object like this. some might even
say wrong.
It a function, this makes it a static function variable.
What is weird here? It works properly, what would be wrong?
It is certainly weird (as we discussed on IRC.) I've never seen anyone do
it in any codebase I liked.
One of the problems is that it isn't immutable, so that earlier callers can
mess with later callers. That is not possible in vapier's proposal, as the
attributes are hidden in the function code and are not visible to callers.
move it into the class definition.
def getNonSystemArchiveDepends(fetchlist, eapi):
...
ARCHIVERS = {
...
}
That makes it a non-static function variable? This is a regression.
I guess I am not seeing why it must be a static function variable. Can you
explain?
+ re.compile('.*\.7[zZ]$'):app-arch/p7zip,
regexes should always use raw strings. there should also be a space
after the colon in dicts. so you want:
re.compile(r'.*\.7[zZ]$'): 'app-arch/p7zip',
Raw strings are a solution when \ forms a problem, which is not the
case here. The colon has no space after it in the rest of repoman near
it, hence I left it out; is there a coding standard we're trying to
respect here? Can you refer it to me?
For the colon's in dicts thing:
http://google-styleguide.googlecode.com/svn/trunk/pyguide.html#Whitespace
+ re.compile('.*\.lzma$'):app-arch/lzma-utils,
xz-utils, not lzma-utils
http://dev.gentoo.org/~ulm/pms/5/pms.html
Please see unpack in PMS 11.3.3.13 Misc Commands, quote:
lzma-compressed files (*.lzma). Ebuilds must ensure that LZMA Utils is
installed.
The TODO comment that had a PMS reference was near it before, but with
the refactor it has since moved; I'll put back the reference to it.
+ re.compile('.*\.(bz2?|tbz2)$'):app-arch/bzip2,
+
re.compile('.*\.(tar(\.(bz2?|gz|Z))?|tbz2|t[bg]z)?$'):app-arch/tar,
+ re.compile('.*\.(gz|tar\.Z|t[bg]z|[zZ])$'):app-arch/gzip,
+ re.compile('.*\.tar.xz$'):app-arch/tar,
requiring people list gzip, tar, and bzip2 is a significant policy
change (which i'm inclined to say is wrong). it needs discussion on
the dev mailing list first.
Please see unpack in PMS 11.3.3.13 Misc Commands, example quote:
gzip-compressed tar files (*.tar.gz, *.tgz, *.tar.Z, *.tbz). Ebuilds
must ensure that GNU gzip and GNU tar are installed.
To spare on mail length, I don't quote the rest of that enumeration.
The @system set in gentoo will ensure these are installed. I understand the
wording of PMS (as the dependencies should be expressed somewhere) but in
general we prefer to do that in @system. For the same reason all packages
do not depend on glibc, or the compiler, or anything else.
+def checkArchiveDepends(atoms, catpkg, relative_path, \
+ system_set_atoms, needed_unpack_depends, stats, fails):
you don't need the \ there because you have paren already to gather
things.
+ for entry in needed_unpack_depends[catpkg]:
+ if entry not in [atom.cp for atom in atoms if
atom != ||]:
+ stats['unpack.' + mytype + '.missing'] += 1
+ fails['unpack.' + mytype +
'.missing'].append( \
+ relative_path + : %s is missing
in %s % \
+ (entry, mytype))
i know existing style doesn't follow it, but imo we should avoid
string concatenation. it makes the code harder to read imo.
key = 'unpack.%s.missing' % mytype
stats[key] += 1
fails[key].append(...)
+def eapi_has_xz_utils(eapi):
+ return eapi not in (0, 1, 2)
i would use eapi_supports_xz_archives unless there's a pre-existing
style -mike
Good idea, I'll take these last ones into account in the next version.
Thank you everyone for the reviews so far.
--
With kind regards,
Tom Wijsman (TomWij)
Gentoo Developer
E-mail address : tom...@gentoo.org
GPG Public Key : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
