Hi, On Thu, Jul 20, 2023 at 10:01:54AM +0200, PICCA Frederic-Emmanuel wrote: > I am working on two packages pyfai[4] and python-fabio[3], I have got a > rejection based on the file timestamp which seems too old.
Looking at the dak (= Debian Archive Kit; aka the tool(s) handling the archive) source [0] shows us that this is an explicit check (BinaryTimestampCheck) against time travel as that "can cause errors on extraction" (says the source, dating from 2012). This check flat out refuses files from before 1975. For the future it is a lot more restrictive… no more than 24 hours in the future. I wonder a bit why this is not applied to sources as well, but I suppose it could be legit to have unchanged source since then… not that I think you will encounter a lot of trouble on extraction, but its likely so untested that something will struggle with it like it does with e.g. the years 2038 or year 0 (compare also the time_t 32 vs 64bit discussion). [0] https://salsa.debian.org/ftp-team/dak/-/blob/master/daklib/checks.py#L461 ff > If you lool at python-fabio status page, it seems that they all failed [5], > but if you only look at the build log the package build on most buildd.[6]. The build was successful on the buildds, so the binary package is uploaded to the archive – but dak refused to import them. That is also why it was successfully imported into some ports architectures as ports is currently not dealt with by dak but by another tool (dubbed mini-dak) for now (note for time travelers: This might change in the future). > So during the build it seems that sphinx keep these timestamp and use it for > all the generated documentation. Taking the timestamp of the source file is not the worst idea as that is fixed and fixed is useful e.g. for reproducible-builds. I somewhat doubt sphinx is doing this as the output usually depends on various input files, but if that is what you see… An alternative is using the value stored in SOURCE_DATE_EPOCH (if it exists). > My question is what should I do now... If it is just about a few files each, it might be easiest to `touch` the binary file in your debian/rules. Somewhere at the top place for good measure: SOURCE_DATE_EPOCH ?= $(shell dpkg-parsechangelog -S Timestamp) and a bit later (as I think its the upstream changelogs): execute_after_dh_installchangelogs: touch -d"@$(SOURCE_DATE_EPOCH)" path/to/binary/file I haven't actually tried this, so please don't rely on me typing it correctly into the blue. Test it! Especially look at the timestamps in the produced deb file. It is a bit iffy to set the timestamp of the changelog (which changes with every revision), but close enough. At least more realistic than that this software wasn't changed since the start of the unix epoch… So please drop this again if its no longer needed. Best regards David Kalnischkies P.S.: d-devel@ isn't entirely wrong as this is sufficiently esoteric, but next time start perhaps on d-mentors@.
signature.asc
Description: PGP signature
