< Reproducible builds

Reproducible builds/Status

Arch Linux is constantly rebuilding core and extra packages and has a status page. This page contains a status of bad packages and what needs to be fixed.

Issues

General

  • A rebuild is required for all packages build with pacman < 5.2 to resolve file order issues and a btrfs size bug. For the file order issue the affecting extra packages can be found running the following one liner on a mirror directory:
for i in /srv/ftp/extra/os/x86_64/*.pkg.tar.??; do
   bsdtar -tf $i | grep "^\." > pkg-order
   sort pkg-order > sort-order
   if ! diff pkg-order sort-order &>/dev/null; then
     echo $i;
   fi
   rm pkg-order sort-order
done

File order rebuild FTBFS

accounts-qml-module-0.7-2-x86_64.pkg.tar.xz
archboot-2019.03-1-any.pkg.tar.xz
cmark-0.29.0-1-x86_64.pkg.tar.xz
gtk-sharp-2-2.12.45-2-x86_64.pkg.tar.xz
guile1.8-1.8.8-7-x86_64.pkg.tar.xz
java11-openjfx-11.0.3.u1-1-x86_64.pkg.tar.xz
java11-openjfx-doc-11.0.3.u1-1-x86_64.pkg.tar.xz
java11-openjfx-src-11.0.3.u1-1-x86_64.pkg.tar.xz
java8-openjfx-8.u202-3-x86_64.pkg.tar.xz
java8-openjfx-doc-8.u202-3-x86_64.pkg.tar.xz
java8-openjfx-src-8.u202-3-x86_64.pkg.tar.xz
java-openjfx-13.u14-1-x86_64.pkg.tar.xz
java-openjfx-doc-13.u14-1-x86_64.pkg.tar.xz
java-openjfx-src-13.u14-1-x86_64.pkg.tar.xz
jdk10-openjdk-10.0.2.u13-2-x86_64.pkg.tar.xz
jre10-openjdk-10.0.2.u13-2-x86_64.pkg.tar.xz
jre10-openjdk-headless-10.0.2.u13-2-x86_64.pkg.tar.xz
jsonrpc-glib-3.34.0-1-x86_64.pkg.tar.xz
libva-vdpau-driver-0.7.4-4-x86_64.pkg.tar.xz
liferea-1.12.7-1-x86_64.pkg.tar.xz
linux-atm-2.5.2-6-x86_64.pkg.tar.xz
mono-tools-4.2-2-x86_64.pkg.tar.xz
npapi-sdk-0.27.2-2-any.pkg.tar.xz
nss_ldap-265-7-x86_64.pkg.tar.xz
openjdk10-doc-10.0.2.u13-2-x86_64.pkg.tar.xz
openjdk10-src-10.0.2.u13-2-x86_64.pkg.tar.xz
pam_ldap-186-6-x86_64.pkg.tar.xz
portaudio-1:19.6.0-6-x86_64.pkg.tar.xz
qtav-1.13.0-1-x86_64.pkg.tar.xz

Packages with JAR files

JARs include a modification timestamp for each file, making them unreproducible. Depending on the build system, there are different solutions available for this.

Ant

Currently has no support for reproducible builds, see the upstream feature request.

Gradle

Should support reproducible builds out of the box.

Maven

Supports the project.build.outputTimestamp property that can be set to a fixed timestamp. Recent versions of Maven plugins respect this property to create reproducible artefacts. The property should be set in the project's pom.xml file, if upstream does not already do this, you can define it at compile time using a command like

mvn -Dproject.build.outputTimestamp="$SOURCE_DATE_EPOCH" clean package

It might be necessary to patch the project's pom.xml to update plugins to a more recent version with support for reproducible builds, see the Maven guide to reproducible builds for the minimum required versions and more information like additional necessary configuration options.

Example package (including a patch for a Maven plugin version update): junit-system-rules.

OpenJDK jar command

The builtin OpenJDK jar program will support SOURCE_DATE_EPOCH starting with OpenJDK version 15.

strip-nondeterminism

As a last resort, strip-nondeterminism from Debian is able to strip unreproducible metadata like file timestamps from a variety of file types, including JARs. It is not a cure-all (e.g. build systems might include additional unreproducible metadata in the JAR manifest, strip-nondeterminism removes some, but not all of these) and should only be used as a last resort if no native support for reproducible builds is available:

strip-nondeterminism --timestamp "$SOURCE_DATE_EPOCH"

KDE Kdeveloper project files

KDE creates Package App template .tar.bz2 files which tar files and userid is different when reproducing with repro which might be a bug in repro. https://gist.githubusercontent.com/jelly/570313f56ee59be7674ad4cc002232e7/raw/b85536690c48b23ce97650e8db8f0ca18c2dbf1a/gistfile1.txt

The cmake file which generates the issue.

Doxygen documentation build with graphviz-2.44.0-2

graphviz lacked a dependency on libpng, making PNG generation unavailable in dot as graphviz was installed before libpng was available and therefore not marking it as to be dlopen'd. All packages which depend on doxygen for generation documentation and with the following diff require a rebuild.

│ │ --rw-r--r--   0 root         (0) root         (0)    20234 2020-05-16 12:32:36.000000 usr/share/doc/grantlee/classGrantlee_1_1Parser.html
│ │ --rw-r--r--   0 root         (0) root         (0)      265 2020-05-16 12:32:36.000000 usr/share/doc/grantlee/classGrantlee_1_1Parser__inherit__graph.map
│ │ --rw-r--r--   0 root         (0) root         (0)       32 2020-05-16 12:32:36.000000 usr/share/doc/grantlee/classGrantlee_1_1Parser__inherit__graph.md5
│ │ --rw-r--r--   0 root         (0) root         (0)     3136 2020-05-16 12:32:36.000000 usr/share/doc/grantlee/classGrantlee_1_1Parser__inherit__graph.png
│ │ +-rw-r--r--   0 root         (0) root         (0)    19961 2020-05-16 12:32:36.000000 usr/share/doc/grantlee/classGrantlee_1_1Parser.html
│ │ +-rw-r--r--   0 root         (0) root         (0)      598 2020-05-16 12:32:36.000000 usr/share/doc/grantlee/classGrantlee_1_1Parser__inherit__graph.dot

[core]

Package Issue Solution/Patch Assignee Solved
linuxSigned modulesnonenoneNo
linux-docslots of issues - ordering, linking, ...nonenoneNo
linux-headers/usr/lib/modules/*/build/vmlinux diff[dead link 2021-11-15 ]nonenoneNo
linux-ltsas for linuxnonenoneNo
linux-lts-docsas for linux-docsnonenoneNo
linux-lts-headersas for linux-headersnonenoneNo

[extra]

Package Issue Solution/Patch Assignee Solved
amdvlkmany differences in usr/lib/amdvlk64.sononenoneNo
ant.jar file differencesnonenoneNo
ant-doclots of timestamps (javadoc), and .zip file differencenonenoneNo
asymptoteDates in html and info. PDF document differences (dates?)nonenoneNo
autogenTimestamp in man pages, sr/share/autogen/libopts-42.1.17.tar.gz with different file ownership, and a small binary change in usr/bin/autogenneed export MAN_PAGE_DATE=... and configure --enable-timeout=70noneNo
bigloouname and timestamps all over the placenonenoneNo
breezy3.0.2.3-3 reproducible with both repro and makechrootpkgtooling issue?noneNo
clispip address; timestamps in ps docs, likely much morenonenoneNo
deluge.pyc file, .egg filesnonenoneNo
doxygen-docslots of pdfs with differencesnonenoneNo
ecluname, timestamp, gzip, lots of other binary differencesnonenoneNo
eclipse-ecj.jar filenonenoneNo
efitools/usr/share/efitools/efi/LockDown.efi has binary differencesnonenoneNo
efllots of binary differencesnonenoneNo
emacsbinary differences in usr/bin/emacsnonenoneNo
firefoxIt is firefox; PGO?nonenoneNo
libblurayfile attribute(?) differences in usr/share/java/{libbluray{,-awt}-j2se-1.2.0.jarnonenoneNo
libgtopuname in /usr/bin/libgtop_server2nonenoneNo
libmp4v2timestamp in usr/include/mp4v2/project.h & usr/lib/libmp4v2.so.2.0.0nonenoneNo
lirctimestamp in yaml files, usr/share/lirc/lirc-0.10.1.tar.gz has lots of timestamp differences, repro causes poll() detection issue not found in makerepropkgpatchnoneNo
rLots of timestamps in files, gzip timestamps, randomly(?) generated paths in /tmp/, binary differences...nonenoneNo
zabbix-agent2Timestamp in /usr/bin/zabbix_agent2nonenoneNo

[multilib]

Package Issue Solution/Patch Assignee Solved
lib32-keyutilsBinary includes build dateproposednoneNo
This article is issued from Archlinux. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.