Bug#1011478:
Control: severity -1 wishlist Dear Maintainer, Currently, Debian's buildd and also the Reproducible Builds team's testing infrastructure[1] both use a fixed build path when building binary packages. This means that your package will pass current reproducibility tests; however we believe that varying the build path still produces undesirable changes in the binary package output, making it more difficult than necessary for independent consumers to check the integrity of those packages by rebuilding them themselves. As a result, this bugreport will remain open and be re-assigned the 'wishlist' severity[2]. You can use the 'reprotest' package build utility - either locally, or as provided in Debian's Salsa continuous integration pipelines - to assist uncovering reproducibility failures due build-path variance. For more information about build paths and how they can affect reproducibility, please refer to: https://reproducible-builds.org/docs/build-path/ Thanks, James [1] - https://tests.reproducible-builds.org/debian/reproducible.html [2] - https://www.debian.org/Bugs/Developer#severities
Bug#1020808:
A correction for a mistake in my previous message: > Because Debian builds packages from a fixed build path, neither the > 'reprotest' > utility in Salsa-CI, nor the Reproducible Builds team's package test > infrastructure for Debian[1] currently check for equivalent binary package > output from differing source package build paths. > > This means that your package will pass current reproducibility tests; ... > [ snip ] Currently the 'reprotest' job in Salsa-CI does in fact continue to exercise variations of the build-path, and will fail if it builds binary packages that contain different contents as a result.
Bug#1020806:
Control: severity -1 wishlist Dear Maintainer, Because Debian builds packages from a fixed build path, neither the 'reprotest' utility in Salsa-CI, nor the Reproducible Builds team's package test infrastructure for Debian[1] currently check for equivalent binary package output from differing source package build paths. This means that your package will pass current reproducibility tests; however we believe that source code and/or build steps still embed the build path into the binary package output, making it more difficult than necessary for independent consumers to check the integrity of those packages by rebuilding them themselves. As a result, this bugreport will remain open and be re-assigned the 'wishlist' severity[2]. For more information about build paths and how they can affect reproducibility, please refer to: https://reproducible-builds.org/docs/build-path/ Thanks, James [1] - https://tests.reproducible-builds.org/debian/reproducible.html [2] - https://www.debian.org/Bugs/Developer#severities
Bug#1021498:
Control: severity -1 wishlist Dear Maintainer, Because Debian builds packages from a fixed build path, neither the 'reprotest' utility in Salsa-CI, nor the Reproducible Builds team's package test infrastructure for Debian[1] currently check for equivalent binary package output from differing source package build paths. This means that your package will pass current reproducibility tests; however we believe that source code and/or build steps still embed the build path into the binary package output, making it more difficult than necessary for independent consumers to check the integrity of binary packages by recompiling them themselves. As a result, this bugreport will remain open and be re-assigned the 'wishlist' severity[2]. For more information about build paths and how they can affect reproducibility, please refer to: https://reproducible-builds.org/docs/build-path/ Thanks, James [1] - https://tests.reproducible-builds.org/debian/reproducible.html [2] - https://www.debian.org/Bugs/Developer#severities
Bug#1033032:
Control: severity -1 wishlist Dear Maintainer, Because Debian builds packages from a fixed build path, neither the 'reprotest' utility in Salsa-CI, nor the Reproducible Builds team's package test infrastructure for Debian[1] currently check for equivalent binary package output from differing source package build paths. This means that your package will pass current reproducibility tests; however we believe that source code and/or build steps still embed the build path into the binary package output, making it more difficult than necessary for independent consumers to check the integrity of binary packages by recompiling them themselves. As a result, this bugreport will remain open and be re-assigned the 'wishlist' severity[2]. For more information about build paths and how they can affect reproducibility, please refer to: https://reproducible-builds.org/docs/build-path/ Thanks, James [1] - https://tests.reproducible-builds.org/debian/reproducible.html [2] - https://www.debian.org/Bugs/Developer#severities
Bug#859572: docbook-xsl: randomly adds ???TITLE??? to title
Followup-For: Bug #859572 X-Debbugs-Cc: solo-debianb...@goeswhere.com, bugs-debian-20170...@james-ross.co.uk Control: reassign -1 libxml2 Control: affects -1 libxslt1.1 xsltproc Control: forwarded -1 https://gitlab.gnome.org/GNOME/libxslt/-/issues/37 Control: tags -1 fixed-upstream Control: fixed -1 libxml2/2.9.12+dfsg-1 Control: close -1 This doesn't appear reproducible anymore, and after tracing back to figure out when the fix for it landed, it was somewhere between bookworm and bullseye. That helped to narrow down the behaviour to indeed something in xsltproc (as James suspected) or libxslt, and then to between[1] versions 1.1.34 and 1.1.35 of the latter. >From there, a commit to add test coverage[2] looked relevant, and sure enough, the referenced commit[3] in libxml2 linked to a report[4] exhibiting this same problem. [1] - https://gitlab.gnome.org/GNOME/libxslt/-/compare/v1.1.34...v1.1.35 [2] - https://gitlab.gnome.org/GNOME/libxslt/-/commit/ea1c27fca299f4f29d8bd1e29ac2ad21aea81bcc [3] - https://gitlab.gnome.org/520zym/libxml2/-/commit/9f42f6baaa91b6461ddfce345c174ea5f1ee73c3 [4] - https://gitlab.gnome.org/GNOME/libxslt/-/issues/37
