not sure what will happen in the future, but adding checks for
this into the current design will noticably slow down the general case (where
the cache isn't changed by external processes).
Regards,
Jason Stubbs
pgpB6hGoz09GO.pgp
Description: PGP signature
On Sunday 12 June 2005 02:09, Jason Stubbs wrote:
On Sunday 12 June 2005 00:34, Brian wrote:
Am I correct in that the imported instance of portage was still using
the old metadata cache at the time of import? Even though the cache was
updated at the end of the sync. After a sync we should
too cluttered output.
* Introducing of flags --buildonly and --merge
--buildpkgonly and --usepkg. --buildpkgonly requires that dependencies be
installed before building.
Regards,
Jason Stubbs
pgpZRMM6DgEkl.pgp
Description: PGP signature
should
be on [EMAIL PROTECTED]
Regards,
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
the information you seek to the ChangeLog, they aren't
likely to be open to adding it anywhere.
Regards,
Jason Stubbs
pgpKflpYCwA0p.pgp
Description: PGP signature
http://bugs.gentoo.org/show_bug.cgi?id=99120
Author: Jeremy Barton
The ccache permissions check incorrectly compares the directory's UID
against the portage GID. UID and GID of the portage are usually the
same but it is possible that they are not.
--
Jason Stubbs
diff -uNr portage-stable/pym
Author: Jason Stubbs
The permissions modifying code of ebuild.sh sets files to have group
wheel on BSD and Darwin and group root on other systems. The
intention is that the group have gid 0 on all systems. This code
removes the if block and uses the numerical identifier.
--
Jason Stubbs
diff
already, it'd be nice if
you could post them here as well preferably before posting to
bugs.gentoo.org. Again, for the same reasons above.
--
Jason Stubbs
pgpO0g5j1hsyW.pgp
Description: PGP signature
On Wednesday 20 July 2005 15:38, 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
.
28474package type preference for binary packages
27093emerge sync and v4 vs v6
22429emerge -pl portage does not show anything
21509Ability to cleanly stop multi-ebuild upgrades
6411Custom favourites files
--
Jason Stubbs
processbugmail.py
Description: application
/digest for old ebuilds and new style for new ones.
--
Jason Stubbs
pgpuCvWaWLjfY.pgp
Description: PGP signature
On Monday 08 August 2005 15:58, Zac Medico wrote:
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
measured a 7.75% decrease in the time taken to
checksum non-elf files when prelink is enabled.
Comments?
Also for 2.1.
--
Jason Stubbs
pgpNuBzRGRdMG.pgp
Description: PGP signature
on
certain vars, preferably defined in a file in the tree similar to
info_vars. This would be used for vars such as USERLAND which are profile
defined.
In other words, don't kill the QA check without addressing the issue that
the QA check is warning about. ;)
--
Jason Stubbs
pgpyAsoZCE427
importantly, what's the chances of a dev finding the
breakage before users? Cleansing the environment to me is akin to using
sandbox. It offers protection against misbehaving packages...
--
Jason Stubbs
pgpAomWNB8iP5.pgp
Description: PGP signature
change.
ignore-pprovided-system-packages.patch
Removes anything in system that is satisfied by package.provided.
--
Jason Stubbs
diff -u -r1.201.2.40 ebuild.sh
--- bin/ebuild.sh 9 Aug 2005 11:25:44 - 1.201.2.40
+++ bin/ebuild.sh 11 Aug 2005 14:26:16 -
@@ -1017,12 +1017,24 @@
for i
cp_all() currently includes category metadata.xml and any other files that
happen to be there. This patch limits cp_all() to directories.
diff -u -r1.524.2.76 portage.py
--- pym/portage.py 29 May 2005 12:40:08 - 1.524.2.76
+++ pym/portage.py 11 Aug 2005 14:26:18 -
@@ -5478,7 +5488,8 @@
Getting rid of the magic constants.
diff -uNr 2.0/bin/ebuild.sh 2.0-patched/bin/ebuild.sh
--- 2.0/bin/ebuild.sh 2005-09-26 11:48:16.0 +0900
+++ 2.0-patched/bin/ebuild.sh 2005-09-27 13:37:33.0 +0900
@@ -83,6 +83,15 @@
export SANDBOX_PREDICT=$SANDBOX_PREDICT:$1
}
+lchown()
+{
+
Kill off the extra stat call by moving the filtering into listdir.
(Brian wrote the bulk of this patch.)
diff -uNr 2.0/pym/portage.py 2.0-patched/pym/portage.py
--- 2.0/pym/portage.py 2005-09-26 11:48:15.0 +0900
+++ 2.0-patched/pym/portage.py 2005-09-27 13:52:49.0 +0900
@@ -272,7
Changes ValueError into OSError so that the except: block can do it's thing.
diff -u -r1.524.2.76 portage.py
--- pym/portage.py 29 May 2005 12:40:08 - 1.524.2.76
+++ pym/portage.py 11 Aug 2005 14:26:18 -
@@ -2595,7 +2597,7 @@
mysettings[LOG_PF]=mysettings[PF]
Subject says it all...
diff -u -r1.524.2.76 portage.py
--- pym/portage.py 29 May 2005 12:40:08 - 1.524.2.76
+++ pym/portage.py 11 Aug 2005 14:26:18 -
@@ -609,7 +609,7 @@
elif ostype == FreeBSD:
if (ld_cache_update):
writemsg( Regenerating +str(root)+var/run/ld-elf.so.hints...\n)
-
Removes any atoms that are satisfied by package.provided in emerge's getlist()
function.
diff -uNr 2.0/bin/emerge 2.0-patched/bin/emerge
--- 2.0/bin/emerge 2005-09-27 13:16:09.0 +0900
+++ 2.0-patched/bin/emerge 2005-09-27 15:00:23.0 +0900
@@ -861,6 +861,16 @@
continue
This patch is by swegener. It allows one to specify atoms after `emerge info`
that will be matched to installed packages. Any installed packages found that
have settings differing to the current settings will have those settings
printed out along with the global info.
diff -u -r1.345.2.37
This patch has two parts. The first adds information to show what package
brought in the offending atom. The second part clarifies that the problem
with ebuild foo is talking about the world/system/cli package rather than
the actual package requiring the unsatisfiable atom.
diff -u -r1.345.2.37
Subject says it all...
diff -uNr 2.0/bin/emerge 2.0-patched/bin/emerge
--- 2.0/bin/emerge 2005-09-27 13:16:09.0 +0900
+++ 2.0-patched/bin/emerge 2005-09-27 15:18:53.0 +0900
@@ -3173,7 +3173,7 @@
if x[3]!=nomerge:
mergecount+=1
#check for blocking dependencies
-
While not harmful, there was one issue with the previous patch; the parent of
the blocking package would be fetched as well. This would usually mean that
one of the packages being merged would be fetched twice. This patch fixes
that.
diff -uNr 2.0/bin/emerge 2.0-patched/bin/emerge
---
Kill 'em all!
(Original patch by solar)
diff -uNr 2.0/pym/portage.py 2.0-patched/pym/portage.py
--- 2.0/pym/portage.py 2005-09-26 11:48:15.0 +0900
+++ 2.0-patched/pym/portage.py 2005-09-27 16:06:21.0 +0900
@@ -1864,7 +1864,7 @@
fetched=0
else:
for x_key
On Wednesday 28 September 2005 12:15, Marius Mauch wrote:
Jason Stubbs wrote:
Kill 'em all!
(Original patch by solar)
Hmm, I actually liked them.
Even now that FEATURES=strict is default and every package results in a
screenful of everything's alright, mate ;-) ?
--
gentoo-portage-dev
Get's rid of all the yelling from the depclean message and shortens it a bit
too. Also got rid of the compulsory long delay (CLEAN_DELAY still takes
affect on non-pretend run). Lastly, made the new sanity checks a long delay
rather than immediately dieing - what if one wanted to take an
correct and what isn't.
just some ideas, maybe needing some development, i hope you find them
useful. :)
Ideas are a dime, a dozen.
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
On Sunday 02 October 2005 01:08, Daniel Stiefelmaier wrote:
On Saturday 01 October 2005 14:17, Jason Stubbs wrote:
This should go to [EMAIL PROTECTED] as ebuild developers are the ones that
decide what USE flags are available and how they're documented.
Of course they decide what flags
I've attached the whole file because the patch was pretty much nonsensical.
* Cleaned up initialization
* Check that the ebuild specified is the ebuild that portage will use and
adjust paths if it isn't.
* Alter clean behavior when FEATURES=noauto to bring it into line with
Brian's changes to
On Tuesday 04 October 2005 03:30, Brian Harring wrote:
On Tue, Oct 04, 2005 at 01:06:35AM +0900, Jason Stubbs wrote:
Don't like the size of this patch, but it's quite repetitive so...
Wouldn't worry on the repetitive, it's repetitive due to the fact the
*dbapi classes don't (ab|)use
and that the creative
process should follow a different path (=plan everything first).
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
much work, so I'd
like to go with 2) or 3). I was thinking to go with 3) with the backported
stuff being named 2.1.0, which is how we arrived at this thread.
Anyway, flame-war time. :D
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
15 October 2005 13:59, Brian Harring wrote:
On Sat, Oct 15, 2005 at 01:45:42PM +0900, Jason Stubbs wrote:
So, there's pretty much three ways we can go:
1) Backport refactorings+features and release.
2) Fix more bugs, backport refactorings+features and release.
3) Fix more bugs, release
On Tuesday 18 October 2005 16:49, Zac Medico wrote:
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. :)
No good. ;)
What if
On Tuesday 18 October 2005 19:52, Marius Mauch wrote:
On Tue, 18 Oct 2005 19:32:26 +0900
Jason Stubbs [EMAIL PROTECTED] wrote:
On Tuesday 18 October 2005 16:49, Zac Medico wrote:
http://bugs.gentoo.org/show_bug.cgi?id=48531
This simple patch automatically bumps portage to the top
On Monday 17 October 2005 08:25, Zac Medico wrote:
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
side of things, will the hooks continue on into later versions?
Specifically, with 3.0 supporting hooks on the python side will the bash
hooks be deprecated? It seems reasonable that both can coexist nicely, so
this is more just confirmation then anything.
--
Jason Stubbs
--
gentoo-portage-dev
trying to use those hooks won't be able to.
In the meantime, it's a nice abuse of a user feature that makes java
1.4-1.5 stuff work, and works fine when 3.0 autodisables it.
I don't get why it's needed by java ebuilds? Is it a fasttrack to getting
unsandboxed root access?
--
Jason Stubbs
On Friday 21 October 2005 19:06, Marius Mauch wrote:
Jason Stubbs wrote:
After thinking about it, incremental feature creep does seem like the
best way to go at this late stage in 2.0's life. The problem is how to
guage what is and what is not more trouble than worth. Perhaps adhering
On Saturday 22 October 2005 10:08, Brian Harring wrote:
On Sat, Oct 22, 2005 at 12:14:40AM +0900, Jason Stubbs wrote:
On Friday 21 October 2005 19:06, Marius Mauch wrote:
Jason Stubbs wrote:
After thinking about it, incremental feature creep does seem like
the best way to go
.
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
On Friday 21 October 2005 19:06, Marius Mauch wrote:
Jason Stubbs wrote:
After thinking about it, incremental feature creep does seem like the
best way to go at this late stage in 2.0's life. The problem is how to
guage what is and what is not more trouble than worth. Perhaps adhering
into the if not
timeout: block.
--
Jason Stubbs
Index: pym/portage_exec.py
===
--- pym/portage_exec.py (revision 2150)
+++ pym/portage_exec.py (working copy)
@@ -4,7 +4,7 @@
# $Id: /var/cvsroot/gentoo-src/portage/pym/portage_exec.py,v 1.13.2.4
On Friday 28 October 2005 19:35, Zac Medico wrote:
Brian Harring wrote:
On Thu, Oct 27, 2005 at 11:50:02PM +0900, Jason Stubbs wrote:
On Wednesday 26 October 2005 23:56, Jason Stubbs wrote:
I've attached a quickly thrown together patch for it, which works here,
but we really need to get
On Saturday 29 October 2005 13:20, Jason Stubbs wrote:
I've adjusted the patch a bit to make all method signature changes into
keyword arguments. I've also change the default tree to None and added a
warning message to doebuild when None is passed and defaulting it to tree
there. With the EAPI
On Saturday 29 October 2005 15:38, Zac Medico wrote:
Jason Stubbs wrote:
On Saturday 29 October 2005 13:20, Jason Stubbs wrote:
I've adjusted the patch a bit to make all method signature changes into
keyword arguments. I've also change the default tree to None and added a
warning message
On Saturday 29 October 2005 19:56, Jason Stubbs wrote:
All file descriptors opened by spawn() are now closed in the correct
places. The code that closes all unnecessary descriptors via brute force is
no longer required.
I found that a file descriptor was being left open and passed around
On Sunday 30 October 2005 01:04, Brian Harring wrote:
On Sun, Oct 30, 2005 at 12:25:23AM +0900, Jason Stubbs wrote:
By the way, this method does not allow having a pipe open to a child
process other than stdin, stdout or stderr.
It does; the portage_exec that is in stable is the modified
Trying to alter patches that have been split up is a PITA. Missed a var rename
in the patch just sent. :/
--
Jason Stubbs
--- portage_exec.py.orig 2005-10-30 02:05:50.0 +0900
+++ portage_exec.py 2005-10-30 02:18:24.0 +0900
@@ -11,11 +11,8 @@
try:
import resource
On Sunday 30 October 2005 02:17, Brian Harring wrote:
On Sun, Oct 30, 2005 at 01:40:41AM +0900, Jason Stubbs wrote:
Even with the fd_pipes, the try/except block in there covers a bug that
is hit every time it is entered.
*cough* really doesn't surprise me. :)
Looking through the 2.4
On Saturday 29 October 2005 19:34, Jason Stubbs wrote:
On Sunday 23 October 2005 15:45, Jason Stubbs wrote:
Commented on the bug due to reasoning behind this patch. Essentially,
SIGTERM is sent to tee, a WNOHANG waitpid() is performed followed by
SIGKILL if it hasn't exited. So if tee
On Sunday 30 October 2005 02:32, Jason Stubbs wrote:
On Saturday 29 October 2005 19:34, Jason Stubbs wrote:
On Sunday 23 October 2005 15:45, Jason Stubbs wrote:
Commented on the bug due to reasoning behind this patch. Essentially,
SIGTERM is sent to tee, a WNOHANG waitpid() is performed
more
mess. ;)
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
method but I'm sure
that there will be alternative opinions...
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
to me... All that's changed is that locations has become an
instance var rather than a local var. What was the issue?
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
on with it. ;)
Reminder: Anybody who commits to portage should be on this list and
following/participating in what's going on.
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
On Friday 04 November 2005 04:30, Thomas de Grenier de Latour wrote:
On Fri, 4 Nov 2005 01:19:35 +0900
Jason Stubbs [EMAIL PROTECTED] wrote:
package.env would be a list of atom file [file ...]
...
With a couple of small modifications to emerge to check FEATURES
for buildpkg after
On Saturday 05 November 2005 04:19, [EMAIL PROTECTED] wrote:
On Sat, Nov 05, 2005 at 03:44:30AM +0900, Jason Stubbs wrote:
Nobody else has shown a real example, why should I?
...
I am focusing on what it could do. I stated all the options in my
previous email.
...
To restate: How
On Tuesday 08 November 2005 17:29, Brian Harring wrote:
On Sun, Nov 06, 2005 at 11:54:11AM +0900, Jason Stubbs wrote:
On Sunday 06 November 2005 06:09, Brian Harring wrote:
Yes we'll run aground of the dead 2.1 release (not incredibly happy
about that), but I'd like to see if we can get
On Tuesday 08 November 2005 19:42, Brian Harring wrote:
On Tue, Nov 08, 2005 at 07:39:01PM +0900, Jason Stubbs wrote:
If the changes are reviewed roughly in proportion to the number of hunks,
we should be okay. At minimum, we should at least see how .54 turns out
as there will be a few
On Thursday 10 November 2005 05:08, Brian Harring wrote:
If people are after having the commit mail dumped in their mbox,
please contact either jstubbs, genone, or myself.
Or if you're a dev, just add yourself. ;)
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
to anybody's attention) in the time since I (and you) have been with the
project. Lastly, 2.3.5.200* is/was hard masked.
My preference would be to put the patch into trunk and release .54_pre1 within
the next 24 hours.
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
On Monday 14 November 2005 23:17, Marius Mauch wrote:
On Mon, 14 Nov 2005 22:38:28 +0900
Jason Stubbs [EMAIL PROTECTED] wrote:
The cache and elog plugin selection(s) come from user settings but
emaint (and repoman whenever that happens (and possibly even emerge
itself one day?)) needs
On Monday 14 November 2005 00:46, Jason Stubbs wrote:
On Sunday 13 November 2005 11:52, Brian Harring wrote:
On Sun, Nov 13, 2005 at 09:19:55AM +0900, Jason Stubbs wrote:
On Sunday 13 November 2005 04:00, Brian Harring wrote:
*cough* that's that funky _p1 you're using
On Tuesday 15 November 2005 00:32, Marius Mauch wrote:
On Tue, 15 Nov 2005 00:24:02 +0900
Jason Stubbs [EMAIL PROTECTED] wrote:
On Monday 14 November 2005 00:46, Jason Stubbs wrote:
On Sunday 13 November 2005 11:52, Brian Harring wrote:
On Sun, Nov 13, 2005 at 09:19:55AM +0900, Jason
+ doc = \n.join(map(lambda x:x.lstrip(), doc.split(\n))) +\n
+ doc += proxied call to module level registry instances %s method % x
+ globals()[x] = pretty_docs(v, doc)
+
+del x, v, proxy_it, doc
What's this currying and pretty_docs stuff?
--
Jason Stubbs
--
gentoo-portage-dev
for the an updated
verify-rdepend code.
snip
Before he does that does anybody have any objections? If so please let
us know what and why.
The last I heard, Brian was the only one *against* having pax-utils added
to portage's RDEPEND list. ;)
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org
inherint dislike of awk, algo is there.
Should be schlopped into emaint though imo; you game, or want someone
to do the python bits?
emaint needs the plugin stuff for that to happen, but yeah...
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
?
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
On Saturday 26 November 2005 00:31, Ned Ludd wrote:
On Sat, 2005-11-26 at 00:01 +0900, Jason Stubbs wrote:
Hi all,
I don't think there's really anything else that can be done for 2.0.53 so
am thinking that we should probably push _rc7 + docs out and let the arch
teams mark it stable
On Saturday 26 November 2005 11:07, Marius Mauch wrote:
On Sat, 26 Nov 2005 00:01:15 +0900
Jason Stubbs [EMAIL PROTECTED] wrote:
The only other new thing in trunk that I know of is logging but
there's still a question mark over the ordering of messages... Can
that be resolved soon
On Saturday 26 November 2005 02:05, Ned Ludd wrote:
On Sat, 2005-11-26 at 00:51 +0900, Jason Stubbs wrote:
On Saturday 26 November 2005 00:31, Ned Ludd wrote:
* post_sync action hook (.53/.54 )
* VDB prevention of single byte NULL entries being created. ( .54 )
Doable for .54.
Yeah
On Sunday 27 November 2005 02:03, Ned Ludd wrote:
On Sat, 2005-11-26 at 13:15 +0900, Jason Stubbs wrote:
On Saturday 26 November 2005 02:05, Ned Ludd wrote:
On Sat, 2005-11-26 at 00:51 +0900, Jason Stubbs wrote:
On Saturday 26 November 2005 00:31, Ned Ludd wrote:
* post_sync action
to remove or not.
The cache entry for CDEP has been replaced with a blank line to keep
the cache format compatible.
The CDEPEND in auxdbkeys is needed, but it won't cause any harm other than the
extra 10 or 11 bytes added to portage.py. This patch is pretty much perfect
as it is. :)
--
Jason Stubbs
On Monday 28 November 2005 00:20, Ned Ludd wrote:
On Mon, 2005-11-28 at 00:15 +0900, Jason Stubbs wrote:
On Monday 28 November 2005 00:01, Ned Ludd wrote:
The following untested attached patch removes CDEPEND from ebuild.sh
A quick grep -i shows that there is one case of CDEPEND left
On Monday 28 November 2005 03:49, Marius Mauch wrote:
Jason Stubbs wrote:
On Sunday 27 November 2005 00:09, Marius Mauch wrote:
Jason Stubbs wrote:
Well, the vote was more for the SHA1 change actually as that's the one
triggering the size increase. The pycrypto stuff itself doesn't do
the passed
virtuals anymore. Hence, all calls to getvirtuals() external to the config
class could theoretically be dropped and replaced with an empty dictionary.
The only possibility of breakage in doing that is if other parts of portage
are accessing *tree's virtual member directly.
--
Jason Stubbs
On Thursday 01 December 2005 22:28, Jason Stubbs wrote:
On Monday 28 November 2005 03:49, Marius Mauch wrote:
Jason Stubbs wrote:
On Sunday 27 November 2005 00:09, Marius Mauch wrote:
Jason Stubbs wrote:
Well, the vote was more for the SHA1 change actually as that's the one
triggering
On Tuesday 06 December 2005 00:21, Alec Warner wrote:
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
On Tuesday 06 December 2005 11:29, Zac Medico wrote:
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
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
On Wednesday 07 December 2005 01:01, Marius Mauch wrote:
On Tue, 6 Dec 2005 23:19:38 +0900
Jason Stubbs [EMAIL PROTECTED] wrote:
If there's no solid opposition, Saturday I will put current trunk into
~arch as 2.1_beta20051210.
Well, I've already stated several times that IMO using a 2.1
On Wednesday 07 December 2005 11:57, Marius Mauch wrote:
On Wed, 7 Dec 2005 08:41:27 +0900
Jason Stubbs [EMAIL PROTECTED] wrote:
On Wednesday 07 December 2005 01:01, Marius Mauch wrote:
On Tue, 6 Dec 2005 23:19:38 +0900
Jason Stubbs [EMAIL PROTECTED] wrote:
If there's no solid
On Friday 09 December 2005 04:03, Zac Medico wrote:
Jason Stubbs wrote:
On Thursday 08 December 2005 16:44, Zac Medico wrote:
The middle hunk fixes a problem with block atoms that do not match any
packages. Previously, these atoms would not make it into the okay_atoms
set which caused
On Friday 16 December 2005 19:01, Brian Harring wrote:
On Fri, Dec 16, 2005 at 12:09:10PM +0900, Jason Stubbs wrote:
On Thursday 15 December 2005 20:06, Brian Harring wrote:
This is the only blocker for merging parallel-fetch as far as I can
tell- so... my vote is nuking the wait out
On Tuesday 20 December 2005 23:15, Jason Stubbs wrote:
On Tuesday 20 December 2005 01:49, Marius Mauch wrote:
Also not talking about implementation details yet, just after comments
about the general idea of forced portage updates.
I gave it a go anyway... ;)
Also needed:
Index: portage.py
?
No problems on my part. As Mike said, it'll only catch the standard unpack
usage but that's not really an issue as far as I can see.
By the way, now that we've got -commit mail, confirming with the ML isn't
really necessary. Of course, if it's something you want to confirm...
--
Jason Stubbs
-sdk -static truetype-fonts -type1-fonts -xprint xv
INPUT_DEVICES=-synaptics -wacom 44,520 kB
I doubt that the NEW and OLD would really be visible in the --verbose output
in the general case anyway. How about just making added flags green to match
the output of changed flags?
--
Jason Stubbs
by this. No clues on the bash
stuff; it seems there's an external confcache binary but I can't tell much
beyond that.
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
not rewriting all of doebuild just for
this :)
Happy here. If there were no other issues, may as well go ahead with it
earlier rather than later. Spread the goodness (or something like that ;)
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
is
only for portage_const, so the tool remains sensored. Unless I'm
missing something.
Nah, Brian's right. Tools need to follow. Backwards compatibility isn't so
important there. The important thing is that portage keeps on living.
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
use --update instead.
emerge: there are no ebuilds to satisfy update.
Doing it that way will show exactly why it's being dropped without the
need for a written explanation (and hopefully no bug about how it's a
terrible usability regression).
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org
there being much of a problem, but so that
we can redo that whole bunch of code without having to do:
if incorrect_syntax:
print warning
make correct syntax
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
of the patch -43/+42. What is the goal?
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
]:
- # These require HTTP Encoding
...
This shouldn't be in a cleanup patch either.
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
minutes to counter the regression
of emerge warning on unsatisfiable world file entries. It was/is not meant to
stand the test of time in its current state. Why would you want to muddy up
your code with it? ;)
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
are made - but very promising.
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
1 - 100 of 109 matches
Mail list logo
