i386

Partial-port

i386 is a partial-port of Ubuntu, which is supported as a multi-arch supplementary architecture.

No boot support

There is no kernel, installers, bootloaders for i386, thus it cannot be booted as pure i386.

Self-hosted, natively built

All package building is self-hosting, and is built in a i386 chroot on an amd64 host.

Allowlist

Launchpad has a whitelist of packages that build for i386, which are based on a seed. This was scoped through the community process. The full set of built i386 packages also consists of their build and runtime dependencies.

If in doubt it is helpful to inspect the germinate output for i386 on mantic or on jammy.

The why column there explains if it comes directly from the i386 whitelist I386.$series i386 seed or indirectly due to a dependency from another package.

Modifying Dependencies

The whitelist won't be auto-updated, so if - for example - one worked on dropping a dependency and is confirmed by germinate output for i386 he will then need to call to the Archive Admins to update the White list.

This update of the whitelist needs to be done before a sync/rebuild of the package formerly depended on is done. If this was missed, after updating the whitelist the i386 build record can be created using a copy-package -b --force-same-destination -e $version $pkg command. In rare cases, this command will fail if this exact package version was previously built on powerpc; in that case, a no-change rebuild will achieve the same.

In addition after that, the old binaries need to be removed. Otherwise e.g. proposed migration will block the new package on "missing build on i386". The Archive Admins usually do this as part of the regular cleanup, but if nothing happens or you want to push on the case one can call to remove it via a removal bug.

How to transition src:foo1 to src:foo2

  • Sometimes as part of an ABI transition src:foo(N+1) needs to be build on i386 to eventually replace src:fooN, for example boost1.71, gcc-11, etc. When such a need arises, one should:

  • ask Archive Admin to add a new versioned abi-source package to newSet in update-i386-whitelist script in ubuntu-archive-tools

  • ask Archive Admin to run it to update laucnhpad's whitelist
  • Then one can upload/sync/no-change rebuild 1src:foo(N+1)` and it will be built for i386.

ProposedMigration requested i386 test result, which does not exist

Sometimes, britney requests test results for i386, despite a source package not building for i386 at all. In such a case please contact Ubuntu Release Team to update the britney hint to badtest the i386 result. These usually clear on subsequent uploads, and thus only happen once per source package.

How to expand i386 port scope

If you genuinely need to increase the scope of the i386 port (i.e. 3rd party app now needs this i386 library), then community process must be used to nominate and get a library added to the i386 seed as the supported target package. Post to https://discourse.ubuntu.com/t/community-process-for-32-bit-compatibility/12598.

Alternatively open bug reports in https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta asking for i386: seed inclusion.

Run local VM based autopkgtest for i386

While the following was fine in the past, with Focal that won't work: 

$ sudo autopkgtest-buildvm-ubuntu-cloud -a i386 -r focal -s 15G
Downloading https://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-i386.img...
No image exists for this release/architecture

First of all, you need a autopkgtest capable of cross arch testing, which is not yet merged in Debian (20210716). (see https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/69) but exists as an Ubuntu delta since lunar.

If you're on focal or jammy you definitely need to clone git and run it from there. 

$ git clone git+ssh://git.launchpad.net/~ubuntu-release/autopkgtest/+git/development

[In our example below that is in ~/work/autopkgtest/autopkgtest]. Do NOT run it from a location installed by "make install", just run it from the checkout location.

Since with Focal you only have amd64 images - to run it you have to add the architecture

  • --architecture i386

And setup the environment before the testing starts

  • --setup-commands="dpkg --add-architecture i386; apt-get update"

Overall that will look like: 

$ sudo autopkgtest-buildvm-ubuntu-cloud -a amd64 -r focal -s 15G
$ sudo ~/work/autopkgtest/autopkgtest/runner/autopkgtest \
  --setup-commands="dpkg --add-architecture i386; apt-get update" --architecture i386 <YOUR.dsc>\
  -- qemu --ram-size=1536 --cpus 2 ~/work/autopkgtest-focal-amd64.img

Test for i386 dependency issues

A common case to need this is e.g. if you have an autopkgtest with an error like: 

   php7.4-common:i386 : Depends: php-common:i386 (>= 1:73) but it is not installable
   php7.4-json:i386 : Depends: php-common:i386 (>= 1:73) but it is not installable
   php7.4-opcache:i386 : Depends: php-common:i386 (>= 1:73) but it is not installable
   php7.4-readline:i386 : Depends: php-common:i386 (>= 1:73) but it is not installable

Then quite often it is secondary or even deeper dependencies that (now on i386) fail. The tests are in x86_64 environments with i386 as arch added, you can easily get that with lxd and dpkg. 

$ lxc launch ubuntu-daily:h h-i386
$ lxc exec h-i386 bash
root@h-i386:~# dpkg --add-architecture i386; apt-get update
# There you can re-create the error of the test by installing its dependencies:
root@h-i386:~# apt install php7.4-common:i386 php7.4-json:i386 php7.4-opcache:i386 php7.4-readline:i386

From there feel free to debug as needed.

P.S. quite often this debugging leads into the Multi-Arch definitions of the involved packages.

Cross Test for i386

Autopkgtests for i386 on Ubuntu run in an amd64 environment with i386 added via dpkg --add-architecture i386. While that gives working environments sometimes the defaults do not work as expected by test scripts. That provides a common error-pattern which gladly also has a common pattern for a fix.

pkg-config

If run just as pkg-config it will return the data for amd64 which either isn't installed (the test installed i386 deps) or amd64 data for pkg-config is installed does not work for i386. We need to ensure pkg-config is called with the right prefix. 

+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+    CROSS_COMPILE_PREFIX="$DEB_HOST_GNU_TYPE-"
+else
+    CROSS_COMPILE_PREFIX=
+fi
-LDFLAGS="$(pkg-config --libs libftdi1) -lboost_unit_test_framework"
+LDFLAGS="$(${CROSS_COMPILE_PREFIX}pkg-config --libs libftdi1) -lboost_unit_test_framework"

Example https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974171 submitting this to Debian.

calling the compiler

Simular to pkg-config you'll want the i386 compiler in those cases. Note: I say i386, but the same would e.g. apply for armhf on arm64 just as much. 

+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+    CROSS_COMPILE_CPP="${CROSS_COMPILE_PREFIX}g++"
+else
+    CROSS_COMPILE_CPP="c++"
+fi
-c++ $CFLAGS -o $WORKDIR/basic.o -c test/basic.cpp
+${CROSS_COMPILE_CPP} $CFLAGS -o $WORKDIR/basic.o -c test/basic.cpp

Example https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946577 submitting this to Debian.

CMake

CMake projects (as alternative to pkg-config) need the same prefix treatment, but in CMake syntax.

The following example prepends things in a CMakeList file that is later processed. Other cases created an https://cmake.org/cmake/help/latest/variable/CMAKE_TOOLCHAIN_FILE.html to then be included. 

+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+    cat <<EOF > "$WORKDIR/toolchain.cmake"
+set(CMAKE_C_COMPILER $DEB_HOST_GNU_TYPE-gcc)
+set(CMAKE_CXX_COMPILER $DEB_HOST_GNU_TYPE-g++)
+set(CMAKE_PREFIX_PATH "/usr/lib/${DEB_HOST_MULTIARCH}/cmake/libftdi1")
+set(PKG_CONFIG_EXECUTABLE $DEB_HOST_GNU_TYPE-pkg-config)
+EOF
+    CCFILE=-DCMAKE_TOOLCHAIN_FILE="$WORKDIR/toolchain.cmake"
+else
+    CCFILE=
+fi

Note: Not all cases need all the statements added in the example above, please test and only add the minimum amount of changes.

Warning: This section is WIP, as e.g. in some cases find_package seems to needs further tweaks to work

Example https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946496 submitting this to Debian.

i386 (last edited 2024-02-17 14:01:38 by tsimonq2)