On Tuesday 24 October 2006 16:36, Brian wrote:
> def get_virtual_dep(atom):
> """returns a resolved virtual dependency.
> contributed by Jason Stubbs, with a little adaptation"""
> # Thanks Jason
> non_virtual_atom = portage.dep_virtu
If not where should I get it? From the virtuals in
> portage or the tree? both? - then which order?
The ones in the tree are just regular packages - but may also exist in the
PROVIDE attribute of associated ebuilds. As for ordering, packages with
PROVIDE override identically named packages in the tree. If you use something
similar to the above, it should all be taken care of though.
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
split() will
split a package identifier into [cat, pkg, ver, rev].
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
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 message and quits.
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
s/ftp/nfs/ in the mail that I just sent.
--
Jason Stubbsw
--
gentoo-portage-dev@gentoo.org mailing list
On Saturday 15 April 2006 03:31, Brian Harring wrote:
> Sidenote, why is userfetch a feature? That seems like something that
> should be userpriv by default to me...
It broke somebody's ftp setup.
http://bugs.gentoo.org/show_bug.cgi?id=92960
--
Jason Stubbs
--
gentoo-portage-dev
quot;usersandbox" on the other hand, it has meant to throw
everything possible at the ebuild. I personally prefer to not use
usersandbox as the sandbox gives a sometimes-not-small performance hit
and I'm a ricer. :P
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
On Saturday 08 April 2006 21:48, Ned Ludd wrote:
> On Sat, 2006-04-08 at 11:18 +0900, Jason Stubbs wrote:
> > On Saturday 08 April 2006 07:36, Ned Ludd wrote:
> > > On Fri, 2006-04-07 at 14:19 -0400, solar wrote:
> > > > FEATURES="buildpkg" ROOT=
ckage and -k (rather than -K) is used, the binary package might
still be chosen. Either way, I'll do some tests and figure out what's not
working.
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
ny rc status.
Can you refresh my memory on what the issue is here?
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
On Thursday 30 March 2006 11:40, Marius Mauch wrote:
> On Thu, 30 Mar 2006 08:30:17 +0900
> Jason Stubbs <[EMAIL PROTECTED]> wrote:
>
> > On Thursday 30 March 2006 01:21, Marius Mauch wrote:
> > > Marius Mauch schrieb:
> > > > So after manifest2 is i
he latest with this patch
and then doesn't sync for three years? The tree may then require a later
portage but the user can't sync to be able to emerge a later portage.
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
On Thursday 23 March 2006 23:43, Brian wrote:
> On Thu, 2006-23-03 at 22:14 +0900, Jason Stubbs wrote:
> > On Thursday 23 March 2006 16:23, Brian wrote:
> > > /etc/portage/lists/userlist1
> > >
> > > format:
> > >
> > > net-www/apache
&g
On Thursday 23 March 2006 16:23, Brian wrote:
> /etc/portage/lists/userlist1
>
> format:
>
> net-www/apache
> www-apache/mod_perl
> ...
If you make that "/etc/portage/sets" and support any package atom (rather
than only cat/pkg) then I you'd pretty much hav
ficulties in maintenance. In actual fact,
there'll likely need to be four variables - CHOST, CFLAGS, CXXFLAGS and
ACCEPT_KEYWORDS. In any case, the user will only ever see the single
/etc/make.conf.example file.
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
n pre6 (pre5?) and in need of testing - especially when
local modifications are made - but very promising.
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
E_INST_GID to make.globals?
>
> Would the profiles not be a more logical place to set these? If not,
> can we twist the logic to make it so? :p
The profiles would be able to override it. In the case of non-incrementals
the first definition found is the winner in the order of:
env ->
int was created in about 30 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
On Sunday 26 February 2006 00:09, Alec Warner wrote:
> Jason Stubbs wrote:
> > - if 0 and match and mykey in ["PORTAGE_BINHOST"]:
> > - # These require HTTP Encoding
> > ...
> >
> > This shouldn't be in a "cleanup" patch either.
&
de, 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.
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
/+1 which makes the relevant
part of the patch -43/+42. What is the goal?
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
nings for the time being.
However, we should probably figure out exactly how it should work and then
print warnings whenever any deprecated syntax is used. Not so much for users
and scripts, of which I can't see 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
jections. Might be better to go with the latter so that
users adjust quickly.
"""
Actions specified without a '--' prefix is no longer supported.
Please use --update instead.
emerge: there are no ebuilds to satisfy "update".
"""
Doing it that way
support
> processing +- in IUSE, how does EAPI help me here? The support check is
> only for portage_const, so the tool remains . Unless I'm
> missing something.
Nah, Brian's right. Tools need to follow. Backwards compatibility isn't so
important there. The important thing
mplementation (and no, I'm 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
ld have said everything that
other possible responders were thinking of saying negating the need for
further responses.
So what's happening with this? As far as I understand it, there's a high
probability of incorrect file generation. Should "vdbkeys" be pulled out of
emaint's "modules" var until next release?
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
users which will be broken 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
On Monday 26 December 2005 22:54, Petteri Räty wrote:
> Jason Stubbs wrote:
> > On Monday 26 December 2005 07:18, Petteri Räty wrote:
> >>I propose we improve the emerge -pv output to be something like the
> >>following:
> >>
> >>[ebuild U ] m
aking added flags green to match
the output of changed flags?
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
way, it's attached. Comments?
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&#
is bumped. Ebuilds
can use the new features before a supporting portage version is widely used
(EAPI-aware portages will mask ebuilds with EAPIs that it can't support).
Portage on the other hand can adjust how it deals with ebuilds based on the
EAPI that the ebuild requests.
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
On Friday 23 December 2005 08:46, Zac Medico wrote:
> Jason Stubbs wrote:
> > On Thursday 22 December 2005 16:21, Brian Harring wrote:
> >>Not sure if hiding the exception away (traceback) is a good thing;
> >>wrapping it with purdy output, sure, but swallowing it?
On Thursday 22 December 2005 16:21, Brian Harring wrote:
> On Wed, Dec 21, 2005 at 03:35:58PM +0000, Jason Stubbs wrote:
> > Author: jstubbs
> > Date: 2005-12-21 15:35:57 + (Wed, 21 Dec 2005)
> > New Revision: 2424
> >
> > Modified:
> >main/trunk
On Wednesday 21 December 2005 01:57, Marius Mauch wrote:
> Jason Stubbs wrote:
> > Reasoning on checking all system atoms is that other groups are just as
> > likely to need the functionality as we are. Combining that with how
> > rarely versions are actually updated fo
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... ;)
ecks when the system is known to be in an incomplete state.
Reasoning on checking all system atoms is that other groups are just as likely
to need the functionality as we are. Combining that with how rarely versions
are actually updated for system
a rescue-portage help on this ?
It's easy enough to install portage from sources (for the time being) that I'd
say it's not necessary at this stage. A HOWTO on the matter would be much
quicker and easier to maintain while it remains viable.
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
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...
e.. I'm kind of
wondering if ctrl-c'ing behaviour will change - how gets the ctrl-c first?
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
On Thursday 08 December 2005 09:24, Marius Mauch wrote:
> On Wed, 7 Dec 2005 21:33:00 +0900
>
> Jason Stubbs <[EMAIL PROTECTED]> wrote:
> > > It isn't about expectations.
> >
> > Ok, I misunderstood your previous posts on this topic then.
> >
> >
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 th
as:
if atom.match(child) and not atom.blocks:
okay_atoms.add(atom)
Combining those two gives:
if atom.blocks and not atom.match(child) or \
atom.match(child) and not atom.blocks:
okay_atoms.add(atom)
Which is exactly the same thing as the original except seven lines longer.
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
> > >
>
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'
On Tuesday 06 December 2005 21:37, Alec Warner wrote:
> 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.
> > > >
> > > > Postpo
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 othe
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 f
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 wo
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
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
--
gentoo-portage-dev@gentoo.org mailing list
lled (the latter overwriting the
former and causing the former to be unmerged). It's essentially bug 1343.
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
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
e
> recent changes to portage_exec.cleanup().
Does changing SIKTERM to SIGKILL fix it?
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
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 t
e if that is safe 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 per
On Sunday 27 November 2005 00:09, Marius Mauch wrote:
> Jason Stubbs wrote:
> > 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
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 Novem
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.
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 message
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 o
out of emerge.. What are the shortterm goals?
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
.5.0 isn't released yet.
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
if [[ ! -e $NEEDED ]]; then
> > grep ^obj $f | awk '{print $2}' | scanelf -BF"%F %n" -f - >
> > $NEEDED
> > fi
> > done
>
> Aside from my inherint dislike of awk, algo is there.
> Should be schlopped into emaint though imo; you game, or w
On Sunday 20 November 2005 01:11, Brian Harring wrote:
> On Sun, Nov 20, 2005 at 12:50:25AM +0900, Jason Stubbs wrote:
>
>
> > > > Also, with a long running portage
> > > > process and badly written code, it'd be quite easy to run out of
> > >
On Saturday 19 November 2005 20:48, Brian Harring wrote:
> On Sat, Nov 19, 2005 at 01:12:46PM +0900, Jason Stubbs wrote:
> > > > +++ ./pym/portage_locks.py 2005-11-16 01:56:25.152161768 -0500
> > > > @@ -358,3 +359,91 @@
> > > > +# should the fd be lef
to configure what algorithm(s) are used. Generation on
the other hand needs to be done for at least MD5 and one other algorithm.
> Having to maintain backwards compatibility with old versions of portage
> is a good idea, however just how far back must be supported?
A year is a good guide.
--
no mathematical proof (as of yet), it is possible to generate
md5s that match while the sha1s don't. If that goes the other way around as
well (sha1s match but md5s don't) there's definitely an improved strength
however slight it may be... But yes, if there's any at all it is only slight.
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
post for
> where exactly).
Hence, if we fix it in the next version we still have to wait six months
to a year for most everybody to be using it so we don't break lots and
lots of systems...
Wouldn't it be easier to just disallow unsigned commits on the server side?
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
On Saturday 19 November 2005 08:47, Brian Harring wrote:
> On Sat, Nov 19, 2005 at 12:43:43AM +0900, Jason Stubbs wrote:
> > +++ ./pym/portage_file.py 2005-11-16 01:56:19.157073160 -0500
> >
> > + # if the dir perms would lack +wx, we
vantage of this tool for the an updated
> verify-rdepend code.
> 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
y()
+ return getattr(registry, method)(*a, **kw)
+
+for x in ["register", "deregister", "query_plugins", "get_plugin"]:
+ v = pre_curry(proxy_it, x)
+ doc = getattr(GlobalPluginRegistry, x).__doc__
+ if doc == None:
+ doc = ''
+ else:
+ # do this so indentation on pydoc __doc__ is sane
+ 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@gentoo.org mailing list
dir_paths() to ensure that 01-kde,
02-server, 03-whatever goes in the intended order but other than that it
looks like you've pretty much got it. :)
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
actually do? Ease seeks? Should I re-run
these tests with a reboot in between? (And what happened to the 4 seconds I
was getting with earlier patches? Bug fixes turn quantity into quality? :)
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
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:
> > &g
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'
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 eve
On Sunday 13 November 2005 11:57, Brian Harring wrote:
> On Sat, Nov 12, 2005 at 11:33:06PM +0900, Jason Stubbs wrote:
> > I've had a go at creating a generic plugin framework for portage. The
> > attached patch contains:
> >
> > * plugins/__init__.py that d
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 there? :)
> >
> > patchlevel..
have
plugins. There's talk of repoman having plugins... Just unifying it.
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
On Sunday 13 November 2005 04:00, Brian Harring wrote:
> On Sat, Nov 12, 2005 at 02:26:41PM +0900, Jason Stubbs wrote:
> > On Saturday 12 November 2005 08:14, Brian Harring wrote:
> > > Might be worth noting that as of my last sync, .53* and friends are
> > > *still* ~ar
I've had a go at creating a generic plugin framework for portage. The attached
patch contains:
* plugins/__init__.py that does plugin searching and loading.
* plugins/cache/__init__.py which specifies what class cache plugins must
derive from.
* cache/{anydbm,flat_hash,flat_list,metadata,sqlite
arch
2.0.53_p1~arch
2.0.54_pre1 package.mask
After a couple of weeks, move 2.0.53_p1 to stable and drop 2.0.53.
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
On Saturday 12 November 2005 08:06, Brian Harring wrote:
> On Fri, Nov 11, 2005 at 11:33:25PM +0900, Jason Stubbs wrote:
> > Long answer: This is not a regression; you'll find the same problem in
> > stable. It's an area where a slight error can break lots of things that
the bug is occurring is very
non-standard and has not cropped up before (or at least hasn't been brought
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
P.S. While I haven't got everything working yet, times have gone from 1.95
to 1.60 seconds on my box here. :)
--
Jason Stubbs
Index: pym/portage.py
===
--- pym/portage.py (revision 2264)
+++ pym/portage.py (working copy)
@@ -38
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
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
> &g
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
I've moved trunk/ to branches/2.1-experimental/ and branches/2.0 to trunk/.
Make sure to update before doing any changes...
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
er". At the moment,
a lot of fixes go out all at once rather than in lots of small bumps. I doubt
the overall speed would change very much.
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
On Saturday 05 November 2005 15:21, Alec Warner wrote:
> Jason Stubbs wrote:
> > On Saturday 05 November 2005 05:08, Thomas de Grenier de Latour wrote:
> >
> > Most operate only on the bash side and/or within doebuild (which should
> > be getting a setcpv()'d se
On Saturday 05 November 2005 05:08, Thomas de Grenier de Latour wrote:
> On Sat, 5 Nov 2005 02:55:01 +0900
>
> Jason Stubbs <[EMAIL PROTECTED]> wrote:
> > gnome-*/* for package.keywords is already not supported.
>
> Sure, i know, but i think it's already an unfor
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
> > pre
On Saturday 05 November 2005 10:39, Brian wrote:
> On Sat, 2005-05-11 at 01:55 +0900, Jason Stubbs wrote:
> > On Friday 04 November 2005 22:33, Marius Mauch wrote:
> > > Ciaran McCreesh wrote:
> > > > On Thu, 03 Nov 2005 23:14:20 -0800 Brian <[EMAIL PROTEC
On Saturday 05 November 2005 03:30, [EMAIL PROTECTED] wrote:
> On Sat, Nov 05, 2005 at 03:22:02AM +0900, Jason Stubbs wrote:
> > So what exactly should it do?
>
> Instead of making up examples of what it can't do,
Nobody else has shown a real example, why should I?
> w
On Saturday 05 November 2005 03:03, [EMAIL PROTECTED] wrote:
> On Sat, Nov 05, 2005 at 01:55:35AM +0900, Jason Stubbs wrote:
> > On Friday 04 November 2005 22:33, Marius Mauch wrote:
> > > Ciaran McCreesh wrote:
> > > > On Thu, 03 Nov 2005 23:14:20 -0800 B
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 " [ ...]"
>
> ...
>
> > With a couple of small modifications to eme
. c-1.1 masked but c-1.0 isn't. Should the
above "keep going" just grab the highest *masked* version at each stage?
Either way, while there are bugs such as error messages being truncated,
requests such as "allow me to break my system easier" are truly far from my
mind. Of course, supplied patches will always be reviewed.
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
On Friday 04 November 2005 22:27, Marius Mauch wrote:
> Jason Stubbs wrote:
> > Hi all,
> >
> > As per previous discussion, 2.0.53_rc7 is pretty much ready to go stable.
> > We're now just waiting on it lasting a couple of weeks without bugs.
> > Seeing a
g" after the call to setcpv() is done rather than doing it once
globally, this would also cover TGL's BUILD_PKGS addition too. Most package.*
type things should be able to be killed off this way.
Thoughts?
--
Jaso
1 - 100 of 237 matches
Mail list logo
