Differences between revisions 14 and 15
Revision 14 as of 2013-01-17 23:53:04
Size: 7497
Editor: wookey
Comment:
Revision 15 as of 2013-06-02 14:28:33
Size: 7720
Editor: josch
Comment: adding usertags to bugs using bts
Deletions are marked like this. Additions are marked like this.
Line 142: Line 142:
Adding the tags to an existing bugreport using the bts command:

{{{
bts user multiarch-devel@lists.alioth.debian.org , usertags <bugnumber> multiarch
bts user crossbuild@debian.org , usertags <bugnumber> cross
}}}

Multiarch cross-dependency bugs

apt can now install cross build-dependencies - i.e the build-dependencies needed for cross-building, as well as the normal native build-dependencies

just do:

apt-get build-dep -a <arch> <package>

e.g

apt-get build-dep -a armel atk1.0

In order for this to work, packages must be correctly marked Multi-Arch: foreign or Multi-Arch: same (or occasionally Multi-Arch: allowed).

In simple terms any architecture-independent tool or package should be marked Multi-Arch: foreign. This is anything which is used in the build and will produce the same output whatever architecture version of it is run (debhelper, make, gettext, pkg-config).

Currently many packages do not have the Multi-Arch: foreign header so apt tries to install the DEB_HOST_ARCH version instead of the DEB_BUILD_ARCH one, and finds it can't because it can't install both the existing build architecture version and the host architecture version at the same time.

Generic apt fix

This bug describes an apt modification which means that Multi-Arch: foreign can be made implicit for Architecture: all packages in Build-deps: 666772

This saves adding the explicit header to many packages, but is not present as of apt 0.9.4 in Debian.

Typical error messages

This is the sort of thing you get on running apt-get build-dep -a

Cross-deps: Running apt-get -aarmel build-dep dash
Reading package lists...
Building dependency tree...
Reading state information...
The following packages have unmet dependencies:
 po-debconf : Depends: gettext (>= 0.16) but it is not going to be installed
              Depends: intltool-debian (>= 0.34.2+20060512) but it is not going to be installed
 sharutils:armel : Depends: libc6:armel (>= 2.4) but it is not going to be installed
                   Depends: libgcc1:armel (>= 1:4.4.0) but it is not going to be installed
E: Build-dependencies for dash could not be satisfied.
Failed to get cross build-deps

So in this case the package to look at is sharutils. This is probably arch-independent in its action in which case it should be marked 'Multi-Arch: foreign' at which point apt would try to install sharutils instead of sharutils:armel

You will see various forms of complaint from apt:

  • "E: Build-Depends dependency for dbus-glib cannot be satisfied because package gtk-doc-tools has no candidate version"

In this latter case gtk-doc-tools is probably the package that needs fixing.

  • gettext:armel : Depends: gettext-base:armel but it is not going to be installed

In this case gettext needs fixing first. gettext-base may also need fixing

When you have fixed one of these, often apt-get build-dep -a still fails as apt simply complains about the next package. It may take several iterations to get all the build-deps correctly annotated.

Sometimes things are more complicated than this and the package in question is not a direct build-dep but something one of the build-deps depends on (eg. -common data). You will need to modify the bugrep to make sense in these cases.

all vs any -dev packages

Sometimes the issue is transitive architecture dependencies.

Consider libdb-dev. This is a trivial package which simply selects which real version of libdb should currently be depended on by default. e.g. libdb4.8-dev. A package build-depending on libdb-dev wants the HOST_ARCH version of the real libdb4.8-dev. i.e libdb4.8-dev:armel if building for armel.

Until multiarch libdb-dev would be Architecture: all because there was nothing arch-specific about it. But now it needs to be Architecture: any so that that arch can be 'passed on' to get the correct arch of libdb4.8-dev.

i.e $package:armel ---build-depends---> libdb-dev:armel ---depends---> libdb4.8-dev:armel

This wouldn't work if libdb-dev was _all.

So sometimes the correct fix is to change the architecture of the package from 'all to 'any'.

When shouldn't I add M-A: foreign?

When the package is not arch-independent in its effects, i.e if you run the wrong-arch version it will operate on the wrong files or produce the wrong output. A common example is gobject-introspection. Whether something should be M-A: foreign does not depend on the architecture of the package itself (all, any), but on what it does.

Also there are packages where the dependency may be either same-arch or cross-arch. These are the cases that need to be marked M-A: allowed. There are very few of these. Ask on #multiarch on OFTC if you are unsure.

What to change

Simply add

Multi-Arch: foreign

to the control file.

By convention it goes after the various Depends/Replaces/Recommends headers and before the Description.

Here is a typical patch:

--- asciidoc-8.6.6/debian/control       2012-03-06 19:14:19.000000000 +0000
+++ asciidoc-8.6.6.new/debian/control   2012-03-05 18:07:24.000000000 +0000
@@ -14,6 +14,7 @@
 Depends: python (>= 2.4), ${misc:Depends}, ${python:Depends}
 Recommends: docbook-utils, xmlto, dblatex, libxml2-utils
 Suggests: vim-addon-manager, source-highlight
+Multi-Arch: foreign
 Description: Highly configurable text format for writing documentation
  AsciiDoc is a text document format for writing articles, books, manuals and
  UNIX man pages. AsciiDoc files can be translated to HTML (with or without

Bug Report Template

Title: Add multiarch metadata to $package

Description/Body text:

We are working on getting multiarch metadata correct throught the archive. This package needs to be marked 'Multi-Arch: foreign' for dependencies and build-depencies to work correctly in all cases.

Any package 'X' build-depending on $package cannot be cross-built because apt-get build-dep -a<arch> cannot satisfy X's build-dependencies until

Multi-Arch: foreign

is added to $packages's control file, to indicate that $package from any available arch will satisfy the dependency.

See http://wiki.debian.org/Multiarch/CrossDependencies and 'Dependencies involving Architecture: all packages' in the Multiarch Spec for further explanation.

Optional extra info to indicate how much a blocker this particular bug is: There are n packages which build-depend on $package in the archive. None of them will be multiarch cross-buildable without this fix.


The bug should be tagged multiarch and cross. In debian that means adding user=multiarch-devel@lists.alioth.debian.org, tag=multiarch user=crossbuild@debian.org, tag=cross

Adding the tags to an existing bugreport using the bts command:

bts user multiarch-devel@lists.alioth.debian.org , usertags <bugnumber> multiarch
bts user crossbuild@debian.org , usertags <bugnumber> cross

Details on how to do it: http://wiki.debian.org/bugs.debian.org/usertags

In Ubuntu that means adding the tags 'multiarch' and 'cross' in launchpad

Debian and Ubuntu differences

Currently apt in Ubuntu and apt in Debian have slightly different apt-get build-dep -a behaviour. You are more likely to see these issues in Ubuntu currently (March 2012), but this is a temporary state of affairs - the required metadata rules are exactly the same in all Debian-based distros.

Testing number of packages affected by this build-dep

This is how to get the 'n' for "There are n packages which build-depend on $package in the archive".

 grep-dctrl -s Package -F Build-depends,Build-depends-indep $package /var/lib/apt/lists/*Sources

(grep-dctrl is from the dctrl-tools package)