Alec Warner [EMAIL PROTECTED] writes:
- Space savings. Certainly your scheme may be smaller, but the XML
tag overhead may eat into the savings. You should do some estimates
to show the community how much smaller the tree will be from this
proposal.
Sorry but you lost me on any point you
Jan Kundrát [EMAIL PROTECTED] writes:
But also the need to replicate http://www.kde.org/ to metadata.xml of
all KDE split ebuilds -- right now, this is set by an eclass.
The usefulness of this is IMHO debatable; why not just writing it one
package (say kde-base/kde or kde-meta) and just there?
Maciej Mrozowski [EMAIL PROTECTED] writes:
- USE=debug is useless when CFLAGS/LDFLAGS or FEATURES are not appropriate
What are you saying here? I'm afraid you're mistaken here.
For the most part, USE=debug means enable debug code paths, which for
lots of projects simply means enable
В Пнд, 01/12/2008 в 06:16 +0100, Maciej Mrozowski пишет:
Currently handling debug/release builds is incoherent and misleading to say
the least. We have got in Gentoo:
All that parts do their separate and quite a different work so I can't
say that it's incoherent (by idea at least).
The
On Mon, Dec 1, 2008 at 12:24 AM, Diego 'Flameeyes' Pettenò
[EMAIL PROTECTED] wrote:
Alec Warner [EMAIL PROTECTED] writes:
- Space savings. Certainly your scheme may be smaller, but the XML
tag overhead may eat into the savings. You should do some estimates
to show the community how much
Alec Warner [EMAIL PROTECTED] writes:
That being said I still don't see the usefulness here.
You seem to think that using the existing APIs for this data is wrong,
and I think the opposite, so I guess we will agree to disagree on this
matter.
Yeah I still think that there is no point in
On Monday 01 of December 2008 08:04:04 Duncan wrote:
Well, so far it's not GLEP, just an idea thrown to brainstorm.
As such, neither /etc/portage/env nor eclasses can effectively deal with
FEATURES in general, tho there are a few specific exceptions that do
happen to be implemented at the
Hi,
Dale [EMAIL PROTECTED]:
If you have a GUI on your system, give this a look:
app-portage/elogviewer That should help you a lot. I been using it
for a good while and it works pretty well. I do wish it had little
flags in the list of packages that have been installed. Sort of a
short
On Monday 01 of December 2008 09:36:12 Diego 'Flameeyes' Pettenò wrote:
- USE=debug is useless when CFLAGS/LDFLAGS or FEATURES are not
appropriate
What are you saying here? I'm afraid you're mistaken here.
The point is to look at this from users' (well, a bit) point of view -
USE=debug
This is your monthly friendly reminder ! Same bat time (typically
the 2nd Thursday at 2000 UTC / 1600 EST), same bat channel
(#gentoo-council @ irc.freenode.net) !
If you have something you'd wish for us to chat about, maybe even
vote on, let us know ! Simply reply to this e-mail for the whole
On 01 Dec 2008 05:30:01
Mike Frysinger [EMAIL PROTECTED] wrote:
If you have something you'd wish for us to chat about, maybe even
vote on, let us know ! Simply reply to this e-mail for the whole
Gentoo dev list to see.
Please give the OK on the following, assuming no objections crop up
before
On Wed, Aug 6, 2008 at 3:18 PM, Robin H. Johnson [EMAIL PROTECTED] wrote:
Getting the bot out there
-
If you would like to have the new bot in your #gentoo-* channel, would
each channel founder/leader please respond to this thread, stating the
channel name, and that
On Mon, 01 Dec 2008 11:39:35 +0300
Peter Volkov [EMAIL PROTECTED] wrote:
This leads me to different conclusion. I was thinking about new
portage feature: emerge --info pkg . So to make portage show not
only global information but per-package either. In many cases this
will simplify analyzing
On Monday 01 of December 2008 08:04:04 Duncan wrote:
(Of
course, if it's the latter, it will need to be an official GLEP, and
you'll have three separate package managers and their developers to push
the proposal thru to at least to general agreement, or the council will
almost certainly
Summarizing from what I've read in this thread it seems you want to find
a way to help user find information s/he doesn't look for.
If users aren't curious about their system they will sure have a hard
time figuring out how to fix it if needs be. PORTAGE_ELOG_* isn't really
that hard to find in
Gilles Dartiguelongue wrote:
As others have said, there are already proper systems, documentation and
linking through other docs. Not finding this is what I'd call lazyness
or lack of google foo. Don't misunderstand me, some stuff can get ouf of
the radar of everyone, it's ok, real people are
On Mon, 01 Dec 2008 15:35:32 -0700
Joe Peterson [EMAIL PROTECTED] wrote:
My intention with the RFC was to see if the concept has any worth and
to kick it around a bit. I do not really see this as a deficiency in
Gentoo's technology (which I have a feeling is how many here have
interpreted
I completely forgot about Google's Summer of Code! Thanks for reminding me.
Hopefully I won't forget again by the time summer rolls around, obviously I
wouldn't mind getting a little extra money for doing something I'd do for
free anyway.
On a more related note: What, exactly, does porttree.py
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Emma Strubell wrote:
I completely forgot about Google's Summer of Code! Thanks for reminding me.
Hopefully I won't forget again by the time summer rolls around, obviously I
wouldn't mind getting a little extra money for doing something I'd do for
Thanks for the clarification. I was planning on forcing an update of the
index as a part of emerge --sync, and implementing a command that would
update the search index (leaving it up to the user to update after making
any manual changes to the portage tree). That way the search index should
I would suggest a different way of updates. When you manually change portage
tree, you have to make an overlay. Overlay, as it's updated and managed by
human being, will be always small (unless someone makes a script, which
creates million overlay updates, but I dont think it would be efficient
Good point. I may just ignore overlays completely because 1) I don't use
them and 2) does anyone really need to search an overlay anyway? aren't any
packages added via an overlay added deliberately?
On Mon, Dec 1, 2008 at 4:52 PM, Tambet [EMAIL PROTECTED] wrote:
I would suggest a different way
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Emma Strubell schrieb:
2) does anyone really need to search an overlay anyway?
Of course. Take large (semi-)official overlays like sunrise. They can
easily be seen as a second portage tree.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9
On Sun, 2008-11-30 at 16:19 +0100, Marius Mauch wrote:
So, time has come for me to realize that my time with Gentoo is over. I
haven't actually been doing much Gentoo work over the last months due
to personal reasons (nothing Gentoo related), and I don't see that
situation changing in the
2008/12/2 Emma Strubell [EMAIL PROTECTED]
True, true. Like I said, I don't really use overlays, so excuse my
igonrance.
Do you know an order of doing things:
Rules of Optimization:
- Rule 1: Don't do it.
- Rule 2 (for experts only): Don't do it yet.
What this actually means -
yes, yes, i know, you're right :]
and thanks a bunch for the outline! about the compression, I agree that it
would be a good idea, but I don't know how to implement it. not that it
would be difficult... I'm guessing there's a gzip module for python that
would make it pretty straightforward? I
26 matches
Mail list logo
