This page lists details about build failures that affect several packages (and the "good" way to solve them).

2023-01-14 GTK 4 test failures

GTK since 4.8.3 logs a warning if it cannot provide accessibility features via AT-SPI. By default, these warnings are not fatal on end-user systems, but they are usually fatal during unit testing, and can also cause autopkgtest failures.

If the package's unit tests benefit from a11y support, you should build-depend on at-spi2-core <!nocheck>, dbus-daemon <!nocheck> and wrap the tests with dbus-run-session -- , for example:

        dbus-run-session -- xvfb-run -a -s "-noreset" dh_auto_test

Or if the package's unit tests do not need a11y (often they do not), instead you can disable it with GTK_A11Y=none during unit testing, for example:

        GTK_A11Y=none xvfb-run -a -s "-noreset" dh_auto_test

If the package has autopkgtests, apply similar changes to the dependencies in debian/tests/control and the test script.

2022-04-13 perl.h regressions

The change applied in broke some uses of macros in expressions.

A possible fix might look like

See for additional information.

2020-12-26 MPI / ORTE / PMIX failures

It seems that many failures are caused by the recent upgrade of openmpi. See

2020-11-19 QPainterPath includes

Qt 5.15 requires explicit #include for QPainterPath. Symptom:

… QPainterPath path’ has incomplete type and cannot be defined
> 138 |     QPainterPath path;

Solution: add

#include <QtGui/QPainterPath>

(and forward that upstream if they don't already have it!)

Build failures caused by directory name

The buildd's version of sbuild, apt-get source, pbuilder all name the directory the package is unpacked in <sourcepackagename>-<upstream_version> but the version of sbuild that Lucas Nussbaum is using for his infrastructure of automated builds names them <sourcepackagename>-<complete_version>. Some packages unwisely rely on the directory name to extract version information for use in the rules. This very often causes files to be either misnamed or missing, which causes strange failures later (often in dpkg-shlibdeps).

A quick glance at debian/rules for such issues is generally a good idea when a build seems to work elsewhere but fails on Lucas's rebuild pool.

Theese issues are usually easy to fix once identified, for example one may replace

version=$(shell expr `pwd` : '.*-\([0-9.]*\)')
version_major=$(shell expr `pwd` : '.*-\([0-9]*\).[0-9.]*')


version:=$(shell dpkg-parsechangelog --show-field=Version | cut -d '-' -f 1)
version_major:=$(shell echo $(version) | cut -d '.' -f 1)

Network access

Network should not be considered available at build time. Difference of network availability can explain why a package builds fine on your computer but not on a buildd or during QA mass-rebuilds. At the bottom of some build logs, an iptables log is available to help you figure out if this was the cause of the build failure. However, the network accesses might have been caused by another package building concurrently on the same node, so use this information with care.