Re: [gentoo-dev] New Dev: antarus (Alec Warner)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Harring wrote: Hola all- We've got a new portage dev; Alec Warner, aka antarus- aside from doc work, he'll be doing repoman work and the usual random bug squashing. Welcome antarus, might I also mention that he helps out the x86 team as well. Glad to have you aboard -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD5bmPSENan+PfizARAkVKAJ4rKK88uGyntqTObyKmBMua0Ki9DQCdE8Cp c7+OJwAJ9+19Ba+CN8YjIQ8= =TDKf -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New Dev: zmedico (Zac Medico)
Brian Harring wrote: Hola all- Well looky here, we've got another new portage dev to report- Zac Medico (zmedico). Areas of focus thus far are general stable work, and work on the rewrite (you can thank him and marienz for the test framework work). Additionally, Zac is the maintainer of two external projects- http://freshmeat.net/projects/linkbrowser/ http://freshmeat.net/projects/rimanip/ Finally, he lives in Orange County, California, and is interested in progressive politics related to social justice and environmental concerns. So... say hello everyone, but kindly no leg humping (this means you Battousai). :) ~harring Nice to have you on board Zac, take care of the tree environment :-) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] IUSE and LINGUAS?
On Thursday 02 February 2006 20:55, Ciaran McCreesh wrote: [EMAIL PROTECTED] wrote: | Yeah that would help. But in the mean time what should we do? What you should always do. Do the right thing, even if repoman disagrees. Seems like repoman is actually our boss in this case, so I was forced to put the linguas_* to use.local.desc. (If you can't tell, yeah I'm using a polemic tone this time) I'm wondering if to have a solution we're going to wait till the use.local.desc file is cluttered with all the linguas_* flags. -- Diego Flameeyes Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpn4lmEr2SUE.pgp Description: PGP signature
Re: [gentoo-dev] New Dev: antarus (Alec Warner)
On 2/5/06, Brian Harring [EMAIL PROTECTED] wrote: I am currently a senior, going after a Computer Science Bachelors with a cognate ( minor basically ) in Japanese. GO gentoo-jp :) Yay, nihongo++! Welcome aboard Alec! -- Marcelo Góes [EMAIL PROTECTED] [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] IUSE and LINGUAS?
On Thursday 02 February 2006 20:55, Ciaran McCreesh wrote: but also make sure that there's a bug filed describing how repoman is broken. FWIW, I've filed that bug and attached a patch that solves the issue by letting repoman load the *.desc files in profiles dir for the use-expanded variables. Now we only need a linguas.desc that contains the right codes (lang.desc does not really sound that good, some of the codes are used in a different way by locales, like en-gb vs en_GB). -- Diego Flameeyes Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgphOi4B5s1oM.pgp Description: PGP signature
[gentoo-dev] env pollution
I have two bugs [1][2] with installs failing due to some environmental variables being set, which end up overriding the settings in the packages' makefiles, causing sandbox violations. While this is a simple enough to work around with some unsets, how much do we really want to work to fix polluted environments? I can't help but think that is not my bug, but instead (apparently) kth-krb's fault for polluting the env (the vars are seemingly worthless man and info pages paths). [1] http://bugs.gentoo.org/show_bug.cgi?id=47486 [2] http://bugs.gentoo.org/show_bug.cgi?id=121663 -- Chris PeBenito [EMAIL PROTECTED] Developer, Hardened Gentoo Linux Embedded Gentoo Linux Public Key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xE6AF9243 Key fingerprint = B0E6 877A 883F A57A 8E6A CB00 BC8E E42D E6AF 9243 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] env pollution
Chris PeBenito wrote: I have two bugs [1][2] with installs failing due to some environmental variables being set, which end up overriding the settings in the packages' makefiles, causing sandbox violations. While this is a simple enough to work around with some unsets, how much do we really want to work to fix polluted environments? I can't help but think that is not my bug, but instead (apparently) kth-krb's fault for polluting the env (the vars are seemingly worthless man and info pages paths). [1] http://bugs.gentoo.org/show_bug.cgi?id=47486 [2] http://bugs.gentoo.org/show_bug.cgi?id=121663 Particularly because those variables don't even work -- should be MANPATH and INFOPATH, not MANDIR and INFODIR. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] env pollution
On Sunday 05 February 2006 12:17, Chris PeBenito wrote: I have two bugs [1][2] with installs failing due to some environmental variables being set, which end up overriding the settings in the packages' makefiles, causing sandbox violations. While this is a simple enough to work around with some unsets, how much do we really want to work to fix polluted environments? I can't help but think that is not my bug, but instead (apparently) kth-krb's fault for polluting the env (the vars are seemingly worthless man and info pages paths). how is kth-krb polluting the env ? via env.d ? -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] IUSE and LINGUAS?
On Sunday 05 February 2006 09:51, Diego 'Flameeyes' Pettenò wrote: On Thursday 02 February 2006 20:55, Ciaran McCreesh wrote: [EMAIL PROTECTED] wrote: | Yeah that would help. But in the mean time what should we do? What you should always do. Do the right thing, even if repoman disagrees. Seems like repoman is actually our boss in this case, so I was forced to put the linguas_* to use.local.desc. that's retarded, please remove all such linguas_* crap from use.desc files -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] IUSE and LINGUAS?
On Sunday 05 February 2006 21:34, Mike Frysinger wrote: that's retarded, please remove all such linguas_* crap from use.desc files I can, but then Mr_Bones_ will come back to me again and we're stuck in this loop. You can remove them, but then it's your turn with Mr_Bones_ about them. So here it's what you can do: - remove an useful feature, but then I'll ask you why can't we use it and fix one of the other two options instead of forcing them back because of what repoman say; - tell Mr_Bones_ and who's doing QA that we don't care about what repoman say and linguas_* can remain IUSE.invalid until repoman is fixed; - leave the 10 flags there alone and wait till repoman is fixed. Up to you baby. -- Diego Flameeyes Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgphIyCXKZ02k.pgp Description: PGP signature
Re: [gentoo-dev] env pollution
On Sun, 2006-02-05 at 15:33 -0500, Mike Frysinger wrote: On Sunday 05 February 2006 12:17, Chris PeBenito wrote: I have two bugs [1][2] with installs failing due to some environmental variables being set, which end up overriding the settings in the packages' makefiles, causing sandbox violations. While this is a simple enough to work around with some unsets, how much do we really want to work to fix polluted environments? I can't help but think that is not my bug, but instead (apparently) kth-krb's fault for polluting the env (the vars are seemingly worthless man and info pages paths). how is kth-krb polluting the env ? via env.d ? Not sure as I don't use it; its what the reporter says. -- Chris PeBenito [EMAIL PROTECTED] Developer, Hardened Gentoo Linux Embedded Gentoo Linux Public Key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xE6AF9243 Key fingerprint = B0E6 877A 883F A57A 8E6A CB00 BC8E E42D E6AF 9243 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] IUSE and LINGUAS?
Mike Frysinger wrote: On Sunday 05 February 2006 09:51, Diego 'Flameeyes' Pettenò wrote: On Thursday 02 February 2006 20:55, Ciaran McCreesh wrote: [EMAIL PROTECTED] wrote: | Yeah that would help. But in the mean time what should we do? What you should always do. Do the right thing, even if repoman disagrees. Seems like repoman is actually our boss in this case, so I was forced to put the linguas_* to use.local.desc. that's retarded, please remove all such linguas_* crap from use.desc files -mike There is nowhere else to put it. It was suggested on bugs to put a new directory in $PORTDIR/metadata/desc/ and have the $USE_EXPAND.desc files in there for portage/repoman to read in. I don't have a problem with doing that but would like feedback on it before jumping right in. Obviously the QA team should be aware of the issue with USE_EXPAND and IUSE. I don't want to rush this, is my point ;) -Alec Warner signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] IUSE and LINGUAS?
On Sun, 5 Feb 2006 21:43:58 +0100 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: | On Sunday 05 February 2006 21:34, Mike Frysinger wrote: | that's retarded, please remove all such linguas_* crap from | use.desc files | | I can, but then Mr_Bones_ will come back to me again and we're stuck | in this loop. Mr_Bones_ is, in this particular instance, wrong. We do not go around changing ebuilds simply because repoman has a bug. Instead, we make sure that there's a bug filed about repoman being broken, and do the right thing in the tree. repoman is there to help catch certain kinds of common screwup, if you're lucky. It is not there to be relied upon, and it is not there to tell you what to do. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] IUSE and LINGUAS?
On Sunday 05 February 2006 15:43, Diego 'Flameeyes' Pettenò wrote: On Sunday 05 February 2006 21:34, Mike Frysinger wrote: that's retarded, please remove all such linguas_* crap from use.desc files I can, but then Mr_Bones_ will come back to me again and we're stuck in this loop. Mr_Bones_ should be aware that this is a repoman limitation, not a bug in the ebuild itself ... fix repoman, not hack other crap You can remove them, but then it's your turn with Mr_Bones_ about them. done -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] env pollution
On Sunday 05 February 2006 15:49, Christopher J. PeBenito wrote: But looking at 02kth-krb in its files directory we have: PATH=/usr/athena/bin ROOTPATH=/usr/athena/sbin LDPATH=/usr/athena/lib MANDIR=/usr/athena/man INFODIR=/usr/athena/info then, as Donnie said, kth-krb is wrong it should be using MANPATH and INFOPATH -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] IUSE and LINGUAS?
On Sunday 05 February 2006 22:04, Mike Frysinger wrote: You can remove them, but then it's your turn with Mr_Bones_ about them. done Thanks :) -- Diego Flameeyes Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp88DTyI0EEz.pgp Description: PGP signature
Re: [gentoo-dev] env pollution
On Sun, 2006-02-05 at 16:07 -0500, Mike Frysinger wrote: On Sunday 05 February 2006 15:49, Christopher J. PeBenito wrote: But looking at 02kth-krb in its files directory we have: PATH=/usr/athena/bin ROOTPATH=/usr/athena/sbin LDPATH=/usr/athena/lib MANDIR=/usr/athena/man INFODIR=/usr/athena/info then, as Donnie said, kth-krb is wrong it should be using MANPATH and INFOPATH Right. I didn't even realize the variable names were wrong. I'll reassign that bug to the kth-krb maintainer. -- Chris PeBenito [EMAIL PROTECTED] Developer, Hardened Gentoo Linux Embedded Gentoo Linux Public Key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xE6AF9243 Key fingerprint = B0E6 877A 883F A57A 8E6A CB00 BC8E E42D E6AF 9243 signature.asc Description: This is a digitally signed message part
[gentoo-dev] Depend syntax
Just a reminder that all of the following are either illegal or strongly deprecated, so please don't use them even if Portage currently lets you get away with it: DEPEND=blah You should always use the full foo-bar/blah spec inside ebuilds. DEPEND==foo-bar/blah If you specify an operator, you must also specify a version (and if you specify a version, you must also specify an operator, but Portage enforces that by way of exploding horribly). DEPEND=foo? foo-bar/blah You should always use ( ) after a use? dependency. DEPEND=foo? || ( ... ) Extension of the above: you should use ( ) after a use? even if it's immediately followed by a ||. There're quite a few oddities like this in the tree. I'll be either fixing them or filing bugs depending upon whether the package in question is maintained. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Depend syntax
On Sunday 05 February 2006 16:46, Ciaran McCreesh wrote: Just a reminder that all of the following are either illegal or strongly deprecated, so please don't use them even if Portage currently lets you get away with it: DEPEND=blah You should always use the full foo-bar/blah spec inside ebuilds. repoman should be detecting this now http://bugs.gentoo.org/42299 -mike -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Self-circular dependencies
Another not-so-uncommon issue that crops up: packages DEPENDing upon
themselves. Sometimes this is legit -- one of the Ada compilers, for
example, DEPENDs upon || ( itself another-compiler ). Sometimes,
however, it's the result of eclass screwups.
Typical example: you're coding a foo.eclass, that is used by foo and
various foo-extras. In the eclass, you set:
DEPEND==fnord-oink/foo-2.0
Which, for foo-extras, is all well and good. However, for foo, which
also inherits the foo eclass, you get h0rked deps. Portage currently
mostly ignores circular dependencies -- however, relying upon this
behaviour probably isn't a good idea.
The following inside an eclass is totally legal:
if [[ ${PN} != foo ]] ; then
DEPEND==fnord-oink/foo-2.0
fi
Please give serious thought to doing this where applicable.
A similar issue: Portage lets you block yourself, and will ignore the
block. So if foo-2.0 has DEPEND=!fnord-oink/foo, you can still
install foo. (This is a separate thing from blocking specific versions
of yourself, which you may want to do on occasion if a package has a
weird upgrade cycle or is slotted.) Again, please try to avoid relying
upon this behaviour, since it's extremely confusing.
I'll prod on IRC / file bugs for any obvious cases where it's
definitely wrong. There's also a full list, complete with a whole load
of legit cases, at:
http://dev.gentoo.org/~ciaranm/tmp/find_self_circular_deps.txt
--
Ciaran McCreesh : Gentoo Developer (King of all Londinium)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm
signature.asc
Description: PGP signature
Re: [gentoo-dev] Self-circular dependencies
On Sunday 05 February 2006 17:11, Ciaran McCreesh wrote: Another not-so-uncommon issue that crops up: packages DEPENDing upon themselves. Sometimes this is legit -- one of the Ada compilers, for example, DEPENDs upon || ( itself another-compiler ). Sometimes, however, it's the result of eclass screwups. your script doesnt take into consideration SLOT's ... the linux-gazette and gcc stuff in your log for example is a false positive -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Self-circular dependencies
On Sun, 5 Feb 2006 20:22:05 -0500 Mike Frysinger [EMAIL PROTECTED] wrote: | On Sunday 05 February 2006 17:11, Ciaran McCreesh wrote: | Another not-so-uncommon issue that crops up: packages DEPENDing upon | themselves. Sometimes this is legit -- one of the Ada compilers, for | example, DEPENDs upon || ( itself another-compiler ). Sometimes, | however, it's the result of eclass screwups. | | your script doesnt take into consideration SLOT's ... the | linux-gazette and gcc stuff in your log for example is a false | positive Yup. Easier to just leave them in and filter them manually, since in general it's impossible for a computer to decide whether some of the weird cases are correct or not. I'm not filing bugs without checking manually first, and I'd certainly hope that no-one else will either. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-portage-dev] Re: [gentoo-dev-portage] [PATCH] prevent world file corruption by writing atomically
On Mon, Jan 30, 2006 at 10:21:22AM -0800, Zac Medico wrote: Zac Medico wrote: Okay, I've created a file-like class called atomic_ostream and it is now used for both write_atomic() and writedict(). I've been using this patch locally with no problems. Do we have any more feedback or are people satisfied with it? IMO we need something like this, if not for (unsupported) parallel merges, at least to prevent loss of an important file when it is being overwritten and an IO error occurs (see bug 114133). Meh you're not supposed to call me on being a slacker for not commenting. :) No complaints with this going into svn for upcoming 2.1_pre*, but I'd like to see the class rewritten actually- the file object lacks a lot of capabilities that a normal file object has. I'd suggest deriving straight from the file class, and just doing changes in close and open. Should be a much smaller class also ;) ~harring pgpiD5Co9VAKj.pgp Description: PGP signature
Re: [gentoo-portage-dev] should CATEGORY be properly documented in ebuild.5 and declared readonly in ebuild.sh?
On Mon, Jan 30, 2006 at 12:36:42PM -0800, Zac Medico wrote: Hi everyone, The subject says it all. What do y'all think? Go for it. ~harring pgpJ5TEihqeyZ.pgp Description: PGP signature
[gentoo-portage-dev] [PATCH] atexit does not work with os.execv
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
While auditing the code related to bug 117988, I've noticed that it calls
portageexit() directly because the normal atexit hooks do not work with the
os.execv call when portage restarts itself. Currently, several other atexit
hooks exist but never get called when portage restarts itself.
Unfortunately, python's atexit module does not have a public interface for
anything but the register() function (_exithandlers and _run_exitfuncs are
accessible but undocumented). In the attached patch, I've copied the private
code (GPL compatible) directly from /usr/lib/python2.4/atexit.py so that the
functionality is duplicated in our portage_exec module. Then I've wrapped all
relevant access to the atexit module in calls to the new
portage_exec.atexit_register() function. The last hunk uses the new function
portage_exec.run_exitfuncs() to manually call the registered functions prior to
the os.execv call. Feedback would be appreciated.
Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFD5vaC/ejvha5XGaMRAmvFAJ90D3b5N6t8YiVjy4Qp0woo/tFm9wCeNwYH
QDCajTK1JPea2fg+AT7WDEs=
=8DuV
-END PGP SIGNATURE-
Index: pym/portage_locks.py
===
--- pym/portage_locks.py (revision 2671)
+++ pym/portage_locks.py (working copy)
@@ -4,7 +4,6 @@
# $Id: /var/cvsroot/gentoo-src/portage/pym/portage_locks.py,v 1.18.2.2 2005/01/16 02:35:33 carpaski Exp $
-import atexit
import errno
import os
import stat
@@ -12,6 +11,7 @@
import time
import types
import portage_exception
+import portage_exec
import portage_file
import portage_util
import portage_data
@@ -30,7 +30,7 @@
if os.path.isdir(mypath):
hardlock_path_list = mypath[:]
-atexit.register(clean_my_hardlocks)
+portage_exec.atexit_register(clean_my_hardlocks)
def lockdir(mydir):
return lockfile(mydir,wantnewlockfile=1)
Index: pym/portage.py
===
--- pym/portage.py (revision 2671)
+++ pym/portage.py (working copy)
@@ -19,7 +19,7 @@
raise SystemExit, 127
try:
- import os,string,types,atexit,signal,fcntl
+ import os,string,types,signal,fcntl
import time,cPickle,traceback,copy
import re,pwd,grp,commands
import shlex,shutil
@@ -6901,7 +6901,7 @@
close_portdbapi_caches()
commit_mtimedb()
-atexit.register(portageexit)
+portage_exec.atexit_register(portageexit)
if (secpass==2) and (not os.environ.has_key(SANDBOX_ACTIVE)):
if settings[PORTAGE_CALLER] in [emerge,fixpackages]:
Index: pym/portage_exec.py
===
--- pym/portage_exec.py (revision 2671)
+++ pym/portage_exec.py (working copy)
@@ -39,6 +39,41 @@
args.append(mycommand)
return spawn(args, opt_name=opt_name, **keywords)
+_exithandlers = []
+def atexit_register(func, *args, **kargs):
+ Wrapper around atexit.register that is needed in order to track
+ what is registered. For example, when portage restarts itself via
+ os.execv, the atexit module does not work so we have to do it
+ manually by calling the run_exitfuncs() function in this module.
+ _exithandlers.append((func, args, kargs))
+
+def run_exitfuncs():
+ This is should behave identically to the routine performed by
+ the atexit module at exit time. It's only necessary to call this
+ function when atexit will not work (because of os.execv, for
+ example).
+
+ # This function is a copy of the private atexit._run_exitfuncs()
+ # from the python 2.4.2 sources. The only difference from the
+ # original function is the string in the print statement.
+ exc_info = None
+ while _exithandlers:
+ func, targs, kargs = _exithandlers.pop()
+ try:
+ func(*targs, **kargs)
+ except SystemExit:
+ exc_info = sys.exc_info()
+ except:
+ import traceback
+ print sys.stderr, Error in portage_exec.run_exitfuncs:
+ traceback.print_exc()
+ exc_info = sys.exc_info()
+
+ if exc_info is not None:
+ raise exc_info[0], exc_info[1], exc_info[2]
+
+atexit.register(run_exitfuncs)
+
# We need to make sure that any processes spawned are killed off when
# we exit. spawn() takes care of adding and removing pids to this list
# as it creates and cleans up processes.
@@ -55,7 +90,7 @@
# of spawn().
pass
-atexit.register(cleanup)
+atexit_register(cleanup)
def spawn(mycommand, env={}, opt_name=None, fd_pipes=None, returnpid=False,
uid=None, gid=None, groups=None, umask=None, logfile=None,
Index: bin/emerge
===
--- bin/emerge (revision 2672)
+++ bin/emerge (working copy)
@@ -9,7 +9,7 @@
import portage
-import emergehelp,xpak,string,re,commands,time,shutil,traceback,atexit,signal,socket,types
+import emergehelp,xpak,string,re,commands,time,shutil,traceback,signal,socket,types
from stat import *
from output import *
@@ -492,7 +492,7 @@
emergelog( *** terminating.)
if
