net-firewall/iptables-1.3.8-r2 doesn't build libipt_IPMARK.so with "extensions" useflag while 1.3.5-r4 is doing fine. It may be associated with some changes in patch-o-matic. Now IPMARK is on separate repository and it has to be downloaded manualy when using patch-o-matic (runme download) Reproducible: Always Steps to Reproduce: Actual Results: Missing libipt_IPMARK.so Expected Results: libipt_IPMARK.so should be built
Yes. extensions USE flag builds only extensions bundled with iptables (inside extensions subdirectory) and in 1.3.8 this extension went away. I need to check the current state of IPMARK and then may be I'll maintain this feature as it sounds like useful.
*** Bug 207961 has been marked as a duplicate of this bug. ***
I wonder if using patch-o-matic in ebuild would be against gentoo policy. If no it would be nice to have some kind of IPTABLES_EXTENSIONS (like ALSA_CARDS) and to run patch-o-matic with supplied patchlets names. PS. "Plain old patch" with IPMARK is accessible at http://people.netfilter.org/ole/pom/IPMARK (that file is in fact a tar.gz archive used by patch-o-matic-ng and downloaded when running ./runme --download).
Michal, there is no such policy. But maintaining of this extensions is hard work because normally they are updated some time later after iptables update. So keeping them all working will require following development of each extensions we'll add and it's quite possible that they will break each iptables upgrade. As I said, IPMARK possibly will be added and connlimit returned into iptables-1.4.0. May be I'll add ipset too. I'm not sure about others (what others?)
I'm closing this bug as FIXED. Mike added different mechanism to apply patches in iptables: just drop patches you want be applied into /etc/portage/patches/net-firewall/iptables/ and they'll be applied during merge. This is not best solution, but is good as a temporal measure until better solution how to handle this extensions will appear.
