Re: [Reproducible-builds] Building packages in the *past* (!!)
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 matter? In fact, there's a fairly strong argument > to be made that if the package does something weird in this case then > there's something far deeper wrong or broken with it - and therefore it > would be advantageous to know about it simply from a QA point of view. No. There is nothing wrong or broken in base-files, and the current tests are making it *gratuitously* to fail. Please *follow* the link I posted before and see it for yourself. If the (simplified for this discussion) standard find debian/tmp -newermt '$(BUILD_DATE)' | xargs touch --date='$(BUILD_DATE)' is not going to work anymore, then there is literally *no* easy way to differentiate between files which have been created during the build process and files that come from upstream and we want their timestamp to be kept untouched. If we put constraints on maintainers and packages that are beyond what it is reasonable, nobody will take us seriously. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Building packages in the *past* (!!)
> 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 package does something weird in this case then there's something far deeper wrong or broken with it - and therefore it would be advantageous to know about it simply from a QA point of view. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Building packages in the *past* (!!)
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 fact, there's a fairly strong argument to > be made I'd like to hear that "strong argument" because I fail to come up with one. > that if the package does something weird in this case then there's something > far deeper wrong or broken with it - and therefore it would be advantageous > to know about it simply from a QA point of view. 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. So the questions are: - do you want to file bugs against software that cannot work with timestamps from the future? - Why is it a bug if software cannot work with timestamps from the future? - What is the real world problem that is fixed by this? - Is there a use case where you would like to build your software with your clock set back to an older timestamp? - Having the complexities of timezones in mind I can totally imagine that there exists bugs that let your package not be built at a certain point in the past but I do not see how *all* software that cannot be built in the past will also have a general QA problem which has to be fixed in the future. Thus, if you build in the past you might also end up with build failures that are not meaningful. - Which QA scenario do you have in mind which would not also be checked when building in the future instead? Personally, I find it very likely that there exists software that cannot handle timestamps from the future because for that software it could easily hint that something in the runtime environment is obviously wrong and has to be fixed. cheers, josch signature.asc Description: signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Building packages in the *past* (!!)
> 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 would still stick by the general principle of "torture testing" aggressively though for the reasons I expoused, however.) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Building packages in the *past* (!!)
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 please *don't* build packages in the past. If we have to choose two very different dates (yes, of course we should do that to ensure reproducibility), try now and two years and two months later, for example (that would ensure that both the year and the month are different). Thanks. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
