[yocto] [meta-raspberrypi][PATCH] firmware.inc: Fetch a zip instead of cloning a git repo

[Andrei Gherzan]

Finally I hop on to this discussion too.

On Mon, Jul 6, 2015 at 12:58 PM, Paul Eggleton <
paul.eggleton at linux.intel.com> wrote:

> On Monday 06 July 2015 12:48:50 Nikolay Dimitrov wrote:
> > One issue with the regularly changing tarball checksums is that people
> > start to get used to thes changes (e.g. everything looks like false
> > positive). Currently the tarball checksums and SCM revisions are
> > probably the most important tool for builds traceability. If we get
> > used to think about these checksums as "unreliable", it will be much
> > easier to miss an important component change, which would otherwise
> > ring a bell.
>
> Fully agreed.
>
> There are a couple of things I think we can do here:
>
> 1) Implement shallow cloning in bitbake's git fetcher as suggested. This
> shouldn't be too tricky. I've filed a bug to track this:
>
>   https://bugzilla.yoctoproject.org/show_bug.cgi?id=7958
>
> (Richard is the default assignee, but anyone could potentially work on
> this).
>
>
This should be the fix that would really fix the issue. And would be a
useful feature for many other BSPs / layers out there.


> 2) In the mean time we could consider upload git mirror tarballs to a
> source
> mirror that gets enabled through meta-raspberrypi (would need to be via
> PREMIRRORS to actually solve the issue). This has the advantage that it
> wouldn't require any changes to the kernel recipe itself, but new tarballs
> would of course need to be uploaded every time SRCREV is changed in the
> recipe.
>
>
And until 1) is done, we can have a premirror. Paul, can you upload a
tarball? Can I help you with anything for having this up? After we have
this, can we force premirrors when using a specific layer? Was thinking of
forcing it by adding PREMIRRORS to layer.conf.

Using github snapshots is not a good idea. Most of the issues you guys
pointed out above I experienced as well. In my opinion we should combine
Paul's solutions in order to address this problem.

One more thing. Given the fact the the repository we are talking about is
not under our control, we shouldn't rely on releases or other things from
the remote repository.

Andrei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20150709/7eafcae1/attachment.html>