[yocto] [meta-raspberrypi][PATCH] firmware.inc: fetch from SVN instead of Git
Jon Szymaniak
jon.szymaniak at gmail.com
Thu Jul 16 10:53:07 PDT 2015
Hi all,
> >
> > So there is no support for depth clones until 2.5.0? I didn't really
> > understand.
>
> Well, shallow clones are supported but only for branch tips, which is
> not what we need. This feature for shallow cloning a specific revision
> is available only in git 2.5.0+. Also, this feature needs a server-side
> configuration option to be enabled, in order to work properly.
>
> Regards,
> Nikolay
>
I'd argue that this whole issue with the whole meta-raspberrypi
firmware.inc download is more than just slow, inconvenient download. I've
left builds running all night (8+ hours on a 30Mib/s residential link) that
just hang on this, usually timing out. I initially thought it was just me,
but am hearing others confirm this as well.
As such, I just wanted to continue this conversation. It sounds like git
fetch's --depth is the best option on the table, but has the issues Nikolay
has described. What are your thoughts on the following?
(1) We create a git-native and build a version that supports this the fetch
depth?
I suspect this could be made to work, but haven't dug into what
dependencies git may have and how that would play out on various LTS
distros. My knee-jerk is that has too high of a risk/benefit ration, given
that we're talking about 1 repo.
(2) We update the git fetcher to check the git version and support a depth=
option if the git version is sufficient. If it is not, we spit out a
warning and fall back to the current behavior.
Neither (1) nor (2) address Nikolay's point that --depth requires
server-side support. However, I'd argue this is something you'd be testing
and verifying when writing the recipe. Is this a reasonable assertion? How
likely is it that a server supporting this would suddenly be re-configured?
(3) We request that the upstream maintainer of meta-raspberrypi use the
GitHub Release feature [a] to post a tarball of a known checksum at
somewhat regular intervals. I'm told by a few package maintainers that
while the tarballs that it generates for specific changesets are subject to
change, that the tarballs it autogenerates when using its Releases feature
do not. However, I have not confirmed this. If this is false, then one
can upload a tarball with known checksums to the release as an attachment;
I would be *shocked* if they touch your attachments.
While (3) is a nice "not our problem" solution, I think (2) might have some
benefits for other recipes later. Any other ideas?
Best regards,
Jon
[a] https://help.github.com/articles/creating-releases/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20150716/5ddbf863/attachment.html>
More information about the yocto
mailing list