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

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
 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

On 21/10/14 23:10, Gustavo Zacarias wrote:
> 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.
> 
> Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
> ---
>  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
> 
> diff --git a/package/Config.in b/package/Config.in
> index 989790e..97985b3 100644
> --- a/package/Config.in
> +++ b/package/Config.in
> @@ -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
> diff --git a/package/xtables-addons/Config.in b/package/xtables-addons/Config.in
> new file mode 100644
> index 0000000..6e3b88c
> --- /dev/null
> +++ b/package/xtables-addons/Config.in
> @@ -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...


> +	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/
> diff --git a/package/xtables-addons/xtables-addons.hash b/package/xtables-addons/xtables-addons.hash
> new file mode 100644
> index 0000000..d742aed
> --- /dev/null
> +++ b/package/xtables-addons/xtables-addons.hash
> @@ -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
> diff --git a/package/xtables-addons/xtables-addons.mk b/package/xtables-addons/xtables-addons.mk
> new file mode 100644
> index 0000000..2992ac6
> --- /dev/null
> +++ b/package/xtables-addons/xtables-addons.mk
> @@ -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)

 Is there a reason why

XTABLE_ADDONS_MAKE_OPTS = $(LINUX_MAKE_FLAGS)

doesn't work instead of overriding the build commands?

 Regards,
 Arnout

> +endef
> +
> +define XTABLES_ADDONS_INSTALL_TARGET_CMDS
> +	$(MAKE) -C $(@D) $(LINUX_MAKE_FLAGS) DESTDIR="$(TARGET_DIR)" install
> +endef
> +
> +$(eval $(autotools-package))
>

On 10/22/2014 02:18 PM, Arnout Vandecappelle wrote:

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

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

On 10/22/2014 02:18 PM, Arnout Vandecappelle wrote:
>> +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
> 
>> +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.

On 23/10/14 00:38, Gustavo Zacarias wrote:
> On 10/22/2014 02:18 PM, Arnout Vandecappelle wrote:
>
> >> +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.

 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]

Dear Gustavo Zacarias,

On Tue, 21 Oct 2014 18:10:50 -0300, Gustavo Zacarias wrote:
> 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.
> 
> Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>

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