From: Martin Jansa <martin.jansa@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: I've downloaded oe
Date: Thu, 25 Nov 2010 14:01:56 +0100 [thread overview]
Message-ID: <20101125130156.GP3274@jama> (raw)
In-Reply-To: <AANLkTi=LJkDCTR_PsUR52VuB9ckpms82MYyn9uyhO9hL@mail.gmail.com>
On Thu, Nov 25, 2010 at 01:44:13PM +0100, Frans Meulenbroeks wrote:
> 2010/11/25 Klaus Schwarzkopf <schwarzkopf@sensortherm.de>:
> > Am 24.11.2010 10:18, schrieb Frans Meulenbroeks:
> >>
> >> 2010/11/24 Martin Jansa<martin.jansa@gmail.com>:
> >>>
> >>> On Wed, Nov 24, 2010 at 08:52:41AM +0100, Frans Meulenbroeks wrote:
> >>>>
> >>>> What about moving all recipes that do not fetch and also did not fetch
> >>>> during Martins test from last march/april to a directory non-fetching
> >>>> or so?
> >>>
> >>> But those recipes were only those where I wasn't able to find the source
> >>> at all (even with google help and couple of popular premirrors). Any
> >>> origin for source was fine for me, because I was only interested in
> >>> checksum check.
> >>>
> >>>> Apparently these are non fetchable for a long time, with no one
> >>>> apparently building them or having an interest to fix them.
> >>>
> >>> More likely those who were building those before are still building
> >>> OK, because they had it in theirs downloads dir. (but the second part is
> >>> right :/).
> >>>
> >>>> My proposal would be to do that before the release is made, thereby
> >>>> improving the % of the recipes that build.
> >>>
> >>> We can improve it also by putting those missing upstream files to
> >>> sources.openembedded.org and use it as premirror. But first we hav to
> >>> find someone who still have it in downloads dir :/ (I don't).
> >>>
> >>> Removing recipes would need to remove those also from tasks/images and
> >>> in the end release images could miss some important functionaly in worst
> >>> case.
> >>
> >> I think most of the non fetching recipes would fall into one of these
> >> categories:
> >> - recipes that are very specific and are not part of a task or image
> >> - recipes that are older versions and that are not used/build
> >>
> >> Wrt the remark on missing important functionality:
> >> For a user with a clean slate, the functionality is already missing as
> >> the task/image cannot be build from scratch.
> >>
> >> It might be a good idea to do a test trying to build all images for
> >> one distro/machine and see what comes out.
> >> Start with a clean system (empty downloads dir, empty TMPDIR, no
> >> pstaged files etc).
> >> Then bitbake all images. By doing it subsequently without cleaning
> >> TMPDIR inbetween it'll become clear which images do build from scratch
> >> and which don't.
> >>
> >> Is someone able/willing to do this test and report the result (suggest
> >> using distro minimal or angstrom or probably shr and machine angstrom)
> >>
> >> Frans
> >
> >
> > Is it usefull to have an image with all/most recipes? This image can be used
> > for testing the recipes (fetch, compile) for several machines.
>
> This functionality exists:
>
> do a
> bitbake world
> or if you only want to fetch:
> bitbake -c fetchall world
Also define
SOURCE_MIRROR_FETCH
to ignore COMPATIBLE_* vars
and still it doesn't catch ie
SRC_URI_machine, SRC_URI_distro
Regards,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
next prev parent reply other threads:[~2010-11-25 13:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-23 20:03 I've downloaded oe Klaus Schwarzkopf
2010-11-23 20:19 ` Khem Raj
2010-11-24 7:52 ` Frans Meulenbroeks
2010-11-24 8:07 ` Martin Jansa
2010-11-24 9:18 ` Frans Meulenbroeks
2010-11-25 12:07 ` Klaus Schwarzkopf
2010-11-25 12:44 ` Frans Meulenbroeks
2010-11-25 13:01 ` Martin Jansa [this message]
2010-11-25 11:58 ` Klaus Schwarzkopf
2010-11-25 12:43 ` Frans Meulenbroeks
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=20101125130156.GP3274@jama \
--to=martin.jansa@gmail.com \
--cc=openembedded-devel@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.