Differences between revisions 2 and 3
Revision 2 as of 2012-03-23 02:43:44
Size: 5704
Editor: wookey
Comment:
Revision 3 as of 2012-03-23 15:12:19
Size: 6112
Editor: wookey
Comment: Add info on tags
Deletions are marked like this. Additions are marked like this.
Line 98: Line 98:
= Template Bug Report = = Bug Report Template =

Title: Add multiarch metadata to $package


Description/Body text:
Line 117: Line 122:
-----
Line 118: Line 124:
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

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

Multiarch cross-dependency bugs

apt can now install cross build-dependencies - i.e the build-dependecnies 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 occaisionally Multi-Arch: allowed).

In simple terms any arch-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 arch version of it is run.

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

Typical error meesages

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-indepent in its action in whcih 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 siply 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.

<more info here on analysis process>

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

When the package is not arch-independent, i.e if you run the wrong-arch version it will operate on the wrong files or procude the wrong output. A common example is gobject-introspection.

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:

--- xfonts-encodings-1.0.4/debian/control       2012-03-16 15:22:32.000000000 +0000
+++ xfonts-encodings-1.0.4.orig/debian/control  2012-03-16 15:24:08.000000000 +0000
@@ -1,8 +1,7 @@
 Source: xfonts-encodings
 Section: x11
 Priority: optional
-Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
-XSBC-Original-Maintainer: Debian X Strike Force <debian-x@lists.debian.org>
+Maintainer: Debian X Strike Force <debian-x@lists.debian.org>
 Uploaders: David Nusinow <dnusinow@debian.org>, Cyril Brulebois <kibi@debian.org>
 Build-Depends:
  debhelper (>= 5.0.0),
@@ -20,6 +19,5 @@
 Architecture: all
 Depends: ${shlibs:Depends}, ${misc:Depends}, x11-common
 Replaces: xfonts-base (<< 1:1.0.0)
-Multi-Arch: foreign
 Description: Encodings for X.Org fonts
  This package contains the encodings that map to specific characters.

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.

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

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-aptavail -s Package -F Build-depends,Build-depends-indep $package /var/lib/apt/lists*Sources