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

[Nikolay Dimitrov]

Hi Andrei,

On 07/09/2015 11:13 PM, Andrei Gherzan wrote:
> 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 <mailto: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.

I don't think this is a good move. The current solution is already
working properly, although with slower-than-ideal download speed.

Prepackaged tarballs will require constant manpower for supporting,
and it's probably better to be invested into looking for a better
solution.

>
> 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
>
>

Regards,
Nikolay