[Buildroot] [PATCH 1/2] ngrep: bump to version 1.47

[Buildroot] [PATCH 1/2] ngrep: bump to version 1.47

[Fabrice Fontaine]

- 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

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 at OS@ @DEFS@ @EXTRA_DEFINES@
- INCLUDES=-I at 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
 
-- 
2.17.1

[Buildroot] [PATCH 2/2] ngrep: add libnet optional dependency

[Fabrice Fontaine]

- Enable tcpkill based on libnet availability
- Add BSD-3-Clause for tcpkill, added in version 1.46 and
  https://github.com/jpr5/ngrep/commit/f2a1f8b09194a8ab87787c1fdb60b968f5957c05

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
---
 ...heck-for-libnet_init-in-configure-in.patch | 28 +++++++++++++++++++
 package/ngrep/ngrep.mk                        |  9 +++++-
 2 files changed, 36 insertions(+), 1 deletion(-)
 create mode 100644 package/ngrep/0002-Check-for-libnet_init-in-configure-in.patch

diff --git a/package/ngrep/0002-Check-for-libnet_init-in-configure-in.patch b/package/ngrep/0002-Check-for-libnet_init-in-configure-in.patch
new file mode 100644
index 0000000000..22b18ab7ee
--- /dev/null
+++ b/package/ngrep/0002-Check-for-libnet_init-in-configure-in.patch
@@ -0,0 +1,28 @@
+From 0a51c8bc62c7b49b8d67a360daa6b1957256f4f5 Mon Sep 17 00:00:00 2001
+From: Romain Francoise <romain@rfr.io>
+Date: Mon, 1 Jan 2018 18:01:13 +0100
+Subject: [PATCH] Check for libnet_init in configure.in
+
+libnet_init_packet was the old libnet 1.0 function which is now long
+deprecated.
+
+Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
+[Retrieved from:
+https://github.com/jpr5/ngrep/commit/0a51c8bc62c7b49b8d67a360daa6b1957256f4f5]
+---
+ configure.in | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/configure.in b/configure.in
+index 06c050a..dbef39b 100644
+--- a/configure.in
++++ b/configure.in
+@@ -174,7 +174,7 @@ dnl
+ AC_ARG_ENABLE(tcpkill,
+ [  --enable-tcpkill        enable connection killing support (default off)],
+ [
+-  AC_CHECK_LIB(net, libnet_init_packet,,echo !!! error: tcpkill feature enabled but no libnet found; exit)
++  AC_CHECK_LIB(net, libnet_init,,echo !!! error: tcpkill feature enabled but no libnet found; exit)
+   use_tcpkill="$enableval"
+ ],
+ [ use_tcpkill="no" ])
diff --git a/package/ngrep/ngrep.mk b/package/ngrep/ngrep.mk
index f116e34e42..d4c84b9639 100644
--- a/package/ngrep/ngrep.mk
+++ b/package/ngrep/ngrep.mk
@@ -6,7 +6,7 @@
 
 NGREP_VERSION = 1_47
 NGREP_SITE = $(call github,jpr5,ngrep,V$(NGREP_VERSION))
-NGREP_LICENSE = BSD-4-Clause-like
+NGREP_LICENSE = BSD-4-Clause-like, BSD-3-Clause (tcpkill)
 NGREP_LICENSE_FILES = LICENSE
 NGREP_INSTALL_STAGING = YES
 # We're patching configure.in
@@ -25,4 +25,11 @@ NGREP_CONF_OPTS = \
 
 NGREP_DEPENDENCIES = libpcap pcre
 
+ifeq ($(BR2_PACKAGE_LIBNET),y)
+NGREP_DEPENDENCIES += libnet
+NGREP_CONF_OPTS += --enable-tcpkill
+else
+NGREP_CONF_OPTS += --disable-tcpkill
+endif
+
 $(eval $(autotools-package))
-- 
2.17.1

[Buildroot] [PATCH 1/2] ngrep: bump to version 1.47

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH 1/2] ngrep: bump to version 1.47

[Fabrice Fontaine]

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

[Buildroot] [PATCH 1/2] ngrep: bump to version 1.47

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH 1/2] ngrep: bump to version 1.47

[Fabrice Fontaine]

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

[Buildroot] [PATCH 1/2] ngrep: bump to version 1.47

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH 1/2] ngrep: bump to version 1.47

[Baruch Siach]

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

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

[Buildroot] [PATCH 1/2] ngrep: bump to version 1.47

[Arnout Vandecappelle]

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

[Buildroot] [PATCH 1/2] ngrep: bump to version 1.47

[Thomas Petazzoni]

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 Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH 1/2] ngrep: bump to version 1.47

[Peter Korsgaard]

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

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 1/2] ngrep: bump to version 1.47

[Arnout Vandecappelle]

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

[Buildroot] [PATCH 1/2] ngrep: bump to version 1.47

[Peter Korsgaard]

>>>>> "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!

-- 
Bye, Peter Korsgaard