Hey Antonio, Antonio Terceiro [2014-05-28 19:36 -0300]: > I am setting severity to important because leaving 2GB behind at every > test run is pretty nasty on automation systems.
Argh, indeed. Agreed! > admin@ip-172-31-36-237:/var/lib/debci/tmp$ time sudo adt-run -u debci > --gnupg-home=/usr/share/debci/gnupg -o libreoffice libreoffice --- schroot > debci-unstable-amd64 I ran that command on that very box, and it didn't fail on copying the tests tree, so I can't reproduce that particular error. :( Instead my run failed much later with adt-run: testbed failed: sent `copydown libreoffice/apt0-tests-tree/ /tmp/adt-run.Fx9J46/apt0-build/libreoffice-4.2.4/', got `timeout', expected `ok...' and libreoffice/ does not have a tests-tree, it got cleaned up properly. So let's see what we can pry out of that log. > dpkg-source: warning: diff > `libreoffice-4.2.4/debian/patches/i18npool-icu53.diff' patches file > libreoffice-4.2.4/i18npool/source/collator/collator_unicode.cxx twice FTR, these are cosmetical and don't break the unpack. > adt-run: testing package libreoffice version 1:4.2.4-3 > adt-run: * <apt:apt0> build not needed Getting here means the unpacking in the testbed was successful. > admin@ip-172-31-36-237:/var/lib/debci/tmp$ echo $? > 16 This means that adt-run or the testbed exit()ed by itself through bomb(), and it wasn't terminated by a signal. So the atexit handlers should run. What's really strange is that there is no error message at all. Every bomb() has an error message which should be visible on stderr. Your log definitively has stderr, maybe something got cut off somehow? Do you still happen to have this in scrollback? > admin@ip-172-31-36-237:/var/lib/debci/tmp$ du -shc libreoffice/* > 1.9G libreoffice/apt0-tests-tree In my current run the complete copied up tests-tree is 2.7 GB. Thus I conclude that the act.tests_tree.copyup() failed somehow (I don't know why, that'd require the error message). However, I do see one error in the code: act.tests_tree = TestbedPath(...) act.tests_tree.copyup() atexit.register(rmtree, 'tests-tree', act.tests_tree.host) That means the cleanup handler is only registered after a successful copyup(), and that's what failed. So I need to register it earlier. That will fix the leftover test-tree in the result dir, but of course it won't fix the cause why the copyup failed. Are you ok with leaving this bug for the cleanup failure? If you can reproduce the copyup failure, can you watch out for an error message? Thanks, Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
signature.asc
Description: Digital signature