Re: [tcpdump-workers] [tcpdump-security] [libpcap] Problem with version 1.9.0

2018-07-24 Thread Dagobert Michelsen
Hi Denis,

Am 24.07.2018 um 10:51 schrieb Denis Ovsienko :
> You had this exact discussion 2 weeks ago, didn't you? For the avoidance of 
> doubt, this thread isn't about voting.

Ah right, it did feel like some kind of deja vu but I falsely remembered
that to be on a different mailing list.


Sorry for the noise!

  — Dago

-- 
"You don't become great by trying to be great, you become great by wanting to 
do something,
and then doing it so hard that you become great in the process." - xkcd #896

___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Re: [tcpdump-workers] [tcpdump-security] [libpcap] Problem with version 1.9.0

2018-07-24 Thread Denis Ovsienko
  On Mon, 23 Jul 2018 21:33:00 +0100 Dagobert Michelsen  
wrote  
 > Hi Jan,
 > 
 > Am 23.07.2018 um 22:04 schrieb Jan Stary :
 > > 
 > > From both a sysadmin and user perspective, I find the GNU autotools
 > > amd CMake a major annoyance. Would you please consider doing what e.g.
 > > http://mandoc.bsd.lv/cgi-bin/cvsweb/configure does?
 > > 
 > > A simple, hand written shell script, with a set of obvious
 > > {test,compat}-*.c helpers. No dependency on anything, orders
 > > of multitude smaller and faster then a auto*-generated configure.
 > 
 > No - please! Handwritten configure scripts are the worst nightmare for
 > downstream packages as each package uses its own way to configure flags
 > for compilation, linkage, install relocation etc. This makes
 > packaging stuff hard as it requires specific adjustments of build
 > procedures. I maintain roughly 1600 packages and this would not be
 > possible when there were no standards. Autotools is far from perfect,
 > but it is a standard and after you figured something out it works for
 > hundreds of builds in the same way.

You had this exact discussion 2 weeks ago, didn't you? For the avoidance of 
doubt, this thread isn't about voting.

Autotools has historically been the build solution because tcpdump originates 
from the UNIX world, and used to compile and work on much more flavors than a 
typical modern software. AIX, HP-UX and Solaris are still around and configure 
works there.

Guy has [relatively] recently added cmake as an alternative build solution 
because, as far as I understand, it also supports Windows in a way that is 
simpler to maintain than autotools. I do not build any software on Windows and 
I do not use cmake to build any software, so this is my interpretation, feel 
free to correct.

Perhaps if someone had written down, in plain English, which specific steps it 
takes to compile tcpdump/libpcap, it would be easier to see if it can be done 
with a simple shell script.

-- 
Denis Ovsienko


___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Re: [tcpdump-workers] [tcpdump-security] [libpcap] Problem with version 1.9.0

2018-07-23 Thread Jan Stary
On Jul 23 13:30:55, g...@alum.mit.edu wrote:
> On Jul 23, 2018, at 1:04 PM, Jan Stary  wrote:
> 
> > From both a sysadmin and user perspective, I find the GNU autotools
> > amd CMake a major annoyance. Would you please consider doing what e.g.
> > http://mandoc.bsd.lv/cgi-bin/cvsweb/configure does?
> 
> What advantage would it give us that would make it worth our effort?

A ./configure script like that is (in my experience) much more
readable and writable, and about hundreds of times faster.
It does not depend on autoconf, automake, m4, etc and does not
require the user to install, to run, or to understand the GNU tools.
The produced Makefile.* is a fraction of that produced by auto*.

Please try it out, either with http://mandoc.bsd.lv/ or with
e.g. https://github.com/columbia-irt/rtptools to see for yourself.
Run ./configure and look at config.h and Makefile.*: clean, obvious code.

To quote from http://mandoc.bsd.lv/cgi-bin/cvsweb/INSTALL :

  The mandoc package intentionally does not use GNU autoconf because
  we consider that toolset a blatant example of overengineering that
  is obsolete nowadays, since all modern operating systems are now
  reasonably close to POSIX and do not need arcane shell magic any
  longer.  If your system does need such magic, consider upgrading
  to reasonably modern POSIX-compliant tools rather than asking for
  autoconf-style workarounds.

If you decide to go that way, I am prepared to help with the effort.

Jan

___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Re: [tcpdump-workers] [tcpdump-security] [libpcap] Problem with version 1.9.0

2018-07-23 Thread Guy Harris
On Jul 23, 2018, at 1:04 PM, Jan Stary  wrote:

> From both a sysadmin and user perspective, I find the GNU autotools
> amd CMake a major annoyance. Would you please consider doing what e.g.
> http://mandoc.bsd.lv/cgi-bin/cvsweb/configure does?

What advantage would it give us that would make it worth our effort?
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Re: [tcpdump-workers] [tcpdump-security] [libpcap] Problem with version 1.9.0

2018-07-23 Thread Dagobert Michelsen
Hi Jan,

Am 23.07.2018 um 22:04 schrieb Jan Stary :
> 
> From both a sysadmin and user perspective, I find the GNU autotools
> amd CMake a major annoyance. Would you please consider doing what e.g.
> http://mandoc.bsd.lv/cgi-bin/cvsweb/configure does?
> 
> A simple, hand written shell script, with a set of obvious
> {test,compat}-*.c helpers. No dependency on anything, orders
> of multitude smaller and faster then a auto*-generated configure.

No - please! Handwritten configure scripts are the worst nightmare for
downstream packages as each package uses its own way to configure flags
for compilation, linkage, install relocation etc. This makes
packaging stuff hard as it requires specific adjustments of build
procedures. I maintain roughly 1600 packages and this would not be
possible when there were no standards. Autotools is far from perfect,
but it is a standard and after you figured something out it works for
hundreds of builds in the same way.


Best regards

  — Dago

-- 
"You don't become great by trying to be great, you become great by wanting to 
do something,
and then doing it so hard that you become great in the process." - xkcd #896

___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Re: [tcpdump-workers] [tcpdump-security] [libpcap] Problem with version 1.9.0

2018-07-23 Thread Jan Stary
On Jul 23 18:38:17, g...@greenie.muc.de wrote:
> Hi,
> 
> On Mon, Jul 23, 2018 at 09:35:30AM -0400, Michael Richardson wrote:
> > Let's switch over to cmake as our official mechanism now... i.e. have
> > travis, etc. use it in preference to configure.
> 
> From a sysadmin perspective, I find cmake to be a major annoyance
> (because it usually does not exist on systems where I want to install
> packages, and if your platform is not "mainstream i386/amd64", there's
> quite often no binary packages, so "go out and compile cmake" is it,
> then... like, FreeBSD/Sparc64).
> 
> I do understand that this is not for me to decide and that you're
> fully free to ignore me, but I still wanted to say it so nobody can
> say afterwards "hey, we announced this on the list and nobody spoke
> up".
> 
> (If you say "... use it in preference to configure" and configure stays
> around as fallback, I shut up and be happy :-) )

From both a sysadmin and user perspective, I find the GNU autotools
amd CMake a major annoyance. Would you please consider doing what e.g.
http://mandoc.bsd.lv/cgi-bin/cvsweb/configure does?

A simple, hand written shell script, with a set of obvious
{test,compat}-*.c helpers. No dependency on anything, orders
of multitude smaller and faster then a auto*-generated configure.

Jan

___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Re: [tcpdump-workers] [tcpdump-security] [libpcap] Problem with version 1.9.0

2018-07-23 Thread Dagobert Michelsen
Hi,

Am 23.07.2018 um 19:11 schrieb Ray Bellis :
> On 23/07/2018 17:38, Gert Doering wrote:
>> I do understand that this is not for me to decide and that you're
>> fully free to ignore me, but I still wanted to say it so nobody can
>> say afterwards "hey, we announced this on the list and nobody spoke
>> up".
> 
> FWIW, I loath CMake too. :p

Is this a vote? It is a real pain to customize parameters in CMake
and I avoid it wherever possible and I would really appreciate if
autoconf at least won’t go away.


Best regards

  — Dago

-- 
"You don't become great by trying to be great, you become great by wanting to 
do something,
and then doing it so hard that you become great in the process." - xkcd #896

___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Re: [tcpdump-workers] [tcpdump-security] [libpcap] Problem with version 1.9.0

2018-07-23 Thread Ray Bellis
On 23/07/2018 17:38, Gert Doering wrote:

> I do understand that this is not for me to decide and that you're
> fully free to ignore me, but I still wanted to say it so nobody can
> say afterwards "hey, we announced this on the list and nobody spoke
> up".

FWIW, I loath CMake too. :p

Ray
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Re: [tcpdump-workers] [tcpdump-security] [libpcap] Problem with version 1.9.0

2018-07-23 Thread Gert Doering
Hi,

On Mon, Jul 23, 2018 at 09:35:30AM -0400, Michael Richardson wrote:
> Let's switch over to cmake as our official mechanism now... i.e. have
> travis, etc. use it in preference to configure.

From a sysadmin perspective, I find cmake to be a major annoyance
(because it usually does not exist on systems where I want to install
packages, and if your platform is not "mainstream i386/amd64", there's
quite often no binary packages, so "go out and compile cmake" is it,
then... like, FreeBSD/Sparc64).

I do understand that this is not for me to decide and that you're
fully free to ignore me, but I still wanted to say it so nobody can
say afterwards "hey, we announced this on the list and nobody spoke
up".

(If you say "... use it in preference to configure" and configure stays
around as fallback, I shut up and be happy :-) )

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Re: [tcpdump-workers] [tcpdump-security] [libpcap] Problem with version 1.9.0

2018-07-23 Thread Michael Richardson
Guy Harris via tcpdump-security  wrote:
>>> Need autoreconf.

> I've updated libpcap-release-howto.md, in the
>g...@bpf.tcpdump.org:maintainer-notes repository, to include the
>autoreconf step (and to clean up the formatting, to work as standard
>Markdown, as well as replacing the specific version numbers with
>variables).

> By the way, is there still a good reason to have the configure scripts
> and config.h.in files checked into Git, or should we remove them from
> Git and require people who build from Git to generate the configure
> scripts themselves (they're probably doing that as developers, so I
> don't mind requiring them to have autoconf installed)?  Generating the
> configure scripts is already part of the release process.

I've mixed feelings about this.

Let's switch over to cmake as our official mechanism now... i.e. have
travis, etc. use it in preference to configure.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[

___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers