Oh, Daniel, I've found that thread that I've subscribed,
On Wed, Nov 19, 2008 at 4:55 AM, Daniel Drake <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm looking to find one or more people to help out with gentoo-sources-2.6
> maintenance (our primary supported kernel). Right now, me and Mike Pagano do
> mo
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
> interpret
On Monday 01 of December 2008 22:51:57 Ciaran McCreesh wrote:
> Experience, manpower, the ability to try out potential enhancements
> rapidly, a long track record of getting it right and the growing
> recognition that most people doing package manager work for Gentoo
> aren't doing it with Portage
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 a
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 t
On Mon, 1 Dec 2008 22:46:18 +0100
Maciej Mrozowski <[EMAIL PROTECTED]> wrote:
> That I found interesting - what does any 3rd party package manager to
> do with setting policies and enhancements regarding official Gentoo
> package manager?
Experience, manpower, the ability to try out potential enha
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 r
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 . So to make portage show not
> only global information but per-package either. In many cases this
> will simplify analyzin
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
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
be
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
G
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
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
> s
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 b
"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 poin
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
В Пнд, 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 dra
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 asse
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 the
"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
20 matches
Mail list logo
