** Description changed:
+ [ Impact ]
+
+ * An explanation of the effects of the bug on users and
+
+ * justification for backporting the fix to the stable release.
+
+ * In addition, it is helpful, but not required, to include an
+ explanation of how the upload fixes this bug.
+
+ [ Test Plan ]
+
+ * detailed instructions how to reproduce the bug
+
+ * these should allow someone who is not familiar with the affected
+ package to reproduce the bug and verify that the updated package fixes
+ the problem.
+
+ * if other testing is appropriate to perform before landing this update,
+ this should also be described here.
+
+ [ Where problems could occur ]
+
+ * Think about what the upload changes in the software. Imagine the change is
+ wrong or breaks something else: how would this show up?
+
+ * It is assumed that any SRU candidate patch is well-tested before
+ upload and has a low overall risk of regression, but it's important
+ to make the effort to think about what ''could'' happen in the
+ event of a regression.
+
+ * This must '''never''' be "None" or "Low", or entirely an argument as to why
+ your upload is low risk.
+
+ * This both shows the SRU team that the risks have been considered,
+ and provides guidance to testers in regression-testing the SRU.
+
+ [ Other Info ]
+
+ * Anything else you think is useful to include
+ * Anticipate questions from users, SRU, +1 maintenance, security teams and
the Technical Board
+ * and address these questions in advance
+
+ [ Original Description ]
+
The shell test suite (iptables/tests/shell/run-tests.sh) is currently
failing on the firewalld tests:
W: [FAILED] ././testcases/firewalld-restore/0001-firewalld_0: expected 0
but got 1
W: [FAILED] ././testcases/firewalld-restore/0002-firewalld-restart_0:
expected 0 but got 1
After some troubleshooting, it turns out this is happening because of an
unsorted order in the output of iptables-save, which was fixed[1] in
later releases of iptables. The code was trying to compensate for that,
but there was a small mistake[2] in a case/esac globbing:
case "$XT_MULTI" in
-*/xtables-nft-multi)
+*xtables-nft-multi)
-
1.
https://git.netfilter.org/iptables/commit/?id=e28cf12cf50b9e2e0114f04331635fc122cb8aef
2.
https://git.netfilter.org/iptables/commit/?id=2b2b7948c1960ba4680677664ff58477be869de6
** Also affects: iptables (Ubuntu Focal)
Importance: Undecided
Status: New
** Changed in: iptables (Ubuntu Focal)
Status: New => In Progress
** Changed in: iptables (Ubuntu Focal)
Assignee: (unassigned) => Andreas Hasenack (ahasenack)
** Changed in: iptables (Ubuntu)
Status: In Progress => Fix Released
--
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/2019023
Title:
Fix shell test suite
Status in iptables package in Ubuntu:
Fix Released
Status in iptables source package in Focal:
In Progress
Bug description:
[ Impact ]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[ Test Plan ]
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
* if other testing is appropriate to perform before landing this update,
this should also be described here.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and
the Technical Board
* and address these questions in advance
[ Original Description ]
The shell test suite (iptables/tests/shell/run-tests.sh) is currently
failing on the firewalld tests:
W: [FAILED] ././testcases/firewalld-restore/0001-firewalld_0: expected 0
but got 1
W: [FAILED] ././testcases/firewalld-restore/0002-firewalld-restart_0:
expected 0 but got 1
After some troubleshooting, it turns out this is happening because of
an unsorted order in the output of iptables-save, which was fixed[1]
in later releases of iptables. The code was trying to compensate for
that, but there was a small mistake[2] in a case/esac globbing:
case "$XT_MULTI" in
-*/xtables-nft-multi)
+*xtables-nft-multi)
1.
https://git.netfilter.org/iptables/commit/?id=e28cf12cf50b9e2e0114f04331635fc122cb8aef
2.
https://git.netfilter.org/iptables/commit/?id=2b2b7948c1960ba4680677664ff58477be869de6
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/2019023/+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
