This page lists details about build failures that affect several packages (and the "good" way to solve them).
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;
(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 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.