build-1-sourcepkg job fails for "3.0 (quilt)" packages

[James Henstridge]

In an MP for one of the projects we're working on, the debian source package version was changed to "3.0 (quilt)". The jenkaas jobs then failed to build the MP:

  https://code.launchpad.net/~michihenning/storage-framework/copyright/+merge/299761/comments/771947

Here is one of the logs from the failing build-1-sourcepkg job:

  https://jenkins.canonical.com/unity-api-1/job/build-1-sourcepkg/release=yakkety/98/console

In particular, it ends with:

  02:32:42 dpkg-source -b storage-framework-0.1+yakkety98bzr24
  02:32:42 dpkg-source: error: can't build with source format '3.0 (quilt)': no upstream tarball found at ../storage-framework_0.1+yakkety98bzr24.orig.tar.{bz2,gz,lzma,xz}
  02:32:42 dpkg-buildpackage: error: dpkg-source -b storage-framework-0.1+yakkety98bzr24 gave error exit status 255

With "1.0" source packages, the build-1-sourcepkg job ends up producing a native package where source and packaging are mixed together in a single .tar.gz.

For a "3.0 (quilt)" source package, the packaging information needs to be distributed as a separate .debian.tar.gz file. Since the job changes the package's upstream version number, no .orig.tar.gz.

There are two solutions I can think of here:

1. Change the build-1-sourcepkg job to add something to the release component of the package version number rather than the upstream component: then it should be able to use the .orig.tar.gz from build-0-fetch.

2. Merge build-0-fetch and build-1-sourcepkg jobs together. bzr-builddeb manages to build a 3.0 source package just fine, so perhaps you could just get it to do so multiple times.