Reproducible builds

Arch Linux is currently working on making all packages reproducible. This lets users and researchers verify the distributed packages from Arch Linux. For the exact definition of reproducible builds and its benefits take a look at the project website.

Verification builds

Repository vs. rebuild

An experimental rebuilderd instance has been setup on our own infrastructure with a status page. Rebuilderd rebuilds our repository packages and checks if they are bit for bit identical. If they are not reproducible there is either a bug in the tooling, the package is not reproducible or the package has not been built cleanly.

A list of known issues is located on /Status.

Rebuild vs. another rebuild with variations

The Reproducible Builds project rebuilds Arch Linux packages and compares them with another rebuild in a different environment. The package status and environment variations are listed in the dedicated Arch Linux page.

Helping out

Tooling

Help out on fixing bugs and adding features for repro.

Running a Rebuilder instance

Setting up rebuilderd to build Arch Linux packages helps to independently verify repository packages.

Verifying packages with repro and finding issues

A great way to help out is to find an unreproducible package and figuring out how it can be made reproducible.

  • Download an Arch Linux package or get one from the Arch Linux Archive
  • Run repro on the downloaded package or a package from your pacman cache. Ideally with repro -d to get diffoscope output. For example, repro -d /var/cache/pacman/pkg/curl-7.73.0-1-x86_64.pkg.tar.zst
  • Investigate if it is an issue with Arch Linux packaging or upstream, issues can be added on the status page. More information can be found on the Reproducible Builds website.

Work on issues in the tests.reproducible-builds.org infrastructure

Arch users can help contribute to Reproducible Build issues by looking at the continuous reproducing environment. There are various issues which can be sorted out:

  • FTBS (failed to build from source): reproduce the build failure locally and create a bug report if the package cannot be built from a clean chroot (extra-x86_64-build or multilib-build).
  • Failed to download sources, reproduce the issue (makepkg -o -d) and create a bug report on the Arch bugtracker.
  • Failed to reproduce. Locally you can reproduce packages using reprotest. Note that not all variations can be used. For simple time related testing: 
    $ reprotest --variations '+time' 'sudo extra-x86_64-build' '*.pkg.tar.zst'

There might be various reasons for a package to not be reproducible, but before digging in take a look at the upstream repository or the reproducible status in Debian

  • Failed to run tests, these failures are heavily on the testing environment. Most likely due to to LANG=C being set and Arch not supporting LANG=C.UTF-8.

If you are interested in the code which runs the continuous reproducing environment, the first build code starts here on salsa

Note: The continuous reproducing environment on tests.reproducible-builds.org does NOT reproduce official arch packages. Its purpose is only to fuzz the packages and attempt to trigger as many bugs as possible, so they can be reported upstream.

Known issues

GPG verification

There is a possible rebuild scenario where GPG keys will not verify as the packager was removed from the keyring or revoked as we use the latest keyring and a package in the archive which we need might need be signed by a revoked key we are unable to verify it and the build will fail.

Contact
gollark: I also seem to not have blkid or lsblk.
gollark: Oh, correction, every *five* seconds.
gollark: ```03-01 21:54:43.706 492 492 F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 492 (recovery), pid 492 (recovery)03-01 21:54:43.707 494 494 F libc : failed to exec crash_dump helper: No such file or directory03-01 21:54:43.708 492 492 F libc : crash_dump helper failed to exec03-01 21:54:48.709 496 496 W libc : Unable to set property "ro.twrp.boot" to "1": error code: 0xb03-01 21:54:48.710 496 496 W libc : Unable to set property "ro.twrp.version" to "3.4.0-TEST_MRMAZAK_10": error code: 0xb03-01 21:54:48.711 496 496 F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 496 (recovery), pid 496 (recovery)03-01 21:54:48.714 498 498 F libc : failed to exec crash_dump helper: No such file or directory03-01 21:54:48.715 496 496 F libc : crash_dump helper failed to exec03-01 21:54:53.721 499 499 W libc : Unable to set property "ro.twrp.boot" to "1": error code: 0xb03-01 21:54:53.721 499 499 W libc : Unable to set property "ro.twrp.version" to "3.4.0-TEST_MRMAZAK_10": error code: 0xb03-01 21:54:53.722 499 499 F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 499 (recovery), pid 499 (recovery)03-01 21:54:53.724 501 501 F libc : failed to exec crash_dump helper: No such file or directory03-01 21:54:53.725 499 499 F libc : crash_dump helper failed to exec```It seems to log this every few times a second, how amazing!
gollark: If it comes to it I *think* I can reflash it from the "MTK scatter tool" but this would require me to find a windows computer somewhere and such.
gollark: Or fastboot.
This article is issued from Archlinux. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.