On Sat, Jan 3, 2026, 19:50 Carsten Schoenert <[email protected]> wrote:
> Version: 1.1.1-3 > > This issue is gonne fixed by the upload of 1.1.1-3, I just forgot to > reference this bug report in the chnagelog file. > > Regards > Carsten > > Am Fri, Feb 23, 2024 at 08:26:25PM +0000 schrieb James Addison: > > Source: python-fudge > > Version: 1.1.1-2 > > Severity: wishlist > > User: [email protected] > > Usertags: timestamps > > > > Dear Maintainer, > > > > I'm an occasional volunteer contributor with the Reproducible Builds[1] > > project, and noticed that the python-fudge package failed an automated > > reproducible build test[2] recently. > > > > While investigating the cause, I found that the debian/rules file in the > > python-fudge source package contains some SOURCE_DATE_EPOCH logic that is > > now natively supported[3] by Sphinx itself. > > > > I believe that removing the SPHINX_DATE_EPOCH-related logic from the > > debian/rules file should be possible, and is likely to address the cause > of > > the reproducibility failure. > > > > To assist with confirmation that your package is reproducible, you may > > optionally enable Debian Salsa's Continuous Integration[4]; this > includes a > > utility called 'reprotest' that will test two maximally-varying builds of > > your source package and indicate whether the binary packages remain > identical > > (as intended) despite build environment variance. > > > > Thank you, > > James > > > > [1] - https://reproducible-builds.org/ > > > > [2] - > https://tests.reproducible-builds.org/debian/rb-pkg/trixie/arm64/diffoscope-results/python-fudge.html > > > > [3] - https://github.com/sphinx-doc/sphinx/pull/1954 > > > > [4] - https://salsa.debian.org/salsa-ci-team/pipeline/ Thank you, Carsten! > >
