This ordering is interesting (from a good case): $ grep -e 'autopkgtest .*\[.*\]: test .*:' -e get_netfilter_capabilities old-iptables-good.txt test_get_netfilter_capabilities (tests.unit.test_util.UtilTestCase) Test get_netfilter_capabilities() ... ok test_get_netfilter_capabilities (tests.unit.test_util.UtilTestCase) Test get_netfilter_capabilities() ... ok autopkgtest [20:42:36]: test test-ufw.py: preparing testbed autopkgtest [20:44:18]: test test-ufw.py: [----------------------- autopkgtest [20:44:22]: test test-ufw.py: -----------------------] autopkgtest [20:44:22]: test test-ufw.py: - - - - - - - - - - results - - - - - - - - - - autopkgtest [20:44:22]: test root-unittest: preparing testbed autopkgtest [20:46:24]: test root-unittest: [----------------------- autopkgtest [20:52:16]: test root-unittest: -----------------------] autopkgtest [20:52:16]: test root-unittest: - - - - - - - - - - results - - - - - - - - - - autopkgtest [20:52:16]: test unittest: preparing testbed autopkgtest [20:52:24]: test unittest: [----------------------- test_get_netfilter_capabilities (tests.unit.test_util.UtilTestCase) Test get_netfilter_capabilities() ... ok autopkgtest [20:59:10]: test unittest: -----------------------] autopkgtest [20:59:11]: test unittest: - - - - - - - - - - results - - - - - - - - - -
That means at least the first two of the times the test runs seems to be from the build as two of the autopkgtest entries come with "build-needed". That is interesting as: 1. the new ufw's actual build was obviously against proposed and there things worked fine You can see both occasions of the test in the build log at [1] 2. that build ran on all my tests before upload and it worked fine there Two occasions in http://paste.ubuntu.com/p/RKFvhTP8Ft/ 3. it is not the test, but the prep stage for "build-needed" that is failing which might also be the reason why there is no auto-timeout-abort The bad part, in a local build this just works fine: - autopkgtest in a VM is ok - sbuild building the package itself is ok Next steps: - what does this particular test actually do that could hang - what might be different in that build time comapred to "local-autopkgtest-vm" and the "normal LP builds" [1]: https://launchpadlibrarian.net/437577267/buildlog_ubuntu-eoan- amd64.ufw_0.36-1ubuntu2_BUILDING.txt.gz -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1840633 Title: autopkgtests get stuck in Eoan with iptables 1.8.3 Status in ufw package in Ubuntu: New Bug description: Hi, it is time to report a bug to keep all info in one place. First of all ufw tests were broken with iptables 1.8.3 due to an ordering issue in the output. This I fixed and tested in [1]. It only adds one more "allowed result" to one of the tests, so it should be no big change. I double checked the upload to not (by any accident) change something else. $ debdiff ufw_0.36-1ubuntu1.dsc ufw_0.36-1ubuntu2.dsc | diffstat changelog | 8 patches/0003-fix-test-iptables1.8.patch | 4151 ++++++++++++++++++++++++++++++++ patches/series | 1 3 files changed, 4160 insertions(+) $ grep -e '---' -e '+++' ufw-0.36/debian/patches/0003-fix-test-iptables1.8.patch --- /dev/null +++ b/tests/root/valid/result.1.8 --- /dev/null +++ b/tests/root/valid6/result.1.8 => That seems safe to me. But since this hit Eoan the tests get stuck and hang what seems until aborted (we have seen up to 75h). A normal execution in the past was ~30 minutes. The modified test worked fine: http://paste.ubuntu.com/p/RKFvhTP8Ft/ But the test for ufw has multiple runs and I only fixed/modified/tested the "root-unitest". I'm running the full test now hoping it might reproduce locally for debugging. First I thought something else in Eoan changed now trigging this issue. But that is rather unlikely, as without the new iptables it works fine. So for now the working theory for now is that iptables 1.8.3 changed something else changed Formerly this was not seen as it failed on the bug I fixed before hitting the hang. But with the fix above applied it now triggers the hang. It always hangs at this tests: Test get_netfilter_capabilities() ERROR (CommandError): No server with a name or ID of '0eb6260d-c544-41eb-8cfa-baa9a745c528' nova show 0eb6260d-c544-41eb-8cfa-baa9a745c528 (adt-eoan-s390x-ufw-20190815-202934) The test uses no Nova, the last two lines is from the automation being aborted. What is interesting is that this test would be ran up to three times, and it sometimes succeeds one or two times now. So it might (in addition to be broken) also be flaky. [1]: https://code.launchpad.net/~paelzer/ubuntu/+source/ufw/+git/ufw/+merge/371391 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1840633/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
