All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Eric Bénard" <eric@eukrea.com>
To: openembedded-core@lists.openembedded.org
Subject: Re: Fetch time optimization (svn : gcc/eglibc - git : linux-yocto)
Date: Fri, 30 Mar 2012 17:24:40 +0200	[thread overview]
Message-ID: <20120330172440.54592fce@eb-e6520> (raw)
In-Reply-To: <1333120364.18082.77.camel@ted>

Le Fri, 30 Mar 2012 16:12:44 +0100,
Richard Purdie <richard.purdie@linuxfoundation.org> a écrit :
> On Fri, 2012-03-30 at 10:50 +0200, Eric Bénard wrote:
> > the default configuration seems to fetch from source control systems
> > as I always see very long time to fetch gcc/eglibc/linux-yocto
> > (despite having a 2.2 MBytes/s downlink DSL line).
> 
> If you're hitting the SCMs I can understand the frustration.
> 
that's not a frustration, that's a feedback on the default
behaviour. But I agree with you that could be a frustration for someone
trying OE-core for the first time ;-)

> Try adding this to your configuration:
> 
> PREMIRRORS = "\
> git://.*/.*   http://downloads.yoctoproject.org/mirror/sources/ \n \
> svn://.*/.*   http://downloads.yoctoproject.org/mirror/sources/ \n"
> 
> and see if that helps the performance. It might be we consider making
> this the default for OE-Core although some people are nervous about
> doing this...
> 
sure that will help : in my work setup I have my own mirrors configured
but here again, that's not what a new user will have and in that
case, I'm testing the plain default configuration to help finding bugs
or things to improve the release.

I think fetching from git or svn should not be the first thing to do in
recipes like gcc, eglibc, linux & co where we are based on a
stable released version : this doesn't bring real added value to the
user in OE context and this wastes bandwidth (a tbz2 kernel is around
75MB, a git one is around 600MB).

Eric



  reply	other threads:[~2012-03-30 15:33 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-29 20:53 Fetch time optimization (svn : gcc/eglibc - git : linux-yocto) Eric Bénard
2012-03-29 22:03 ` Richard Purdie
2012-03-30  1:03   ` Bruce Ashfield
2012-03-30  6:44     ` Samuel Stirtzel
2012-03-30  9:21       ` Paul Eggleton
2012-03-30  9:32       ` Richard Purdie
2012-03-30 10:07         ` Samuel Stirtzel
2012-03-30 10:45           ` Richard Purdie
2012-04-02  8:15             ` Samuel Stirtzel
2012-03-30  7:00     ` Martin Jansa
2012-03-30 10:06       ` Richard Purdie
2012-03-30  8:50   ` Eric Bénard
2012-03-30 15:12     ` Richard Purdie
2012-03-30 15:24       ` Eric Bénard [this message]
2012-03-30 15:49         ` Bruce Ashfield
2012-03-30 15:55           ` Eric Bénard
2012-03-30 16:02         ` Richard Purdie
2012-03-30 16:17           ` Eric Bénard
2012-03-30 17:33             ` Bruce Ashfield
2012-03-30 18:36               ` Eric Bénard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120330172440.54592fce@eb-e6520 \
    --to=eric@eukrea.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.