Plus One Basics

The purpose of the +1 maintenance team (the name derives from the term "ubuntu+1" used by some to refer to the next release of Ubuntu) is to make things better in the archive: to look at things which a package uploader would not necessarily notice or care about such as knock-on effects to other packages from their upload. For example uploading a new version of a library leaves any dependent packages no longer built against the current version of that package and potentially no longer rebuildable. See the PlusOneMaintenanceTeam home page for more information and links.

The team hangs out on Libera in the #ubuntu-release channel.

There are a few main places we look for things which need fixing:

• proposed-migration: https://ubuntu-archive-team.ubuntu.com/proposed-migration/

• FTBFS: http://qa.ubuntuwire.org/ftbfs/

• NBS: https://ubuntu-archive-team.ubuntu.com/nbs.html

In rough order we are interested in NBS (reducing the bottom section), FTBFS for main, paying down the proposed-migration backlog, and FTBFS for universe. These are often intertwined, and obviously anything which gets fixed is a benefit.

There are some other reports of interest:

• Merges: https://merges.ubuntu.com/

• Component Mismatch: http://people.canonical.com/~ubuntu-archive/component-mismatches.svg

• ARM Porting Issues: https://wiki.ubuntu.com/ARM/PortingIssues

• ARM EABI Problems (Debian): http://wiki.debian.org/ArmEabiProblems

FTBFS

The FTBFS list has a row for each build failures, columns representing the failed architectures. There are four categories of failure, but the primary causes are dependency issues (in yellow) and actual failed builds (in red).

Build Failures

These are simple failures (FTBFS) which can normally be attacked by downloading the package and attempting to build it in an sbuild chroot (see below). Where the package simply works when rebuilt it is appropriate to request the package be put back, a core-dev should have a button for this on the failure page similar to a PPA.

Dependency Issues

Dependency Issues are typically caused by versioned dependancies or new dependencies on packages which are unavailable, not yet built or in the wrong component (such as a main package depending on a package in universe). Often these will resolve themselves when the pre-requisite package either completes building or is fixed.

These are attacked by looking at the pre-requisite package and seeing if it is currently queued/building, if so it can be ignored safely. If the package is broken it will typically show up on the FTBFS list and would be attacked appropriately.

proposed-migration

proposed-migration is the system which checks packages for consistency between upload and moving them into the "release pocket" consisting of packages which are presumptively suitable for release. Many of the consistency checks here involve things like ensuring dependency correctness across large groups of packages. If left untended it is possible for complicated blockages to build up here, and so it's in everyone's interests to keep the backlog small and avoid multiple large changes becoming intertwined too badly. See its wiki page for more details.

NBS

The NBS list contains all binary packages which are no longer built from source, packages which were built by a source package no longer in the archive. This will typically be older versions of binary packages where the source package has been updated. This most commonly happens with libraries as packages which use them gain version specific dependancies via the ${shlibs:Depends} incantations in debian/control, when the library package is modified the older version is held in the archive by these dependancies.

Resolution here also normally involves attempting a rebuild in an sbuild chroot. In a lot of cases the interfaces will be compatible and the package will simply rebuild and work. There it is appropriate to perform a no-change rebuild (see below) of the package.

Where it does not it is appropriate to attempt to fix the issue and upload a patched package. Do remember to forward the change to debian (submittodebian) and upstream as appropriate.

How-To

No Change Rebuild

A no change rebuild is basically an upload with no code changes. dch will create an appropriately versioned changelog entry:

• dch -R
  dch -r
  dpkg-buildpackage -S

You should supply the reason for the change similar to below:

•  * No change upload to get the latest version of FOO.

Getting Setup

To be effective you will need to be able to test build packages. For these test builds to be meaningful you need them to be as close to the real builds as possible. We recommend testing those in an sbuild environment which is very close to how the buildds build the packages.

Setting up sbuild

Also see: https://wiki.ubuntu.com/SimpleSbuild

You will first want to install the sbuild and mk-sbuild tools and generate a local archive key:

• sudo apt-get install sbuild ubuntu-dev-tools
  sudo adduser <username> sbuild
  sbuild-update --keygen

Then you will want to configure mk-sbuild:

• ## CONFIGURE mk-sbuild basic configuration ...
  cat - <<EOM >~/.mk-sbuild.rc 
  # mk-sbuild build tunables -- SOURCE_CHROOTS_TGZ used with 'file' and SOURCE_CHROOTS_DIR with 'directory'
  SCHROOT_CONF_SUFFIX="source-root-users=root,sbuild,admin
  source-root-groups=root,sbuild,admin
  preserve-environment=true"
  SKIP_UPDATES="1"
  DEBOOTSTRAP_INCLUDE="devscripts"
  EOM

Note: Check if your system contains /etc/networks before running mk-sbuild as it will fail. Run  sudo touch /etc/networks  beforehand to ensure they exist.

You will almost certainly want to use a local caching proxy within the chroots as each build will attempt to download dependent packages, squid-deb-proxy works well for this. Supply the proxy when building the chroots and it will carry over into the chroots:

• http_proxy=http://192.168.2.1:8000/ mk-sbuild --arch=i386 --distro=ubuntu quantal
  http_proxy=http://192.168.2.1:8000/ mk-sbuild --arch=amd64 --distro=ubuntu quantal

If you already have chroots with the default names (quantal-i386, quantal-amd64 etc) you may wish to make sbuild specific chroots instead:

• http_proxy=http://192.168.2.1:8000/ mk-sbuild --name sbuild-quantal --arch=i386 --distro=ubuntu quantal
  http_proxy=http://192.168.2.1:8000/ mk-sbuild --name sbuild-quantal --arch=amd64 --distro=ubuntu quantal
  ## RENAME the chroots so that sbuild finds them by default.
  sudo sed -i -e 's/\[sbuild-\(.*\)\]/[\1-sbuild]/' /etc/schroot/chroot.d/sbuild-*

To use these chroots use the sbuild command against the dsc files from the source pacakge, the other source package files should be in the same directory. Note the use of -A with the i386 build to emulate the behaviour of the buildds:

• sbuild -A --arch i386 -d quantal grub-gfxpayload-lists_0.7~apw2.dsc
  sbuild -A --arch amd64 -d quantal grub-gfxpayload-lists_0.7~apw2.dsc

To examine a failed build it is handy to have the chroots persist on failure, you can do this by adding this fragment to your .sbuildrc:

• $purge_build_directory = 'successful';
  $purge_session = 'successful';

The chroot identifier is listed in the build log *.build generated in during the attempt. You may attach to a chroot using the schroot -rc <id> and release a chroot using schroot -ec <id>. Clean up any left over chroots with schroot --all-sessions -e.

Tips

General

Use pull-lp-source to get source packages, e.g., 'pull-lp-source mono utopic'

When we have an Ubuntu delta we have to not use the Debian maintainer fields, running update-maintainer JDTRT for you.

Use 'what-patch' to identify which patching system was used by the package.

Use 'rmadison' to remotely query the Debian archive about a package.

Use 'haveged' to generate enough entropy for your sbuild key on ARM.

Use 'submittodebian' to submit your patch to Debian.

Use 'retry-autopkgtest-regressions' from ubuntu-archive-tools to generate URLs to re-run autopkgtests. The --only-unknown flag is a good candidate for retries (use --help for more info).

Check in the channel if somebody is already working on a particular problem.

When building KDE packages be sure to install pkg-kde-tools.

Debuild in the release you are working on!

Update Excuses

uninstallable in update excuses might simply require a no change rebuild.

FTBFS

Make sure there isn't a merge in-flight that will fix the issue

Merges

Check the merges.ubuntu.com patch, this should be used as a guideline for your patch.

Remaining Changes in the changelog are deltas remaining between Debian and Ubuntu.

Debdiff needs to be a patch between the old Ubuntu version and the new one.

Circular Build Dependencies

This case occurs when a package isn't building because it needs newer versions of dependencies, but those dependencies in turn require a newer version of the main package.

For example, phpunit migrates from 8.5 to 9.5, but version 9.5 fails to build because it needs newer versions of php-codecoverage, php-exporter, and a few other packages. However, the new versions of these dependencies require phpunit >= 9.0 to build themselves (specifically, for running their testsuite).

Since the issue occurs at build-time rather than at autopkgtest-time, we can't simply construct a re-trigger as in other situations. However, there are a few paths to untangle things.

A seemingly obvious approach would be to have an archive admin copy the binary packages from the Debian Unstable pocket. For the sake of archive build reproducibility and general archive policy, it's strongly preferred not to use this approach except under certain controlled situations.

A second approach is to see if the problematic dependencies can be temporarily disabled. In our example, the reason the dependencies require phpunit is for running their own testsuites. So, a workaround is to delete 'phpunit' from each of the packages' debian/control file and comment out lines in debian/rules that invoke phpunit. Another situation where this approach can work is when the dependencies enable an optional feature, that can be temporarily disabled.

A third approach is "bootstrapping". This is done by finding an intermediate version of the package and migrating to that instead. To do this, upload the intermediate version (and any required dependency updates) to a PPA and verify it builds, and that the autopkgtests pass. Next, request an archive admin remove the -proposed version of the package and upload the intermediate ones as well. The archive admin can't copy the binaries directly from your PPA due to policy, but can often reuse your packaging work, so make sure to document the steps you follow (e.g. what order things need to be uploaded in order to resolve dependencies).