FTBFS on ppc64el, blocks updates of all packages depending on krb5, for example CUPS

Bug #1592841 reported by Till Kamppeter on 2016-06-15
This bug affects 2 people
Affects Status Importance Assigned to Milestone
krb5 (Ubuntu)

Bug Description

krb5 in Yakkety, version 1.14.2+dfsg-1 does not build on ppc64el and so it does not make it from -proposed into release. This blocks packages which depend on krb5, like CUPS, from getting from -proposed to release, preventing further development on the main platforms (amd64, i386, ...) due to the failure on this more exotic platform.

Other packages depending on krb5 and so suffering the same problem as CUPS are: libkdb5, openssh-server, dnsutils, cvs, libkadm5clnt-mit9, libkadm5srv-mit9, libdns162, unity-control-center, libdns100.

cjwatson on IRC, channel #ubuntu-release about this FTBFS and a possible fix:

I suspect it's due to -O3
 Looks like the sort of thing where the compiler does a bit more uninitialised-variable tracking at higher optimisation levels
 Would probably go away at -O2, or somebody could adjust the offending function to pacify the compiler; either way

Till Kamppeter (till-kamppeter) wrote :

I tried to replace the -O3 in the CFLAGS by -O2, by adding

DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)

ifeq ($(DEB_HOST_ARCH),ppc64el)

to debian/rules near the beginning, as it was done in the cowdancer package and built this in my PPA for testing and this did not solve the problem.

Sam Hartman (hartmans) wrote :

Looks simple; preparing fix

Changed in krb5 (Ubuntu):
assignee: nobody → Sam Hartman (hartmans)
Sam Hartman (hartmans) wrote :

Can I get you to try the attached debdiff and upload if it works (I am not an ubuntu developer). I don't have a ppc64el test environment. This should either work or get us much closer.

Changed in krb5 (Ubuntu):
assignee: Sam Hartman (hartmans) → nobody
Till Kamppeter (till-kamppeter) wrote :

Sam, your debdiff does not work this way. You have directly edited the upstream code instead of creating a patch in debian/patches/. Can you do a new debdiff with a proper patch for your change? Thanks.

O, sorry.
I knew that seemed simpler than it should have been:-)
Yeah, you could stick single-debian-patch in debian/source/options and
it would work, but I'll do it right.

Sam Hartman (hartmans) wrote :

I've replaced the debdiff with one that hopefully works. I'm sorry for spacing at the controls there. Perhaps yearning for a simpler time:-)

The attachment "krb5_1.14.2+dfsg-1ubuntu1.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

tags: added: patch

With your last debdiff I was able to generate a source package which I have uploaded to my PPA (ppc64el activated before) but it still does not build on ppc64el. Here is the build log:


Sam Hartman (hartmans) wrote :

Try this. I've fixed the new instance of the error as well. Incremented the version number so the patch has a different name, but you may not want to do that if you end up uploading

Sam Hartman (hartmans) wrote :

Fails also, but at a later point:


What you need to do is the following:

Build the package on the system which you have at hand (amd64, i386, ...), directing the build output into a file. Search through the output to see whther there are any compiler warnings and fix them all. With that done the package should build on ppc64el.

Or look into the buildlog for amd64 on Launchpad to find all the warnings.

Sam Hartman (hartmans) wrote :

>>>>> "Till" == Till Kamppeter <email address hidden> writes:

    Till> Build the package on the system which you have at hand (amd64,
    Till> i386, ...), directing the build output into a file. Search
    Till> through the output to see whther there are any compiler
    Till> warnings and fix them all. With that done the package should
    Till> build on ppc64el.

No, that won't work.
The issue is the ppc64el compiler is behaving differently than the amd64
The warning would be an error on any platform.
It's not an warning on amd64, nor is it a warning for ppc64el in debian.

I've spent the time I have here. On the Debian side I'd definitely take
a patch that added extra extranious initializations to pacify the
I recommend that approach to avoid a divergence between ubuntu and

Jeremy Bicha (jbicha) wrote :

Sam, if you wanted to test your patches on Ubuntu's ppc64el, you can use a PPA.

Just click the "Change details" link on your PPA and tell it to build packages for the ppc64el architecture too.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in krb5 (Ubuntu):
status: New → Confirmed
Steve Langasek (vorlon) wrote :

Turns out that last error was the final one breaking the build. Attached is the complete patch I've just uploaded to yakkety.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package krb5 - 1.14.2+dfsg-1ubuntu1

krb5 (1.14.2+dfsg-1ubuntu1) yakkety; urgency=medium

  * Fix uninitialized variable warning on ppc64el (LP: #1592841).
    Thanks to Sam Hartman for the preliminary patch.

 -- Steve Langasek <email address hidden> Wed, 16 Jun 2016 08:58:08 +0300

Changed in krb5 (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers