On 2015-07-19 15:34, Andrei Gherzan wrote:
Hello,
--
Andrei Gherzan
On Thu, Jul 16, 2015 at 7:53 PM, Jon Szymaniak <jon.szyman...@gmail.com
<mailto:jon.szyman...@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
------------------------------------------------------------
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
