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
<[email protected] <mailto:[email protected]>>
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
--
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto
