I took a look at this and found that: a) firewalld root-unittests autopkgtests fail when using either iptables 1.6 or 1.8 in release due to https://bugzilla.redhat.com/show_bug.cgi?id=1601610 and the failure is: "2019-03-24 17:30:19 ERROR: COMMAND_FAILED: '/sbin/ipset add foobar 10.1.2.0/22' failed: ipset v6.38: Kernel support protocol versions 6-7 while userspace supports protocol versions 6-6". b) firewalld smoke-with-recommends autopkgtests fail when using 1.8 in -proposed (this bug) c) someone in the Debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914694 claims that https://git.netfilter.org/iptables/commit/?id=947c51c95 resolves this issue. I took a look at backporting this and found that libnftnl requires 5 patches (which apply cleanly) and iptables needs at least 13 patches before the claimed fix can apply and 1 bug fix patch after. It seems that Debian is waiting for iptables 1.8.3 since the changes are so intrusive (I stopped at 13 patches because I found that I needed more and more earlier patches to support the new table and rule caching) d) firewalld in 0.6.3-5 introduced the dependency on iptables 1.8.1 and dropped the recommends on ebtables. Dropping this and keeping iptables at 1.6 results in allowing smoke-with-recommends to pass and restores the 0.6.3-4 failing ipset behavior. e) adjust iptables.postinst to use a lower update-alternatives priority such that iptables-legacy is used results in allowing smoke-with-recommends to pass and restores the 0.6.3-4 failing ipset behavior. We may want to reintroduce the Recommends in firewalld on ebtables so as not to mix ebtables-nft with iptables-legacy
Attempting to cherrypick all the patches to try to fix this is too regression-prone IME (indeed, there was one known regression with the patches; who knows how many more are lurking at the tip of upstream). I also don't want to take a git snapshot for similar reasons. I would much rather wait for upstream to release 1.8.3, much like Debian is. This leaves us with 3 options: a) leave 1.6 in disco and adjust the firewalld packaging to not require 1.8 b) adjust 1.8 in disco to prefer the legacy iptables commands instead of nft c) keep everything as is and ignore the firewalld error. This is how Debian Buster is going to release Since this represents a real bug in iptables, I think 'c' is out. While 'b' is an option, it is less well tested and I prefer 'a'. Once iptables 1.8.3 is out and/or Debian fixes 914694, then we can pull 1.8 into the archive. We will definitely want 1.8 in for 20.04 LTS. I will remove 1.8 from disco-proposed and upload a firewalld with the adjusted Depends/Recommends, but someone else should look at the firewalld autopkgtest ipset regression. ** Bug watch added: Red Hat Bugzilla #1601610 https://bugzilla.redhat.com/show_bug.cgi?id=1601610 ** Changed in: iptables (Ubuntu) Status: New => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1820317 Title: The firewalld autopackage tests fail due to iptables Status in firewalld package in Ubuntu: Fix Committed Status in iptables package in Ubuntu: Won't Fix Status in iptables package in Debian: Unknown Bug description: The firewalld autopkgtest fail in disco on what looks like an iptables issue https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest- disco/disco/amd64/f/firewalld/20190315_154203_ef4d6@/log.gz 'Mar 15 15:41:39 autopkgtest firewalld[1691]: ERROR: '/usr/sbin/iptables-restore -w -n' failed: iptables-restore v1.8.2 (nf_tables): line 4: RULE_REPLACE failed (No such file or directory): rule in chain INPUT line 4: RULE_REPLACE failed (No such file or directory): rule in chain OUTPUT' That looks like the issue reported on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914694 which is fixed in upstream iptables https://git.netfilter.org/iptables/commit/?id=947c51c95 That fix seems to depends on git master changes from libnftnl https://git.netfilter.org/libnftnl/log/ ('chain: Support per chain rules list' and following commits) Unsure at this point what's best disco, if we should start looking at backporting those changes? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firewalld/+bug/1820317/+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
