Brian D. Harring wrote:
Hola all, patch (incvs now) to fix up a traceback on first sync with
an empty tree; bug #96410
http://bugs.gentoo.org/show_bug.cgi?id=96410
The fix isn't exactly what I'd call pretty (creating an intermediate
portdbapi and config instance to do the updates), but it's a
Drake Wyrm wrote:
Jason Stubbs [EMAIL PROTECTED] wrote:
When logging is enabled, ebuild output is passed via tee. Running
anything that checks for terminal type inside of pkg_config therefore
doesn't work correctly. This patch disables logging during pkg_config
altogether.
There was a
Alec Warner wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Was talking with Brian about the build environment and how settings were
to be passed into the build environment.
Essentially three scenarios were presented.
1) The full environment is passed to the build environment. This was
Brian Harring wrote:
Round 3, fixed all uglyness.
You *will* see uglyness for the changeover from flat_list to flat_hash
if you're setting portdbapi.auxdbmodule to flat_hash, but that's a one
time hit, and is the reason we blow away the cache on portage
upgrades.
Either way, full patch,
Brian Harring wrote:
Round 3, fixed all uglyness.
You *will* see uglyness for the changeover from flat_list to flat_hash
if you're setting portdbapi.auxdbmodule to flat_hash, but that's a one
time hit, and is the reason we blow away the cache on portage
upgrades.
Either way, full patch,
Paul de Vrieze wrote:
On Wednesday 31 August 2005 14:57, Brian Harring wrote:
Re: tagging EAPI at the top of a file, infra would probably shoot me for doing
such- till a live, fully compatible and *roughly* equivalent parser is
available, portage would have to do a bit of grepping, jacking
Brian Harring wrote:
On Thu, Sep 01, 2005 at 10:27:44PM -0700, Zac Medico wrote:
A better approach IMO would be to store the EAPI in a separate file such as
metadata.xml. This would allow *absolute* flexibility in the ebuild
format. Portage would be able to select an appropriate parser
Rafael Fernández López wrote:
Hi,
This is Rafael Fernández López. I'm a spanish student (computer
engineering) and I'd like to know if I can do some work for portage...
like translating it to spanish or if I see any bugs, fix them. I'm
starting to read portage code, and I'd like to know if
http://bugs.gentoo.org/show_bug.cgi?id=85803
This trivial patch seems to work for me but I'm not sure if it will cause
regressions or not. Feedback is appreciated.
Zac
Index: portage-2.0.51.22/bin/ebuild.sh
===
---
Jason Stubbs wrote:
It will likely be that some of the bugs marked against 108262 won't be fixed
in time. Perhaps it would have been better to just open a metabug when the
branch is opened and mark bugs against it as they are fixed.
It's nice to have a list of open bugs against the release
http://bugs.gentoo.org/show_bug.cgi?id=48531
This simple patch automatically bumps portage to the top of the merge list.
I've always wanted this feature and it is a dependency of bug 108262. Feedback
please. :)
Zac
Index: bin/emerge
http://bugs.gentoo.org/show_bug.cgi?id=100479
The problem here is that we are iterating through pkgfiles.keys() and inside
the iteration loop we modify the obj variable so subsequent calls to
pkgfiles[obj] may fail. The obvious solution is to use a separate variable for
the pkgfiles key. My
m h wrote:
Hmmm, then I must be missing where the spec file gets generated,
because there is no code in ebuild.py that does it...
A little grep -r rpm /usr/lib/portage led me to a dyn_spec() function inside
/usr/lib/portage/bin/ebuild.sh.
Zac
--
gentoo-portage-dev@gentoo.org mailing list
capitalista wrote:
zmedico requested that I let you guys know about this idea via the
mailing list, so here you go. Feel free to check it out at
http://bugs.gentoo.org/show_bug.cgi?id=112779.
So, basically, you want to have multiple directories that the traditional
/etc/portage inherits
Brian Harring wrote:
Adding another configurable to control it gets back to my point-
should be a simple, extensible *singular* method of doing this, not N
methods.
Agreed.
Not so much transactional as groupping/seperation of each apps files.
(sort of).
The type of changes you're talking
Brian Harring wrote:
The modification is pretty straight forward offhand; the notable
difference this time around is rather then extending portage_exec to
have the capability to 'spawn' python funcs (something I always found
ugly), this handles the fork itself.
This patch seems to work well
capitalista wrote:
Is /etc/portage/includes really necessary? In my bug I said that a
possibility could be for /etc/portage/package.* directories. zmedico
coded it up so that it would be /usr/portage/includes/kde/ (yes, I
like using kde as an example). What about just allowing for
capitalista wrote:
The file grouping would be excellent in the sense that you could tar
up a directory and make it available for others people to use, and all
you would need to do is extract it to /etc/portage/includes.
Does it often make sense to group a set of package.* files together?
capitalista wrote:
I'd be happier if, pending you indeed went the source route, you'd
source directories and not files. You could have another file that
would contain info on the other directories, or maybe put in a
variable in make.conf like PORTDIR_OVERLAY, creating
/etc/portage/includes style
Marius Mauch wrote:
Ok, patch is now available at
dev.gentoo.org/~genone/patches/portage-recursive-grab+config.diff
That's an interesting approach. I'd be interested to see what people think
about modifying grabdict to append later values to earlier ones (rather than
overwrite them).
Zac
Brian Harring wrote:
2) Display a warning message via an atexit hook when parallel-fetching is
enabled, in order to alert the user that background fetching may _still_ be
in progress if emerge appears to hang after an ebuild dies (this happened
to me while kde-3.5 was fetching in the
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
Zac Medico wrote:
1) Save test_conditionals.py in your PYTHONPATH as
portage/test/ebuild/test_conditionals.py
2) Run `trial portage.test.ebuild` and watch it fail.
3) Apply DepSet-AndRestriction.patch then watch the previous test
succeed.
4) Run vdb-depset-test.py to try it on your whole
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew Gaffney wrote:
| Why hasn't this been done before? I'm nowhere near an expert on the
| portage internals, but this looks like it was pretty easy.
Well, the cache related code has had a lot of changes lately due to Brian's
cache backport
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zac Medico wrote:
Mike Frysinger wrote:
makelinks is set to 1 by default when upgrading a package so that running
ldconfig will update any shared lib links ... however, if the package
doesnt
install any libraries, then there's no point
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
There is dangerous handling of world file updates throughout portage. The
attached patch wraps all world file updates in a write_atomic() function which
is designed to prevent interprocess interference and prevent corruption when an
'out
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Harring wrote:
the atomic writing of data in writedict could be gutted out to a
derivative of the file class; via that, same underlying atomic update
code for writedict and wordfile updates...
Hmm, override the constructor and close
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zac Medico wrote:
Brian Harring wrote:
the atomic writing of data in writedict could be gutted out to a
derivative of the file class; via that, same underlying atomic update
code for writedict and wordfile updates...
Hmm, override
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zac Medico wrote:
I was playing with the metadata cache stuff this weekend and decided to
write a patch that obsoletes metadata transfers on sync.
I have reimplemented the previous patch as a normal cache module that adds a
writable layer on top
: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFD3JMf/ejvha5XGaMRAitfAKDrw2C09xIzDyMZ6nVNHdIU1K1l3wCeLvIi
hD4yWTjTdRtPQyuAQQ6TtFc=
=Yr2K
-END PGP SIGNATURE-
# Copyright: 2006 Gentoo Foundation
# Author(s): Zac Medico ([EMAIL PROTECTED])
# License: GPL2
import time
if not hasattr(__builtins__, set):
from
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zac Medico wrote:
I've implemented whiteouts so that items can now be deleted properly. The
whiteouts themselves are stored inside the existing writable database
(self.db_rw) in order to avoid the need for an additional storage area
(similar
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
The subject says it all. What do y'all think?
Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFD3nja/ejvha5XGaMRAuSAAJsG/uoATFOFha6QV9bYuGJUxgosIwCfV9eh
adS9Ngj/2dWrwuMnUkF54B0=
=i9iu
-END PGP
-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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Harring wrote:
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Harring wrote:
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
http://bugs.gentoo.org/show_bug.cgi?id=122527
When emerge would normally discard resume data, the attached patch causes it to
save the resume data in mtimedb[resume_backup] if the length of the mergelist
is greater than 1. When the user calls
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rumen Yotov wrote:
On Wednesday 22 February 2006 03:07, Alec Warner wrote:
Your testing is appreciated.
[1]http://dev.gentoo.org/~zmedico/overlay/sys-apps/portage/portage-2.1_pre5
.ebuild
Hi,
The install went w/o errors, but there's a problem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Varner wrote:
On Tue, 2006-02-21 at 20:07 -0500, Alec Warner wrote:
Your testing is appreciated.
The only thing that I have noted so far is that every emerge command is
printing ** before it does anything else. For example:
# emerge -pv
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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
*
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
I've been working on a script for doing global updates on packages installed in
the vdb (related to bug 122089). It's called vdb-update [1] and it does
basically the same thing as fixpackages but it works on installed packages
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
The current state of ebuild.sh is that it's been abused to perform
miscellaneous shell tasks that are triggered before or after various ebuild
phases. In order to rectify the situation, I propose that we factor out any
logic and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marius Mauch wrote:
Marius Mauch schrieb:
The first should be delayed until there is some consensus how the gpg
stuff should work in the future, the others I don't see the use for.
Also I only checked portage.py for changes, so emerge/repoman/...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rumen Yotov wrote:
Hi,
Recently have problems with latest portage-2.1_pre6-r3, specially when using
eix and now esearch too.
In the former case (eix) it gives too little packages in the database:
Strange is that this happened just after i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rumen Yotov wrote:
On Saturday 18 March 2006 10:14, Rumen Yotov wrote:
Updating Portage cache: 100%
===
# update-eix
Reading Portage settings ..
Building database (/var/cache/eix) from scratch ..
[0] /var/portage/ (cache: backport)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
tvali wrote:
Is /usr/lib/portage/pym dir and /usr/bin/emerge files together the whole
portage (excluding package tree)? Is there any portage code outside
those dirs?
Does `cat /var/db/pkg/sys-apps/portage-*/CONTENTS` answer your question? You
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rumen Yotov wrote:
On Saturday 18 March 2006 10:44, Zac Medico wrote:
If that's all you've done, then please file a bug for the CacheCorruption
error.
The error that you've received could be related to this:
http://bugs.gentoo.org/show_bug.cgi?id
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
I've written a patch [1] that adds support for tracing python. It uses pythons
debugger hooks [2] to trace execution events (mostly function calls and
returns).
The patch causes python tracing to be enabled in --debug mode if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Frysinger wrote:
On Saturday 01 April 2006 17:17, Zac Medico wrote:
Mike Frysinger wrote:
i thought about this some more ... why do we even care about the mtimes
during package merge ? if a package doesnt install any files into a
libdir
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alec Warner wrote:
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian wrote:
Just a word of caution. I don't know why but sometimes after an upgrade
of portage a reload(portage) in porthole fails and porthole crashes. I
don't remember the details atm and have not investigated the reasons.
In all cases
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
What do people think about adding userpriv and usersandox to make.globals
FEATURES? I've been using these for a long time and haven't had any trouble
with them. Are there any arguments against making them default?
Zac
-BEGIN PGP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Frysinger wrote:
On Monday 10 April 2006 08:08, Ned Ludd wrote:
On Mon, 2006-04-10 at 02:24 -0700, Zac Medico wrote:
What do people think about adding userpriv and usersandox to make.globals
FEATURES? I've been using these for a long time
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Harring wrote:
On Sat, Apr 15, 2006 at 11:01:56AM +0900, Jason Stubbs wrote:
On Saturday 15 April 2006 03:31, Brian Harring wrote:
cache backend selection (failed import == defaults to sys default)
This is incorrect. It displays an error
-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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alec Warner wrote:
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
The 2006.1 release is scheduled for this coming August and there are
a lot of people counting on portage-2.1 being stable in time for
that release. In order to ensure that this happens, we need to stop
the addition of new features.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Simon Stelling wrote:
Zac Medico wrote:
the addition of new features. From this time forward, please do not
commit anything to the 2.1 branch (current trunk) unless it is a fix
for functionality that already exists. Thank you in advance
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Frysinger wrote:
no one responded last time about this patch so lets try one more time :P
backend support for FEATURES=debug-build ... no hooks/hacks/etc... included
here to handle a user interface `emerge --debug-build`
-mike
This type
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dan Corson wrote:
I am sorry, you are indeed correct. What I should have requested is: a
way to have the package list output in non-interactive,
package-installing (that is, not --pretend) execution.
Sure, that's easy. I know of at least one
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
The attached patch for bug #132355 [1] adds a --mindeps option for emerge that
effectively allows build time dependencies to be excluded from dependency
calculations involving binary and installed packages. With this patch, it's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ned Ludd wrote:
Please invert the logic so that rather than changing default behavior
you add a new option choose the types of deps to include.
Can you explain how my proposed change in the default behavior of --usepkg is
going to hurt things?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ned Ludd wrote:
On Wed, 2006-07-12 at 08:22 -0700, Zac Medico wrote:
Ned Ludd wrote:
Please invert the logic so that rather than changing default behavior
you add a new option choose the types of deps to include.
Can you explain how my
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
It's come to my attention that the built_with_use function in eutils.eclass
accesses the installed package database directly. This is a major problem
because it prevents us from being able to have an alternative installed package
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris White wrote:
Here's round 3. I've striped out the known issues, since everyone know
nows them. Replaced that missing link, and clarified on the give an
example bit.
It looks good to me. I've taken the liberty of committing your pkgcomp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris White wrote:
Hi,
While doing some documenting on what functions needed to be documented
for the API documentation project, I found that portage.py seems to be
quite a dumping ground for functions:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris White wrote:
1) Create aliases to the new functions, then at some
yet-to-be-determined point, kill the aliases and bomb on the scripts
(this suffers from procrastination).
2) Make an official release with the new function names and no
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Kelly wrote:
Hello,
This is that patch I had mentioned earlier on #gentoo-portage. It works
by sourcing every script found in
/var/libexec/portage/hooks/{pre,post}_${EBUILD_PHASE} at the
appropriate time.
In my case, I feel this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
The Java team is trying to migrate all the Java ebuilds to the Generation 2 [1]
system for building Java packages. They would like to have support included in
repoman in order to help enforce the migration. Please see the attached
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Frysinger wrote:
On Tuesday 01 August 2006 15:49, Thomas de Grenier de Latour wrote:
- =sys-libs/db-1.8* matches 1.85 (found in
net-nds/directoryadministrator)
- =app-text/docbook-xsl-stylesheets-1.6* matches 1.68.1 and 1.69.1
(found in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
I've written a patch [1] that adds support for package.use.mask in the profile.
It should behave exactly as use.mask currently does except that it allows USE
flags to be masked for specific packages rather than for all packages.
In
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Harring wrote:
On Thu, Aug 03, 2006 at 12:23:58PM -0700, Zac Medico wrote:
Hi everyone,
I've written a patch [1] that adds support for package.use.mask in the
profile. It should behave exactly as use.mask currently does except
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Harring wrote:
On Fri, Aug 04, 2006 at 12:38:39PM -0700, Zac Medico wrote:
I haven't seen a specification for use dependencies yet, so I'm not quite
sure how they'd work.
cat/pkg-ver[use1,use2,-use3,use4]
cat/pkg-ver[use]
etc.
Okay, so
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
I've written a patch [1] that implements support for use.force and
package.use.force as originally described by Sven Wegener [2] over a year ago.
Basically, this feature is the exact opposite of use.mask and package.use.mask.
It
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Harring wrote:
On Sun, Aug 06, 2006 at 02:54:36AM -0700, Zac Medico wrote:
seems to me that we'd also have to implement use-dep matching in
order to correctly support use-dep syntax.
If you were actually supporting use deps, yes. You're
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Harring wrote:
You're asking on the wrong ml. Profile monkeying really should
include a run through of -dev, *especially* something like that that's
going to be a pita to turn off when folks start abusing it...
I'm just running it by the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Simon Stelling wrote:
repo-level profile, we move parts of the EAPI out into the tree, which
is a bad idea because we are unable to support multiple versions. As the
EAPI needed for the ebuild is unknown when sourcing
install-helpers.eclass, we're
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Simon Stelling wrote:
Brian Harring wrote:
B) fragmentation this implicitly enables
isn't good.
I agree here.
Fragmentation is always a potential with free and open software. People can
fork if they want or collaborate if they want. The
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Simon Stelling wrote:
Zac Medico wrote:
Well, if the metadata generation step is viewed as being separate from the
rest,
and the helpers aren't needed during that step, then it's possible to get the
EAPI from the ebuild without the helpers being
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Harring wrote:
Just so we're clear... if gentoo-x86 wants to define their own base
template all ebuilds in that repo use, that's fine. That's a
different beast from moving the format definition into the tree
though.
Kind of curious if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alec Warner wrote:
Zac Medico wrote:
Incompatible changes for a given EAPI specification are simply unacceptable.
People really should know better than that. If not, educate them.
See this is a bad idea. If you give them a hand, they take
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Forwarding here in case anyone isn't subscribed to gentoo-dev.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFL2E9/ejvha5XGaMRAmRoAKDiwYChPwHBhMLXaXAhExP9ndp4KQCfex+w
EUJa+X8LjRT+DOu94Ew2wxw=
=CzYX
-END PGP SIGNATURE-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marius Mauch wrote:
So now I was wondering a) if I'm the only one who finds this
feature useful and b) if adding it at the dbapi level (in dbapi.aux_get)
would be considered a good idea, so it could be used by other tools?
I think of aux_get as a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Barkalow wrote:
If some operation requires root or portage access, and the user doesn't
have it, and the --ask option is enabled, replace it with --pretend
instead of aborting with an error.
Thanks, that's a good idea. I've committed a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marius Mauch wrote:
And last but not least a CLI option is bound to emerge, but this feature can
also be useful for other tools. Checking an env var in the config class would
enable it implicitly for all users of portage.py, without it everyone
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fabian Groffen wrote:
Please find attached the patch of the prefix repoman sources against the
current trunk.
I like the idea of having svn support, but I think it will be much
nicer if we separate the cvs and svn support into plugins. That
way,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Barkalow wrote:
On Tue, 28 Nov 2006, 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
James Cloos wrote:
I'm getting an inordinate number of masked- by corruption failures
since merging portage-2.1.2_rc3-r7.
Do you get a !!! Digest verification failed: message before that,
or only the masked by: corruption message? Assuming that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian wrote:
Changing: vers = self.get_versions()
To: vers = self.get_versions()[:] # make a copy
It's fixed in svn r5382. Thanks!
Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
James Cloos wrote:
Thanks for the replies; my apologies for the delay in repying
back
Based on the replies, I was able to track the problem down. The cdb
patch is incompatable with the latest version of portage. Removing
that from
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
Sorry, but I didn't have an internet connection for January to notice but
when I
upgraded to 2.1.2-r7 pkgsplit, catpkgsplit, catsplit no longer accepted ebuild
strings with any atoms. Porthole was crashing in several
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zac Medico wrote:
[EMAIL PROTECTED] wrote:
Sorry, but I didn't have an internet connection for January to notice but
when I
upgraded to 2.1.2-r7 pkgsplit, catpkgsplit, catsplit no longer accepted
ebuild
strings with any atoms. Porthole
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
http://bugs.gentoo.org/show_bug.cgi?id=167667
In order so smoothly and transparently drop Manifest1, it seems like
we'll need a toggle built into portage so that it automatically
drops Manifest1 when appropriate. The need for this toggle will be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alec Warner wrote:
My only concern is about consistency. IE the portage backend (if I
recall correctly) should return all matching nodes; emerge would then
take that list and find the first one that matches in the vdb. However
it becomes a bit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
George Hedfors wrote:
Hi list
This is my first post and I just joined so I apologize if the question
already has been raised previously.
I've been trying to build the docbook-sgml-util package now for a
while without success. Nothing on the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arfrever Frehtes Taifersar Arahesis wrote:
Hi list,
I would like to know what is the status of license filtering and packages sets
in trunk version of Portage. Documentation is very poor in these cases and I
hope that I'm not disturbing you.
I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marius Mauch wrote:
One possible solution that I've thought about would be to remove the
hardcoded selective parameter and let the set configuration determine
if a set is selective or not (with missing = false), and then enable
it for world and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arfrever Frehtes Taifersar Arahesis wrote:
Hello,
Does localization.py exist for a reason?
Over the years we've had a few people express a desire for
internationalization and localization support in portage (bugs
#13618, #32630, and #191189 and
: diffutils-2.8.7-r2.ebuild
-IUSE=nls static userland_GNU
+IUSE=nls static
On 04-11-2007 08:10:29 +, Zac Medico wrote:
Author: zmedico
Date: 2007-11-04 08:10:29 + (Sun, 04 Nov 2007)
New Revision: 8420
Modified:
main/trunk/pym/portage/dbapi/bintree.py
Log:
When evaluating *DEPEND
1 - 100 of 1971 matches
Mail list logo
