Re: [tcpdump-workers] Autoconf with Debian patches
--- Begin Message --- On Jan 8, 2023, at 5:24 AM, Denis Ovsienko wrote: > Thank you for this information. Let me add that Ubuntu 20.04 defaults > to 2.69, but Ubuntu 22.04, FreeBSD, NetBSD, OpenBSD and OmniOS all > currently default to Autoconf 2.71. ...and macOS doesn't ship with autoconf in the first place, so the user would have to install a third-party version. The current GNU release is 2.71, and the current Homebrew release: https://formulae.brew.sh/formula/autoconf#default is 2.71, so... > Would it make the most sense to make 2.71 the nominal version (especially for > releases), but to maintain > backward compatibility with 2.69 for quite a while longer? ...yes. That means people should be careful when updating the configure script, and might call for at least one part of the CI process involve testing, on a machine with 2.69 installed, both "does it work if you just use the packaged configure script?" and "does it work if you get rid of configure and config.h.in, run autoconf to generate the script with 2.69, and use the resulting configure script?", to catch cases where people aren't careful.--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Autoconf with Debian patches
--- Begin Message --- On Sat, 7 Jan 2023 18:47:37 -0800 Guy Harris wrote: > On Jan 7, 2023, at 8:51 AM, Denis Ovsienko > wrote: > > > On Fri, 6 Jan 2023 17:13:20 -0800 > > Guy Harris wrote: > > > >> On Jan 6, 2023, at 3:31 PM, Denis Ovsienko > >> wrote: > >> > >>> It is the latter, and a custom Autoconf seems an unreasonable > >>> requirement for contributing. > >> > >> Reasonable, or unreasonable? > > > > Unreasonable, if it is more complicated than installing an Autoconf > > package using the package manager of the OS. > > Which it is likely to be. Okay, let's not go out of the packaged Autoconf space then. > >> (By the way, have other Linux distributions applied the same > >> changes that Debian and its derivatives have? If not, then users > >> of those distributions would be in the same situation as macOS and > >> FreeBSD users.) > > > > I do not remember to what extent these patches have propagated > > beyond Debian and Ubuntu. Maybe somebody else has other > > distributions ready to check? > > Fedora 36 and later appear to ship autoconf 2.71; the Debian sid > package for autoconf 2.71 applies no patches to it, as, I presume, > all of the Debian packages are applied (the off_t patch is already > incorporated in 2.71). Debian's currently shipping 2.69, which > requires their pile of patches. Thank you for this information. Let me add that Ubuntu 20.04 defaults to 2.69, but Ubuntu 22.04, FreeBSD, NetBSD, OpenBSD and OmniOS all currently default to Autoconf 2.71. Would it make the most sense to make 2.71 the nominal version (especially for releases), but to maintain backward compatibility with 2.69 for quite a while longer? > Fedora shipped autoconf 2.69, without a patch like the Debian off_t > patch but with a patch like the Debian "add runstatedir" patch. I > don't know what RHEL has. > > Looking at the Arch Linux repository, there doesn't appear to be a > version of the off_t patch from when they shipped 2.69; they're > currently shipping 2.71. The same applies to Gentoo. > > But at least some of them have 2.71 patches, so there's no guarantee > that all the releases that have 2.71 will generate exactly the same > script. Identical behaviour everywhere would be unrealistic. Minimizing the average noise level in pull requests should be realistic, although not critical, but nice to have. -- Denis Ovsienko --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Autoconf with Debian patches
--- Begin Message --- On Jan 7, 2023, at 8:51 AM, Denis Ovsienko wrote: > On Fri, 6 Jan 2023 17:13:20 -0800 > Guy Harris wrote: > >> On Jan 6, 2023, at 3:31 PM, Denis Ovsienko >> wrote: >> >>> It is the latter, and a custom Autoconf seems an unreasonable >>> requirement for contributing. >> >> Reasonable, or unreasonable? > > Unreasonable, if it is more complicated than installing an Autoconf > package using the package manager of the OS. Which it is likely to be. >> (By the way, have other Linux distributions applied the same changes >> that Debian and its derivatives have? If not, then users of those >> distributions would be in the same situation as macOS and FreeBSD >> users.) > > I do not remember to what extent these patches have propagated beyond > Debian and Ubuntu. Maybe somebody else has other distributions ready to > check? Fedora 36 and later appear to ship autoconf 2.71; the Debian sid package for autoconf 2.71 applies no patches to it, as, I presume, all of the Debian packages are applied (the off_t patch is already incorporated in 2.71). Debian's currently shipping 2.69, which requires their pile of patches. Fedora shipped autoconf 2.69, without a patch like the Debian off_t patch but with a patch like the Debian "add runstatedir" patch. I don't know what RHEL has. Looking at the Arch Linux repository, there doesn't appear to be a version of the off_t patch from when they shipped 2.69; they're currently shipping 2.71. The same applies to Gentoo. But at least some of them have 2.71 patches, so there's no guarantee that all the releases that have 2.71 will generate exactly the same script.--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Autoconf with Debian patches
--- Begin Message --- On 07/01/2023 20:13, Michael Richardson wrote: > > Francois-Xavier Le Bail via tcpdump-workers wrote: > > Or don't generate it and have the build process be: > > ./autogen.sh && ./configure && ... > > That just leads to non-deterministic builds for everyone :-( Could you explain why? My test with tcpslice on https://github.com/the-tcpdump-group/tcpslice/pull/16 gives "18 successful checks" on CI. (Some tests are with autoconf 2.69, some with 2.71) --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Autoconf with Debian patches
--- Begin Message --- On 06/01/2023 21:38, Francois-Xavier Le Bail via tcpdump-workers wrote: >> As some have experienced before, attempts to regenerate the configure >> script often result in two groups of unnecessary changes (runstatedir >> and LARGE_OFF_T), both of which come from Debian-specific patches to >> Autoconf because traditionally the configure scripts were generated >> using non-Debian Autoconf. In practice this means that a regenerated >> revision of a configure script almost always requires "git add -p" >> instead of "git add". >> >> This has been discussed in some detail in [1], and my understanding is >> that making Debian Autoconf the new standard should make this problem >> smaller (it certainly would in my development environment). Would >> anybody like to make their point for or against such a switch in one of >> the next releases? >> >> 1: https://github.com/the-tcpdump-group/tcpslice/pull/12 > I agree to use Debian Autoconf 2.69. Or, perhaps better, remove the generated configure script from the repository. (See my previous message) --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Autoconf with Debian patches
--- Begin Message --- On Fri, 6 Jan 2023 17:13:20 -0800 Guy Harris wrote: > On Jan 6, 2023, at 3:31 PM, Denis Ovsienko > wrote: > > > It is the latter, and a custom Autoconf seems an unreasonable > > requirement for contributing. > > Reasonable, or unreasonable? Unreasonable, if it is more complicated than installing an Autoconf package using the package manager of the OS. > Whatever version is chosen as the standard autoconf, if the goal is > to have the version of the configure script in the repository always > be generated by the standard autoconf, some users will have to build > and install that version if they will be changing the configure > script, and, for other contributions, they'll either have to build or > install that version or they will have to take care not to check in > the configure script if they haven't changed configure.ac or > aclocal.m4. > > (By the way, have other Linux distributions applied the same changes > that Debian and its derivatives have? If not, then users of those > distributions would be in the same situation as macOS and FreeBSD > users.) I do not remember to what extent these patches have propagated beyond Debian and Ubuntu. Maybe somebody else has other distributions ready to check? > > Or the --runstatedir and LARGE_OFF_T bits between releases could > > appear and disappear at random > > Meaning we let users check in the configure script in whatever form > it exists on their machine? Yes. The obvious drawbacks of that would be lowering signal-to-noise ratio in the diffs and potentially making subsequent git-cherry-pick more likely to fail due to merge conflicts. > > until it is a release time, then the standard > > could be enforced as and if necessary. > > I.e., part of the process of making a release would be regenerating > the configuration file using Debian autoconf and checking in the > regenerated version.? Yes. This bit looks relatively simple. -- Denis Ovsienko --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Autoconf with Debian patches
--- Begin Message --- On 06/01/2023 23:49, Guy Harris via tcpdump-workers wrote: > An alternative would be *not* to keep the generated configure script in the > repository (that's what Wireshark ended up doing before it ceased to use > autoconf/automake), and generate it as part of the release-build process, > which we would do on a machine on which Debian autoconf was installed. Or don't generate it and have the build process be: ./autogen.sh && ./configure && ... > That requires that developers have autoconf installed if they're not going to > be using CMake, but there are already tools they need installed (a C > compiler, make, Flex, Bison/Berkeley YACC, ...) so I don't see that as a > problem. > > It also means that configure.ac and aclocal.m4 would have to work with > various sufficiently-recent versions of autoconf. FYI, test for tcpslice here: https://github.com/the-tcpdump-group/tcpslice/pull/16 Some warnings like The macro `XXX' is obsolete. (Some tests are with autoconf version 2.71) --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Autoconf with Debian patches
--- Begin Message --- On Jan 6, 2023, at 3:31 PM, Denis Ovsienko wrote: > It is the latter, and a custom Autoconf seems an unreasonable > requirement for contributing. Reasonable, or unreasonable? Whatever version is chosen as the standard autoconf, if the goal is to have the version of the configure script in the repository always be generated by the standard autoconf, some users will have to build and install that version if they will be changing the configure script, and, for other contributions, they'll either have to build or install that version or they will have to take care not to check in the configure script if they haven't changed configure.ac or aclocal.m4. (By the way, have other Linux distributions applied the same changes that Debian and its derivatives have? If not, then users of those distributions would be in the same situation as macOS and FreeBSD users.) > Or the --runstatedir and LARGE_OFF_T bits between releases could appear > and disappear at random Meaning we let users check in the configure script in whatever form it exists on their machine? > until it is a release time, then the standard > could be enforced as and if necessary. I.e., part of the process of making a release would be regenerating the configuration file using Debian autoconf and checking in the regenerated version.?--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Autoconf with Debian patches
--- Begin Message --- On Fri, 6 Jan 2023 14:49:54 -0800 Guy Harris wrote: > On Jan 6, 2023, at 2:24 PM, Denis Ovsienko > wrote: > > > On Fri, 6 Jan 2023 13:25:14 -0800 > > Guy Harris wrote: > > > >> If we switch to making Debian Autoconf the new standard and keeping > >> the generated configure script in the repository, would that mean > >> that developers working from the repository would either have to > >> install Debian Autoconf or use "git add -p" instead of "git add"? > > > > Yes. Right now it is the other way around (contributors that use > > Debian or its derivatives have to filter their output). So perhaps > > this switch would not be convenient for macOS and FreeBSD users. > > If we go that way, we should document it when addressing developers. Yes, and it would be nice to have this documented even if we don't (currently the contribution guidelines do not discuss this). > Is there a place where people can download a tarball for Debian > autoconf and just do ./configure, make, and make install, or will > they have to download the Debian package and apply the patches? If > the latter, we should, at minimum, give documentation on how to do > that - or we could just do that ourselves and have a "Debian > autoconf" source tarball to download. It is the latter, and a custom Autoconf seems an unreasonable requirement for contributing. > An alternative would be *not* to keep the generated configure script > in the repository (that's what Wireshark ended up doing before it > ceased to use autoconf/automake), and generate it as part of the > release-build process, which we would do on a machine on which Debian > autoconf was installed. Or the --runstatedir and LARGE_OFF_T bits between releases could appear and disappear at random until it is a release time, then the standard could be enforced as and if necessary. > That requires that developers have autoconf installed if they're not > going to be using CMake, but there are already tools they need > installed (a C compiler, make, Flex, Bison/Berkeley YACC, ...) so I > don't see that as a problem. > > It also means that configure.ac and aclocal.m4 would have to work > with various sufficiently-recent versions of autoconf. -- Denis Ovsienko --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Autoconf with Debian patches
--- Begin Message --- On Jan 6, 2023, at 2:24 PM, Denis Ovsienko wrote: > On Fri, 6 Jan 2023 13:25:14 -0800 > Guy Harris wrote: > >> If we switch to making Debian Autoconf the new standard and keeping >> the generated configure script in the repository, would that mean >> that developers working from the repository would either have to >> install Debian Autoconf or use "git add -p" instead of "git add"? > > Yes. Right now it is the other way around (contributors that use > Debian or its derivatives have to filter their output). So perhaps > this switch would not be convenient for macOS and FreeBSD users. If we go that way, we should document it when addressing developers. Is there a place where people can download a tarball for Debian autoconf and just do ./configure, make, and make install, or will they have to download the Debian package and apply the patches? If the latter, we should, at minimum, give documentation on how to do that - or we could just do that ourselves and have a "Debian autoconf" source tarball to download. An alternative would be *not* to keep the generated configure script in the repository (that's what Wireshark ended up doing before it ceased to use autoconf/automake), and generate it as part of the release-build process, which we would do on a machine on which Debian autoconf was installed. That requires that developers have autoconf installed if they're not going to be using CMake, but there are already tools they need installed (a C compiler, make, Flex, Bison/Berkeley YACC, ...) so I don't see that as a problem. It also means that configure.ac and aclocal.m4 would have to work with various sufficiently-recent versions of autoconf.--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Autoconf with Debian patches
--- Begin Message --- On Fri, 6 Jan 2023 13:25:14 -0800 Guy Harris wrote: > If we switch to making Debian Autoconf the new standard and keeping > the generated configure script in the repository, would that mean > that developers working from the repository would either have to > install Debian Autoconf or use "git add -p" instead of "git add"? Yes. Right now it is the other way around (contributors that use Debian or its derivatives have to filter their output). So perhaps this switch would not be convenient for macOS and FreeBSD users. -- Denis Ovsienko --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Autoconf with Debian patches
--- Begin Message --- On Jan 4, 2023, at 2:30 PM, Denis Ovsienko via tcpdump-workers wrote: > As some have experienced before, attempts to regenerate the configure > script often result in two groups of unnecessary changes (runstatedir > and LARGE_OFF_T), both of which come from Debian-specific patches to > Autoconf because traditionally the configure scripts were generated > using non-Debian Autoconf. In practice this means that a regenerated > revision of a configure script almost always requires "git add -p" > instead of "git add". > > This has been discussed in some detail in [1], and my understanding is > that making Debian Autoconf the new standard should make this problem > smaller (it certainly would in my development environment). Would > anybody like to make their point for or against such a switch in one of > the next releases? If we switch to making Debian Autoconf the new standard and keeping the generated configure script in the repository, would that mean that developers working from the repository would either have to install Debian Autoconf or use "git add -p" instead of "git add"?--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Autoconf with Debian patches
--- Begin Message --- On 04/01/2023 23:30, Denis Ovsienko via tcpdump-workers wrote: > As some have experienced before, attempts to regenerate the configure > script often result in two groups of unnecessary changes (runstatedir > and LARGE_OFF_T), both of which come from Debian-specific patches to > Autoconf because traditionally the configure scripts were generated > using non-Debian Autoconf. In practice this means that a regenerated > revision of a configure script almost always requires "git add -p" > instead of "git add". > > This has been discussed in some detail in [1], and my understanding is > that making Debian Autoconf the new standard should make this problem > smaller (it certainly would in my development environment). Would > anybody like to make their point for or against such a switch in one of > the next releases? > > 1: https://github.com/the-tcpdump-group/tcpslice/pull/12 I agree to use Debian Autoconf 2.69. --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
