Note from my debug builds:

TDEBUG: check OSError
GNC: Enter get_netfilter_capabilities
GNC: we are root
GNC: chain ufw-caps-testSqLa5Y
GNC: exe /sbin/iptables

That means it is the first action of the test, just running
  /sbin/iptables -N ufw-caps-testSqLa5Y
Nothing else of the python stack was running before as part of the test.

debian/rules just has:
 30 install: build                                                              
     
 31 »···dh_testdir                                                              
     
 32 »···dh_testroot                                                             
     
 33 »···dh_prep                                                                 
     
 34 »···dh_installdirs                                                          
     
 35                                                                             
     
 36 ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))                          
     
 37 »···./run_tests.sh -i $(PYTHON2)                                            
     
 38 »···./run_tests.sh -i $(PYTHON)                                             
     
 39 »···# the testsuite creates the build/ directory with test values that we   
     
 40 »···# don't want to use                                                     
     
 41 »···make clean                                                              
     
 42 endif

We should actually be able to just run
$ sudo apt build-dep ufw
$ ./debian/rules install

In general this is mostly python, so build almost only consists of
selftests.

But no matter what I do the test either
a) works
b) breaks on the root check like
  File "/home/ubuntu/ufw/tests/unit/test_util.py", line 918, in 
test_get_netfilter_capabilities
    ufw.util.get_netfilter_capabilities)
  File "/home/ubuntu/ufw/tests/unit/support.py", line 164, in 
check_for_exception
    t.fail('%s not thrown' % str(expectedException))
AssertionError: <type 'exceptions.OSError'> not thrown

-- 
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

Reply via email to