Skip to content
GitLab
Commits (5)
Hide whitespace changes
Inline Side-by-side
_blog/posts/192.md
View file @ 83c7ca08
---
layout: new/blog
week: 192
published: 2019-01-01 19:44:41
---
Here's what happened in the [Reproducible Builds](https://reproducible-builds.org) effort between Sunday December 23 and Saturday December 29 2018:
......@@ -17,6 +18,8 @@ Here's what happened in the [Reproducible Builds](https://reproducible-builds.or
* The [Open Build Service (OBS)](https://openbuildservice.org/), a system to build and distribute binary packages from sources in an automatic & consistent form. was found to [publish new binaries under old names](https://github.com/openSUSE/open-build-service/issues/6690) which was confusing some tools.
* On January 9th 2019, Chris Lamb will speak at [Université de Rennes](https://www.univ-rennes1.fr/), France on reproducible builds.
* Holger Levsen bumped the `Standards-Version` field in [all of our tools]({{ "/tools/" | prepend: site.baseurl }}) to `4.3.0`. [[...](https://salsa.debian.org/reproducible-builds/diffoscope/commit/2d236c7)][[...](https://salsa.debian.org/reproducible-builds/strip-nondeterminism/commit/57de24c)][[...](https://salsa.debian.org/reproducible-builds/disorderfs/commit/a12fdeb)][[...](https://salsa.debian.org/reproducible-builds/reprotest/commit/62cbe96)]
## Packages reviewed and fixed, and bugs filed
......
_docs/jvm.md
View file @ 83c7ca08
......@@ -43,6 +43,7 @@ scm.tag=<source control management tag as in pom.xml>
# build environment information
java.version=<full Java version>
os.name=<Operating system name>
build-tool=<mvn|sbt|...>
# Each build tool or plugin is free to add additional entries to the buildinfo.
......@@ -51,7 +52,7 @@ sbt.version=1.2.3
scala.version=2.12.6
# A buildinfo file can contain checksums for multiple output files, for
# example for the main jar and the accompanying pom.xml:
# example for the main jar and the accompanying (generated) pom.xml:
outputs.0.filename=<file name>
outputs.0.length=<file size>
outputs.0.checksums.sha512=<sha512>
......
contribute/index.html deleted 100644 → 0
View file @ 573dd7fa
---
layout: page
title: Contribute
permalink: /contribute/
order: 4
---
<div class="row">
<div class="four columns title">
<h2>Get involved</h2>
</div>
<div class="eight columns">
<p>
First, please join the <a href="https://lists.reproducible-builds.org/listinfo/rb-general">rb-general general mailing-list</a>.
</p>
<p>
IRC discussions happen in the <code>#reproducible-builds</code> channel on <a href="https://www.oftc.net/">irc.oftc.net</a>.
</p>
<ul>
<li><a href="{{ "/contribute/salsa/" | prepend: site.baseurl }}">Join the Reproducible Builds group</a> on <a href="https://salsa.debian.org/">Salsa</a> to contribute directly on our Git repositories.</li>
<li>Subscribe to the <a href="https://lists.alioth.debian.org/mailman/listinfo/reproducible-builds">reproducible-builds@lists.alioth.debian.org mailing list</a> and/or other <a href="https://lists.reproducible-builds.org/">reproducible builds</a> oriented lists.</li>
<li>Join the <a href="https://webchat.oftc.net/?channels=#reproducible-builds">#reproducible-builds IRC channel on OFTC</a> and possibly <a href="https://webchat.oftc.net/?channels=#debian-reproducible">#debian-reproducible</a> too.</li>
<li>You can also subscribe to <a href="https://lists.reproducible-builds.org/listinfo/rb-commits">commit notifications</a>.</li>
</ul>
</div>
</div>
<div class="row">
<div class="four columns title">
<h2>Task suggestions</h2>
</div>
<div class="eight columns">
<ol>
<li>
If you maintain a package for Debian, you can make sure that your
package uses a <a
href="https://salsa.debian.org/debian/debhelper/blob/master/dh">modern
debhelper style</a> (e.g. one-liner <code>debian/rules</code> with
overrides as needed). We aim to fix many causes of non-deterministic
builds in the debhelper suite directly, so packages that use debhelper
will be much easier to make reproducible with just an upgrade of the
toolchain.
</li>
<li><a href="#Inventorying_issues">Inventory issues</a> found by the continuous integration platform.</li>
<li><a href="#Fixing_issues">Fix known reproducibility issues</a>. See the <a href="https://reproducible.debian.net/index_issues.html">inventory of identified issues</a>.</li>
<li>Improve our common tools: <a href="https://tracker.debian.org/diffoscope">diffoscope</a>, <a href="https://tracker.debian.org/strip-nondeterminism">strip-nondeterminism</a>, <a href="https://tracker.debian.org/disorderfs">disorderfs</a>.</li>
<li>Redesign <a href="https://reproducible.debian.net/">reproducible.debian.net</a> status pages using a CSS toolkit like Bootstrap.</li>
<li>Enhance <a href="https://tracker.debian.org/dak">dak</a> <a href="https://bugs.debian.org/763822">support for .buildinfo</a>.</li>
<li>Research how to run rebuilds on ''buildd''s.</li>
<li>Research on how change dak to only accept packages after multiple matching builds.</li>
<li>Hack binNMU infrastructure (dak?) so .dsc for binNMUs are kept in the archive instead of being thrown away.</li>
</ol>
<p>
To get help, feel free to ask on the IRC channel or the mailing list. We
want to be friendly, supportive, and have fun experimenting together.
</p>
</div>
</div>
<div class="row">
<div class="four columns title">
<h2>How to report bugs in Debian</h2>
</div>
<div class="eight columns">
<p>
<a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?usertag=reproducible-builds@lists.alioth.debian.org">Overview of all bug reports concerning reproducible builds</a>
</p>
<p>
All bugs relevant to the reproducible builds project should use <a href="https://bugs.debian.org/usertags">usertags</a> with user <code>reproducible-builds@lists.alioth.debian.org</code>. Also use <code>X-Debbugs-Cc</code> to notify the list, but please use our <code>reproducible-bugs@lists.alioth.debian.org</code> list for this header.
</p>
<p>
To usertag a bug after it has been submitted use:
</p>
<pre>
bts user reproducible-builds@lists.alioth.debian.org . usertag XXXXXX + timestamps toolchain
</pre>
<p>Current usertags in use:</p>
<dl>
<dt>toolchain</dt>
<dd>affects a tool used by other package build systems</dd>
<dt>infrastructure</dt>
<dd>affects the whole Debian infrastructure or policies</dd>
<dt>timestamps</dt>
<dd>time of build in recorded during the build process</dd>
<dt>fileordering</dt>
<dd>build output varies with readdir() order</dd>
<dt>buildpath</dt>
<dd>path of sources is recorded during the build process</dd>
<dt>username</dt>
<dd>username is recorded during the build process</dd>
<dt>hostname</dt>
<dd>hostname is recorded during the build process</dd>
<dt>uname</dt>
<dd>uname output is recorded during the build process</dd>
<dt>environment</dt>
<dd>environment variables are recorded during the build process</dd>
<dt>randomness</dt>
<dd>some build aspects are dependent on (pseudo-)randomness</dd>
<dt>cpu</dt>
<dd>some build aspects are dependent on CPU features or computation speed</dd>
<dt>signatures</dt>
<dd>uses a cryptographic signatures as part of the build process</dd>
<dt>umask</dt>
<dd>permissions depend on current umask</dd>
<dt>buildinfo</dt>
<dd>issues related to .buildinfo control files</dd>
<dt>ftbfs</dt>
<dd>fails to build from source</dd>
<dt>locale</dt>
<dd>varying locales lead to differing behavior (e.g. sorting)</dd>
</dl>
<h3>
Example email to submit a patch:
</h3>
<pre>
From: J. Random Hacker &lt;jrhacker@example.org&gt;
To: submit@bugs.debian.org
Subject: <PACKAGE>: please make the build reproducible (timestamps, fileordering)
Source: <PACKAGE>
Version: <VERSION>
Severity: wishlist
Tags: patch
User: reproducible-builds@lists.alioth.debian.org
Usertags: timestamps fileordering
X-Debbugs-Cc: reproducible-bugs@lists.alioth.debian.org
Hi!
While working on the “reproducible builds” effort [1], we have noticed
that <PACKAGE> could not be built reproducibly.
The attached patch removes extra timestamps from the build system and
ensure a stable file order when creating the source archive. Once applied,
<PACKAGE> can be built reproducibly in our current experimental framework.
[1]: https://wiki.debian.org/ReproducibleBuilds
</pre>
</div>
</div>
<div class="row">
<div class="four columns title">
<h2 id="Inventorying_issues">Inventorying issues</h2>
</div>
<div class="eight columns">
<p>
The easiest way to find issues is to examine the list of <a
href="https://reproducible.debian.net/index_FTBR.html">packages failing
to build reproducibly</a> as found by continuous integration. The first
packages in the list are the one who have been tried most recently.
</p>
<p>
Notes about packages are kept in the <a
href="https://salsa.debian.org/reproducible-builds/notes.git">notes</a>
Git repository in <code>packages.yml</code>. The list of <a
href="https://reproducible.debian.net/index_issues.html">known common
issues</a> is kept in the <code>issues.yml</code> file.
</p>
<p>
The page for a given package should open on the <a href="https://tracker.debian.org/diffoscope">diffoscope</a>
output. Read the list of known issues to get an idea of what you may
found. Here are some more advices:
</p>
<ul>
<li>
When a binary has mismatching mtimes for files in
<code>control.tar.gz</code>, it means that they are <a
href="https://reproducible.debian.net/issues/not_using_dh_builddeb_issue.html">not
adjusted before creating the binary package</a>.
</li>
<li>
<a href="https://reproducible.debian.net/issues/timestamps_in_gzip_headers_issue.html">Timestamps in gzip headers</a> are a no-brainer.
</li>
<li>
When there's a mismatching ''Build ID'' in an executable, it means a
variation happens during the compilation. Investigation can be done
using <a href="https://sources.debian.org/">sources.debian.org</a> (see
link at the top).
</li>
<li>
First step should be a search for the
<a href="https://reproducible.debian.net/issues/timestamps_from_cpp_macros_issue.html">__DATE__, __TIME__ or __TIMESTAMP__</a>
using <a href="https://codesearch.debian.net/">codesearch</a>.
Otherwise, try to locate calls to <code>date</code> in <code>configure.ac</code>,
<code>Makefile.am</code>, etc.
</p>
<p>
The <a
href="https://salsa.debian.org/reproducible-builds/misc.git/tree/clean-notes">clean-notes</a>
script in the <code>misc</code> repository will detect outdated notes and
re-order packages by alphabetical order. It should be run before
committing changes to the <code>notes</code> repository.
</p>
</div>
</div>
<div class="row">
<div class="four columns title">
<h2 id="Fixing_issues">Fixing issues</h2>
</div>
<div class="eight columns">
<p>
Fixing reproducibility issues falls into two categories: either the
problem is specific to a single package or the cause is the output of
another package (then referenced as “toolchain” package).
</p>
<h3>Fixing a single package</h3>
<p>
The usual steps are:
</p>
<ol>
<li>
Use <code>debcheckout</code> or <code>apt-get source</code> to retrieve the source code.
</li>
<li>
Do the changes. With packages using the <code>3.0 (quilt)</code>
format, <code>dpkg-source --commit</code> can be useful.
</li>
<li>
Update <code>debian/changelog</code>. New version is usually original
version with <code>.0~reproducible1</code>.
</li>
<li>
Use <code>dpkg-buildpackage -S</code> to create source package.
</li>
<li>
Use <a href="/tools/">reprotest</a> to test reproducibility. If the
package is not reproducible, examine the diffoscope output
<code>logs/PACKAGE.diffoscope.html</code> or compare build logs
<code>logs/PACKAGE.build1</code> and <code>logs/PACKAGE.build2</code>,
then repeat from step 2 unless the issue comes from another package. In
that case, see about “toolchain” packages below.
</li>
<li>
Use <code>debdiff</code> or <code>git format-patch</code> to create
patches.
</li>
<li>
<a href="https://wiki.debian.org/ReproducibleBuilds/Contribute#How_to_report_bugs">Create a new
bug report</a>, and don't forget to attach the patch!
</li>
<li>
Add an entry or reference the bug in <code>packages.yml</code> in
<code>notes.git</code>.
</li>
</ol>
<h3>Fixing a toolchain package</h3>
<p>
Fixing an issue in a package that affects the reproducibility of other
packages requires some more steps, but the general process is the same:
</p>
<ol>
<li>
Use <code>debcheckout</code> or <code>apt-get source</code> to retrieve
the source code.
</li>
<li>
Do the changes. With packages using the <code>3.0 (quilt)</code>
format, <code>dpkg-source --commit</code> can be useful.
</li>
<li>
Update <code>debian/changelog</code>. New version is usually original
version with <code>.0~reproducible1</code>.
</li>
<li>
Use <code>pdebuild</code> or <code>gbp buildpackage</code> to build the
package.
</li>
<li>
Backup <code>base-reproducible.tgz</code>.
</li>
<li>
Use <code>pbuilder --login --save-after-exec --basetgz
base-reproducible.tgz</code> to install the newly built package.
</li>
<li>
Test a package affected with <code>reprotest</code>. If the issue is
still not fixed, repeat from step 2.
</li>
<li>
If the package is in Git, create a new repository on <a
href="https://salsa.debian.org/reproducible-builds/packages">salsa.debian.org</a>.
Push your
changes to a (rebasable) <code>pu/reproducible_builds</code> branch.
</li>
<li>
Subscribe to the <code>upload-source</code> notification for the
package on the <a href="https://tracker.debian.org/">Package
Tracking System</a>. This is needed so you don't forget to update the
custom package when a new version hits the archive.
</li>
<li>
<a
href="https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain#Adding_a_package_to_the_APT_archive">Upload</a>
the package to the reproducible APT repository.
</li>
<li>
Document the changes on the <a
href="https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain#Modified_packages">wiki</a>.
</li>
<li>
Reference the bug in <code>issues.yml</code> in <code>notes.git</code>
and on the wiki page about the issue if there's one.
</li>
<li>
Everybody with a <a href="https://sso.debian.org">Debian SSO</a> client
certificate (both DDs and guest/alioth) can schedule source packages
to be rebuilt by using the authenticated endpoint at
https://tests.reproducible-builds.org/cgi-bin/schedule. There are handy
icons (<code>♻</code>)in every package page that links to that cgi-bin
script with the correct parameters.
If you don't have a valid client certificate or have any other trouble
you can find somebody in the #debian-reproducible IRC channel to help you.
Also, if you need to mass schedule many packages (even over the daily limit
imposed by the public scheduling script described here), you can find
the jenkins administrators in that channel that can do mass scheduling for you.
</li>
<li>
If the changes don't break anything, <a
href="https://wiki.debian.org/ReproducibleBuilds/Contribute#How_to_report_bugs">create
a new bug report</a>. Don't forget to attach patches and to use the
<code>toolchain</code> usertag.
</li>
</ol>
</div>
</div>
<div class="row">
<div class="four columns title">
<h2>Continuous integration platform</h2>
</div>
<div class="eight columns">
<p>
Several jobs have been created to regularly test packages (from sid main) on <a href="https://jenkins.debian.net">jenkins.debian.net</a>. As a result there is the <a href="https://reproducible.debian.net">reproducible build overview of packages</a>.
</p>
<p>
The setup is explained in <a href="http://layer-acht.org/thinking/blog/20140925-reproducible-builds/">this blog post</a> only, but this post is somewhat outdated by now and needs to be amended.
</p>
<p>
See the various <code>reproducible_*</code> scripts in the <a href="http://salsa.debian.org/qa/jenkins.debian.net/tree/master/bin/">Jenkins Git repository</a>.
</p>
</div>
</div>
<div class="row">
<div class="four columns title">
<h2>Working on installation media or live systems</h2>
</div>
<div class="eight columns">
<p>
Having installation and live systems which can be built reproducibly would also be great. In Debian, <a href=https://bugs.debian.org/900918">#900918</a> is being used to track the progress of reproducible installation images. There is an <code><a href="https://github.com/adrelanos/Whonix/blob/master/help-steps/analyze_image">analyze_image</a></code> Bash script that creates sha512 hashes of all files included within an image, access rights, symlinks, partition table, bootloader and more. Doing this with two images that should match and comparing the reports the script creates can help to identify sources of non-determinism in images. It does not have iso support yet. The author (Patrick Schleizer) is interested to generalize the script for more generic, Debian use cases
</p>
</div>
</div>
<div class="row">
<div class="four columns title">
<h2>External links</h2>
</div>
<div class="eight columns">
<ul>
<li><a href="https://wiki.debian.org/ReproducibleBuilds/ReproducibleInstalls">Reproducible installs</a></li>
<li><a href="http://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20131209/000009.html">Announcing Whonix's First Implementation of Verifiable Builds</a></li>
<li><a href="https://www.whonix.org/wiki/Verifiable_Builds">Whonix Verifiable Builds</a></li>
<li><a href="https://tails.boum.org/blueprint/reproducible_builds/">Tails reproducible builds blueprint</a></li>
<li><a href="https://github.com/lamby/debootstrap/commits/pu/source-date-epoch">reproducible debootstrap</a></li>
</ul>
</div>
</div>
<div class="row">
<div class="four columns title">
<h2>Donate</h2>
</div>
<div class="eight columns">
<p>
Another way to help is to financially support our project. We welcome any
kind of donation, of any size. Please see our <a href="{{ "/donate/" |
prepend: site.baseurl }}">donation page</a> for more information.
</p>
</div>
</div>
contribute/index.md 0 → 100644
View file @ 83c7ca08
---
layout: new/default
title: Contribute
permalink: /contribute/
order: 4
---
# Contribute
## Get involved
First, please join the [rb-general general mailing-list](https://lists.reproducible-builds.org/listinfo/rb-general).
IRC discussions happen in the `#reproducible-builds` channel on [irc.oftc.net](https://www.oftc.net/).
* [Join the Reproducible Builds group]({{ "/contribute/salsa/" | prepend: site.baseurl }}")
on [Salsa](https://salsa.debian.org/) to contribute directly on our Git
repositories.
* Subscribe to the [reproducible-builds@lists.alioth.debian.org mailing list](https://lists.alioth.debian.org/mailman/listinfo/reproducible-builds)
and/or other [reproducible builds](https://lists.reproducible-builds.org/)
oriented lists.
* Join the [#reproducible-builds IRC channel on OFTC](https://webchat.oftc.net/?channels=#reproducible-builds)
and possibly [#debian-reproducible](https://webchat.oftc.net/?channels=#debian-reproducible)
too.
* You can also subscribe to
[commit notifications](https://lists.reproducible-builds.org/listinfo/rb-commits).
## Task suggestions
1. If you maintain a package for Debian, you can make sure that your package
uses a [modern debhelper style](https://salsa.debian.org/debian/debhelper/blob/master/dh)
(e.g. one-liner `debian/rules` with overrides as needed). We aim to fix many
causes of non-deterministic builds in the debhelper suite directly, so
packages that use debhelper will be much easier to make reproducible with
just an upgrade of the toolchain.
1. [Inventory issues](#Inventorying_issues) found by the continuous integration
platform.
1. [Fix known reproducibility issues](#Fixing_issues). See the
[inventory of identified issues](https://reproducible.debian.net/index_issues.html).
1. Improve our common [tools]({{ "/tools/" | prepend: site.baseurl }}):
[diffoscope](https://tracker.debian.org/diffoscope),
[strip-nondeterminism](https://tracker.debian.org/strip-nondeterminism),
[disorderfs](https://tracker.debian.org/disorderfs).
1. Redesign [reproducible.debian.net](https://reproducible.debian.net/) status
pages using a CSS toolkit like Bootstrap.
1. Enhance [dak](https://tracker.debian.org/dak)
[support for .buildinfo](https://bugs.debian.org/763822).
1. Research how to run rebuilds on ''buildd''s.
1. Research on how change dak to only accept packages after multiple matching
builds.
1. Hack binNMU infrastructure (dak?) so `.dsc` for binNMUs are kept in the archive
instead of being thrown away.
To get help, feel free to ask on the IRC channel or the mailing list. We want
to be friendly, supportive, and have fun experimenting together.
## How to report bugs in Debian
[Overview of all bug reports concerning reproducible builds](http://bugs.debian.org/cgi-bin/pkgreport.cgi?usertag=reproducible-builds@lists.alioth.debian.org)
All bugs relevant to the reproducible builds project should use
[usertags](https://bugs.debian.org/usertags) with user
`reproducible-builds@lists.alioth.debian.org`. Also use `X-Debbugs-Cc` to
notify the list, but please use our `reproducible-bugs@lists.alioth.debian.org`
list for this header.
To usertag a bug after it has been submitted use:
bts user reproducible-builds@lists.alioth.debian.org . usertag XXXXXX + timestamps toolchain
### Usertags
* **toolchain**: affects a tool used by other package build systems
* **infrastructure**: affects the whole Debian infrastructure or policies
* **timestamps**: time of build in recorded during the build process
* **fileordering**: build output varies with readdir() order
* **buildpath**: path of sources is recorded during the build process
* **username**: username is recorded during the build process
* **hostname**: hostname is recorded during the build process
* **uname**: uname output is recorded during the build process
* **environment**: environment variables are recorded during the build process
* **randomness**: some build aspects are dependent on (pseudo-)randomness
* **cpu**: some build aspects are dependent on CPU features or computation speed
* **signatures**: uses a cryptographic signatures as part of the build process
* **umask**: permissions depend on current umask
* **buildinfo**: issues related to .buildinfo control files
* **ftbfs**: fails to build from source
* **locale**: varying locales lead to differing behavior (e.g. sorting)
### Example email to submit a patch:
```
From: J. Random Hacker &lt;jrhacker@example.org&gt;
To: submit@bugs.debian.org
Subject:
Source:
Version: <VERSION>
Severity: wishlist
Tags: patch
User: reproducible-builds@lists.alioth.debian.org
Usertags: timestamps fileordering
X-Debbugs-Cc: reproducible-bugs@lists.alioth.debian.org
Hi!
While working on the “reproducible builds” effort [1], we have noticed
that
The attached patch removes extra timestamps from the build system and
ensure a stable file order when creating the source archive. Once applied,
it can be built reproducibly in our current experimental framework.
[1]: https://wiki.debian.org/ReproducibleBuilds
```
## Inventorying issues
The easiest way to find issues is to examine the list of
[packages failing to build reproducibly](https://reproducible.debian.net/index_FTBR.html)
as found by continuous integration. The first packages in the list are the one
who have been tried most recently.
Notes about packages are kept in the
[notes](https://salsa.debian.org/reproducible-builds/notes.git). Git repository
in `packages.yml`. The list of [known common issues](https://reproducible.debian.net/index_issues.html)
is kept in the `issues.yml` file.
The page for a given package should open on the
[diffoscope](https://tracker.debian.org/diffoscope) output. Read the list of
known issues to get an idea of what you may found. Here is some more advice:
* When a binary has mismatching mtimes for files in `control.tar.gz`, it means
that they are [not adjusted before creating the binary package](https://reproducible.debian.net/issues/not_using_dh_builddeb_issue.html).
* [Timestamps in gzip headers](https://reproducible.debian.net/issues/timestamps_in_gzip_headers_issue.html)
are a no-brainer.
* When there's a mismatching `Build ID` in an executable, it means a variation
happens during the compilation. Investigation can be done using
[sources.debian.org](https://sources.debian.org/) (see link at the top).
* First step should be a search for the [`__DATE__`, `__TIME__` or `__TIMESTAMP__](https://reproducible.debian.net/issues/timestamps_from_cpp_macros_issue.html)
using [codesearch](https://codesearch.debian.net/). Otherwise, try to locate
calls to `date` in `configure.ac`, `Makefile.am`, etc.
The [clean-notes](https://salsa.debian.org/reproducible-builds/misc.git/tree/clean-notes)
script in the `misc` repository will detect outdated notes and re-order
packages by alphabetical order. It should be run before committing changes to
the `notes` repository.
## Fixing issues
Fixing reproducibility issues falls into two categories: either the problem is
specific to a single package or the cause is the output of another package
(then referenced as "toolchain" package).
### Fixing a single package
The usual steps are:
1. Use `debcheckout` or `apt-get source` to retrieve the source code.
1. Do the changes. With packages using the `3.0 (quilt)` format,
`dpkg-source --commit` can be useful.
1. Update `debian/changelog`. New version is usually original version with
`.0~reproducible1`.
1. Use `dpkg-buildpackage -S` to create source package.
1. Use [reprotest]({{ "/tools/" | prepend: site.baseurl }}) to test
reproducibility. If the package is not reproducible, examine the diffoscope
output `logs/PACKAGE.diffoscope.html` or compare build logs
`logs/PACKAGE.build1` and `logs/PACKAGE.build2`, then repeat from step 2
unless the issue comes from another package. In that case, see about
"toolchain" packages below.
1. Use `debdiff` or `git format-patch` to create patches.
1. [Create a new bug report](https://wiki.debian.org/ReproducibleBuilds/Contribute#How_to_report_bugs),
and don't forget to attach the patch!
1. Add an entry or reference the bug in `packages.yml` in `notes.git`.
### Fixing a toolchain package
Fixing an issue in a package that affects the reproducibility of other packages
requires some more steps, but the general process is the same:
1. Use `debcheckout` or `apt-get source` to retrieve the source code.
1. Do the changes. With packages using the `3.0 (quilt)` format,
`dpkg-source --commit` can be useful.
1. Update `debian/changelog`. New version is usually original
version with `.0~reproducible1`.
1. Use `pdebuild` or `gbp buildpackage` to build the package.
1. Backup `base-reproducible.tgz`.
1. Use `pbuilder --login --save-after-exec --basetgz base-reproducible.tgz` to
install the newly built package.
1. Test a package affected with `reprotest`. If the issue is still not fixed,
repeat from step 2.
1. If the package is in Git, create a new repository on
[salsa.debian.org](https://salsa.debian.org/reproducible-builds/packages).
Push your changes to a (rebasable) `pu/reproducible_builds` branch.
1. Subscribe to the `upload-source` notification for the package on the
[Package Tracking System](https://tracker.debian.org/). This is needed so
you don't forget to update the custom package when a new version hits the
archive.
1. [Upload](https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain#Adding_a_package_to_the_APT_archive)
the package to the reproducible APT repository.
1. Document the changes on the
[wiki](https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain#Modified_packages).
1. Reference the bug in `issues.yml` in `notes.git` and on the wiki page about
the issue if there's one.
1. Everybody with a [Debian SSO](https://sso.debian.org) client certificate
(both DDs and guests) can schedule source packages to be rebuilt by using
the authenticated endpoint at
https://tests.reproducible-builds.org/cgi-bin/schedule. There are handy
icons (`♻`)in every package page that links to that cgi-bin script with the
correct parameters. If you don't have a valid client certificate or have
any other trouble you can find somebody in the #debian-reproducible IRC
channel to help you. Also, if you need to mass schedule many packages (even
over the daily limit imposed by the public scheduling script described
here), you can find the jenkins administrators in that channel that can do
mass scheduling for you.
1. If the changes don't break anything,
[create a new bug report](https://wiki.debian.org/ReproducibleBuilds/Contribute#How_to_report_bugs).
Don't forget to attach patches and to use the `toolchain` usertag.
## Continuous integration platform
Several jobs have been created to regularly test packages (from `main/sid`) on
[jenkins.debian.net](https://jenkins.debian.net). As a result there is the
[reproducible build overview of packages](https://reproducible.debian.net).
The setup is explained [in this blog post](http://layer-acht.org/thinking/blog/20140925-reproducible-builds/)
onlya and this post is somewhat outdated by now and needs to be amended.
See the various `reproducible_*` scripts in the
[Jenkins Git repository](http://salsa.debian.org/qa/jenkins.debian.net/tree/master/bin/)
## Working on installation media or live systems
Having installation and live systems which can be built reproducibly would also
be great.
In Debian, [#900918](https://bugs.debian.org/900918) is being used to track the
progress of reproducible installation images. There is an
`[analyze_image](https://github.com/adrelanos/Whonix/blob/master/help-steps/analyze_image)`
Bash script that creates sha512 hashes of all files included within an image,
access rights, symlinks, partition table, bootloader and more. Doing this with
two images that should match and comparing the reports the script creates can
help to identify sources of non-determinism in images. It does not have iso
support yet. The author (Patrick Schleizer) is interested to generalize the
script for more generic, Debian use cases
## External links
* [Reproducible installs](https://wiki.debian.org/ReproducibleBuilds/ReproducibleInstalls)
* [Announcing Whonix's First Implementation of Verifiable Builds](http://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20131209/000009.html)
* [Whonix Verifiable Builds](https://www.whonix.org/wiki/Verifiable_Builds)
* [Tails reproducible builds blueprint](https://tails.boum.org/blueprint/reproducible_builds/)
* [reproducible debootstrap](https://github.com/lamby/debootstrap/commits/pu/source-date-epoch)
## Donate
Another way to help is to financially support our project. We welcome any
kind of donation, of any size. Please see our
[donation page]({{ "/donate/" | prepend: site.baseurl }}) for more information.
who.md
View file @ 83c7ca08
......@@ -25,7 +25,7 @@ their users and developers.
{% for x in site.data.sponsors %}
<div class="col-xs-12 col-sm-6 col-md-4 col-lg-4 mb-4">
<div class="card text-center">
<a href="{{ x.url }}" >
<a href="{{ x.url }}" name="{{ x.name }}">
<img class="p-5" src="{{ x.logo | prepend: "/assets/images/who/" | prepend: site.baseurl }}" alt="{{ x.name }}">
</a>
</div>
......