** they simply run a build and/or the tests of the master branch of their git repository on every commit against sid. If that succeeds, the same source will be built on bullseye, then on buster and - in the lintian case only - also for stretch-backports.
** they simply run a build and/or the tests of the master branch of their git repository on every commit against sid. If that succeeds, the same source will be built on testing and stable.
* There are also jobs related to link:https://udd.debian.org[UDD]:
** they check for multiarch version screws in various suites or issues with orphaned packages without the correct the relevant bug.
*** the UDD schema is available at https://udd.debian.org/schema/udd.html
* The (current) purpose of https://tests.reproducible-builds.org is to show the potential of reproducible builds for Debian - and six other projects currently. This is research, showing what could (and should) be done... check https://wiki.debian.org/ReproducibleBuilds for the real status of the project for Debian!
* For Debian, five suites, 'stretch', 'buster', 'bullseye', 'unstable' and 'experimental', are tested on four architectures: 'amd64', 'i386', 'arm64' and 'armhf'. The tests are done using 'pbuilder' through several concurrent workers: 40 for 'amd64', 24 for 'i386', 32 for 'arm64' and 45 for 'armhf', which are each constantly testing packages and saving the results of these tests. There's a single link:https://salsa.debian.org/qa/jenkins.debian.net/blob/master/bin/reproducible_build_service.sh[systemd service] starting all of these link:https://salsa.debian.org/qa/jenkins.debian.net/blob/master/bin/reproducible_worker.sh[workers] which in turn launch the actual link:https://salsa.debian.org/qa/jenkins.debian.net/blob/master/bin/reproducible_build.sh[build script]. (So the actual builds and tests are happening outside the jenkins service.)
* For Debian, six suites, 'stretch', 'buster', 'bullseye', 'bookworm', 'unstable' and 'experimental', are tested on four architectures: 'amd64', 'i386', 'arm64' and 'armhf'. The tests are done using 'pbuilder' through several concurrent workers: 40 for 'amd64', 24 for 'i386', 32 for 'arm64' and 45 for 'armhf', which are each constantly testing packages and saving the results of these tests. There's a single link:https://salsa.debian.org/qa/jenkins.debian.net/blob/master/bin/reproducible_build_service.sh[systemd service] starting all of these link:https://salsa.debian.org/qa/jenkins.debian.net/blob/master/bin/reproducible_worker.sh[workers] which in turn launch the actual link:https://salsa.debian.org/qa/jenkins.debian.net/blob/master/bin/reproducible_build.sh[build script]. (So the actual builds and tests are happening outside the jenkins service.)
** To shutdown all the workers use: `sudo systemctl stop reproducible_build@startup.service ; /srv/jenkins/bin/reproducible_cleanup_nodes.sh`
** To start all the workers use: `sudo systemctl start reproducible_build@startup.service`
* We would love to have more or more powerful ARM hardware in the future, if you can help, please talk to us!
* Packages to be build are scheduled in the database via a scheduler job, which runs every hour and if the queue is below a certain threshold schedules four types of packages:
** new untested packages (either uploaded to 'unstable' or 'experimental' or migrated to 'bullseye', or security updates to 'buster' or 'stretch'),
** new untested packages (either uploaded to 'unstable' or 'experimental' or migrated to 'bookworm', or security updates to 'bullseye', 'buster' or 'stretch'),
** new versions of existing packages, which were already tested - these are always scheduled, no matter how full the queue is
** old versions, already tested (at least two weeks ago)
** and also some old versions which failed to build (at least ten days ago), if no bug has been filed.
Holger Levsen <holger@layer-acht.org>