thanks for this very precise explanation. Fredric
----- Le 20 Juil 23, à 15:58, David Kalnischkies da...@kalnischkies.de a écrit : > 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@.
