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

2024-03-13 -Werror=implicit-function-declaration

In dpkg version 1.22.6, the compiler flag -Werror=implicit-function-declaration was enabled by default for all architectures in build flags (in dpkg 1.22.5 it had been enabled conditionally on the abi time64 feature, so only on most 32-bit architectures). The reason for doing this is avoiding misbehavior of software affected by the ReleaseGoals/64bit-time transition. When using a function with a time_t argument with an implicit declaration, its type would be assumed to be int causing silent truncation, or no symbol redirection (to their _time64 counterparts) would take effect.

The most common causes for these diagnostics are:

These are typically upstream bugs and the patches should be forwarded upstream.

2023-09-28 tzdata-legacy split from tzdata

That change was introduced in tzdata 2023c-8 (https://tracker.debian.org/news/1451157/accepted-tzdata-2023c-8-source-into-unstable/) and partially reverted in 2023c-9 and 2023c-10:

   * Ship only timezones in tzdata that follow the current rules of geographical
     region (continent or ocean) and city name. Move all legacy timezone symlinks
     (that are upgraded during package update) to tzdata-legacy. This includes
     dropping the special handling for US/* timezones. (Closes: #1040997)

  * Move top-level UTC timezone back to tzdata (Closes: #1043250, LP: #2030684)

  * Partially revert 2023c-8: Move top-level timezones like UTC and CET back to
    tzdata. Only the old or merged timezones mentioned in the upstream backward
    file stay in tzdata-legacy (Closes: #1043250, LP: #2030684)

This breaks a number of build that relied on timezones now in tzdata-legacy. In most cases switching the timezones to use their current names is the correct solution (example for marshmallow: https://github.com/marshmallow-code/marshmallow/pull/2198). Otherwise add Build-depends on tzdata-legacy to get the legacy names back.

2023-07-26 Meson: "Can not run test applications in this cross environment" on mips64el

This is a Meson 1.2.0 regression (1041499). Workaround: https://salsa.debian.org/gnome-team/gjs/-/commit/0e64684a809fb2c3996bde8b92d61c4f4aa9b4e0

2023-07-26 Meson: Cannot find (any matches for) "usr/lib/python3*..."

With recent versions of Meson, some Python packages install to /usr/local (1041537). Workaround: export DEB_PYTHON_INSTALL_LAYOUT = deb in debian/rules.

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:

override_dh_auto_test:
        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:

override_dh_auto_test:
        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 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009149 broke some uses of macros in expressions.

A possible fix might look like https://salsa.debian.org/claws-mail-team/claws-mail/-/blob/master/debian/patches/20cope_with_fix_for_1009149.patch

See https://github.com/Perl/perl5/issues/18780 for additional information.

2020-12-26 MPI / ORTE / PMIX failures

It seems that many failures are caused by the recent upgrade of openmpi. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978022

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.

These 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.]*')

with

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.