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
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
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.
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
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
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
# 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
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
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="
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
unsubscribe
signature.asc
Description: This is a digitally signed message part.
11 matches
Mail list logo