On Thu, Oct 06, 2005 at 12:14:30AM +0100, Ciaran McCreesh wrote:
On Wed, 5 Oct 2005 18:00:12 -0500 Brian Harring [EMAIL PROTECTED]
wrote:
| Beyond that, there is the shebang issue which can be addresses via a
| combination of automated scans/fixes, and fixing bugs as it's hit.
| Hardcoded
On Thu, Oct 06, 2005 at 12:38:35AM +0100, Ciaran McCreesh wrote:
On Wed, 5 Oct 2005 18:22:37 -0500 Brian Harring [EMAIL PROTECTED]
wrote:
| On Thu, Oct 06, 2005 at 12:14:30AM +0100, Ciaran McCreesh wrote:
| On Wed, 5 Oct 2005 18:00:12 -0500 Brian Harring
| [EMAIL PROTECTED]
| wrote
On Thu, Oct 06, 2005 at 01:13:53AM +0100, Ciaran McCreesh wrote:
On Wed, 5 Oct 2005 18:40:46 -0500 Brian Harring [EMAIL PROTECTED]
wrote:
| It does in some places, it doesn't in others. It especially doesn't
| for things that aren't normally found via PATH. It's a hell of a
| mess
On Thu, Oct 06, 2005 at 02:23:47AM +0100, Ciaran McCreesh wrote:
On Wed, 5 Oct 2005 20:17:40 -0500 Brian Harring [EMAIL PROTECTED]
wrote:
| The issue is that you need to fix autoconf before you can claim that
| any non-trivial test case works correctly.
|
| And how are you going to verify
On Thu, Oct 06, 2005 at 02:40:58AM +0100, Ciaran McCreesh wrote:
On Wed, 5 Oct 2005 20:32:20 -0500 Brian Harring [EMAIL PROTECTED]
Portage is considerably less work than the tree. Saving as much effort
as possible from an ebuild perspective should be a major consideration,
even if it makes
On Thu, Oct 06, 2005 at 03:01:12AM +0100, Ciaran McCreesh wrote:
On Wed, 5 Oct 2005 20:48:26 -0500 Brian Harring [EMAIL PROTECTED]
wrote:
| The sensible place to start experimenting is by adapting existing
| ebuilds and tinkering with ebuild.sh, not by adding something which
| may or may
On Thu, Oct 06, 2005 at 02:14:32PM +1000, Finn Thain wrote:
On Wed, 5 Oct 2005, Kito wrote:
[snip]
My first question would be how to identify ebuilds that respect ${prefix}?
A separate profile/keyword seems wrong.
ICANINSTALLTO was the best idea presented, but that implies
Quicky description of the bug is that A was being defined to '' in the
ebuild env; due to the fact ebuild.sh automatically stomps the current
passed in env with the previous env (it's bad, we know it already :),
this resulted in A getting auto set to a bad value, and the value
lingering.
On Tue, Oct 04, 2005 at 09:17:22AM -0500, Brian Harring wrote:
Responding to myself, because I'm an idiot, attached is the correct
patch.
~harring
Index: bin/ebuild.sh
===
--- bin/ebuild.sh (revision 2082)
+++ bin/ebuild.sh
On Sun, Oct 02, 2005 at 11:07:13PM +0200, Francesco R wrote:
The ready to cut ebuild at the bottom print it's environment (variable
and functions) to a bunch of files into /var/tmp/fakebuild/.
May be useful for who want to have a look at what and when is
avaible during the various emerge
On Mon, Oct 03, 2005 at 07:39:05PM +0200, Jan Kundr?t wrote:
Ciaran McCreesh wrote:
On Mon, 3 Oct 2005 23:15:37 +0900 Georgi Georgiev [EMAIL PROTECTED] wrote:
| Does it seem like it is time for RESTRICT=interactive. Such ebuilds
| would refuse to emerge if stdout is not a tty. If only there
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 inheritance...
* Make all aux_get() functions return a list of
On Tue, Oct 04, 2005 at 08:27:09AM +0900, Jason Stubbs wrote:
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
On Sat, Oct 01, 2005 at 11:57:01PM +0200, Daniel Stiefelmaier wrote:
man emerge provides information on possible options, why should there
not be a way to get information on an ebuilds option???
because emerge is the tool, not the object. You wouldn't expect the
openoffice
Hola.
Subject says it all; SANDBOX_DISABLED functions as (essentially)
RESTRICT=sandbox, except sandbox is left on for pkg_setup .
This is pretty much redundant, considering it's usage. People stick
it in the global scope; if you _must_ turn off the sandbox for a
specific phase, use
On Thu, Sep 29, 2005 at 12:46:36AM -0400, Dave Nebinger wrote:
Hey, folks.
I'm trying to write an ebuild, not my first, but definitely something
that is relatively new to me.
Anyways, I've got the following URL that pulls down the source package:
On Tue, Sep 27, 2005 at 09:07:00AM -0500, Kito wrote:
[Portage devs please don't throw rocks at me]
All out of rocks :/
My impression of the userland, elibc, and kernel use expanded vars is
it was a quick way to sidestep some of the issues with GLEP22... it
would seem the full keywords
On Tue, Sep 27, 2005 at 08:27:34AM -0400, Chris Gianelloni wrote:
On Tue, 2005-09-27 at 10:39 +0200, Henrik Brix Andersen wrote:
On Tue, Sep 27, 2005 at 10:31:04AM +0200, Jan Kundr??t wrote:
our documentation [1] lists syslog-ng as the default system logger
while current profiles uses
On Tue, Sep 27, 2005 at 01:47:49PM -0400, Mike Frysinger wrote:
On Tuesday 27 September 2005 01:29 pm, Chris Gianelloni wrote:
On Tue, 2005-09-27 at 11:57 -0500, Brian Harring wrote:
I'd rather see reasons listed as to why syslog-ng is a superior
default for users who (most likely) don't
Hola all.
The short version of it is that there is no good reason to be using
has_version/portageq in the global scope; it's slow, it's not allowed,
and any attempts to change metadata via it screw up the build plan.
It's really a no go... so next version of portage will trigger an
On Thu, Sep 22, 2005 at 09:30:20AM -0400, Chris Gianelloni wrote:
On Wed, 2005-09-21 at 17:55 -0500, Lance Albertson wrote:
Is this just a one-off implementation until GLEP 23 is implemented, or
something that will complement it? Whats going to happen to this data
after GLEP23 gets
On Tue, Sep 20, 2005 at 10:01:39AM +0300, Alin Nastac wrote:
Georgi Georgiev wrote:
maillog: 20/09/2005-09:37:23(+0300): Alin Nastac types
Georgi Georgiev wrote:
- that package in my overlay that has net-wireless/gnome-phone-manager
in its *DEPENDs to work for as long as needed
On Sun, Sep 18, 2005 at 03:48:43PM +, John N. Laliberte wrote:
* but you are taking away choice! - If a program has both GTK2 and GTK3
interfaces, there are many ways to allow for testing of the experimental
interface. For instance, package.mask with a revision number.
package.mask isn't
Hola.
http://glep.gentoo.org/glep-0031.html-- the details
http://bugs.gentoo.org/106544-- the bug
http://bugs.gentoo.org/attachment.cgi?=68828 -- the patch
Attached the patch also; one additional tweak is that file.size is now
a fatal check, since the tree seem's to
On Mon, Sep 19, 2005 at 04:12:08PM -0500, Brian Harring wrote:
Attached the patch also; one additional tweak is that file.size is now
a fatal check, since the tree seem's to finally be clean.
Dropped the file.size becoming fatal change on the bug, and intend to
for the final version.
Either
On Sat, Sep 17, 2005 at 11:28:03AM +0200, Kevin F. Quinn wrote:
The 30-day could be calculated from the $Header: of ebuilds that have
no UNSTABLE, or where it's empty.
Doesn't work for N arches keywording, or ebuild dev doing minor
syntax touch ups.
~harring
pgp9GsjkqH1mC.pgp
Description:
On Fri, Sep 16, 2005 at 08:14:08PM +0200, Martin Schlemmer wrote:
On Fri, 2005-09-16 at 19:42 +0200, Paul de Vrieze wrote:
On Friday 16 September 2005 00:20, Mike Frysinger wrote:
actually this is came up in the meeting as something we would like to see
spelled out explicitly ... either
On Sat, Sep 17, 2005 at 08:23:47AM +1200, Nick Rout wrote:
Thanks for the clarification Chris.
On a semi-related matter I was looking for the catalyst .spec files, and
see a thread pointing at cvs, however I believe that as a non-dev mortal I
can't get access to gentoo cvs. Is that so? If it
On Wed, Sep 14, 2005 at 04:38:04PM +0100, Ciaran McCreesh wrote:
On Wed, 14 Sep 2005 09:42:43 +0200 Thierry Carrez [EMAIL PROTECTED]
wrote:
| Before debating if the QA team should have more power to enforce,
| let's just have a proper QA project. Apparently not much devs want to
| do QA, not
On Tue, Sep 13, 2005 at 03:24:38PM +0200, Frank Schafer wrote:
Hello,
this bug is from 2005-02-05. It was reported again (in this thread)
2005-02-10. I hit the same behavior 2005-09-08.
internal compiler error: segmentation fault during emerge Xorg
The bug is simply reproducible (emerge
On Tue, Sep 13, 2005 at 05:02:45PM -0400, Mike Frysinger wrote:
On Tuesday 13 September 2005 04:43 pm, Donnie Berkholz wrote:
Mike Frysinger wrote:
this side note is unrelated to the point being made and really belongs in
the previous discussions on the devrel list
besides, is this
On Mon, Sep 12, 2005 at 02:13:43PM +0200, Frank Schafer wrote:
Hi,
I fought with a stage1 install during this weekend. Today in the morning
I succeeded.
I had to move a lot in /var/log/portage.
For the content of this directory I'd suggest the following:
Remove the 4 digit number from
Top posting, since trying to make a point here in relation to
everything that follows from your email.
define exactly how one proves themself, and in what context.
It's the arguement against (essentially) having AT's on the same level
as ebuild devs, so it best be defined.
On Tue, Sep 13,
With the 'proven' definition being repeated contributions, and
explicit in the previous email the view AT's are lesser, but can move
'up' to the level of an ebuild dev, back to this email...
On Tue, Sep 13, 2005 at 04:14:34AM +0100, Ciaran McCreesh wrote:
On Mon, 12 Sep 2005 23:01:20 -0400
Icky on the html email :P
On Wed, Sep 07, 2005 at 05:45:16PM -0700, m h wrote:
Hello-
I'm investigating the similarities between portage and openpkg. More
specifically I was wondering if it is possible to take portage and
install in on top of an existing linux installation in its own sandbox
On Fri, Sep 02, 2005 at 10:53:05AM +0200, Paul de Vrieze wrote:
On Friday 02 September 2005 08:04, Brian Harring wrote:
Like I've said, EAPI is ebuild specific. Ebuild is a format; eapi
defines revisions of it, in my mind a minor revision of the ebuild 1
format. Any form of loss
On Sat, Aug 27, 2005 at 03:42:25AM -0500, Brian Harring wrote:
Hola all.
Straight to the point, I'm proposing that the following files-
arch.list
categories
use.desc
use.local.desc
package.mask
updates
Addition to this list: thirdpartymirrors .
~harring
pgpvIGSGfwz7G.pgp
Description
On Tue, Aug 30, 2005 at 07:46:24PM +0200, Marius Mauch wrote:
On 08/29/05 Brian Harring wrote:
That and the fact the 2.1 state should be decided, if we're going to
have (effectively) two branches of development going at once, vs
developmental line and maintenance branch.
Well
On Fri, Sep 02, 2005 at 07:58:05AM +0200, Marius Mauch wrote:
On 08/26/05 Brian Harring wrote:
On Fri, Aug 26, 2005 at 11:44:44AM -0400, Dan Meltzer wrote:
Hows the upgrade path RE: end-user useflag changes? Will everyone
that has gtk in their make.conf die a horrible death
On Fri, Sep 02, 2005 at 08:17:39AM +0200, Marius Mauch wrote:
On 08/27/05 Brian Harring wrote:
Straight to the point, I'm proposing that the following files-
arch.list
categories
use.desc
use.local.desc
package.mask
updates
be moved out of the profiles directory in the tree
On Mon, Aug 29, 2005 at 12:56:35PM -0400, Chris Gianelloni wrote:
On Sat, 2005-08-27 at 05:01 -0500, Brian Harring wrote:
Basically, you've taken then 2005.1 profile and made it useless, since
the stages weren't built against it anyway.
Via that logic (don't change it lest it negates a release
On Mon, Aug 29, 2005 at 01:27:34PM -0400, Chris Gianelloni wrote:
This could still be done under profiles. Personally, I like the idea of
something more like this:
project/os/arch/version for profiles
This would give us something like this:
default/linux/x86/2006.0
On Mon, Aug 29, 2005 at 05:48:20PM -0400, Chris Gianelloni wrote:
What other changes are you guys thinking of regarding profiles?
That would be Marius's department. I'm not willing (personally) to
look at revamping profiles till rewrite is finished.
At that point, new profile's should be able
On Mon, Aug 29, 2005 at 05:43:35PM -0400, Chris Gianelloni wrote:
snip
Re: not shoving work onto you, complicating your job, etc, I agree,
and actually is what I was getting at in the badly worded section
below
My point is pretty simple,
why should we spend a bunch of time maintaining
On Sun, Aug 28, 2005 at 02:31:24AM -0700, Zac Medico wrote:
Brian Harring wrote:
Please test this out; if you want to test the EAPI checking, tag
EAPI=1 into an ebuild, and try making emerge bail.
I needed to patch ebuild.sh so that EAPI would be parsed. It bails out
properly now.
Crud
Note, sending to dev only, not cc'ing core; the inital -core post was
to make sure those who aren't watching dev ml see the email (annoying,
but it's an old habit I've yet to kick despite needing to).
On Sat, Aug 27, 2005 at 04:48:26AM -0500, Donnie Berkholz wrote:
Brian Harring wrote:
I
On Sat, Aug 27, 2005 at 01:17:50PM +0200, Kevin F. Quinn wrote:
On 27/8/2005 10:42:25, Brian Harring ([EMAIL PROTECTED]) wrote:
Hola all.
Straight to the point, I'm proposing that the following files-
arch.list
categories
use.desc
use.local.desc
package.mask
updates
On Sat, Aug 27, 2005 at 01:32:33PM +0200, Fernando J. Pereda wrote:
On Sat, Aug 27, 2005 at 01:17:50PM +0200, Kevin F. Quinn wrote:
Not sure about package.mask. I thought that was part of the profile,
as different profiles might package.mask separately. I know I use it
in /etc/profile to
On Sat, Aug 27, 2005 at 03:29:32PM +0200, Kevin F. Quinn wrote:
On 27/8/2005 13:34:15, Brian Harring ([EMAIL PROTECTED]) wrote:
Rough filtering stack-
profiles/package.mask
/etc/make.profile/package.mask (incremental through subprofiles)
users package.mask, and users package.unmask
Pardon the delay, been putting this one off since it's going to be a
fun one to address, and will be a bit long :)
On Thu, Aug 25, 2005 at 12:34:00PM +0200, Paul de Vrieze wrote:
What I mean is compatibility with current portage versions. Current
versions do not understand EAPI. There would
On Fri, Aug 26, 2005 at 03:49:35PM -0400, Kristian Benoit wrote:
On the EAPI subject Brian just brought back, I had this idea that we
could use the same approch XML took with HTML.
The ebuild could define which EAPI to use, but instead beiing a version,
the EAPI would be an ebuild API
On Fri, Aug 26, 2005 at 03:02:13PM -0700, Drake Wyrm wrote:
Brian Harring [EMAIL PROTECTED] wrote:
B) EAPI is pretty much bash env template switching
[snip]
Perhaps the EAPI handling could be implemented using eclasses, rather
than something in the deep, dark, python-based internals
On Thu, Aug 25, 2005 at 12:05:11PM +0200, Paul de Vrieze wrote:
Why not create that directory in the /var/tmp/portage/package/ directory.
It would also safeguard against packages using files that they did not
request. Maybe in the future a similar thing could be done for patches
(when
On Thu, Aug 25, 2005 at 01:41:00PM +0200, Paul de Vrieze wrote:
On Wednesday 24 August 2005 15:23, Martin Schlemmer wrote:
Same thing (and probably better option) if you put it in pkg_setup()
...
Isn't pkg_setup run too when just building a binary package (-B) (then the
check shouldn't
Hola all.
Out of curiousity, since for once my portage installation is *not*
filtering out all flags but my own, I'm wondering why it is that the
system default now holds a lot of use flags that aren't really related
to the system set of packages.
See, from my standpoint cascaded profiles
On Wed, Aug 24, 2005 at 08:50:58PM -0400, Mike Frysinger wrote:
On Wednesday 24 August 2005 08:04 pm, Brian Harring wrote:
Again, returning to the USE=-* arguement, yes, they can go that
route. It's also kind of a crappy arguement dodging out of the fact that
progressive bloat going
Hola all.
robbat2 made the suggestion, and after a bit of playing I think it's
best- in short, to support multiple DISTDIR's, we need either
intelligent querying of portage from bash side as to a files true
location, or a directory full of symlinks pointing at the ebuild's
stated files.
On Tue, Aug 23, 2005 at 06:58:53PM -0400, Kristian Benoit wrote:
Yeah, I'd really like having a snapshot, even if I'd prefer having
cvs/svn access. You can send me it by mail or make it available
somewhere.
Pardon the delay, wanted to iron out building code before
pushing the snapshot up- it's
On Tue, Aug 23, 2005 at 08:23:24AM +0200, Dirk Heinrichs wrote:
Hi,
I have written an ebuild for pam_krb5, based on the version found in fedora,
since the one from sourceforge which is currently in portage is way
outdated.
However, even after reading all the ebuild docs, I can't figure
On Tue, Aug 23, 2005 at 09:21:50AM +0200, Fabian Zeindl wrote:
Since nobody except Diego replied on my mail a week ago:
Is there another way besides filing bugs and mailing the list to make a
proposal which gets investigated? I think many users are concerned about that
gstreamer oddness, and
On Tue, Aug 23, 2005 at 03:20:16PM +0200, Paul de Vrieze wrote:
To allow for this to work with current portage versions, perhaps it would
be an option to introduce a new extension for .ebuild scripts that use
it's functionality. That would allow all non-EAPI aware portage versions
to
On Tue, Aug 23, 2005 at 12:25:03PM -0400, Kristian Benoit wrote:
On Mon, 2005-08-22 at 15:39 -0500, Brian Harring wrote:
That and help would always be welcome :P
Then where do I find the code (I'm an official dev yet, so I only have
access to what's in the mirrors and the patchs on mailing
On Tue, Aug 23, 2005 at 12:25:03PM -0400, Kristian Benoit wrote:
On Mon, 2005-08-22 at 15:39 -0500, Brian Harring wrote:
That and help would always be welcome :P
Then where do I find the code (I'm an official dev yet, so I only have
access to what's in the mirrors and the patchs on mailing
Lot of text left inline, pardon, just scroll and deal with it :P
On Tue, Aug 23, 2005 at 12:28:08PM -0400, Kristian Benoit wrote:
Here is my recent communication with Pieter:
On Sat, 2005-08-13 at 21:59 +0200, Pieter Van den Abeele wrote:
On 13 Aug 2005, at 19:16, Kristian Benoit wrote:
First, sidenote (mild ot to this thread also), pardon the dupe posts,
thick fingered typing dumping an old message :)
On Tue, Aug 23, 2005 at 01:34:33PM -0400, Olivier Crete wrote:
On Tue, 2005-23-08 at 11:16 +0200, Paul de Vrieze wrote:
As an aside to this. Does anyone know how debug
On Tue, Aug 23, 2005 at 01:58:46PM -0400, Olivier Crete wrote:
I havent looked at your new implementation (does it exist).. but yea
what you wrote seems to make sense... except that I keep the source code
too.. so it would bloat binary packages.. I think it should be done
before the packages
On Wed, Aug 24, 2005 at 12:11:19PM +1200, Nick Rout wrote:
On Tue, 23 Aug 2005 04:41:49 +0200
Marius Mauch wrote:
DOWNLOAD_CMD=wget http://laby.toybox.de/download15/ -O
laby_$(P).tar.gz
Nope. You have three options:
a) bug upstream to fix that crap
b) use RESTRICT=fetch
c)
On Wed, Aug 24, 2005 at 12:34:41PM +1200, Nick Rout wrote:
Thanks to all of you, thats now very clear.
The message i have is that it will work, but its not allowed.
Wrong interpretation- it won't work within an ebuild.
It requires exteneral user intervention to make the ebuild work,
*every*
On Mon, Aug 22, 2005 at 01:49:14PM -0400, Kristian Benoit wrote:
On Mon, 2005-08-22 at 16:38 +0200, Marius Mauch wrote:
Anyway, I hope you realize that your project doesn't only involve
hacking on portage, but rewriting almost all of it for the client part.
Actually I'd rather suggest you
Hola all.
Short version, the nostrip feature is a bit funky as an option. What
I'm after is effectively building all packages *with* debugging
information as default, and leaving it up to the repository you're
merging the package to, to decide on stripping or not.
IOW, if you prefer stripped
Fair warning,
To anyone relying on the vars BUILD_PREFIX, BUILDDIR to be available
in the ebuild env, they're going to be yanked down the line; right
now, going by scans nobody relies on them- so... please keep it that
way.
Thanks,
~harring
pgpjVDBwDVZS4.pgp
Description: PGP signature
On Mon, Aug 22, 2005 at 11:33:23PM +0200, Marius Mauch wrote:
Theoretical discussions about this are pointless IMO without
numbers/facts to back things up.
I'd posit theroetical discussions about this are pointless without
getting ebuild dev's to give a yay/nay on whether they want it or not;
On Sat, Aug 20, 2005 at 01:13:37PM -0400, Nathan L. Adams wrote:
Chris Gianelloni wrote:
Reviewing an ebuild has nothing to do with inclusion. For inclusion in
the tree, it also needs to be tested.
You don't take the slightest look at an ebuild (the code) before
including it? Anyhow,
On Fri, Aug 19, 2005 at 12:10:44AM -0700, Donnie Berkholz wrote:
Brian Harring wrote:
| Yeah, but the angle I'm pushing for default IUSE's ...er.. use is
| eliminating no* flags, and giving ebuild maintainers more flexibility
| in breaking the package down into conditionals.
|
| I really
On Thu, Aug 18, 2005 at 11:37:05AM -0400, Chris Gianelloni wrote:
Other distributions are also binary-only, so there's no real comparison
here. While I think having client and server type USE-flags is
really a bad idea, I don't see a problem with providing a library.
I 100% disagree with
On Thu, Aug 18, 2005 at 09:08:51AM -0700, Donnie Berkholz wrote:
Brian Harring wrote:
| Kind of curious about people's opinion on the IUSE default use flag
| thing, initial syntax was (using the above example)
| IUSE=+client server
| with client defaulting to on unless the user's config
On Thu, Aug 18, 2005 at 01:16:05PM -0400, Alec Warner wrote:
As long as there is a way provided disable the 'default use flags' in
this case referring to the IUSE=+foo stuff, with a big warning that
says crap generally isn't expected to work great with that setting on,
then thats fine. I
On Thu, Aug 18, 2005 at 01:18:17PM -0400, Mike Frysinger wrote:
Yes, very. Saves us from hacky local USE flag handling by naming them
no* or adding them to profiles.
Which then raises the question of whether or not -* in a users USE
should disable it.
I say no, since -* is mainly for
On Thu, Aug 18, 2005 at 06:24:03PM +0100, Ciaran McCreesh wrote:
On Thu, 18 Aug 2005 10:56:06 -0500 Brian Harring [EMAIL PROTECTED]
wrote:
| Best solution in my opinon? Two use flags address this, client, and
| server. Regardless of the setting of the two, you get the library;
| from
On Fri, Aug 19, 2005 at 01:06:35AM +0100, Ciaran McCreesh wrote:
On Thu, 18 Aug 2005 13:13:56 -0500 Brian Harring [EMAIL PROTECTED]
wrote:
| You're a bit vague in the 'die in pkg_setup' bit; if you're
| referencing doing the changes now, and sticking a die in, I already
| explicitly stated
On Fri, Aug 19, 2005 at 05:30:42AM +0200, Christian Parpart wrote:
On Thursday 18 August 2005 17:44, Chris Gianelloni wrote:
On Thu, 2005-08-18 at 10:17 -0500, Brian Harring wrote:
2) ebuild maintenance will be a nightmare- every new version will
require again walking the source to see
Hola-
basically, use_expand'd vars need to be exempted from IUSE checks, as
long as the USE_EXPAND var is in IUSE.
This does that.
~harring
Index: ebuild.sh
===
RCS file: /var/cvsroot/gentoo-src/portage/bin/ebuild.sh,v
retrieving
On Fri, Aug 12, 2005 at 12:04:34PM -0400, Kristian Benoit wrote:
I remember, when I started using Gentoo, reading that portage is a stand
alone tool, it is not bind into Gentoo in anyway, someone could use it
on redhat, debian, lfs...
Nice intention, but impossible with stable/alpha code- the
On Tue, Aug 09, 2005 at 07:36:31AM -0500, Caleb Tennis wrote:
On Monday 08 August 2005 08:14 pm, Donnie Berkholz wrote:
If you could bring up some specific examples, we could discuss them.
Sure. Qt has optional support for xkb, tablet, fontconfig, xrender, xrandr,
xcursor, xinerama
On Fri, Aug 05, 2005 at 10:59:23AM +0200, Sune Kloppenborg Jeppesen wrote:
On Friday 05 August 2005 03:40, Brian D. Harring wrote:
On Thu, Aug 04, 2005 at 05:31:43PM -0400, Chris Gianelloni wrote:
It's not an overnight thing, glep19 (stable portage tree) addresses a
chunk of concerns
On Tue, Jun 21, 2005 at 08:35:52PM +0200, Thierry Carrez wrote:
I don't say that it cannot be done, and I don't ask what's the best way
to do it. I just ask *if* we should try to provide higher-level tools
(and/or doc) to help in doing so. It's not obvious (especially for
non-developers) how
On Wed, Jun 01, 2005 at 11:25:00PM +0900, Jason Stubbs wrote:
I'd be for having RDEPEND required to be set manually. ;)
As would I, actually...
Granted it's a useful convenience, but it also makes nailing the deps
down much harder. Personally down the line, I'd like to see packages
that
On Fri, May 27, 2005 at 01:47:37PM +0200, Danny van Dyk wrote:
Hi Brian
What's the gain, aside from implication of collapsing it into a
single file? Honestly my only use for metadata.xml is looking up who
I get to poke about fixing broken ebuilds...
The gain is:
... that you portage
On Tue, May 24, 2005 at 11:07:54AM +0100, Ciaran McCreesh wrote:
On Tue, 24 May 2005 11:53:30 +0200 Michael Haubenwallner
[EMAIL PROTECTED] wrote:
| Variables to be set by portage:
| PREFIX=/home/haubi
| AFFIX=home/haubi/ (not used here)
Hrm. So what do we use for finding out where our
On Tue, May 17, 2005 at 09:58:43AM +0200, Thierry Carrez wrote:
Stefan Schweizer wrote:
Many bugs in bugzilla have ebuilds contributed, the work is done,
there is just no developer to add them to the tree and review them.
Bugvoting would allow other developers to see where they can help.
On Tue, May 10, 2005 at 10:59:42PM -0700, Duncan wrote:
Since our tree layout is based upon category, if you tried shifting the
focus of it to packages_in anyway_, you would explicitly disallow same
name packages, different category. Doesn't matter how you structure the
tree, if you do
On Wed, May 11, 2005 at 10:11:32AM +0200, Danny van Dyk wrote:
Fine, fine this means i can remove them as soon as i pout the new
versions in :-) I'm now going to package mask all of icc/ifc.
Hmm. mm'kay, get cracking, they'll still get flagged in my script :)
These fetching failures are
On Wed, May 11, 2005 at 06:01:17PM +0900, Georgi Georgiev wrote:
maillog: 11/05/2005-03:40:04(-0500): Brian Harring types
On Wed, May 11, 2005 at 09:46:03AM +0200, Kevin F. Quinn wrote:
Here's my suggestion, for what it's worth :)
The layout on disk and the semantics of categories do
On Wed, May 11, 2005 at 11:11:02AM -0400, Alec Warner wrote:
Yes and no. You're assuming that people don't use the layout on disk for
digging
around without calling portage. Personally, I do.
Not need to be related, but shouldn't be related. In essence this
allows people to put the
On Tue, May 10, 2005 at 09:54:33PM +0100, Ciaran McCreesh wrote:
Is there a standard way of handling testing for utility-type eclasses?
For versionator I currently have a __versionator__test_blah function
included in the eclass (source versionator.eclass works, it doesn't have
any
On Tue, May 10, 2005 at 08:04:04PM +0900, Georgi Georgiev wrote:
maillog: 10/05/2005-11:28:21(+0200): Martin Schlemmer types
On Mon, 2005-05-09 at 13:07 -0400, Aron Griffis wrote:
Georgi Georgiev wrote:[Sun May 08 2005, 08:19:20PM EDT]
Would it be inappropriate to start bitching
On Wed, May 11, 2005 at 01:27:46PM +0900, Georgi Georgiev wrote:
As to whether the categories are good or not... think about it. If they
were good, would we still be seeing packages moving around the tree?
That's why I think that multiple categories are a necessity. Unless of
course, packages
On Mon, May 09, 2005 at 03:46:57AM +0300, Marius Mauch wrote:
Brian Harring wrote:
Clarify please :)
Offhand, I don't see why a bin repo for a home target isn't viable,
along with a vdb repo in the same location. It's a bit trickier, but
I suspect it might be a bit more flexible
On Mon, May 09, 2005 at 10:12:03PM +0200, Paul de Vrieze wrote:
What about adding a panic mode to portage which, when confronted with a
missing profile, (and after confirmation) continues to upgrade portage to the
latest version it can find with some default settings that should allways
Unless someone steps up, the intel compiler toolchain
packages dev-lang/icc (intel cc) and dev-lang/ifc (intel fortran
compiler) are prime candidates for removal from the tree; open bugs,
primary maintainer is retired, and no devs have moved in to pick up the
packages, let along touched the
701 - 800 of 813 matches
Mail list logo
