This page aims at explaining how to work on a FTBFS. There are some ppc64el specific pointers, but most of it is valid for other architectures.

Setup a chroot

Note: there are other ways to setup a build environment. The goal here is to present an easy, fast and widely accepted one (here, based on sbuild). This overview does not replace reading the Debian guides and wiki.

On the build machine, to create a new schroot, we'll make use of mk-sbuild tool. It will create a source schroot that will be used to instantiate temporary schroots. Each time you'll call sbuild, it will create a temporary schroot based on the source schroot and it will build the package in this temporary space. Once done, it will exit, removing the temporary schroot. The schroot will never be modified by this operation. It is persistent.

$ sudo apt install ubuntu-dev-tools
$ mk-sbuild --debootstrap-include=devscripts unstable

mk-sbuild should be run a 2nd time with your user being in sbuild group (either relogin or use newgrp)

$ exit

# login again

$ mk-sbuild --debootstrap-include=devscripts unstable

After that, you may uncomment source-root-groups=root,sbuild in /etc/schroot/chroot.d/unstable-ppc64el-sbuild if you want to be able to jump in your source schroot as root to customize it without any password.

$ sed -i 's/^#\(source-root-groups=.*\)/\1/' /etc/schroot/chroot.d/unstable-ppc64el

And then you can install your preferred tools in the source schroot once for all :

$ schroot -c source:unstable-ppc64el -u root
(unstable) # apt install vim quilt less
(unstable) # exit                           # saves your changes to the source schroot

The tool to use this schroot and to build automatically packages is sbuild :

$ sudo apt install sbuild

To work on FTBFS, it is important to have a schroot up to date and to prevent you from updating all your schroots manually or forget, we'll setup a crontab for this (to update, dist-upgrade, clean, autoclean, and autoremove) :

# cat <<EOF > /etc/cron.daily/update-schroots 
#!/bin/sh
sbuild-update -udcar $(schroot -l --all-source-chroots --exclude-aliases|sed 's/source://g')
EOF
# chmod +x /etc/cron.daily/update-schroots

Be careful, if the update happens while you are in a temporary schroot, it may break it because it changed the underlying source schroot.

Finding FTBFS

There are different places listing bugs:

Reproducing the build

As simple as :

$ sbuild --anything-failed-commands='%SBUILD_SHELL' -d unstable my_failing_package

we just specify :

We can also ask sbuild to do all the setup (temporary schroot, build dependency installation..) and to drop us to the shell before launching the build with the following :

$ sbuild --starting-build-commands='%SBUILD_SHELL' -d unstable my_failing_package

And we could do some preliminary steps and then run dpkg-buildpackage .

sbuild is also able to take into account DEB_BUILD_OPTIONS, which is useful to pass nostrip,debug,noopt or parallel=1 to help for debugging or exit as soon as an error occurs (see man dpkg-buildpackage)

Hack and fix

With the provided information here you just need to use dquilt alias to add a patch (for example for bug #999999), modify the source

(unstable)$ dquilt new fix99999.patch
(unstable)$ dquilt edit source_file   # make sure to follow the DEP3 Patch Tagging Guidelines https://anonscm.debian.org/viewvc/dep/web/deps/dep3.mdwn?view=markup
(unstable)$ dquilt refresh

One can also use dpkg-source --commit after having done some changes without using quilt directly : dpkg-buildpackage will notice the changes. But for further modifications of this patch, you will need dquilt.

Note : if you just want to modify the packaging itself, no patch is needed : just change the file in the debian/ directory . Then, we can just rebuild the package with dpkg-buildpackage -sa

Generate a fix to send to the maintainer

Once you've modified the source, you'll need to add a new debian/changelog entry :

(unstable)$ dch -l ~fix999999      # add a comment describing your change, and keep the version but with a new suffix related to the bug
(unstable)$ dpkg-buildpackage -sa  # create a new package with sources
(unstable)$ cd ..
(unstable)$ debdiff old.dsc new.dsc > fix999999.debdiff   # create a debdiff patch

Submit the fix

If no bug is already opened, you should open one by mail or with reportbug tool: check here.

Here is a template for submitting a new bug :

Date: Thu, 20 Sep 2018 18:00:09 +0200
From: Frédéric Bonnard <frediz@debian.org>
Subject: my_failing_package: FTBFS on ppc64el and maybe others
To: submit@bugs.debian.org

Package: src:my_failing_packag
Version: 1.2.3-4

--

Dear maintainer,
I saw that my_failing_package fails to build on ppc64el due to ... :

https://buildd.debian.org/status/fetch.php?pkg=my_failing_package&arch=ppc64el&ver=1.2.3-4&stamp=1535454641&raw=0

You may put here an extract with the error and some other details.

Thanks,

Regards.
F.

Once you've received an acknowledgment by mail with the bug id, you just need to send a mail properly formatted to 999999@bugs.debian.org (for example) with the debdiff attached. It can be good to provide other details : for example, to reference it as a ppc64el related issue, you can use a usertag :

$ bts user 'debian-powerpc@lists.debian.org' , usertags <bug-id> ppc64el

When adding a patch (this is recommended so that the above FTBFS on ppc64el page becomes aware of you having sent a patch)

$ bts tag <bug-id> + patch

Note : you may also submit the change with a Merge Request to the Debian's gitlab of the package if it exists and mention it in the bug report.