> 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