| Message ID | 20181101132326.13015-1-fontaine.fabrice@gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [1/2] ngrep: bump to version 1.47 | expand |
Hello, On Thu, 1 Nov 2018 14:23:25 +0100, Fabrice Fontaine wrote: > - Add an upstream patch to fix --enable-pcre If there is a --enable-pcre option, it is a strong indication that PCRE is not mandatory. Indeed: $ ./configure --help [...] --enable-pcre use PCRE instead of GNU regex (default GNU) So PCRE is not mandatory. > -NGREP_LIBS = -lpcap -lpcre Since this variable no longer exists... > ifeq ($(BR2_STATIC_LIBS),y) > NGREP_LIBS += `$(STAGING_DIR)/usr/bin/pcap-config --static --additional-libs` > endif > @@ -20,7 +20,6 @@ NGREP_CONF_ENV += LIBS+="$(NGREP_LIBS)" This assignment becomes totally pointless. > NGREP_CONF_OPTS = \ > --with-pcap-includes=$(STAGING_DIR)/usr/include/pcap \ > --enable-pcre \ > - --with-pcre=$(STAGING_DIR)/usr \ > --disable-dropprivs \ > --disable-pcap-restart > You should add a --disable-tcpkill here, and then in your PATCH 2/2, add the optional dependency on libdnet. Your series on wireshark has the same issue: the first patch should ensure all new optional dependencies are unconditionally disabled, and then follow-up patches should enable them conditionally. This is necessary for a correctly bisectable patch series. When patches are so close in the same series, it's not a big big deal, but it's always better when it's done really correctly. Thanks! Thomas
Dear Thomas, Le sam. 3 nov. 2018 à 22:42, Thomas Petazzoni <thomas.petazzoni@bootlin.com> a écrit : > > Hello, > > On Thu, 1 Nov 2018 14:23:25 +0100, Fabrice Fontaine wrote: > > > - Add an upstream patch to fix --enable-pcre > > If there is a --enable-pcre option, it is a strong indication that PCRE > is not mandatory. Indeed: > > $ ./configure --help > [...] > --enable-pcre use PCRE instead of GNU regex (default GNU) > > So PCRE is not mandatory. Indeed, PCRE is not really "mandatory", ngrep use GNU regex by default but this was already the case before the bump (in version 1.45): see https://github.com/jpr5/ngrep/blob/V1_45/configure.in. I didn't want to change this behavior when bumping the package and I could find why pcre wasn't made optional in the initial commit back in 2011. However, I'll add a third patch in my serie to make pcre an optional dependency before bumping the package.. > > > -NGREP_LIBS = -lpcap -lpcre > > Since this variable no longer exists... Yes, -lpcap and -lpcre are now correctly added by the project. > > > ifeq ($(BR2_STATIC_LIBS),y) > > NGREP_LIBS += `$(STAGING_DIR)/usr/bin/pcap-config --static --additional-libs` > > endif > > @@ -20,7 +20,6 @@ NGREP_CONF_ENV += LIBS+="$(NGREP_LIBS)" > > This assignment becomes totally pointless. OK, I'll replace it by: ifeq ($(BR2_STATIC_LIBS),y) NGREP_CONF_ENV += LIBS="$(STAGING_DIR)/usr/bin/pcap-config --static --additional-libs" endif > > > NGREP_CONF_OPTS = \ > > --with-pcap-includes=$(STAGING_DIR)/usr/include/pcap \ > > --enable-pcre \ > > - --with-pcre=$(STAGING_DIR)/usr \ > > --disable-dropprivs \ > > --disable-pcap-restart > > > > You should add a --disable-tcpkill here, and then in your PATCH 2/2, > add the optional dependency on libdnet. OK, I'll make a v2 with this update (and the other ones) > > Your series on wireshark has the same issue: the first patch should > ensure all new optional dependencies are unconditionally disabled, and > then follow-up patches should enable them conditionally. This is > necessary for a correctly bisectable patch series. When patches are so > close in the same series, it's not a big big deal, but it's always > better when it's done really correctly. OK, I'll do a v2 of wireshark serie too. > > Thanks! > > Thomas > -- > Thomas Petazzoni, CTO, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com Best Regards, Fabrice
Hello, On Sat, 3 Nov 2018 23:01:07 +0100, Fabrice Fontaine wrote: > > So PCRE is not mandatory. > Indeed, PCRE is not really "mandatory", ngrep use GNU regex by default > but this was already the case before the bump (in version 1.45): see > https://github.com/jpr5/ngrep/blob/V1_45/configure.in. > I didn't want to change this behavior when bumping the package and I > could find why pcre wasn't made optional in the initial commit back in > 2011. > However, I'll add a third patch in my serie to make pcre an optional > dependency before bumping the package.. Indeed, it could be a third patch. > > > @@ -20,7 +20,6 @@ NGREP_CONF_ENV += LIBS+="$(NGREP_LIBS)" > > > > This assignment becomes totally pointless. > OK, I'll replace it by: > ifeq ($(BR2_STATIC_LIBS),y) > NGREP_CONF_ENV += LIBS="$(STAGING_DIR)/usr/bin/pcap-config --static > --additional-libs" > endif Sorry, my bad here, I had entirely missed that NGREP_LIBS was still being set in the BR2_STATIC_LIBS case. So the way you did it originally was OK, sorry about that. Doing is directly in NGREP_CONF_ENV also works, since there will be a single assignment of LIBS. > > You should add a --disable-tcpkill here, and then in your PATCH 2/2, > > add the optional dependency on libdnet. > OK, I'll make a v2 with this update (and the other ones) Thanks! Thomas
Dear Thomas, Le dim. 4 nov. 2018 à 11:19, Thomas Petazzoni <thomas.petazzoni@bootlin.com> a écrit : > > Hello, > > On Sat, 3 Nov 2018 23:01:07 +0100, Fabrice Fontaine wrote: > > > > So PCRE is not mandatory. > > Indeed, PCRE is not really "mandatory", ngrep use GNU regex by default > > but this was already the case before the bump (in version 1.45): see > > https://github.com/jpr5/ngrep/blob/V1_45/configure.in. > > I didn't want to change this behavior when bumping the package and I > > could find why pcre wasn't made optional in the initial commit back in > > 2011. > > However, I'll add a third patch in my serie to make pcre an optional > > dependency before bumping the package.. > > Indeed, it could be a third patch. OK, when I tried to enable GNU regex (on 1.47), I got the following error: /usr/bin/make w -j --jobserver-fds=3,4 -C regex-0.12 regex.o make[2]: Entering directory '/home/fabrice/buildroot/output/build/ngrep-1_47/regex-0.12' make[2]: *** No rule to make target 'w'. Stop. This error is raised by this command: $(MAKE) $(MAKEFLAGS) -C $(REGEX_DIR) $(notdir $(REGEX_OBJS)) which means that MAKEFLAGS is set to "w -j --jobserver-fds=3,4". I don't understand where this "w" and not "-w" is coming from. Do you have any advice or clue? I can make a patch to remove MAKEFLAGS but this won't be upstreamable. Thanks for your help. > > > > > @@ -20,7 +20,6 @@ NGREP_CONF_ENV += LIBS+="$(NGREP_LIBS)" > > > > > > This assignment becomes totally pointless. > > OK, I'll replace it by: > > ifeq ($(BR2_STATIC_LIBS),y) > > NGREP_CONF_ENV += LIBS="$(STAGING_DIR)/usr/bin/pcap-config --static > > --additional-libs" > > endif > > Sorry, my bad here, I had entirely missed that NGREP_LIBS was still > being set in the BR2_STATIC_LIBS case. So the way you did it originally > was OK, sorry about that. Doing is directly in NGREP_CONF_ENV also > works, since there will be a single assignment of LIBS. > > > > You should add a --disable-tcpkill here, and then in your PATCH 2/2, > > > add the optional dependency on libdnet. > > OK, I'll make a v2 with this update (and the other ones) > > Thanks! > > Thomas > -- > Thomas Petazzoni, CTO, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com Best Regards, Fabrice
Hello, On Sun, 4 Nov 2018 12:04:19 +0100, Fabrice Fontaine wrote: > > Indeed, it could be a third patch. > OK, when I tried to enable GNU regex (on 1.47), I got the following error: > /usr/bin/make w -j --jobserver-fds=3,4 -C regex-0.12 regex.o > make[2]: Entering directory > '/home/fabrice/buildroot/output/build/ngrep-1_47/regex-0.12' > make[2]: *** No rule to make target 'w'. Stop. > > This error is raised by this command: > $(MAKE) $(MAKEFLAGS) -C $(REGEX_DIR) $(notdir $(REGEX_OBJS)) > > which means that MAKEFLAGS is set to "w -j --jobserver-fds=3,4". > I don't understand where this "w" and not "-w" is coming from. Do you > have any advice or clue? > I can make a patch to remove MAKEFLAGS but this won't be upstreamable. > Thanks for your help. I don't immediately have an idea, but I did a build of ngrep 1.47 without pcre enabled, and it build fine here. I did this yesterday, before replying to you that pcre was an optional dependency. Anyway, we can keep pcre as a mandatory dependency for now, so I'll apply your original patch. Best regards, Thomas
Hi Fabric, Fabrice Fontaine writes: > Dear Thomas, > Le dim. 4 nov. 2018 à 11:19, Thomas Petazzoni > <thomas.petazzoni@bootlin.com> a écrit : >> >> Hello, >> >> On Sat, 3 Nov 2018 23:01:07 +0100, Fabrice Fontaine wrote: >> >> > > So PCRE is not mandatory. >> > Indeed, PCRE is not really "mandatory", ngrep use GNU regex by default >> > but this was already the case before the bump (in version 1.45): see >> > https://github.com/jpr5/ngrep/blob/V1_45/configure.in. >> > I didn't want to change this behavior when bumping the package and I >> > could find why pcre wasn't made optional in the initial commit back in >> > 2011. >> > However, I'll add a third patch in my serie to make pcre an optional >> > dependency before bumping the package.. >> >> Indeed, it could be a third patch. > OK, when I tried to enable GNU regex (on 1.47), I got the following error: > /usr/bin/make w -j --jobserver-fds=3,4 -C regex-0.12 regex.o > make[2]: Entering directory > '/home/fabrice/buildroot/output/build/ngrep-1_47/regex-0.12' > make[2]: *** No rule to make target 'w'. Stop. > > This error is raised by this command: > $(MAKE) $(MAKEFLAGS) -C $(REGEX_DIR) $(notdir $(REGEX_OBJS)) > > which means that MAKEFLAGS is set to "w -j --jobserver-fds=3,4". > I don't understand where this "w" and not "-w" is coming from. Do you > have any advice or clue? This is most likely related to mismatch of make versions being used when we build our own host-make. See the discussion in this thread related to boa: http://lists.busybox.net/pipermail/buildroot/2018-October/232957.html There is no fix to this issue yet. baruch
On 04/11/18 12:34, Baruch Siach wrote: > Hi Fabric, > > Fabrice Fontaine writes: >> Dear Thomas, >> Le dim. 4 nov. 2018 à 11:19, Thomas Petazzoni >> <thomas.petazzoni@bootlin.com> a écrit : >>> >>> Hello, >>> >>> On Sat, 3 Nov 2018 23:01:07 +0100, Fabrice Fontaine wrote: >>> >>>>> So PCRE is not mandatory. >>>> Indeed, PCRE is not really "mandatory", ngrep use GNU regex by default >>>> but this was already the case before the bump (in version 1.45): see >>>> https://github.com/jpr5/ngrep/blob/V1_45/configure.in. >>>> I didn't want to change this behavior when bumping the package and I >>>> could find why pcre wasn't made optional in the initial commit back in >>>> 2011. >>>> However, I'll add a third patch in my serie to make pcre an optional >>>> dependency before bumping the package.. >>> >>> Indeed, it could be a third patch. >> OK, when I tried to enable GNU regex (on 1.47), I got the following error: >> /usr/bin/make w -j --jobserver-fds=3,4 -C regex-0.12 regex.o >> make[2]: Entering directory >> '/home/fabrice/buildroot/output/build/ngrep-1_47/regex-0.12' >> make[2]: *** No rule to make target 'w'. Stop. >> >> This error is raised by this command: >> $(MAKE) $(MAKEFLAGS) -C $(REGEX_DIR) $(notdir $(REGEX_OBJS)) >> >> which means that MAKEFLAGS is set to "w -j --jobserver-fds=3,4". >> I don't understand where this "w" and not "-w" is coming from. Do you >> have any advice or clue? > > This is most likely related to mismatch of make versions being used when > we build our own host-make. See the discussion in this thread related to > boa: > > http://lists.busybox.net/pipermail/buildroot/2018-October/232957.html > > There is no fix to this issue yet. Since we don't really want to pass any flags from Buildroot down to the package build systems, perhaps we should just set override MAKE := make <jlevel stuff> at the top of package/Makefile.in? I've done a quick test, and it seems to fix the boa issue at least. This would revert the following commit though: commit 4705b600764c683e934da7db54f7971a3c647e8a Author: Ulf Samuelsson <ulf.samuelsson@atmel.com> Date: Tue Jul 17 14:09:07 2007 Ensure we use host 'make', even when building 'make' in buildroot but that doesn't explain why it is not wanted to use the Buildroot-built make... Regards, Arnout Regards, Arnout
Hello, On Tue, 6 Nov 2018 01:14:48 +0100, Arnout Vandecappelle wrote: > Since we don't really want to pass any flags from Buildroot down to the package > build systems, perhaps we should just set > > override MAKE := make <jlevel stuff> > > at the top of package/Makefile.in? I've done a quick test, and it seems to fix > the boa issue at least. > > This would revert the following commit though: > > commit 4705b600764c683e934da7db54f7971a3c647e8a > Author: Ulf Samuelsson <ulf.samuelsson@atmel.com> > Date: Tue Jul 17 14:09:07 2007 > > Ensure we use host 'make', even when building 'make' in buildroot > > but that doesn't explain why it is not wanted to use the Buildroot-built make... But then it would mean that if you have a build like this: packageA packageB packageC host-make packageD packageE packageF then package{A,B,C} would be built with the system-provided make, and then package{D,E,F} would be built with host-make ? Is this really a desirable situation ? Thomas
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes: > Hello, > On Tue, 6 Nov 2018 01:14:48 +0100, Arnout Vandecappelle wrote: >> Since we don't really want to pass any flags from Buildroot down to the package >> build systems, perhaps we should just set >> >> override MAKE := make <jlevel stuff> >> >> at the top of package/Makefile.in? I've done a quick test, and it seems to fix >> the boa issue at least. >> >> This would revert the following commit though: >> >> commit 4705b600764c683e934da7db54f7971a3c647e8a >> Author: Ulf Samuelsson <ulf.samuelsson@atmel.com> >> Date: Tue Jul 17 14:09:07 2007 >> >> Ensure we use host 'make', even when building 'make' in buildroot >> >> but that doesn't explain why it is not wanted to use the Buildroot-built make... > But then it would mean that if you have a build like this: > packageA > packageB > packageC > host-make > packageD > packageE > packageF > then package{A,B,C} would be built with the system-provided make, and > then package{D,E,F} would be built with host-make ? Is this really a > desirable situation ? Well, it sounds better than the breakage we have today. In general, mixing make versions in recursive invocations seems a bit icky. I guess we could end up with issues if/when we do toplevel parallel builds as well if the job control tracking differs between versions.
On 06/11/18 10:54, Peter Korsgaard wrote: >>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes: > > > Hello, > > On Tue, 6 Nov 2018 01:14:48 +0100, Arnout Vandecappelle wrote: > > >> Since we don't really want to pass any flags from Buildroot down to the package > >> build systems, perhaps we should just set > >> > >> override MAKE := make <jlevel stuff> > >> > >> at the top of package/Makefile.in? I've done a quick test, and it seems to fix > >> the boa issue at least. > >> > >> This would revert the following commit though: > >> > >> commit 4705b600764c683e934da7db54f7971a3c647e8a > >> Author: Ulf Samuelsson <ulf.samuelsson@atmel.com> > >> Date: Tue Jul 17 14:09:07 2007 > >> > >> Ensure we use host 'make', even when building 'make' in buildroot > >> > >> but that doesn't explain why it is not wanted to use the Buildroot-built make... > > > But then it would mean that if you have a build like this: > > > packageA > > packageB > > packageC > > host-make > > packageD > > packageE > > packageF > > > then package{A,B,C} would be built with the system-provided make, and > > then package{D,E,F} would be built with host-make ? Is this really a > > desirable situation ? > > Well, it sounds better than the breakage we have today. At first sight, I don't see why it should be a problem to use a different make for different packages. A bit weird, but it really shouldn't affect reproducibility or anything. > In general, mixing make versions in recursive invocations seems a bit > icky. I guess we could end up with issues if/when we do toplevel > parallel builds as well if the job control tracking differs between > versions. Ooh, yes, top-level parallel build might break dramatically in such a situation... Well, let's fix that problem when we get there, right? Regards, Arnout
>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes: Hi, >> > then package{A,B,C} would be built with the system-provided make, and >> > then package{D,E,F} would be built with host-make ? Is this really a >> > desirable situation ? >> >> Well, it sounds better than the breakage we have today. > At first sight, I don't see why it should be a problem to use a different make > for different packages. A bit weird, but it really shouldn't affect > reproducibility or anything. Well, it could in case a package behaved differently depending on the make version (E.G. newer make versions have broken older Makefiles), so enabling a package X that pulls in host-make suddenly changes something for the build of package Y - Or the other way around, E.G. package Y depends on package X which pulls in host-make so we never notice that package Y needs a newer make version, and then a version bump of Y makes X optional, .. But I agree that it is quite unlikely to cause any real issues. >> In general, mixing make versions in recursive invocations seems a bit >> icky. I guess we could end up with issues if/when we do toplevel >> parallel builds as well if the job control tracking differs between >> versions. > Ooh, yes, top-level parallel build might break dramatically in such a situation... > Well, let's fix that problem when we get there, right? Agreed!
diff --git a/package/ngrep/0001-Fix-typo-in-configure-in-when-testing-for-use_pcre.patch b/package/ngrep/0001-Fix-typo-in-configure-in-when-testing-for-use_pcre.patch new file mode 100644 index 0000000000..69c5c887e8 --- /dev/null +++ b/package/ngrep/0001-Fix-typo-in-configure-in-when-testing-for-use_pcre.patch @@ -0,0 +1,25 @@ +From b8b1e9751e1d074af0dd77c2554c1b25fd8f7abe Mon Sep 17 00:00:00 2001 +From: Romain Francoise <romain@rfr.io> +Date: Mon, 1 Jan 2018 18:00:34 +0100 +Subject: [PATCH] Fix typo in configure.in when testing for use_pcre + +Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> +[Retrieved from: +https://github.com/jpr5/ngrep/commit/b8b1e9751e1d074af0dd77c2554c1b25fd8f7abe] +--- + configure.in | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/configure.in b/configure.in +index cff37e9..06c050a 100644 +--- a/configure.in ++++ b/configure.in +@@ -146,7 +146,7 @@ AC_ARG_ENABLE(pcre, + [ use_pcre="$enableval" ], + [ use_pcre="no" ]) + +-if test use_pcre = yes; then ++if test $use_pcre = yes; then + USE_PCRE="1" + EXTRA_LIBS="$EXTRA_LIBS -lpcre" + else diff --git a/package/ngrep/0001-make-objs.patch b/package/ngrep/0001-make-objs.patch deleted file mode 100644 index 8b55e3f456..0000000000 --- a/package/ngrep/0001-make-objs.patch +++ /dev/null @@ -1,23 +0,0 @@ -ngrep: don't include regex objects since we're using pcre - -Signed-off-by: Wade Berrier <wberrier@gmail.com> - ---- ngrep-1.45/Makefile.in.orig 2006-11-28 06:35:37.000000000 -0700 -+++ ngrep-1.45/Makefile.in 2011-06-29 14:05:27.000000000 -0600 -@@ -32,13 +32,13 @@ - - INSTALL = ./install-sh - --REGEX_DIR=@REGEX_DIR@ --REGEX_OBJS=@REGEX_OBJS@ -+REGEX_DIR= -+REGEX_OBJS= - - - all: $(TARGET) - --$(TARGET): $(REGEX_OBJS) $(OBJS) -+$(TARGET): $(OBJS) - $(CC) $(CFLAGS) $(LDFLAGS) $(STRIPFLAG) -o $(TARGET) $(OBJS) $(REGEX_OBJS) $(LIBS) - - debug: $(REGEX_OBJS) $(OBJS) diff --git a/package/ngrep/0002-pcre-header.patch b/package/ngrep/0002-pcre-header.patch deleted file mode 100644 index 40b9234dbc..0000000000 --- a/package/ngrep/0002-pcre-header.patch +++ /dev/null @@ -1,16 +0,0 @@ -ngrep: don't use versioned header - -Signed-off-by: Wade Berrier <wberrier@gmail.com> - -diff -ur ngrep-1.45/ngrep.c ngrep-1.45.mod/ngrep.c ---- ngrep-1.45/ngrep.c Tue Nov 28 15:38:43 2006 -+++ ngrep-1.45.mod/ngrep.c Sat May 19 10:21:27 2007 -@@ -92,7 +92,7 @@ - #endif - - #if USE_PCRE --#include "pcre-5.0/pcre.h" -+#include "pcre.h" - #else - #include "regex-0.12/regex.h" - #endif diff --git a/package/ngrep/0003-fix-static-link.patch b/package/ngrep/0003-fix-static-link.patch deleted file mode 100644 index 98c262696d..0000000000 --- a/package/ngrep/0003-fix-static-link.patch +++ /dev/null @@ -1,25 +0,0 @@ -ngrep: fix static link with pcre - -Libraries must be placed after object files. - -Signed-off-by: Romain Naour <romain.naour@openwide.fr> ---- - Makefile.in | 2 +- - 1 file changed, 1 insertion(+), 1 deletion(-) - -diff --git a/Makefile.in b/Makefile.in -index 2ae4506..761d7d9 100644 ---- a/Makefile.in -+++ b/Makefile.in -@@ -11,7 +11,7 @@ CFLAGS=@CFLAGS@ -D@OS@ @DEFS@ @EXTRA_DEFINES@ - INCLUDES=-I@srcdir@ @PCAP_INCLUDE@ @EXTRA_INCLUDES@ - - LDFLAGS=@LDFLAGS@ @PCAP_LINK@ --LIBS=-lpcap @EXTRA_LIBS@ -+LIBS=@LIBS@ @EXTRA_LIBS@ - - STRIPFLAG=@STRIPFLAG@ - --- -1.8.1.4 - diff --git a/package/ngrep/Config.in b/package/ngrep/Config.in index cd91225791..5f87f2f79b 100644 --- a/package/ngrep/Config.in +++ b/package/ngrep/Config.in @@ -5,4 +5,4 @@ config BR2_PACKAGE_NGREP help Network grep. - http://ngrep.sourceforge.net/ + https://github.com/jpr5/ngrep/ diff --git a/package/ngrep/ngrep.hash b/package/ngrep/ngrep.hash index e0a6a2580b..bf9e621a89 100644 --- a/package/ngrep/ngrep.hash +++ b/package/ngrep/ngrep.hash @@ -1,2 +1,3 @@ # Locally computed: -sha256 aea6dd337da8781847c75b3b5b876e4de9c58520e0d77310679a979fc6402fa7 ngrep-1.45.tar.bz2 +sha256 dc4dbe20991cc36bac5e97e99475e2a1522fd88c59ee2e08f813432c04c5fff3 ngrep-1_47.tar.gz +sha256 d46e593e048e0b9fc803561ed4c283f37a2d5447e4dcfa10cad29b394c2b8b9e LICENSE diff --git a/package/ngrep/ngrep.mk b/package/ngrep/ngrep.mk index 3f569374b4..f116e34e42 100644 --- a/package/ngrep/ngrep.mk +++ b/package/ngrep/ngrep.mk @@ -4,14 +4,14 @@ # ################################################################################ -NGREP_VERSION = 1.45 -NGREP_SOURCE = ngrep-$(NGREP_VERSION).tar.bz2 -NGREP_SITE = http://downloads.sourceforge.net/project/ngrep/ngrep/$(NGREP_VERSION) +NGREP_VERSION = 1_47 +NGREP_SITE = $(call github,jpr5,ngrep,V$(NGREP_VERSION)) NGREP_LICENSE = BSD-4-Clause-like -NGREP_LICENSE_FILES = LICENSE.txt +NGREP_LICENSE_FILES = LICENSE NGREP_INSTALL_STAGING = YES +# We're patching configure.in +NGREP_AUTORECONF = YES -NGREP_LIBS = -lpcap -lpcre ifeq ($(BR2_STATIC_LIBS),y) NGREP_LIBS += `$(STAGING_DIR)/usr/bin/pcap-config --static --additional-libs` endif @@ -20,7 +20,6 @@ NGREP_CONF_ENV += LIBS+="$(NGREP_LIBS)" NGREP_CONF_OPTS = \ --with-pcap-includes=$(STAGING_DIR)/usr/include/pcap \ --enable-pcre \ - --with-pcre=$(STAGING_DIR)/usr \ --disable-dropprivs \ --disable-pcap-restart
- Switch site from sourceforge to github as there is no new releases on sourceforge and http://ngrep.sourceforge.net/ is redirected to https://github.com/jpr5/ngrep/ - Remove first patch, not needed since version 1.46 and https://github.com/jpr5/ngrep/commit/997c9d81d34d3a6646e6c5e363645015e644b3de as this commit added the support for system pcre - Remove second patch, not needed since version 1.46 and https://github.com/jpr5/ngrep/commit/2d8fd9ac7ef1ac6947f738f6005e7b533654f331 - Remove third patch and LIBS=-lpcap -lpcre, not needed since 1.46 and https://github.com/jpr5/ngrep/commit/cca6e3121f2d80dd32a5a33dead9495fe40eed70 - LICENSE.txt has been renamed to LICENSE since version 1.47 and https://github.com/jpr5/ngrep/commit/3cb4c580a9de4afe11c2c17b0f354b59b74ae974 - Add an upstream patch to fix --enable-pcre - Remove --with-pcre which is not recognized anymore - Add hash for license file Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> --- ...nfigure-in-when-testing-for-use_pcre.patch | 25 +++++++++++++++++++ package/ngrep/0001-make-objs.patch | 23 ----------------- package/ngrep/0002-pcre-header.patch | 16 ------------ package/ngrep/0003-fix-static-link.patch | 25 ------------------- package/ngrep/Config.in | 2 +- package/ngrep/ngrep.hash | 3 ++- package/ngrep/ngrep.mk | 11 ++++---- 7 files changed, 33 insertions(+), 72 deletions(-) create mode 100644 package/ngrep/0001-Fix-typo-in-configure-in-when-testing-for-use_pcre.patch delete mode 100644 package/ngrep/0001-make-objs.patch delete mode 100644 package/ngrep/0002-pcre-header.patch delete mode 100644 package/ngrep/0003-fix-static-link.patch