[yocto] [meta-raspberrypi][PATCH] firmware.inc: fetch from SVN instead of Git
Gary Thomas
gary at mlbassoc.com
Mon Jul 20 08:59:30 PDT 2015
On 2015-07-19 15:34, Andrei Gherzan wrote:
> Hello,
>
> --
> Andrei Gherzan
>
> On Thu, Jul 16, 2015 at 7:53 PM, Jon Szymaniak <jon.szymaniak at gmail.com <mailto:jon.szymaniak at gmail.com>> wrote:
>
> 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?
>
>
> Definitely 2 is the best opinion in my opinion too. I'm wondering if there is any work started in this direction.
>
It would sure be nice to get this fixed! The latest download
(I always save the tarballs for the next time) is over 4GB!!
-rw-rw-r-- 1 gthomas gthomas 4194568645 Jul 20 09:44 /local/rpi2_2015-03-05/downloads/git2_github.com.raspberrypi.firmware.git.tar.gz
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
More information about the yocto
mailing list