Skip to contentSkip to conversation

xtables-addons: new package

PATCH New Gustavo Zacarias 3 participants 12 messages Oct 21, 2014 – Jan 10, 2015

lore
Share & tools
lore
#0 lore raw

PATCH 1/3 xtables-addons: new package

The geoip "helpers" are basically scripts that download and reformat the geoip database in a form usable by xt_geoip.
The netfilter (kernel & userland) sides of it are built and installed. Since there are many considerations to geoip databases (free, commercial and variants for each) it's left to the user to deal with that if they plan to use the extension which is only one among many.

---
 package/Config.in                          |  1 +
 package/xtables-addons/Config.in           | 22 +++++++++++++++++++++
 package/xtables-addons/xtables-addons.hash |  3 +++
 package/xtables-addons/xtables-addons.mk   | 31 ++++++++++++++++++++++++++++++
 4 files changed, 57 insertions(+)
 create mode 100644 package/xtables-addons/Config.in
 create mode 100644 package/xtables-addons/xtables-addons.hash
 create mode 100644 package/xtables-addons/xtables-addons.mk
package/Config.in +1 -0
index 989790e..97985b3 100644
@@ -1128,6 +1128,7 @@ endif
 	source "package/wvdial/Config.in"
 	source "package/xinetd/Config.in"
 	source "package/xl2tp/Config.in"
+	source "package/xtables-addons/Config.in"
 	source "package/znc/Config.in"
 
 endmenu
package/xtables-addons/Config.in new file +22 -0
new file mode 100644
index 0000000..6e3b88c
@@ -0,0 +1,22 @@
+comment "xtables-addons needs a Linux kernel to be built"
+	depends on !BR2_LINUX_KERNEL
+
+comment "xtables-addons needs a toolchain w/ dynamic library, largefile, threads"
+	depends on BR2_LINUX_KERNEL
+	depends on BR2_PREFER_STATIC_LIB || !BR2_LARGEFILE || \
+		!BR2_TOOLCHAIN_HAS_THREADS
+
+
+config BR2_PACKAGE_XTABLES_ADDONS
+	bool "xtables-addons"
+	depends on BR2_LINUX_KERNEL
+	depends on BR2_LARGEFILE
+	depends on BR2_TOOLCHAIN_HAS_THREADS
+	depends on !BR2_PREFER_STATIC_LIB # extensions are .so
+	select BR2_PACKAGE_IPTABLES
+	help
+	  Xtables-addons is the successor to patch-o-matic(-ng).
+	  Likewise, it contains extensions that were not, or are not yet,
+	  accepted in the main kernel/iptables packages.
+
+	  http://xtables-addons.sourceforge.net/
package/xtables-addons/xtables-addons.hash new file +3 -0
new file mode 100644
index 0000000..d742aed
@@ -0,0 +1,3 @@
+# From http://sourceforge.net/projects/xtables-addons/files/Xtables-addons/2.6/
+md5	087835ba7e564481b6fd398692268340	xtables-addons-2.6.tar.xz
+sha1	10586961a70fd4fe4f972cb3f31962c6766b359c	xtables-addons-2.6.tar.xz
package/xtables-addons/xtables-addons.mk new file +31 -0
new file mode 100644
index 0000000..2992ac6
@@ -0,0 +1,31 @@
+################################################################################
+#
+# xtables-addons
+#
+################################################################################
+
+XTABLES_ADDONS_VERSION = 2.6
+XTABLES_ADDONS_SOURCE = xtables-addons-$(XTABLES_ADDONS_VERSION).tar.xz
+XTABLES_ADDONS_SITE = http://downloads.sourceforge.net/project/xtables-addons/Xtables-addons/$(XTABLES_ADDONS_VERSION)
+XTABLES_ADDONS_CONF_OPTS = --with-kbuild="$(LINUX_DIR)" \
+	--with-xtables="$(STAGING_DIR)/usr" \
+	--with-xtlibdir="/usr/lib/xtables"
+XTABLES_ADDONS_DEPENDENCIES = iptables linux host-pkgconf
+XTABLES_ADDONS_LICENSE = GPLv2+
+XTABLES_ADDONS_LICENSE_FILES = LICENSE
+
+# geoip helpers need perl with modules and unzip so disable
+define XTABLES_DISABLE_GEOIP_HELPERS
+	$(SED) 's/ geoip//' $(@D)/Makefile.in
+endef
+XTABLES_ADDONS_POST_PATCH_HOOKS += XTABLES_DISABLE_GEOIP_HELPERS
+
+define XTABLES_ADDONS_BUILD_CMDS
+	$(MAKE) -C $(@D) $(LINUX_MAKE_FLAGS)
+endef
+
+define XTABLES_ADDONS_INSTALL_TARGET_CMDS
+	$(MAKE) -C $(@D) $(LINUX_MAKE_FLAGS) DESTDIR="$(TARGET_DIR)" install
+endef
+
+$(eval $(autotools-package))
Signature · 1 line
2.0.4
#1 lore raw

PATCH 2/3 iptables: enable basic kernel options

Enable the basic kernel options for iptables to be useful at least to filter incoming connections.

---
 linux/linux.mk | 5 +++++
 1 file changed, 5 insertions(+)
linux/linux.mk +5 -0
index 2b862ec..b9d3c8e 100644
@@ -210,6 +210,11 @@ define LINUX_CONFIGURE_CMDS
 		$(call KCONFIG_ENABLE_OPT,CONFIG_SECURITY,$(@D)/.config)
 		$(call KCONFIG_ENABLE_OPT,CONFIG_SECURITY_SMACK,$(@D)/.config)
 		$(call KCONFIG_ENABLE_OPT,CONFIG_SECURITY_NETWORK,$(@D)/.config))
+	$(if $(BR2_PACKAGE_IPTABLES),
+		$(call KCONFIG_ENABLE_OPT,CONFIG_IP_NF_IPTABLES,$(@D)/.config)
+		$(call KCONFIG_ENABLE_OPT,CONFIG_IP_NF_FILTER,$(@D)/.config)
+		$(call KCONFIG_ENABLE_OPT,CONFIG_NETFILTER,$(@D)/.config)
+		$(call KCONFIG_ENABLE_OPT,CONFIG_NETFILTER_XTABLES,$(@D)/.config))
 	$(if $(BR2_LINUX_KERNEL_APPENDED_DTB),
 		$(call KCONFIG_ENABLE_OPT,CONFIG_ARM_APPENDED_DTB,$(@D)/.config))
 	yes '' | $(TARGET_MAKE_ENV) $(MAKE1) $(LINUX_MAKE_FLAGS) -C $(@D) oldconfig
Signature · 1 line
2.0.4
#2 lore raw

PATCH 2/3 iptables: enable basic kernel options

Gustavo, Peter,

Quoted 14 lines · Gustavo Zacarias

Enable the basic kernel options for iptables to be useful at least to filter incoming connections.

---
 linux/linux.mk | 5 +++++
 1 file changed, 5 insertions(+)
linux/linux.mk +0 -0
index 2b862ec..b9d3c8e 100644
@@ -210,6 +210,11 @@ define LINUX_CONFIGURE_CMDS
 		$(call KCONFIG_ENABLE_OPT,CONFIG_SECURITY,$(@D)/.config)

linux/linux.mk define LINUX_CONFIGURE_CMDS · line 220

Quoted 10 lines
linux/linux.mk +5 -0
 		$(call KCONFIG_ENABLE_OPT,CONFIG_SECURITY_SMACK,$(@D)/.config)
 		$(call KCONFIG_ENABLE_OPT,CONFIG_SECURITY_NETWORK,$(@D)/.config))
+	$(if $(BR2_PACKAGE_IPTABLES),
+		$(call KCONFIG_ENABLE_OPT,CONFIG_IP_NF_IPTABLES,$(@D)/.config)
+		$(call KCONFIG_ENABLE_OPT,CONFIG_IP_NF_FILTER,$(@D)/.config)
+		$(call KCONFIG_ENABLE_OPT,CONFIG_NETFILTER,$(@D)/.config)
+		$(call KCONFIG_ENABLE_OPT,CONFIG_NETFILTER_XTABLES,$(@D)/.config))
 	$(if $(BR2_LINUX_KERNEL_APPENDED_DTB),
 		$(call KCONFIG_ENABLE_OPT,CONFIG_ARM_APPENDED_DTB,$(@D)/.config))
 	yes '' | $(TARGET_MAKE_ENV) $(MAKE1) $(LINUX_MAKE_FLAGS) -C $(@D) oldconfig

For this one, I don't know. Back some time ago, Peter said that his preference was to not enforce too much stuff in terms of kernel configuration options in linux/linux.mk. I think the idea is that it's something that can quickly become very complicated if you want to handle all the kernel config options that all packages might need. It's also being forced without the user being capable of doing anything against that: those KCONFIG_ENABLE_OPT calls are done even if the user passes a custom configuration file.

But back at the time, we only had the CONFIG_AEABI option being handled. Now it's true we already have ktap, systemd, smack being handled, and many other things related to appended DTB, initramfs, and more. So it seems like the iptables/xtables-addons proposal from Gustavo are not really creating a precedent.

Peter, what is your position on this?

Thanks,

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#3 lore raw

PATCH 2/3 iptables: enable basic kernel options

Quoted 9 lines · Thomas Petazzoni

For this one, I don't know. Back some time ago, Peter said that his preference was to not enforce too much stuff in terms of kernel configuration options in linux/linux.mk. I think the idea is that it's something that can quickly become very complicated if you want to handle all the kernel config options that all packages might need. It's also being forced without the user being capable of doing anything against that: those KCONFIG_ENABLE_OPT calls are done even if the user passes a custom configuration file.

Quoted 7 lines

But back at the time, we only had the CONFIG_AEABI option being handled. Now it's true we already have ktap, systemd, smack being handled, and many other things related to appended DTB, initramfs, and more. So it seems like the iptables/xtables-addons proposal from Gustavo are not really creating a precedent.

Peter, what is your position on this?

Unfortunately it's not optional for xtables-addons, it needs the iptables bits for the xtables bits in the other patch. We could just get them together or ditch the package since it will result in a build failure.
Regards.

#4 lore raw

PATCH 2/3 iptables: enable basic kernel options

Dear Gustavo Zacarias,

Quoted 17 lines · Gustavo Zacarias
Quoted 15 lines · Thomas Petazzoni

For this one, I don't know. Back some time ago, Peter said that his preference was to not enforce too much stuff in terms of kernel configuration options in linux/linux.mk. I think the idea is that it's something that can quickly become very complicated if you want to handle all the kernel config options that all packages might need. It's also being forced without the user being capable of doing anything against that: those KCONFIG_ENABLE_OPT calls are done even if the user passes a custom configuration file.

But back at the time, we only had the CONFIG_AEABI option being handled. Now it's true we already have ktap, systemd, smack being handled, and many other things related to appended DTB, initramfs, and more. So it seems like the iptables/xtables-addons proposal from Gustavo are not really creating a precedent.

Quoted 6 lines
Quoted 1 line

Peter, what is your position on this?

Unfortunately it's not optional for xtables-addons, it needs the iptables bits for the xtables bits in the other patch. We could just get them together or ditch the package since it will result in a build failure.

As said on IRC, if those options are needed at build time for xtables-addons, it makes a very good case for having them.

Peter, OK ?

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#5 lore raw

PATCH 2/3 iptables: enable basic kernel options

Quoted 22 lines · Thomas Petazzoni

Dear Gustavo Zacarias,

Quoted 19 lines · Gustavo Zacarias
Quoted 16 lines · Thomas Petazzoni

For this one, I don't know. Back some time ago, Peter said that his preference was to not enforce too much stuff in terms of kernel configuration options in linux/linux.mk. I think the idea is that it's something that can quickly become very complicated if you want to handle all the kernel config options that all packages might need. It's also being forced without the user being capable of doing anything against that: those KCONFIG_ENABLE_OPT calls are done even if the user passes a custom configuration file.

But back at the time, we only had the CONFIG_AEABI option being handled. Now it's true we already have ktap, systemd, smack being handled, and many other things related to appended DTB, initramfs, and more. So it seems like the iptables/xtables-addons proposal from Gustavo are not really creating a precedent.

Peter, what is your position on this?

Quoted 7 lines
Quoted 4 lines

Unfortunately it's not optional for xtables-addons, it needs the iptables bits for the xtables bits in the other patch. We could just get them together or ditch the package since it will result in a build failure.

As said on IRC, if those options are needed at build time for xtables-addons, it makes a very good case for having them.

I completely agree with that reasoning.

Actually, I think it's just the ktap and smack modifications that are really
controversial. The others are either required for building, or they are system configuration options and for those it's logical to propagate to the kernel config.

Regards,
Arnout

Quoted 5 lines

Peter, OK ?

Thomas

Signature · 6 lines
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
#6 lore raw

PATCH 3/3 xtables-addons: enable necessary kernel options

In reply to Gustavo Zacarias

Enable the required conntrack/netfilter options, otherwise xtables-addons will fail to build.
The basic iptables options are already covered by the iptables package which is a required dependency anyway.

---
 linux/linux.mk | 3 +++
 1 file changed, 3 insertions(+)
linux/linux.mk +3 -0
index b9d3c8e..ee8c6a0 100644
@@ -215,6 +215,9 @@ define LINUX_CONFIGURE_CMDS
 		$(call KCONFIG_ENABLE_OPT,CONFIG_IP_NF_FILTER,$(@D)/.config)
 		$(call KCONFIG_ENABLE_OPT,CONFIG_NETFILTER,$(@D)/.config)
 		$(call KCONFIG_ENABLE_OPT,CONFIG_NETFILTER_XTABLES,$(@D)/.config))
+	$(if $(BR2_PACKAGE_XTABLES_ADDONS),
+		$(call KCONFIG_ENABLE_OPT,CONFIG_NF_CONNTRACK,$(@D)/.config)
+		$(call KCONFIG_ENABLE_OPT,CONFIG_NF_CONNTRACK_MARK,$(@D)/.config))
 	$(if $(BR2_LINUX_KERNEL_APPENDED_DTB),
 		$(call KCONFIG_ENABLE_OPT,CONFIG_ARM_APPENDED_DTB,$(@D)/.config))
 	yes '' | $(TARGET_MAKE_ENV) $(MAKE1) $(LINUX_MAKE_FLAGS) -C $(@D) oldconfig
Signature · 1 line
2.0.4
#7 lore raw

PATCH 1/3 xtables-addons: new package

In reply to Gustavo Zacarias
Quoted 36 lines · Gustavo Zacarias

The geoip "helpers" are basically scripts that download and reformat the geoip database in a form usable by xt_geoip.
The netfilter (kernel & userland) sides of it are built and installed. Since there are many considerations to geoip databases (free, commercial and variants for each) it's left to the user to deal with that if they plan to use the extension which is only one among many.

---
 package/Config.in                          |  1 +
 package/xtables-addons/Config.in           | 22 +++++++++++++++++++++
 package/xtables-addons/xtables-addons.hash |  3 +++
 package/xtables-addons/xtables-addons.mk   | 31 ++++++++++++++++++++++++++++++
 4 files changed, 57 insertions(+)
 create mode 100644 package/xtables-addons/Config.in
 create mode 100644 package/xtables-addons/xtables-addons.hash
 create mode 100644 package/xtables-addons/xtables-addons.mk
package/Config.in +1 -0
index 989790e..97985b3 100644
@@ -1128,6 +1128,7 @@ endif
 	source "package/wvdial/Config.in"
 	source "package/xinetd/Config.in"
 	source "package/xl2tp/Config.in"
+	source "package/xtables-addons/Config.in"
 	source "package/znc/Config.in"
 
 endmenu
package/xtables-addons/Config.in new file +0 -0
new file mode 100644
index 0000000..6e3b88c

package/xtables-addons/Config.in line 5

Quoted 5 lines
package/xtables-addons/Config.in new file +5 -0
@@ -0,0 +1,22 @@
+comment "xtables-addons needs a Linux kernel to be built"
+	depends on !BR2_LINUX_KERNEL
+
+comment "xtables-addons needs a toolchain w/ dynamic library, largefile, threads"
+	depends on BR2_LINUX_KERNEL

Do we usually do this? I mean, if a user discovers the 'needs a Linux kernel'
comment and builds a kernel, then he comes back only to discover that he still has to enable all this other stuff...

Quoted 46 lines
package/xtables-addons/Config.in new file +17 -0
+	depends on BR2_PREFER_STATIC_LIB || !BR2_LARGEFILE || \
+		!BR2_TOOLCHAIN_HAS_THREADS
+
+
+config BR2_PACKAGE_XTABLES_ADDONS
+	bool "xtables-addons"
+	depends on BR2_LINUX_KERNEL
+	depends on BR2_LARGEFILE
+	depends on BR2_TOOLCHAIN_HAS_THREADS
+	depends on !BR2_PREFER_STATIC_LIB # extensions are .so
+	select BR2_PACKAGE_IPTABLES
+	help
+	  Xtables-addons is the successor to patch-o-matic(-ng).
+	  Likewise, it contains extensions that were not, or are not yet,
+	  accepted in the main kernel/iptables packages.
+
+	  http://xtables-addons.sourceforge.net/
package/xtables-addons/xtables-addons.hash new file +3 -0
new file mode 100644
index 0000000..d742aed
@@ -0,0 +1,3 @@
+# From http://sourceforge.net/projects/xtables-addons/files/Xtables-addons/2.6/
+md5	087835ba7e564481b6fd398692268340	xtables-addons-2.6.tar.xz
+sha1	10586961a70fd4fe4f972cb3f31962c6766b359c	xtables-addons-2.6.tar.xz
package/xtables-addons/xtables-addons.mk new file +14 -0
new file mode 100644
index 0000000..2992ac6
@@ -0,0 +1,31 @@
+################################################################################
+#
+# xtables-addons
+#
+################################################################################
+
+XTABLES_ADDONS_VERSION = 2.6
+XTABLES_ADDONS_SOURCE = xtables-addons-$(XTABLES_ADDONS_VERSION).tar.xz
+XTABLES_ADDONS_SITE = http://downloads.sourceforge.net/project/xtables-addons/Xtables-addons/$(XTABLES_ADDONS_VERSION)
+XTABLES_ADDONS_CONF_OPTS = --with-kbuild="$(LINUX_DIR)" \
+	--with-xtables="$(STAGING_DIR)/usr" \
+	--with-xtlibdir="/usr/lib/xtables"
+XTABLES_ADDONS_DEPENDENCIES = iptables linux host-pkgconf
+XTABLES_ADDONS_LICENSE = GPLv2+

package/xtables-addons/xtables-addons.mk line 24

Quoted 10 lines
package/xtables-addons/xtables-addons.mk new file +10 -0
+XTABLES_ADDONS_LICENSE_FILES = LICENSE
+
+# geoip helpers need perl with modules and unzip so disable
+define XTABLES_DISABLE_GEOIP_HELPERS
+	$(SED) 's/ geoip//' $(@D)/Makefile.in
+endef
+XTABLES_ADDONS_POST_PATCH_HOOKS += XTABLES_DISABLE_GEOIP_HELPERS
+
+define XTABLES_ADDONS_BUILD_CMDS
+	$(MAKE) -C $(@D) $(LINUX_MAKE_FLAGS)

Is there a reason why

XTABLE_ADDONS_MAKE_OPTS = $(LINUX_MAKE_FLAGS)

doesn't work instead of overriding the build commands?

Regards,
Arnout

Quoted 8 lines
package/xtables-addons/xtables-addons.mk new file +7 -0
+endef
+
+define XTABLES_ADDONS_INSTALL_TARGET_CMDS
+	$(MAKE) -C $(@D) $(LINUX_MAKE_FLAGS) DESTDIR="$(TARGET_DIR)" install
+endef
+
+$(eval $(autotools-package))
Signature · 6 lines
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
#8 lore raw

PATCH 1/3 xtables-addons: new package

Quoted 9 lines · Arnout Vandecappelle

package/xtables-addons/Config.in line 5

Quoted 5 lines
package/xtables-addons/Config.in new file +5 -0
+comment "xtables-addons needs a Linux kernel to be built"
+	depends on !BR2_LINUX_KERNEL
+
+comment "xtables-addons needs a toolchain w/ dynamic library, largefile, threads"
+	depends on BR2_LINUX_KERNEL

Do we usually do this? I mean, if a user discovers the 'needs a Linux kernel'
comment and builds a kernel, then he comes back only to discover that he still has to enable all this other stuff...

I can move it to linux extensions instead of it being a package, i don't know if it's worth bloating too much there.
For the comment i didn't want to make it too wide with both, i wouldn't mind making it a single one since i use terminals wider than 80 normally.

Quoted 8 lines

package/xtables-addons/xtables-addons.mk line 24

Quoted 2 lines
package/xtables-addons/xtables-addons.mk new file +2 -0
+define XTABLES_ADDONS_BUILD_CMDS
+	$(MAKE) -C $(@D) $(LINUX_MAKE_FLAGS)

Is there a reason why

XTABLE_ADDONS_MAKE_OPTS = $(LINUX_MAKE_FLAGS)

doesn't work instead of overriding the build commands?

The build is somewhat fragile since it calls kbuild in the process, i'll give it another try but i think it had some issues when building for PowerPC SPE ABI otherwise (configure gets it's stuff from the autotools vanilla cmds and uses that for userland, however builds vars are use for kbuild exclusively and something sneaked in in a bad way IIRC). Regards.

#9 lore raw

PATCH 1/3 xtables-addons: new package

Quoted 7 lines · Gustavo Zacarias
Quoted 4 lines · Arnout Vandecappelle

package/xtables-addons/Config.in

Quoted 4 lines
package/xtables-addons/Config.in new file +4 -0
+comment "xtables-addons needs a Linux kernel to be built"
+    depends on !BR2_LINUX_KERNEL
+
+comment "xtables-addons needs a toolchain w/ dynamic library, largefile,

threads"

Quoted 8 lines
Quoted 5 lines
Quoted 1 line

+ depends on BR2_LINUX_KERNEL

Do we usually do this? I mean, if a user discovers the 'needs a Linux kernel'
comment and builds a kernel, then he comes back only to discover that he still has to enable all this other stuff...

I can move it to linux extensions instead of it being a package, i don't know if it's worth bloating too much there.

No, that's not what I meant: linux extensions are for things that modify
the kernel source, so it's really exceptional.

What I meant is that the second comment should not depend on
BR2_LINUX_KERNEL, so both comments appear if you don't have the kernel nor largefile selected.

Regards,
Arnout

[snip]

Signature · 6 lines
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
#10 lore raw

PATCH 1/3 xtables-addons: new package

In reply to Arnout Vandecappelle
Quoted 9 lines · Arnout Vandecappelle

package/xtables-addons/xtables-addons.mk line 24

Quoted 2 lines
package/xtables-addons/xtables-addons.mk new file +2 -0
+define XTABLES_ADDONS_BUILD_CMDS
+	$(MAKE) -C $(@D) $(LINUX_MAKE_FLAGS)

Is there a reason why

XTABLE_ADDONS_MAKE_OPTS = $(LINUX_MAKE_FLAGS)

doesn't work instead of overriding the build commands?

Quoted 8 lines

Regards,
Arnout

package/xtables-addons/xtables-addons.mk line 29

Quoted 5 lines
package/xtables-addons/xtables-addons.mk new file +5 -0
+endef
+
+define XTABLES_ADDONS_INSTALL_TARGET_CMDS
+	$(MAKE) -C $(@D) $(LINUX_MAKE_FLAGS) DESTDIR="$(TARGET_DIR)" install
+endef

It works for build but not for install, i can send a v2 just dropping the build cmds and adding the opts.
Regarding the comment, there are packages that do so, for example fmc and fmlib.
There are other packages that depend on linux as well but don't have/need separate comment entries - being dependant on a kernel being built i suspect some may need extra toolchain options but they aren't audited by autobuilds hence they're not taken care of. Regards.

#11 lore raw

PATCH 1/3 xtables-addons: new package

In reply to Gustavo Zacarias

Dear Gustavo Zacarias,

Quoted 8 lines · Gustavo Zacarias

The geoip "helpers" are basically scripts that download and reformat the geoip database in a form usable by xt_geoip.
The netfilter (kernel & userland) sides of it are built and installed. Since there are many considerations to geoip databases (free, commercial and variants for each) it's left to the user to deal with that if they plan to use the extension which is only one among many.

Thanks, I've applied the three patches of this series, only after doing a minor set of changes on the first patch:

[Thomas:
- Take into account the rename of BR2_PREFER_STATIC_LIB to BR2_STATIC_LIBS
- Remove "depends on BR2_LINUX_KERNEL" as suggested by Arnout.
- Move XTABLES_ADDONS_CONF_OPTS a bit further down, with newlines around it, and adjust the indentation of the first line. Just to make it slightly more readable.]

Thanks!

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com