Comment 8 for bug 1648520

--- snapd-2.17.1ubuntu1/debian/tests/integrationtests 2016-11-04 16:40:03.000000000 +0000
+++ snapd-2.20ubuntu1/debian/tests/integrationtests 2016-12-15 21:07:08.000000000 +0000
@@ -2,6 +2,14 @@

 set -ex

+if [ "$(dpkg --print-architecture)" = "ppc64el" ]; then
+ echo "Tests on ppc64el disabled for now because autopkgtest thinks they "
+ echo "worked at some point but they did not and noone can override this "
+ echo "in the autopkgtest database apparently so autopkgtest keeps "
+ echo "blocking snapd because it assumes there is a regression."
+ exit 0
+fi
+
 # for these tests, run snap and snapd from outside of the core snap
 mkdir -p /etc/systemd/system/snapd.service.d/
 cat <<EOF | tee /etc/systemd/system/snapd.service.d/no-reexec.conf

That is incorrect. We *can* override this. We do not do so, because ppc64el is a supported server architecture, and snapd is part of our server product, and snapd should not get a blanket exception for test regressions on this architecture.

We will provide exceptions for snapd/ppc64el, upon review, to ensure that the failing tests are not regressions.

But the above change, which disables the autopkgtests on ppc64el altogether and means we get no test results at all, is a non-starter for an SRU, and I am rejecting these packages.

The correct solution here is for the snapd package to be fixed to test the correct things on ppc64el, so that the autopkgtests actually /run and pass/.

In the meantime, I can reupload with this change reverted.