Autopkgtest regressions

After a package has successfully built, the autopkgtest infrastructure at autopkgtest.ubuntu.com runs its DEP-8 for each of its supported architectures. Failed tests can block the migration and result in a Regression listed for the failed architecture(s). The failed migrations, along with the reasons, are listed on the update excuses page.

This article explains common regression reasons.

Proposed migration series

The Proposed migration article series explains the various migration failures and ways of investigating them.

Process overview:

Proposed migration

Practical guidance:

How to resolve a migration issue

Issue types:

Migration status

Each package listed on the update excuses page reports its Migration status. The line is in this format:

Migration status for <package> (<version-x> to <version-y>): <reason>

This means: package <package> has a new version <version-y> uploaded to the -proposed pocket, which should replace the existing version <version-x>. But the change has not yet been permitted. The various reasons typically seen are outlined in the items below.

BLOCKED: Rejected/violates migration policy/introduces a regression

This indicates an autopkgtest Regression with the given package. It is by far the most common situation that requires attention. A typical result looks like this:

autopkgtest for <package>/<version>: amd64: Regression ♻, arm64: Not a regression, armhf: Pass, ppc64el: Test in progress, …

The Regression items indicate problems needing to be solved. See the Issues preventing migration section for diagnostic tips.

Waiting for test results, another package or too young (no action required now - check later)

This means one or more tests still need to run. These are noted as Test in progress under the Issues preventing migration: line.

Will attempt migration (Any information below is purely informational)

This is good – it indicates the item is currently in process and is likely to migrate soon (within a day or so).

Waiting for another item to be ready to migrate (no action required now - check later)

This is usually good if it’s recent, but if it’s more than a few days old, then there may be a deeper issue with a dependency. For items that are:

  • Recent: wait (a day or so)

  • Few days old: refer to the items listed under the Issues preventing migration: line to see what specifically has gone wrong, and then see the Issues preventing migration article for diagnostic tips.

BLOCKED: Cannot migrate due to another item, which is blocked (please check which dependencies are stuck)

The package itself is probably fine, but it’s blocked by an issue with some other package. Check beneath the Invalidated by dependency line to see what package(s) need attention.

BLOCKED: Maybe temporary, maybe blocked but Britney is missing information (check below)

This often occurs when one of the package’s dependencies is failing to build, which is indicated by a line stating missing build on <arch>. Once the dependency’s build failure is resolved, this package should migrate successfully. If it doesn’t migrate within a day or so, re-trigger the test.

Tip

In case of unreliable tests, hardware instabilities, and intermittent network issues, re-triggering a test run (by clicking the ♻ symbol) is often the only thing needed to achieve a Pass result. Before doing so, check the recent test-run history to see if someone else has already tried doing that. To view the recent test-run history for a specific architecture, click the respective name of the architecture.

All tests passing

Passing packages are usually not shown. When no test is marked Regression, it generally means that the test ran against an outdated version of the dependency. For example, you may see:

Example: All tests passing

  • python3-defaults (3.10.1-0ubuntu1 to 3.10.1-0ubuntu2)

    • Migration status for python3-defaults (3.10.1-0ubuntu1 to 3.10.1-0ubuntu2): BLOCKED: Rejected/violates migration policy/introduces a regression

    • Issues preventing migration:

    • …

    • autopkgtest for netplan.io/1.1.2-2ubuntu1: amd64: Pass, arm64: Pass, armhf: Pass, ppc64el: Pass, s390x: Pass.

    • …

In this case, use the rmadison tool to check versions of the package in the Ubuntu Archive:

$ rmadison netplan.io
 netplan.io | 1.1.2-2ubuntu1    | plucky          | source, amd64, arm64, ...
 netplan.io | 1.1.2-2ubuntu1.1  | plucky-updates  | source, amd64, arm64, ...
 netplan.io | 1.1.2-7ubuntu2    | questing        | source, amd64, arm64, ...

Note the test ran against version 1.1.2-2ubuntu1, but a newer version (1.1.2-7ubuntu2) is in the Archive. Look at the autopkgtest summary page for one of the architectures:

https://autopkgtest.ubuntu.com/packages/n/netplan.io/jammy/amd64

0.104-0ubuntu2

netplan.io/0.104-0ubuntu2

2022-03-10
11:38:36
UTC

1h 01m
59s

-

✔ pass

log

artifacts

[…]

0.104-0ubuntu1

python3-defaults/3.10.1-0ubuntu2

2022-03-08
04:26:47
UTC

0h 44m
47s

-

✔ pass

log

artifacts

Notice:

  • Version 0.104-0ubuntu1 was triggered against the python3-defaults version currently in -proposed (3.10.1-0ubuntu2).

  • But version 0.104-0ubuntu2 only ran against netplan.io itself, and thus ran against the old python3-defaults.

A test needs to run against both of these new versions (and against any other dependencies of the netplan.io package that are also in -proposed).