Anthony Gorecki wrote:
In the future, it might be helpful to post those patches in-line, along with
the message. That way no-one needs to open a separate program to view the
changes.
There are mailreaders without an internal textviewer? I have a few
problems believing that. I'd strongly
On 08/21/05 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
On 08/27/05 Brian Harring wrote:
Hola.
Attached is a patch that
A) adds EAPI awareness to portage; mainly, if 0, complain and be
unwilling to merge the package
Actually I just wrote also a patch for it (for 2.1), however instead of
complaining I just masked them (without unmask
On 08/30/05 Brian Harring wrote:
What's the point of using anyway?
Simplicity in the code right now, since stable will *never* support
anything but eapi0. It's an easy check.
You really want to tell me that you consider
if myeapi 0:
as simpler than
EAPI_COMPATIBLE=0
if myeapi
On 08/29/05 Brian Harring wrote:
Somebody care to split a masking patch for stable rather then the
emerge modifications I did btw? I'm poking at ensuring an eapi=0
portage's generated eapi=1 cache entries are not used by an eapi=1
portage without a forced regeneration atm.
Well, the
Mikey wrote:
The utility that fetches packages via emerge mangles the resulting file
name, as well as wget (does emerge use wget?). When fetching the above url,
emerge or wget saves the file as package_ids.php?action=packageid=10105.
This of course throws a wrench into my use of custom ebuilds
Mikey wrote:
On Sunday 09 October 2005 19:32, Marius Mauch wrote:
Well, ebuilds (and therefore eclasses) can't override anything related
to the fetch process (other than setting RESTRICT and/or SRC_URI). Your
problem has to be fixed server side (assuming you want a proper
solution), as portage
Brian Harring wrote:
On Tue, Oct 11, 2005 at 10:37:43AM +0300, Marius Mauch wrote:
Brian Harring wrote:
On Sun, Oct 09, 2005 at 06:52:24PM -0500, Mikey wrote:
http://codeserver.wherever.net/pman/package_ids.php?action=packageid=10105
[snip bits about wget screwing up]
Others have
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 to the kernel's
rule of Separate each logical change into its
On Sat, 22 Oct 2005 00:14:40 +0900
Jason Stubbs [EMAIL PROTECTED] wrote:
The cheapness is exactly why I was questioning. Consider:
# svn cp tags/2.0.53 branches/2.0.53-branch
# cd branches/2.0.53-branch
# patch something-that-needs-fixing-now.patch
# svn ci
# cd ../..
# svn cp
First patch for elog integration in 2.0.x adding the basic elog
framework without the actual modules, config samples or other docs. The
code is mostly unchanged from the 2.1 branch and only lightly tested
on 2.0. Known issues with this patch:
- needs better integration of isolated-functions.sh,
This patch depends on elog_base (although it doesn't break anything
without it) and adds the actual logging modules. I've just atatched the
files completely, as a) svn diff doesn't play nice with generating
new-file diffs and b) they are just new files to be dropped in
pym/elog_modules (together
Jason Stubbs wrote:
On Sunday 23 October 2005 00:08, Marius Mauch wrote:
- needs better integration of isolated-functions.sh, probably should be
a separate patch (Brian?)
Not sure what you mean by better as I'm happy with the current method. Other
than the hardcoded path, it should work fine
On Sat, 5 Nov 2005 20:58:57 -0600
Jason Pepas [EMAIL PROTECTED] wrote:
So, I have been going over how class config works in portage, but I
am still unsure of where to fit in the changes I would need.
I suppose I'll lay out the structure of what I had in mind and ask
y'all for advice.
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 Stubbs wrote:
On Sunday 13 November 2005 04:00, Brian
On Mon, 14 Nov 2005 09:42:56 -0600
Brian Harring [EMAIL PROTECTED] wrote:
On Mon, Nov 14, 2005 at 04:32:35PM +0100, Marius Mauch wrote:
On Monday 14 November 2005 00:46, Jason Stubbs wrote:
Replace 2.1.0 with 2.2.0 and I'll agree.
Skipping 2.1 accomplishes what?
Avoid any possible
Anthony Gorecki wrote:
On Wednesday, November 16, 2005 23:12, Zac Medico wrote:
I wouldn't mind having a feature like this. I would provide a way for
automatic unmasking tools to keep their changes separate and easily
reversible.
This seems to be borderlining on being unnecessary, in my
On Sat, 19 Nov 2005 20:59:07 +0900
Jason Stubbs [EMAIL PROTECTED] wrote:
On Saturday 19 November 2005 20:41, Mike Auty wrote:
If portage can already handle multiple hash formats,
Portage can't handle multiple hash formats at the moment. It is only
smart enough to not throw a fit when other
On Fri, 18 Nov 2005 19:13:13 +0100
jb benoit [EMAIL PROTECTED] wrote:
$ diff -Naur portage.py.sav portage.py
--- portage.py.sav 2005-11-17 15:32:20.0 +0100
+++ portage.py 2005-11-17 15:15:24.0 +0100
@@ -3866,6 +3866,42 @@
On Fri, 18 Nov 2005 18:40:14 -0600
Brian Harring [EMAIL PROTECTED] wrote:
On Wed, Nov 16, 2005 at 04:33:02AM +0100, Marius Mauch wrote:
- digestfn =
mysettings[FILESDIR]+/digest-+mysettings[PF]
+ digestfn =
portdb.finddigest(mysettings[CATEGORY]+/+mysettings[PF])
Like this mod
On Fri, 18 Nov 2005 22:01:27 -0800
Robin H. Johnson [EMAIL PROTECTED] wrote:
Ergo, instead of a Manifest being re-generated each time, it needs to
act like a FIFO queue.
Or in other words: transactional manifests.
Each queue element consists of:
- checksum/existing Manifest element of items
On Sat, 19 Nov 2005 15:29:30 +0900
Jason Stubbs [EMAIL PROTECTED] wrote:
On Saturday 19 November 2005 15:01, Robin H. Johnson wrote:
After my post to -core about how to move ahead with signing, I
thought the next best place to continue is in a discussion of how
Portage handles manifests
On Fri, 18 Nov 2005 09:01:38 -0600
Brian Harring [EMAIL PROTECTED] wrote:
On Thu, Nov 17, 2005 at 07:36:05PM -0800, Zac Medico wrote:
Okay, I wrote a small patch that handles everything supported by
/etc/portage except bashrc (package.mask, package.unmask,
package.keywords, package.use,
On Tue, 22 Nov 2005 21:47:40 +0100
jb benoit [EMAIL PROTECTED] wrote:
Marius Mauch wrote:
- Doesn't work with binpkgs (though that's probably also a problem in
getmaskingstatus() itself)
- there is more than keyword and p.mask for masking (profiles)
- the function name is misleading
On Wed, 23 Nov 2005 14:12:22 -0600
Brian Harring [EMAIL PROTECTED] wrote:
Add the keys only if there is a func that can be used- list of
required chksums is a config thing (and repoman thing during
commiting), so I'm not seeing any reason to have None as a value in
your hashfunc mapping...
Robert wrote:
Hey, for some reason I cannot seem to install arts (KDE).
Try asking that on the gentooo-user list, it has nothing to do with
portage development.
Marius
--
gentoo-portage-dev@gentoo.org mailing list
On Thu, 17 Nov 2005 09:30:15 +0200
Marius Mauch [EMAIL PROTECTED] wrote:
Anthony Gorecki wrote:
On Wednesday, November 16, 2005 23:12, Zac Medico wrote:
I wouldn't mind having a feature like this. I would provide a way
for
automatic unmasking tools to keep their changes separate
On Sat, 26 Nov 2005 00:01:15 +0900
Jason Stubbs [EMAIL PROTECTED] 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 when they're ready (or stick
with
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 other new thing in trunk that I know of is logging but
there's still a question mark over the ordering of messages... Can
Andrea Carpani wrote:
Hi all. Here's my problem.
I'm using a lot binary packages of in portage and custom created
ebuilds. I have a virtual ebuild I use that contains only dependencies
and I use this one to merge given versions of packages all in one shot:
sort of a shanpshot of a given moment
On Tue, 6 Dec 2005 23:19:38 +0900
Jason Stubbs [EMAIL PROTECTED] wrote:
So I'm going to make a decision and offer until Friday (Saturday in
my time) for opposers to solidify and state any opposition. If
there's no solid opposition, Saturday I will put current trunk into
~arch as
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 opposition, Saturday I will put current trunk
into ~arch
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.
I just think it's bad engineering to use the same version prefix for
two rather different codebases. ... After all, wasn't
Brian Harring wrote:
So... thoughts? I'm not much for making portage depend on tarsync
just for emerge-webrsync improvements, would rather chunk the bugger
out.
How about runtime detection?
Marius
--
gentoo-portage-dev@gentoo.org mailing list
Carsten Lohrke wrote:
On Thursday 15 December 2005 13:05, Marius Mauch wrote:
package.keywords isn't better or worse than ACCEPT_KEYWORDS, it's just
different in its behavior.
I disagree. ACCEPT_KEYWORDS is problematic for (new) users, because of its
behaviour.
problematic != worse
Brian Harring wrote:
On Thu, Dec 15, 2005 at 01:54:06PM +0200, Marius Mauch wrote:
Brian Harring wrote:
So... thoughts? I'm not much for making portage depend on tarsync
just for emerge-webrsync improvements, would rather chunk the bugger
out.
How about runtime detection?
runtime
Ok, the subject might be confusing, so let me explain this a bit:
Whenever we want/need to make structural changes to the tree that are
going to break backwards compability we have a serious problem (see
GLEP 44 in case you don't know about it). To reduce the impact of that
problem I've got the
Mike Auty wrote:
Yeah,
I agree that the updates should only affect that individual tree.
Whilst I can imagine cases where a move in the main tree should affect
overlay trees (such as recategorizing some net-misc ebuilds into a
net-proxy category), that could at least be emulated with a
On Mon, 9 Jan 2006 10:21:49 -0500
Alec Warner [EMAIL PROTECTED] wrote:
My Apologies, KMail died, and when I restarted it it had the mail but
stripped the attachment ;)
-- Forwarded Message --
Subject: /etc/portage/profile/{pmask,arch.list, categories}
Date: Monday 09
Currently vardbapi.aux_get only works for a subset of all auxdbkeys, as
some like KEYWORDS or DESCRIPTIOn aren't stored in vdb directly.
They are however stored in environment.bz2, but not accessible
there.
This is unintuitive and limits tools like equery or my own auxget
and metascan tools in
Mikey wrote:
I have been emailing the published addresses for GLEP 19 for 2 months now
with no success. I am very interested in any ideas or projects that might
help gentoo be more server friendly, in an enterprise environment, for
lack of a better term.
I have an idea towards stabilizing
On Sun, 22 Jan 2006 10:25:37 -0600
Mikey [EMAIL PROTECTED] wrote:
On Saturday 21 January 2006 22:39, Marius Mauch wrote:
Check the archives for gentoo-dev and gentoo-server, several
implementation plans have been presented in the not-so-distant past.
However everyone seems to have
On Sun, 22 Jan 2006 13:02:37 -0600
Mikey [EMAIL PROTECTED] wrote:
On Sunday 22 January 2006 13:02, Marius Mauch wrote:
Well, posting YAIP (yet another implementation plan) won't really
help either.
Correct, plans never seem to go anywhere in regards to this...
Don't see the goal
On Sun, 22 Jan 2006 14:55:48 -0600
Mikey [EMAIL PROTECTED] wrote:
Users are discouraged from changing make.globals. It would be better
to implement in make.conf or as a command line option to emerge
itself. It is a configuration item for a user preference, not a
(global) portage
On Wed, 11 Jan 2006 12:39:03 -0800
Brian Harring [EMAIL PROTECTED] wrote:
Regex you've got there allows for pulling the wrong text- recall, ebd
originally was doing grep based filtering (regex). Had to rewrite
that in a major hurry since bash syntax (specifically here ops)
forces you to
On Tue, 24 Jan 2006 08:19:22 -0500
Mike Frysinger [EMAIL PROTECTED] wrote:
On Tuesday 24 January 2006 03:43, Francesco Riosa wrote:
Indeed, could someone shade a light on what happen to /var/db/pkg
and world file when using ebuild this manner ?
Could be rephrased as Does it act exactly the
On Tue, 24 Jan 2006 04:50:31 -0800
Brian Harring [EMAIL PROTECTED] wrote:
Yo.
Looking to integrate confcache support into trunk some time in the
near future- had users testing it for about 2 months (give or take),
so far it's behaved pretty decently. A few packages eat themselves
when
On Mon, 23 Jan 2006 14:08:00 -0800
Brian Harring [EMAIL PROTECTED] wrote:
On Mon, Jan 23, 2006 at 07:44:44PM +0100, Marius Mauch wrote:
On Mon, 23 Jan 2006 03:47:11 -0800
Can't follow your thinking here. As said, the code won't corrupt any
data, at worst it will tell the user
Right now 'emerge action' and 'emerge --action' are both supported. But
as we learned with the rsync case 'emerge action' has potential
namespace conflicts with 'emerge package' I'd propose to deprecate
'emerge action' before we hit another real conflict.
(The alternative would be to deprecate
On Thu, 16 Feb 2006 13:04:20 +
Ciaran McCreesh [EMAIL PROTECTED] wrote:
On Thu, 16 Feb 2006 12:31:25 +0100 Marius Mauch [EMAIL PROTECTED]
wrote:
| Right now 'emerge action' and 'emerge --action' are both supported.
| But as we learned with the rsync case 'emerge action' has potential
This is another attempt to prepare the way for including metascan, this
time based on a new restriction framework (which has absolutely nothing
to do with the one in savior/bcportage) included in the attached and
completely undocumented patch (once you get the concept it should be
self-explanatory
Patrick Lauer wrote:
Hi all,
this is an idea we had at FOSDEM to make bugreports easier to read:
During build portage should change the locale to en_us so that any error
messages are easy to read even if the user has set it differently. This
shouldn't affect users much and could get rid of the
So while on my way to FOSDEM I decided to do something useful with the
time and wrote a new manifest2 implementation. This has nothing to do
with the original prototype I posted a while ago, it's been written
completely from scratch.
Basically all functionality (creation, parsing, validation) is
On Sun, 5 Mar 2006 20:46:25 -0500
Mike Frysinger [EMAIL PROTECTED] wrote:
On Sunday 05 March 2006 19:48, Kevin F. Quinn (Gentoo) wrote:
Ned Ludd [EMAIL PROTECTED] wrote:
On Fri, 2006-03-03 at 23:32 -0500, Mike Frysinger wrote:
so we've found some cases where a package installs objects
tvali wrote:
Ok, i send a lot of them, but hopefully they're interesting :)
I did research a bit about adding SQL support to portage -- as much as
i see, mysql is smallest sql server, which could be emerged with
python module.
In beginning, i think that SQL database structure should be
tvali wrote:
I did think about some priorities too, so that it could be perfect for me.
It should be possible to add package with a priority. I will give you an
use case and explanation how i would use portage.
Heh, make the dep resolver even more complex ;)
Also don't really see a need for
Brian wrote:
On Tue, 2006-14-03 at 13:14 +0200, tvali wrote:
Ok, i was, yes, speaking about kde.
I will check out this Porthole :) I was actually thinking more about c
++, but nothing against python -- i was quite a fan of python when i
first found it.
I believe Kuroo is in C, maybe c++
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/... might
still have to be fixed.
Last but not least: I did some basic
So after manifest2 is in, I'll revive the other issue that IMO is a
requirement for 2.1: enforcing dependencies needed to use the tree (see
old threads or glep44 for reasoning). A patch for that is available at
dev.gentoo.org/~genone/patches/treedeps.diff. Unless somebody objects
I'll add that
Marius Mauch schrieb:
So after manifest2 is in, I'll revive the other issue that IMO is a
requirement for 2.1: enforcing dependencies needed to use the tree (see
old threads or glep44 for reasoning). A patch for that is available at
dev.gentoo.org/~genone/patches/treedeps.diff. Unless somebody
On Thu, 06 Apr 2006 19:11:49 -0700
Zac Medico [EMAIL PROTECTED] wrote:
The manifest code doesn't have very many use cases so I'd expect that
we would have hit most major problems by now (even with a small
sample). Any necessary changes are likely to be small patches. As
an alternative, we
On Sun, 23 Apr 2006 08:55:58 -0700
Brian [EMAIL PROTECTED] wrote:
I was thinking that /etc/portage/sets/glsa could be a symlink to set
list in the current metadata/glsa directory of the portage tree. That
file should be relatively easy to auto-generate from the existing
glsa*.xml files there
On Mon, 24 Apr 2006 07:04:13 -0700
Brian [EMAIL PROTECTED] wrote:
On Mon, 2006-24-04 at 14:20 +0200, Marius Mauch wrote:
On Sun, 23 Apr 2006 08:55:58 -0700
Brian [EMAIL PROTECTED] wrote:
I was thinking that /etc/portage/sets/glsa could be a symlink to
set list in the current
[EMAIL PROTECTED] schrieb:
I doubt this is the right place to bring this up, but maybe some one
can tell me where to go :-)
Yeah, this is definitely the wrong place, not really sure where the
appropriate place for this is though. Probably a perl or coreutils
related list/forum might help
Zac Medico schrieb:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ned Ludd wrote:
How do you think we should handle it?
Should we install a post_sync in a postinst phase outside of portage's
handling if and only if not post_sync already exists?
Should we change it to handled a postsync.d by
On Mon, 12 Jun 2006 17:18:44 -0700
Brian [EMAIL PROTECTED] wrote:
On Mon, 2006-12-06 at 18:58 -0500, Andrew Gaffney wrote:
Brian wrote:
Did I understand it wrong or did they get this mixed up in the GWN
announcement:
/etc/portage/package.unmask/kde,
On Mon, 12 Jun 2006 18:20:16 -0700
Brian [EMAIL PROTECTED] wrote:
I also just did a man portage and the man page did not appear to be
updated for this change.
I guess quite a few docs aren't up to date in 2.1. Anyone wanna work on
that?
Marius
--
Public Key at
On Sun, 18 Jun 2006 04:43:28 -0700 (PDT)
Andrei Slavoiu [EMAIL PROTECTED] wrote:
Hello, I want to raise a issue with the way that
package integrity verification is done by portage. For
an example of such an issue see bug 136742.
The idea is that portage now checks the Manifest as a
whole,
On Sat, 24 Jun 2006 18:02:19 -0700
Dan Corson [EMAIL PROTECTED] 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. It may be
that --pretend is a little
On Sat, 22 Jul 2006 16:52:38 -0700
Zac Medico [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Kelly wrote:
In my case, I feel this functionality would be very useful as it
allows for me to integrate my GLEP 27 implementation into portage
without portage
On Sat, 22 Jul 2006 16:25:01 -0700
Zac Medico [EMAIL PROTECTED] wrote:
-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
On Mon, 31 Jul 2006 15:48:23 -0700
Brian Harring [EMAIL PROTECTED] wrote:
but I'd suspect that many
people share my original assumption and expect it to only match full
version components
Hear a bit of screaming from it once every 4-6 months; personally, I
interpret that as devs know
On Mon, 7 Aug 2006 14:14:11 -0700
Brian Harring [EMAIL PROTECTED] wrote:
On Mon, Aug 07, 2006 at 01:13:34PM -0700, Zac Medico wrote:
Brian Harring wrote:
Semantics of USE=-gtk not working on a package that has gtk
forced doesn't sound all that nice btw;
Which is why the flag
On Tue, 10 Oct 2006 00:04:57 -0700
Brian Harring [EMAIL PROTECTED] wrote:
I might be daft (likely), but why not just introduce a var indicating
max parallelization instead? Tweak portage to push that setting into
MAKEOPTS=${MAKEOPTS+${MAKEOPTS} } -j${PARALLELIZATION}.
Might sound daft,
Ok, I have to admit the subject may be a bit confusing, so let me get
the motivation first:
Often people want to know the dependencies of a package. Not much of a
problem when they know how to use auxget or the portageq metadata
commands. However these all work on the specific DEPEND, RDEPEND and
On Sat, 28 Oct 2006 15:42:50 +0300
Ali Polatel [EMAIL PROTECTED] wrote:
Hi everyone,
I wonder if GPG support for mod_mail would be useful.I wrote some
basic code that works.The user is required to export his public key
and put the path to PORTAGE_ELOG_MAILGPG.
Attached is the patch
On Thu, 16 Nov 2006 09:33:05 -0800
Zac Medico [EMAIL PROTECTED] wrote:
Sure, that's one way to solve that particular problem. However, I feel
that command line options are more aesthetically appealing than environment
variables (maybe it's just me).
Zac
It's just you ;)
Marius
--
On Thu, 16 Nov 2006 15:43:48 -0800
Zac Medico [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marius Mauch wrote:
On Thu, 16 Nov 2006 09:33:05 -0800
Zac Medico [EMAIL PROTECTED] wrote:
Sure, that's one way to solve that particular problem. However, I feel
On Wed, 22 Nov 2006 03:10:45 -0500 (EST)
Daniel Barkalow [EMAIL PROTECTED] wrote:
There are packages (such as perl) which work fine on both x86 and arm,
but don't build on x86 cross-compiling for arm. Furthermore, pam-0.78 can
be cross-compiled (with a patch available in bug comments), but
Sometimes a package has to depend on a specific version of a slotted package
being the active one to build correctly, like in the current tr1 discussion
on -dev [1] or with packages that depend on the running kernel.
Currently this isn't really possible, however I while ago I got an idea how to
On Tue, 30 Jan 2007 08:25:31 -0800
Brian Harring [EMAIL PROTECTED] wrote:
On Tue, Jan 30, 2007 at 05:06:51PM +0100, Marius Mauch wrote:
Sometimes a package has to depend on a specific version of a
slotted package being the active one to build correctly, like in
the current tr1 discussion
On Tue, 30 Jan 2007 13:01:47 -0500
Alec Warner [EMAIL PROTECTED] wrote:
Marius Mauch wrote:
Sometimes a package has to depend on a specific version of a slotted
package being the active one to build correctly, like in the current
tr1 discussion on -dev [1] or with packages that depend
On Tue, 30 Jan 2007 18:04:41 +0200
Petteri Räty [EMAIL PROTECTED] wrote:
Marius Mauch wrote:
Sometimes a package has to depend on a specific version of a slotted
package being the active one to build correctly, like in the current
tr1 discussion on -dev [1] or with packages that depend
On Wed, 31 Jan 2007 17:47:26 +
Stephen Bennett [EMAIL PROTECTED] wrote:
On Tue, 30 Jan 2007 17:06:51 +0100
Marius Mauch [EMAIL PROTECTED] wrote:
The idea is to add a special category (let's call it active for
now) that has the following properties:
- this category doesn't exist
There are several cases where the information from which repository
(portdir, overlays, ...) a package originally came from when it was
installed. Currently that information isn't really available, at most
you can use some heuristics on environment.bz2 or comparing ebuilds
directly, but those
On Sat, 17 Feb 2007 12:30:31 +0100
George Shapovalov [EMAIL PROTECTED] wrote:
Hi guys.
I am quite confused by the following:
aldar ~ # emerge -puD world --tree
These are the packages that would be merged, in reverse order:
Calculating world dependencies... done!
[nomerge ]
If you haven't noticed, I just added a new 'preserve-libs' feature for
bug 62207 that moves shared object that are still used but would be
removed on an update into the new package instance (so on a update from
expat-1 to expat-2 the user would still have libexpat.so.0, owned by
expat-2). The
On Sat, 17 Feb 2007 13:42:49 +0100
George Shapovalov [EMAIL PROTECTED] wrote:
Ok, found it.
Thanks Marius! (for the debug hint)
It was indeed forcing gnat-gcc-4.1.1 by asis-gcc-4.1.1 which has
=dev-lang/gnat-4.1.1 (this is an extension to compiler and has to
match it 1 for 1, forgot to
On Sat, 17 Feb 2007 14:55:26 +0100
Simon Stelling [EMAIL PROTECTED] wrote:
Marius Mauch wrote:
So everyone who has valid objections to the _general idea_ of this
implementation (preserving old libraries to avoid some runtime
linker errors) speak up now.
For how long are these libraries
On Thu, 8 Mar 2007 20:14:26 +0100
Kevin F. Quinn [EMAIL PROTECTED] wrote:
This is an old issue, but I want to suggest a re-visit :)
As we all know, setting LC_ALL and friends can cause all sorts of
trouble in package builds. However, many users really appreciate
being able to set it so
Please reply on gentoo-portage-dev, _not_ on gentoo-dev, thanks.
One missing feature in portage is the lack of package sets. Before we
(re)start working on that however I'd like to get some feedback about
what properties/features people would expect from portage package set
support.
Some key
On Thu, 28 Jun 2007 21:03:54 -0700
Ned Ludd [EMAIL PROTECTED] wrote:
On Fri, 2007-06-29 at 05:07 +0200, Marius Mauch wrote:
Please reply on gentoo-portage-dev, _not_ on gentoo-dev, thanks.
One missing feature in portage is the lack of package sets. Before
we (re)start working
On Fri, 29 Jun 2007 05:07:28 +0200
Marius Mauch [EMAIL PROTECTED] wrote:
Please reply on gentoo-portage-dev, _not_ on gentoo-dev, thanks.
One missing feature in portage is the lack of package sets. Before we
(re)start working on that however I'd like to get some feedback about
what
On Sun, 21 Oct 2007 05:23:45 -0700
Ned Ludd [EMAIL PROTECTED] wrote:
On Sun, 2007-10-21 at 13:01 +0200, Marius Mauch wrote:
So, what do people think about removing (some) of the special
treatment for the system and world targets?
Mainly I'm interested in removing the selective parameter
On Sun, 21 Oct 2007 12:23:59 -0700
Zac Medico [EMAIL PROTECTED] wrote:
-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
On Mon, 22 Oct 2007 04:54:59 +0200
Arfrever Frehtes Taifersar Arahesis [EMAIL PROTECTED] wrote:
2007-10-21 22:49:10 Marius Mauch napisał(a):
On Sun, 21 Oct 2007 12:23:59 -0700
Zac Medico [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arfrever Frehtes
On Mon, 22 Oct 2007 21:29:02 -0700
Zac Medico [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ryan Hill wrote:
Zac Medico wrote:
implement greedy atoms for the world set. I've been pondering the
idea of making world non-greedy for slots by default [1], since you
On Sun, 21 Oct 2007 15:12:31 +0200
Marius Mauch [EMAIL PROTECTED] wrote:
Well, the primary goal is to make all sets behave in a consistent way.
And some sets have the explicit purpose to rebuild stuff, so making
sets selective by default also has issues.
The proposed change would also make
On Tue, 23 Oct 2007 21:11:48 +0200
Thomas de Grenier de Latour [EMAIL PROTECTED] wrote:
On 2007/10/23, Marius Mauch [EMAIL PROTECTED] wrote:
On Mon, 22 Oct 2007 21:29:02 -0700
Zac Medico [EMAIL PROTECTED] wrote:
Well, you can already use SLOT atoms in your world file if you
don't
On Wed, 24 Oct 2007 00:03:47 +0200
Thomas de Grenier de Latour [EMAIL PROTECTED] wrote:
Bah, you're introducing a new options set, and have (i think) ways to
emulate all of the old ones with them, so what is stopping you? You
would just have to forbid mixes of old style and new style on the
1 - 100 of 120 matches
Mail list logo
