Differences between revisions 64 and 65
Revision 64 as of 2020-11-19 10:09:13
Size: 17236
Editor: ?StuartPrescott
Comment: Add fix for QPainterPath FTBFS errors
Revision 65 as of 2020-12-26 22:15:06
Size: 2170
Comment:
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:

== 2020-12-26 MPI / ORTE / PMIX failures ==

It seems that many failures are caused by the recent upgrade of pmix. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978066
Line 16: Line 20:

== 2017-01-29 tzdata and lsb-base no longer installed in build chroots ==

tzdata and lsb-base are no longer (transitively) build-essential. Packages that require them to build must explicitely build-depend on them.

== 2014-01-21 using dh-autoreconf during the build ==

The easiest way is a dependency on {{{dh-autoreconf}}} and using that during the package build. If the package is already using the {{{autools-dev}}} package, make sure that the {{{config.guess}}} and {{{config.sub}}} files are also updated by {{{dh-autoreconf}}}; for very few cases you need to use both tools (see [[DebianBug:698765]]).

To check that the libtool change was picked up, grep the regenerated files for the {{{powerpc64le}}} string. To check that the {{{config.*}}} changes were picked up, grep for the {{{aarch64-linux-gnu}}} string.

For new debhelper based packages:

{{{
%:
        dh $@ --with autoreconf
}}}

For old debhelper based packages

{{{
configure-stamp:
        dh_autoreconf
        ./configure ...

clean:
        dh_autoreconf_clean
        dh_clean
}}}

For cdbs based packages:

{{{
include /usr/share/cdbs/1/rules/autoreconf.mk
}}}

If the package isn't ready to use the recent autotools versions, then you can force dh-autoreconf to use older ones:

{{{
export AUTOMAKE = automake-1.11
export ACLOCAL = aclocal-1.11
}}}

If the regeneration is failing with missing autoconf macros, search the archive for the macros (mostly provided in {{{/usr/share/aclocal}}}), and build-depend on these packages.

If the regeneration is still failing, talk to the upstream to update to newer autotools and backport the patches.

If anything else fails, patch the generated files directly (should be avoided). This includes the {{{config.guess}}} and {{{config.sub}}} files, and the {{{libtool.m4}}} and {{{aclocal.m4}}} files and depending configure files.

[[http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=autoreconf;users=debian-devel@lists.debian.org|Bug reports]] to introduce {{{dh-autoreconf}}} during the build are tracked with usertags

{{{
User: debian-devel@lists.debian.org
Usertags: autoreconf
}}}

For more information, check the [[Autoreconf|Debian autoreconf page]]

== 2013-11-23 FTBFS: QT4_CREATE_MOC_COMMAND Macro invoked with incorrect arguments for macro ==
The number of arguments in QT4_CREATE_MOC_COMMAND seems to have changed: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9ce60ff509c4ff27fe861fc5b2080f50897a68c4

{{{
Suggested solution (not sure if this is the "good" way to solve this, please correct it if you have a deeper insight):
- QT4_CREATE_MOC_COMMAND(${infile} ${outfile} "${moc_flags}" "${moc_options}")
+ QT4_CREATE_MOC_COMMAND(${infile} ${outfile} "${moc_flags}" "${moc_options}" "${moc_target}")
}}}


== 2013-10-27 checking whether the Boost::Foo library is available... yes configure: error: Could not link against ! ==

Boost is now multiarched, and it's libraries are in standard multiarch locations. Unfortunately autoconf archive based m4 macros for boost detection fail by default thus the following option needs to be passed to the configure scripts

{{{
include /usr/share/dpkg/default.mk
dh_auto_configure -- --with-boost-libdir=/usr/lib/$(DEB_HOST_MULTIARCH)
}}}

== 2013-09-28 fatal error: modplug.h: No such file or directory ==

A recent change to libmodplug removed the -Ilibmodplug that was configured for package using pkg-config to setup the build environement. You will have to replace occurence of:

   #include <modplug.h>

by

   #include <libmodplug/modplug>

== 2013-07-27 ld: undefined reference to symbol 'xyz@@GLIBC_2.2.5' ==

If your package fails to build from source with the ld: undefined reference to symbol error, it usually indicates that libraries that are needed to build the package are not linked in.

 1. Add the library in your configure scripts to LIBS, not LDFLAGS.
 2. Forward the patch upstream.
 2. Do not use DEB_LDFLAGS_MAINT_APPEND to add the missing library in debian/rules. This works in Debian if you pass e.g. -lm before -Wl, --as-needed but will fail in derivatives like Ubuntu when --as-needed is already called as the standard implementation.

See also [[ToolChain/DSOLinking#Only_link_with_needed_libraries]].

and the autoconf manual (LDFLAGS and LIBS)

https://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/Preset-Output-Variables.html



== 2013-06-09 makeinfo/texinfo complains about @sp missing argument ==

Starting with texinfo 5.0 some incompatible changes wrt 4.13 and below have been introduced. Notably the above warning has turned into an error in 5.0 and above.

As the documentation of texinfo states, after @sp must follow the number of blank lines.

A way to fix this is:
{{{
-@sp
+@sp 1
}}}

== 2013-06-01 error: incompatible types when assigning to type '__pyx_t_6cube_c_Vector' from type 'float *' ==

Newer gcc complains about missing type cast. The "`__pyx_`" prefix indicates that the code is generated by Cython from a '.py' or a '.pyx' file.
Type cast is done like this:
{{{
v0 = cython.cast(cython.p_float, get_faces(i)[face].normal) # .py files
v0 = <float*>get_faces(i)[face].normal # .pyx files
}}}

== 2013-06-31 boost::TIME_UTC: error: expected unqualified-id before numeric constant ==

TIME_UTC is a C11 macro that colides with boost::TIME_UTC. In Boost 1.50, this constant was renamed to TIME_UTC_. To fix it use the new symbol name:

{{{
-boost::xtime_get(&wakeup_time, boost::TIME_UTC);
+boost::xtime_get(&wakeup_time, boost::TIME_UTC_);
}}}

== 2013-05-31 makeinfo/texinfo complains about @itemx which does not follow @item ==

Starting with texinfo 5.0 some incompatible changes wrt 4.13 and below have been introduced. Notably the
above warning has turned into an error in 5.0 and above.

As the documentation of texinfo (info texinfo, chapter 11.4.3) states:
Use '@item' for the first entry, and '@itemx' for all subsequent
entries; '@itemx' must always follow an '@item' command, with no blank
line intervening.

That means the simples way to fix this is to convert the first occurence of an itemx into item. Typical patch from the lilypond package:
{{{
@@ -1001,20 +1001,20 @@
 ...
 @end example

-@itemx --skip-lily-check
+@item --skip-lily-check
 Do not fail if no lilypond output is found. It is used for LilyPond
 Info documentation without images.

-@itemx --skip-png-check
+@item --skip-png-check
 Do not fail if no PNG images are found for EPS files. It is used for
 LilyPond Info documentation without images.
...
}}}

== 2013-02-26 glib2.0: error: 'g_type_init' is deprecated (declared at /usr/include/glib-2.0/gobject/gtype.h:669) ==

Starting with 2.35, glib2.0 deprecated the g_type_init function. You don't need to call it at all. If you're building with -Werror=deprecated-declarations then you'll get a build failure if you do call it. You can either remove the call completely if you don't care about building on olrder glib versions or, if you do, do something like [[https://mail.gnome.org/archives/commits-list/2012-November/msg07809.html|this upstream commit]] (several other examples available if you search):

{{{
#if !GLIB_CHECK_VERSION(2,35,0)
g_type_init()
#endif
}}}

== 2012-03-22 dh_usrlocal: sed: -e expression #1, char 20: extra characters after command ==

Introduced by debhelper 9.20120311 (assumed to be the fix for #660794). Niko agrees and has reassigned #665263 to debhelper. Fixed in 9.20120322

== 2011-09-23 dpkg-source complains about unexpected upstream changes ==

This is due to [[http://lists.debian.org/debian-devel-announce/2011/09/msg00001.html|changes introduced by dpkg 1.16.1]], in particular: "dpkg-source -b” on a “2.0” or “3.0 (quilt)” source package will fail if it detects upstream changes which are not managed by a quilt patch."

Many of the failures with dpkg 1.16.1 will no longer happen with dpkg 1.16.1.1 ([[http://anonscm.debian.org/gitweb/?p=dpkg/dpkg.git;a=commitdiff;h=669e0ff496e6870c06de82da111ba069263a0456|bugfix here]]), but the presence of a debian/patches/debian-changes-&lt;ver&gt; file is still a sign of a problem in your workflow. Usually it means that the clean rule does not bring the build directory to its initial state and that some cruft is left-over. If that's the case you should fix this (and delete the automatic patch).

If the automatic patch contains desired changes, then you should really rename it and document it properly with a [[http://dep.debian.net/deps/dep3/|DEP-3]] header. If it contains desired changes that are not managed with quilt but with your VCS, then you should put "single-debian-patch" in debian/source/local-options.

== 2011-05-04 Libtool complains about file not found on += assignment ==

This is a bashism, the problem stems from an out-of-sync setting for the SHELL variable. The libtool script in the build directory is generated at build time by configure, and it will use bashisms if the shell detected is bash, but then the Makefiles might be calling the script explicitly with /bin/sh. The solution is to search for SHELL variables in Makefile.in and assign to them @SHELL@.

== 2011-05-02 Packages failing with GCC 4.6 ==

With g++ 4.6, the type size_t is no longer defined by including things like STL. The correct fix is to explicitly include either <stddef.h> (for ::size_t) or <cstddef> (for std::size_t).

== 2009-11-18 Packages failing on hurd-i386 ==

Two lists of porting guidelines are available on http://www.debian.org/ports/hurd/hurd-devel-debian and http://www.gnu.org/software/hurd/hurd/porting/guidelines.html . A porter box is available as strauss.debian.net

== 2009-11-02 Packages failing because binutils-gold/indirect linking ==

Some packages fail to build with binutils-gold due to ''undefined reference''. This is in most cases the problem that your executable links against a library ''A'' which links against library ''B'', but your executable needs symbols in library ''B''. This is problematic in the situation where library ''A'' removes its dependency to library ''B''. The next time the executable gets rebuild it will break and cannot be linked.

This doesn't affect the created executable as it will still have entries in DT_NEEDED for both library ''A'' and library ''B'' in the case of an successful build. It isn't known which will be the preferred linker in the future or if the behavior will be changed in GNU ld or GNU gold. As the debian buildd's still use the original GNU ld the bugs aren't release critical and it is sufficient to inform upstream.

All packages can be fixed by adding the needed library which provides the symbols to the linker call. In some cases the pkg-config file of library ''A'' could be broken as it requires library ''B'' for the build. This could be the case if the executable doesn't use library ''B'' directly in its source code, but library ''A'' inserts the symbols of library ''B'' using defines or other similar mechanisms inside their header files to executable, but hasn't the correct Requires statement inside the .pc file of library ''B''.

A common problem seems to be calls to XOpenDisplay without directly linking to -lX11, but to a library like Xtst. Similar is to use glib2.0, but only linking to gtk2.0: using libm, but not linking to it; libqt*, but only linking to kdecore. Another interesting problem is that some program links its C++ object files using gcc instead of g++, but the g++ symbols get resolved by another C++ library they link to.

This problem can be seen when either giving parameter --no-add-needed to the linker (-Wl,--no-add-needed when linking either through gcc or g++) or installing binutils-gold_2.20-1.

A discussion about that issue can be found at http://lists.debian.org/debian-devel/2009/11/msg00099.html

== 2008-05-25 ld: cannot find -ldts ==

This happens compiling multimedia packages with gcc 4.3. To avoid it, add libdts-dev to the Build-Depends in debian/control. This package contains the headers and static libraries used to build applications that use libdts (-ldts).

== 2008-04-13 Failures with dpkg-dev 1.14.18 ==

dpkg now sets default values for CFLAGS, CPPFLAGS, etc (see dpkg-buildpackage(1)). This can break some build scripts that don't deal with those variables nicely.

== 2008-01-03 Failures with dash as /bin/sh ==

Ubuntu has been using dash as /bin/sh since Ubuntu edgy (released in october 2006). There's a nice page at UbuntuWiki:DashAsBinSh giving some advice.

== 2007-12-01 Package failing with dpkg-shlibdeps "failure: something" messages ==

Check the dpkg-shlibdeps man page in dpkg-dev 1.14.12, it contains explanations of those new failures and suggestion on how to fix them.

== 2007-09-29 Packages failing to build with GTK+ 2.12 (symbol errors on GTK_TOOLTIPS, gtk_widget_unref and more) ==

GTK+ 2.12 deprecated a bunch of API and packages that define GTK_DISABLE_DEPRECATED now fail to build. Easy solution is to remove GTK_DISABLE_DEPRECATED from CFLAGS; better solution is to port to newer API (upstream may already have done it).

 * gtk_widget_ref → g_object_ref
 * gtk_widget_unref → g_object_unref
 * GtkTooltips → GtkTooltip

== 2007-09-17 Packages failing to build cause of "called object 'major' is not a function" ==

nfs-utils fixed it this way (#442122, from 09-define-major-minor.patch):
{{{
#ifndef major
# define major(dev) gnu_dev_major (dev)
#endif
#ifndef minor
# define minor(dev) gnu_dev_minor (dev)
#endif
[..]
}}}

== 2007-09-14 Packages failing to build with ecj-gcj due to missing java.lang.object ==

 * DebianBug:441660 tex4ht: FTBFS: The type java.lang.Object cannot be resolved

Somewhere between 3.3.0+0728-1 and 3.3.0+0728-4 "ecj" dropped its dependency on gij which was used to build it.
Packages should build fine with 3.3.0+0728-5 upwards. -- KapilHariParanjape

== 2007-09-12 Packages failing due to undetected libdb ==

 * DebianBug:441763 (libdb4.2): “libdb-4.2.so must link against libpthread”
 * DebianBug:441870 (libdb4.3-dev): “libdb.so must link against libpthread”.

Please block those FTBFSes with the appropriate libdb bug. -- CyrilBrulebois

== 2007-08-28 Packages failing because of missing camlp4o ==

Quite some packages fail because camlp4 has been moved from ocaml-nox's Build-Depends to
Recommends. The Ocaml team has tightened their Build-Depends and wants the Packages
B-D on caml4p directly:

09:35 <abi> as of the recent rebuild sid/x86 about ~10 packages FTBFS because of missing camlp4o, do the packages have to Build-Depend on camlp4 or would it make more sense to move it from the Recommends to Depends in ocaml-nox

09:35 <abi> i just wonder if i should file the bug for the packages or ocaml-nox

09:36 <smimou> well I think that we should tighten our build-deps instead

09:37 <smimou> we have already started doing this

09:37 <abi> ok, so im going to file the bugs against the packages rather than ocaml-nox?

09:37 <smimou> yes, please

09:38 <smimou> camlp4 is quite a big package so I'd rather avoid ocaml depending on it

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 pmix. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978066

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 unpackad in <sourcepackagename>-<upstream version> but the version of sbuild lucas uses 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 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.]*')

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.