> On Thu, 15 Mar 2018, 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 h
> On Fri, 16 Mar 2018, 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.
> They may be susceptible to changes in git, in tar, or in gzip.
In fact, only git and gzip (because the
NP-Hardass wrote:
>
> IIRC, it was attributed to
> https://github.com/git/git/commit/22f0dcd9634a818a0c83f23ea1a48f2d620c0546
Thanks. That explains why I was not able to produce a difference:
It involves only the rather exotic case that a path in a git repository
is longer than 100 characters.
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.
Yes, but with emphasis on _long_ time and theory.
In practice this was happening now exactly _once_ in a decade
(according to all
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 theoret
> 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
>
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 invari
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 t
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 solutio
On Mon, 12 Mar 2018 07:55:46 +0900
Benda Xu wrote:
> Ha, indeed many packages hardwrites "date of build" alike. That is a
> hard question to define reproducibility. I would rather ignore the
> timestamps when comparing two binaries.
If a hard-timestamp is to be used, assuming you have portage
10 matches
Mail list logo
