[yocto] [meta-raspberrypi][PATCH] firmware.inc: fetch from SVN instead of Git

[Andrei Gherzan]

Hello,

--
Andrei Gherzan

On Thu, Jul 16, 2015 at 7:53 PM, Jon Szymaniak <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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20150719/25e29d06/attachment.html>