Hello fellow developers, I went through the current failures of our autopkgtests on ppc64el [1]. A lot of them are due to running in a container with much fewer packages preinstalled than in our cloud-image VMs, i. e. they are missing test depends (and sometimes point out missing binary depends); I got two handfuls of those fixed in trusty already, but not yet all of them.
I categorized the current failures for packages which don't fail on x86. Tests that fail due to ppc64el specific issues ---------------------------------------------- apt-clone: tries to get indexes for ppc64el/saucy which don't exist pbuilder: tries to debootstrap from archive.u.c., needs ports.u.c. sbuild: tries to debootstrap from archive.u.c., needs ports.u.c. software-properties: additional test fails that succeeds on x86 ubuntu-release-upgrader: no fglrx package, need to make that test x86 only glib2.0: often hangs in monitor tests, but we had successes already upstart: test failures during package build Tests run, but some failures ---------------------------- The test failures which might be specific to ppc64el or due to running them in a container: adequate bowtie2: no error message at all bzr devscripts eglibc exim4 firestring floodlight gearmand ip4r mysql-5.5 nagios3: no error message at all in test "nagios3" neutron notify-osd: no error message at all nut: same test also often fails on x86, race condition openvswitch: no useful error message php5 postfix puppet ubuntu-drivers-common Tests that fail due to packages not (yet) existing for ppc64el -------------------------------------------------------------- asis aspcud bzr-git chromium-browser click-update-manager: missing Qt colord: missing valgrind dbus-test-runner fatrace: needs powertop which probably won't work on ppc64el, so should skip the test on non-x86 firefox friends fsharp git-annex ipython juju-core juju-deployer libacpi (should be an x86 only test) libaunit libfann libgmpada libgtkada libncursesada libtemplates-parser libtexttools libxmlada matplotlib mercurial mod-german mongodb node-marked nova ofono-phonesim opentoken pandas psqlodbc pyqt5 python-dbusmock python-memprof python-numpy roboptim-core rubygems-integration skimage system-image trac-bzr u1db ubuntu-purchase-service ubuntuone-credentials unity-firefox-extension unity-scope-click visp winff Tests that fail due to missing test/binary dependencies ------------------------------------------------------- It could of course be that after adding them they fail for different reasons. deja-dup lapack open-iscsi postgresql-pgmp pycparser pygments python-boto: looks like missing binary depends to p-requests? python-leveldb spamassassin varnish: package doesn't even install, looks like it's missing deps Tests that don't work in a container ------------------------------------ These can be dealt with by marking the tests as "don't work in a container". The plan for that is [2], the fix is [3], and I asked for this new autopkgtest feature in the FFE request [4]. apport bluez click-apparmor: EPERM to change /sys (disallowed in container), getpwnam() error crash: trying to access the network [5], and probably won't work in a container coreutils: two failures which are container specific (fails on x86 too); should fix/disable these two gvfs libnih: hangs eternally in test_file 78; some errors opening /proc/*/ns/, could be that it does not work in a container network-manager python2.7/3.3/3.4: I sent the fix to Matthias, he applied it in Debian; should work on next upload squid3: tries to access the network [5], apparmor test fails systemd systemd-shim udisks2 Fixing/testing -------------- I'll look into the "missing depends" and "don't work in a container" failures, but I can't single-handedly handle all the others. So if you care about ppc64el, please feel invited to fix tests yourself. I'm happy to assist with doing test runs of a .dsc from you on the ppc64el boxes after they run in LXC on x86 for you: First, create a suitable container: $ debcheckout autopkgtest $ sudo autopkgtest/tools/adt-build-lxc ubuntu trusty Sorry, the adt-build-lxc script is not yet packaged properly, but next version will do that as we use it in production now and it works well enough. Run the test on the version of the source package "mypkg" in trusty: $ autopkgtest/run-from-checkout mypkg --- lxc -es adt-trusty Run them with -proposed enabled: $ autopkgtest/run-from-checkout --apt-pocket=proposed -U mypkg --- lxc -es adt-trusty Run the test of a local .dsc: $ autopkgtest/run-from-checkout /path/to/mypkg.dsc --- lxc -es adt-trusty If you only changed the tests, not the package itself, you can run $ autopkgtest/run-from-checkout -B /path/to/mypkg.dsc --- lxc -es adt-trusty to avoid building the .dsc first. See man adt-run for details of the options. Thanks, Martin [1] https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest%20ppc64el/ [2] http://lists.alioth.debian.org/pipermail/autopkgtest-devel/2014-January/000565.html http://lists.alioth.debian.org/pipermail/autopkgtest-devel/2014-February/000586.html [3] http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=commitdiff;h=ff5809720 [4] https://launchpad.net/bugs/1285026 [5] I sent a ticket for IS to allow the test boxes to access our standard proxy, so that tests can at least reach *.ubuntu.com. -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
signature.asc
Description: Digital signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
