Hi Chris! On Thu, Jan 09, 2025 at 11:33:38AM +0000, Chris Lamb wrote: > Hi Dmitry, > > > - docs/conf.py has copyright 2011-2024; > > - last entry of debian/changelog is from 2023; > > - Sphinx replaces current year with year from SOURCE_DATE_EPOCH [1]; > > - the reproducibility test was run in 2024. > > > > This error should have gone away starting with 2025. > > "Gone away staring with 2025" — as in, building/testing with a clock year > of 2025, or a SOURCE_DATE_EPOCH value within 2025?
I meant running both test builds with a clock year of >= 2025. The diff
happens when one build is from 2024 and another is from a different year.
As year 2024 is mentioned in the copyright, when it is the current year it
gets replaced with year from SOURCE_DATE_EPOCH, but when the current year
is >= 2025, it is not replaced.
But the other thing you suggested (setting SOURCE_DATE_EPOCH to 2025 and
building with any clock year) will work too, because Sphinx replaces
copyright year only with an earlier year, so it will not replace 2024 with
2025.
I can understand why upstream Sphinx did that: some upstream developers put
`copyright = f"{date.today().year} Author name"` in conf.py and we need to
replace this dynamic date with a static one for reproducibility. But in this
case the year in conf.py was static, not dynamic, yet it was still replaced.
> > But I recommend against time travelling anyway: upstream should not put
> > copyright 2024 in a commit made in October 2023 [2].
>
> Ah, I think I get it now: upstream has put in a year from the future
> — "time travelling", as you call it? If so, this shouldn't affect any
> other packages.
Yes, I hope it won't affect many other packages.
> I would agree with your recommendation, but upstreams are always going
> to do strange things with copyright years. :(
In this case we can also patch out future copyright years in Debian
(if at the moment of preparing a Debian package that year is still in future).
--
Dmitry Shachnev
signature.asc
Description: PGP signature
