ngrep: bump to version 1.47

PATCH Superseded Fabrice Fontaine 5 participants 13 messages Nov 1, 2018 – Nov 6, 2018

Share & tools

Fabrice Fontaine

author

2018-11-01 13:23 UTC #0 lore raw

PATCH 1/2 ngrep: bump to version 1.47

- 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 <[email protected]>

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

package/ngrep/0001-Fix-typo-in-configure-in-when-testing-for-use_pcre.patch new file +25 -0

new file mode 100644
index 0000000000..69c5c887e8
@@ -0,0 +1,25 @@
+From b8b1e9751e1d074af0dd77c2554c1b25fd8f7abe Mon Sep 17 00:00:00 2001
+From: Romain Francoise <[email protected]>
+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 <[email protected]>
+[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

package/ngrep/0001-make-objs.patch deleted +0 ~~-23~~

deleted file mode 100644
index 8b55e3f456..0000000000
@@ -1,23 +0,0 @@
-ngrep: don't include regex objects since we're using pcre
-
-Signed-off-by: Wade Berrier <[email protected]>
-
---- 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)

package/ngrep/0002-pcre-header.patch deleted +0 ~~-16~~

deleted file mode 100644
index 40b9234dbc..0000000000
@@ -1,16 +0,0 @@
-ngrep: don't use versioned header
-
-Signed-off-by: Wade Berrier <[email protected]>
-
-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

package/ngrep/0003-fix-static-link.patch deleted +0 ~~-25~~

deleted file mode 100644
index 98c262696d..0000000000
@@ -1,25 +0,0 @@
-ngrep: fix static link with pcre
-
-Libraries must be placed after object files.
-
-Signed-off-by: Romain Naour <[email protected]>
----
- 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
-

package/ngrep/Config.in +1 -1

index cd91225791..5f87f2f79b 100644
@@ -5,4 +5,4 @@ config BR2_PACKAGE_NGREP
 	help
 	  Network grep.
 
-	  http://ngrep.sourceforge.net/
+	  https://github.com/jpr5/ngrep/

package/ngrep/ngrep.hash +2 -1

index e0a6a2580b..bf9e621a89 100644
@@ -1,2 +1,3 @@
 # Locally computed:
-sha256  aea6dd337da8781847c75b3b5b876e4de9c58520e0d77310679a979fc6402fa7  ngrep-1.45.tar.bz2
+sha256  dc4dbe20991cc36bac5e97e99475e2a1522fd88c59ee2e08f813432c04c5fff3  ngrep-1_47.tar.gz
+sha256  d46e593e048e0b9fc803561ed4c283f37a2d5447e4dcfa10cad29b394c2b8b9e  LICENSE

package/ngrep/ngrep.mk +5 -6

index 3f569374b4..f116e34e42 100644
@@ -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

Signature · 1 line

2.17.1

Fabrice Fontaine

author

2018-11-01 13:23 UTC #1 lore raw

PATCH 2/2 ngrep: add libnet optional dependency

- 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 <[email protected]>

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

package/ngrep/0002-Check-for-libnet_init-in-configure-in.patch new file +28 -0

new file mode 100644
index 0000000000..22b18ab7ee
@@ -0,0 +1,28 @@
+From 0a51c8bc62c7b49b8d67a360daa6b1957256f4f5 Mon Sep 17 00:00:00 2001
+From: Romain Francoise <[email protected]>
+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 <[email protected]>
+[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" ])

package/ngrep/ngrep.mk +8 -1

index f116e34e42..d4c84b9639 100644
@@ -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))

Signature · 1 line

2.17.1

Thomas Petazzoni

2018-11-03 21:42 UTC #2 lore raw

PATCH 1/2 ngrep: bump to version 1.47

In reply to Fabrice Fontaine

Hello,

Quoted 1 line · Fabrice Fontaine

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

Quoted 1 line

-NGREP_LIBS = -lpcap -lpcre

Since this variable no longer exists...

Review NGREP_CONF_ENV += LIBS+="$(NGREP_LIBS)"

Quoted 4 lines

ifeq ($(BR2_STATIC_LIBS),y)
NGREP_LIBS += $(STAGING_DIR)/usr/bin/pcap-config --static --additional-libs endif
(quoted diff) +0 -0
@@ -20,7 +20,6 @@ NGREP_CONF_ENV += LIBS+="$(NGREP_LIBS)"

This assignment becomes totally pointless.

package/ngrep/ngrep.mk NGREP_CONF_ENV += LIBS+="$(NGREP_LIBS)" · line 25

Quoted 7 lines

package/ngrep/ngrep.mk +0 -1

 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

Signature · 3 lines

Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Fabrice Fontaine

author

2018-11-03 22:01 UTC #3 lore raw

PATCH 1/2 ngrep: bump to version 1.47

Dear Thomas,
Le sam. 3 nov. 2018 ? 22:42, Thomas Petazzoni
<[email protected]> a ?crit :

Quoted 7 lines

Hello,
Quoted 1 line · Fabrice Fontaine
- Add an upstream patch to fix --enable-pcre

Quoted 8 lines

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

Quoted 4 lines

Quoted 2 lines
-NGREP_LIBS = -lpcap -lpcre
Since this variable no longer exists...

Yes, -lpcap and -lpcre are now correctly added by the project.

Quoted 7 lines

Review NGREP_CONF_ENV += LIBS+="$(NGREP_LIBS)"
Quoted 5 lines
ifeq ($(BR2_STATIC_LIBS),y)
NGREP_LIBS += $(STAGING_DIR)/usr/bin/pcap-config --static --additional-libs endif
(quoted diff) +0 -0
@@ -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

Quoted 11 lines

package/ngrep/ngrep.mk NGREP_CONF_ENV += LIBS+="$(NGREP_LIBS)" · line 25
Quoted 8 lines
package/ngrep/ngrep.mk +0 -1
 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)

Quoted 7 lines

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.

Quoted 8 lines

Thanks!
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Best Regards,

Fabrice

Thomas Petazzoni

2018-11-04 10:19 UTC #4 lore raw

PATCH 1/2 ngrep: bump to version 1.47

Hello,

Quoted 9 lines · Fabrice Fontaine

Quoted 1 line
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.

Quoted 8 lines

Quoted 3 lines
Review NGREP_CONF_ENV += LIBS+="$(NGREP_LIBS)"
Quoted 1 line
(quoted diff) +0 -0
@@ -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.

Quoted 3 lines

Quoted 2 lines
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

Signature · 3 lines

Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Fabrice Fontaine

author

2018-11-04 11:04 UTC #5 lore raw

PATCH 1/2 ngrep: bump to version 1.47

Dear Thomas,
Le dim. 4 nov. 2018 ? 11:19, Thomas Petazzoni
<[email protected]> a ?crit :

Quoted 15 lines

Hello,
Quoted 9 lines · Fabrice Fontaine
Quoted 1 line
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..

Quoted 1 line

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.

Quoted 19 lines

Quoted 9 lines
Quoted 4 lines
Review NGREP_CONF_ENV += LIBS+="$(NGREP_LIBS)"
Quoted 2 lines
(quoted diff) +0 -0
@@ -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.
Quoted 3 lines
Quoted 2 lines
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)

Quoted 7 lines

Thanks!
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Best Regards,

Fabrice

Thomas Petazzoni

2018-11-04 11:28 UTC #6 lore raw

PATCH 1/2 ngrep: bump to version 1.47

Hello,

Quoted 7 lines · Fabrice Fontaine

Quoted 1 line
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.

Quoted 8 lines

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

Signature · 3 lines

Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Baruch Siach

2018-11-04 11:34 UTC #7 lore raw

PATCH 1/2 ngrep: bump to version 1.47

In reply to Fabrice Fontaine

Hi Fabric,

Quoted 25 lines · Fabrice Fontaine

Dear Thomas,
Le dim. 4 nov. 2018 ? 11:19, Thomas Petazzoni
<[email protected]> a ?crit :
Quoted 15 lines
Hello,
Quoted 9 lines · Fabrice Fontaine
Quoted 1 line
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..
Quoted 1 line
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.

Quoted 6 lines

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

Signature · 3 lines

     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 -

Arnout Vandecappelle

2018-11-06 00:14 UTC #8 lore raw

PATCH 1/2 ngrep: bump to version 1.47

Quoted 35 lines · Baruch Siach

Hi Fabric,
Quoted 25 lines · Fabrice Fontaine
Dear Thomas,
Le dim. 4 nov. 2018 ? 11:19, Thomas Petazzoni
<[email protected]> a ?crit :
Quoted 15 lines
Hello,
Quoted 9 lines · Fabrice Fontaine
Quoted 1 line
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..
Quoted 1 line
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.
Quoted 6 lines
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?

Quoted 7 lines

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 <[email protected]>
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

Thomas Petazzoni

2018-11-06 07:59 UTC #9 lore raw

PATCH 1/2 ngrep: bump to version 1.47

Hello,

Quoted 10 lines · Arnout Vandecappelle

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:

Quoted 7 lines

commit 4705b600764c683e934da7db54f7971a3c647e8a
Author: Ulf Samuelsson <[email protected]>
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

Signature · 3 lines

Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Peter Korsgaard

2018-11-06 09:54 UTC #10 lore raw

PATCH 1/2 ngrep: bump to version 1.47

Quoted 33 lines

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas Petazzoni <[email protected]> writes:
Hello,
Quoted 10 lines · Arnout Vandecappelle
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:
Quoted 7 lines
commit 4705b600764c683e934da7db54f7971a3c647e8a
Author: Ulf Samuelsson <[email protected]>
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

Quoted 3 lines

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.

Signature · 1 line

Bye, Peter Korsgaard

Arnout Vandecappelle

2018-11-06 10:31 UTC #11 lore raw

PATCH 1/2 ngrep: bump to version 1.47

Quoted 33 lines · Peter Korsgaard

Quoted 32 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas Petazzoni <[email protected]> writes:
Hello,
Quoted 10 lines · Arnout Vandecappelle
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:
Quoted 7 lines
commit 4705b600764c683e934da7db54f7971a3c647e8a
Author: Ulf Samuelsson <[email protected]>
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

Quoted 5 lines

Quoted 3 lines
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.

Quoted 4 lines

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

Peter Korsgaard

2018-11-06 11:18 UTC #12 lore raw

PATCH 1/2 ngrep: bump to version 1.47

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Arnout" == Arnout Vandecappelle <[email protected]> writes:

Hi,

Quoted 9 lines

Quoted 5 lines
Quoted 3 lines
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.

Quoted 8 lines

Quoted 4 lines
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!

Signature · 1 line

Bye, Peter Korsgaard