Differences between revisions 25 and 26
Revision 25 as of 2019-10-14 00:13:06
Size: 6032
Editor: eriberto
Comment: Added an explanation for a link and debuild command
Revision 26 as of 2019-10-14 01:17:02
Size: 5938
Editor: PaulWise
Comment: reword the section about testing migration
Deletions are marked like this. Additions are marked like this.
Line 11: Line 11:
Since July 2019, the build system no longer allow binaries uploaded by maintainers to migrate to testing. In other words, is needed to do source-only uploads to reach the test release. See more information at the link [[https://lists.debian.org/debian-devel-announce/2019/07/msg00002.html | Source-only uploads required for migration to testing for bullseye]]. Since July 2019, binaries uploaded by maintainers are [[https://lists.debian.org/msgid-search/20190707014700.GF15255@powdarrmonkey.net|not allowed]] to migrate to testing. In other words, packages must have source-only uploads before they can reach the next release.

Source-only uploads

Summary

Source-only are uploads to the Debian archive that do not include a binary build of the Debian package. Then the buildd network handles the build and distributes it to the archive.

Since circa August 2014, the Debian archive accepts source-only uploads and since August 2015, Architecture: all packages are built on the buildds.

Since July 2019, binaries uploaded by maintainers are not allowed to migrate to testing. In other words, packages must have source-only uploads before they can reach the next release.

Restrictions

NEW uploads and uploads with NEW binaries currently cannot be source-only.

Uploads to jessie-security are supported except for Architecture: all packages.

Rationale

Historically, the uploads of packages required them to be built on the developer's machine. The binary, arch-specific packages would be taken as-it-is by the archive after the upload (along with all binary packages, which are architecture agnostic). This means in particular that when you install an amd64 package it is very likely the exact version that was compiled by the maintainer.

There are a few problems with this approach:

  • it happens sometimes that a developer uploads a miscompiled package by a mistake (e.g., for another suite); this needs then to be fixed with one-time binNMU

  • often the developer compile in an out-of-date environment (e.g., old chroots), and the package might end up linking against old libraries; this is particularly annoying during transitions as it requires investigating why it happens and issuing binNMUs
  • if the machine of a developer is compromised, the package may contain maliciously compiled code

Source-only uploads address these issues by essentially having a central authority to compile all code. However, the disadvantage is that if the archive is compromised then every package is compromised. This is true, but it is true even now for more than 90% packages that are built by the archive.

A complementary project is ReproducibleBuilds which aims to make builds fully, bit-per-bit, reproducible. In the future one can imagine that packages are built both by the developer and the archive, the results are tested for equality and the package is only accepted if they match. All this work is about distributing trust and detecting problems early.

How to make a source-only upload

The dpkg-buildpackage program accepts the --changes-option=-S flag which builds the packages as always, but the final .changes file will contain only the source code. You can then use dput to upload the .changes file (see this thread). Example:

$ cd nghttp2
$ dpkg-buildpackage --changes-option=-S
$ cd ..
$ ls *nghttp2*.*
libnghttp2-doc_1.3.4-1_all.deb  nghttp2_1.3.4-1_amd64.changes  nghttp2_1.3.4-1.dsc
nghttp2_1.3.4-1_amd64.build     nghttp2_1.3.4-1.debian.tar.xz  nghttp2_1.3.4.orig.tar.bz2
$ egrep '^ \S{32} ' nghttp2_1.3.4-1_amd64.changes 
 01c9325805a6fe7fc444c890cf43e0fa 2008 httpd optional nghttp2_1.3.4-1.dsc
 cce2f954f27981191e539f43066e939a 1504585 httpd optional nghttp2_1.3.4.orig.tar.bz2
 e0be575279e76a872eac15708374499e 10060 httpd optional nghttp2_1.3.4-1.debian.tar.xz

You can also use the -S flag which only creates the source-only upload (the package is not even built in this case). Please make sure that the package builds properly before.

If you like debuild command, you can do:

$ debuild -S

Generating _source.changes with sbuild and pbuilder

While you should not build binary packages to upload directly with dpkg-buildpackage, it is fine to use dpkg-buildpackage -S to prepare source-only uploads.

If you build binaries for testing with sbuild and pbuilder, as a convenience feature, they can be made to emit a _source.changes too.

Using sbuild

The --source-only-changes option generates a source-only upload

A typical build command would be:

sbuild -A -s -d unstable --source-only-changes --run-lintian

git-buildpackage support

If you are using git-buildpackage without pbuilder or sbuild, it will happily accept -S or --changes-option=-S switch:

gbp buildpackage --changes-option=-S

This also works with --git-pbuilder too in jessie and below.

If you are using --git-pbuilder in stretch or later, you should use --git-pbuilder-options=--source-only-changes:

gbp buildpackage --git-pbuilder --git-pbuilder-options=--source-only-changes

This will give a binary+source .changes file and a source-only .changes file. Naturally, you must discard the .changes file that includes information about binary packages (.deb files) and only sign and upload the source-only .changes file in order to make a source-only upload.

Alternatively, you can set SOURCE_ONLY_CHANGES=yes in your pbuilderrc and avoid needing to give the option on the command-line.

When using git-buildpackage with sbuild (≥ 0.70.0-1), specify --source-only-changes in order to get both a binary .changes file and a source-only .changes file, e.g.:

gbp buildpackage --git-builder='sbuild --source-only-changes -v -As --dist=unstable'

This can also be hardcoded in the configuration file, see sbuild.conf for details:

$source_only_changes = 1;

Sources