> I would not find it unreasonable if a build would fail if some of the
> software that is run either during compilation or testing stages detects
> that some of the files they are working on have a timestamp from the future.
I didn't consider the mtime case carefully enough. I agree with you.
(I
On Wed, Sep 30, 2015 at 12:25:10PM +0200, Holger Levsen wrote:
> it has been reverted.
Thanks a lot.
Would there be an easy way to discard all the tests which have been
made with a timestamp in the past? I guess nearly 100% of them are
going to be false positives (I first noticed about this in a
Hi,
Quoting Chris Lamb (2015-09-30 11:57:20)
> > There is a minimum of sanity that we should assume on the autobuilders,
>
> Agree in principle..
>
> > namely, that packages are built on a date which is later than the one
> > in the last changelog entry.
>
> .. but why should this matter? In fa
Hi,
thanks for bringing this up here.
it has been reverted.
building in the past is just easier than in the future… thats why.
cheers,
Holger, with fever
signature.asc
Description: This is a digitally signed message part.
___
Reproducible-b
On Wed, Sep 30, 2015 at 10:57:20AM +0100, Chris Lamb wrote:
> > There is a minimum of sanity that we should assume on the autobuilders,
>
> Agree in principle..
>
> > namely, that packages are built on a date which is later than the one
> > in the last changelog entry.
>
> .. but why should this
> There is a minimum of sanity that we should assume on the autobuilders,
Agree in principle..
> namely, that packages are built on a date which is later than the one
> in the last changelog entry.
.. but why should this matter? In fact, there's a fairly strong argument
to be made that if the pa
Hi.
Are we building packages in the *past* now?:
https://reproducible.debian.net/rb-pkg/unstable/amd64/base-files.html
There is a minimum of sanity that we should assume on the autobuilders,
namely, that packages are built on a date which is later than the one
in the last changelog entry.
So pl
