Re: rejection of binary package based on file timestamp
thanks for this very precise explanation.
Fredric
----- Le 20 Juil 23, à 15:58, David Kalnischkies david@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@.
Reply to: