[gentoo-dev]

2009-07-09 Thread Aaron Bauman
unsubscribe signature.asc Description: This is a digitally signed message part.

Re: [gentoo-dev] One-Day Gentoo Council Reminder for July

2009-07-09 Thread Tobias Scherbaum
Heya, just to be sure: there is *no* meeting today. We're probably going to schedule a meeting for next week. - Tobias Am Mittwoch, den 08.07.2009, 03:00 + schrieb Mike Frysinger: > This is your one-day friendly reminder ! The monthly Gentoo Council > meeting is tomorrow in #gentoo-council

[gentoo-dev] Problems with the current bzr eclass.

2009-07-09 Thread Harley Peters
The current bzr eclass uses EBZR_FETCH_CMD="bzr checkout --lightweight" to initially fetch the sources. The problem with this is though it saves some time and bandwidth on the initial fetch it actually ends up using a lot more time and bandwidth on every update. Ok great I can set EBZR_FETCH_CMD="

[gentoo-dev] Re: Problems with the current bzr eclass.

2009-07-09 Thread Christian Faulhammer
Hi, Harley Peters : > Since I did a full checkout with the EBZR_FETCH_CMD="bzr checkout" > it now deletes the entire previous checked out branch (to save disk > space ?) and proceeds to fetch the entire source again. > Why would I ever want to do that ? The whole point of bzr is to save > bandwidt

[gentoo-dev] Last rites for x11-misc/e-fancylauncher

2009-07-09 Thread Victor Ostorga
# Víctor Ostorga (9 Jul 2009) # Fails to build, dead upstream. # # Removal scheduled for 2009-09-09 # bug #227721 x11-misc/e-fancylauncher Regards, Víctor Ostorga

Re: [gentoo-dev] Re: Problems with the current bzr eclass.

2009-07-09 Thread Harley Peters
On Thu, 9 Jul 2009 20:55:54 +0200 Christian Faulhammer wrote: > Hi, > > Harley Peters : > > Since I did a full checkout with the EBZR_FETCH_CMD="bzr checkout" > > it now deletes the entire previous checked out branch (to save disk > > space ?) and proceeds to fetch the entire source again. > > W

[gentoo-dev] Re: Problems with the current bzr eclass.

2009-07-09 Thread Christian Faulhammer
Hi, Harley Peters : > Ok that's what I am doing. Was just wondering if there was something > simple I over looked. To give you an idea what we gain here, I compiled some numbers. GNU Emacs live ebuild (app-editors/emacs-cvs) will be the biggest consumer once they switch from CVS. First we will

Re: [gentoo-dev] Re: Problems with the current bzr eclass.

2009-07-09 Thread Harley Peters
On Thu, 9 Jul 2009 22:16:34 +0200 Christian Faulhammer wrote: > Hi, > > Harley Peters : > > Ok that's what I am doing. Was just wondering if there was something > > simple I over looked. > > To give you an idea what we gain here, I compiled some numbers. GNU > Emacs live ebuild (app-editors/e

Re: [gentoo-dev] Re: Re: A Little Council Reform Anyone?

2009-07-09 Thread Andrew D Kirch
Ciaran McCreesh wrote: > < trelane> ciaranm: I want Paludis to fail. It's unhealthy (or at least > the loudest and most visible of it's devs are) for Gentoo. > > < trelane> lets be VERY clear on that point. So long as Paludis, and > the culture it creates are unhealthy for Gentoo I want it to fail.

Re: [gentoo-dev] Re: Re: A Little Council Reform Anyone?

2009-07-09 Thread Alec Warner
On Thu, Jul 9, 2009 at 7:50 PM, Andrew D Kirch wrote: > Ciaran McCreesh wrote: >> < trelane> ciaranm: I want Paludis to fail. It's unhealthy (or at least >> the loudest and most visible of it's devs are) for Gentoo. >> >> < trelane> lets be VERY clear on that point. So long as Paludis, and >> the c

[gentoo-dev] Re: Problems with the current bzr eclass.

2009-07-09 Thread Christian Faulhammer
Hi, Harley Peters : > Because the numbers don't look so good for Gnash. > bzr branch http://bzr.savannah.gnu.org/r/gnash/trunk They look similar on my system to that of Emacs, although I have to try with new revisions added. > Having said that it's only a two line change to the bzr.eclass code