Re: [gentoo-dev] Re: How to deal with git sources?
On Fri, Mar 16, 2018 at 1:21 PM, William Hubbs wrote: > > I am in the same camp as Martin and James. I would rather see the issues > fixed for the specific packages involved than us try to host tarballs > for every package that doesn't create them. > ++ If github didn't already provide a solution that works 95% of the time I'd consider it more of a need. And while a lot of people have issues with github, IMO this one part of github is largely FOSS (they're just using git archive here). Simply serving up git and git archive tarballs is something that could be easily moved to another hosting provider if somebody stepped up to offer the service. If somebody were offering to build a homegrown solution that would probably be fine, but I'm not really seeing that... -- Rich
Re: [gentoo-dev] Re: How to deal with git sources?
On Fri, Mar 16, 2018 at 12:00:47PM +0100, Ulrich Mueller wrote: > > On Fri, 16 Mar 2018, Martin Vaeth wrote: > > > Ulrich Mueller wrote: > >> > >> I think the conclusion is that github generates tarballs on the > >> fly, and therefore we cannot rely on them being invariant over a > >> long time. > > > So I would not worry too much about it: It is not worth the cost of > > hosting a huge number of tarballs permanently > > I agree, because hosting tarballs of upstream packages is not a task > for us as a distro. > > > (or to convince upstream to let them be hosted by github for every > > single version, only because one cannot theoretically exclude that a > > similar thing won't ever happen again). [...] > > In the first place, upstream should make proper releases, which > includes creating a pristine tarball and permanently hosting it. > So, yell at them if they don't. And no, a git tag is not a release. > > Ulrich Yelling at an upstream might get you somewhere, but you can't force them, and in this case, they might tell you to create the pristine tarball yourself using "git archive" if you want one. I am in the same camp as Martin and James. I would rather see the issues fixed for the specific packages involved than us try to host tarballs for every package that doesn't create them. William signature.asc Description: Digital signature
Re: [gentoo-dev] Re: How to deal with git sources?
W dniu pią, 16.03.2018 o godzinie 12∶00 +0100, użytkownik Ulrich Mueller napisał: > > > > > > On Fri, 16 Mar 2018, Martin Vaeth wrote: > > Ulrich Mueller wrote: > > > > > > I think the conclusion is that github generates tarballs on the > > > fly, and therefore we cannot rely on them being invariant over a > > > long time. > > So I would not worry too much about it: It is not worth the cost of > > hosting a huge number of tarballs permanently > > I agree, because hosting tarballs of upstream packages is not a task > for us as a distro. > > > (or to convince upstream to let them be hosted by github for every > > single version, only because one cannot theoretically exclude that a > > similar thing won't ever happen again). [...] > > In the first place, upstream should make proper releases, which > includes creating a pristine tarball and permanently hosting it. > So, yell at them if they don't. And no, a git tag is not a release. > Feel free to convince Python upstreams to include tests in their releases. Last I tried, I heard that tests are not useful for people who install packages, and that they would make tarballs bigger. -- Best regards, Michał Górny
Re: [gentoo-dev] Re: How to deal with git sources?
On Fri, 16 Mar 2018 10:03:44 + (UTC) Martin Vaeth wrote: > So I would not worry too much about it: It is not worth the cost of > hosting a huge number of tarballs permanently (or to convince > upstream to let them be hosted by github for every single version, > only because one cannot theoretically exclude that a similar thing > won't ever happen again). Yes, for the transition period (until all > github servers use a new enough version) a solution for the few > involved tarballs has to be found (like temporarily hosting on > devspace). But after this period it is only a question of updating the > checksum once for the involved packages. Agreed. I use this GitHub feature quite a lot and I've only ever seen this happen maybe once? Even then, I think it might have been one of the additional downloads rather than the git archives, which upstream had probably replaced without bumping. -- James Le Cuirot (chewi) Gentoo Linux Developer
Re: [gentoo-dev] Re: How to deal with git sources?
On 03/15/2018 07:20 PM, Martin Vaeth wrote: > Vadim A. Misbakh-Soloviov wrote: >> >> GH support answered me (in TL;DR version) "that's because we've upgraded git >> on *some* of our nodes" (means, some other using older git) > > That would still require that the "git archive" output would have > changed in some recent git versions. And at least between the most > current 2.16.2 and comparing with all my git tarballs (some as > mentioned rather old), I could not produce any difference. > So I still do not understand what should be going on. > > IIRC, it was attributed to https://github.com/git/git/commit/22f0dcd9634a818a0c83f23ea1a48f2d620c0546 -- NP-Hardass signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: How to deal with git sources?
> Perhaps they refer to .zip instead of .tar.gz which as mentioned is > a less stable format due to the inclusion of the timezone. Nope. I myself also faced tarballs checksum difference (even between few calls). GH support answered me (in TL;DR version) "that's because we've upgraded git on *some* of our nodes" (means, some other using older git), and "we've never guaranteed same checksums".
Re: [gentoo-dev] Re: How to deal with git sources?
On 03/12/2018 04:29 AM, Martin Vaeth wrote: > Duncan <1i5t5.dun...@cox.net> wrote: >> >> If I'm recalling correctly a warning posted on this list, repeated calls >> to the github tarballing API for the same commit will result in delivery >> of tarballs with differing checksums. > > This was so many many years ago in the beginning of github. > This has long been fixed since then. Every once in a while they still change. This is from a few weeks ago: https://marc.info/?l=openbsd-ports&m=151973450514279&w=2
