Thanks for tackling this! Autoconf definitely needs a new release. On Mon, Mar 9, 2020 at 2:23 PM Zack Weinberg <zackw@xxxxxxxxx> wrote: > It has been eight years since the release of autoconf 2.69, there’s > been substantial improvements checked into the development trunk since > then, and the mailing list regularly gets requests for a new release. > It is my understanding that the most important roadblock to a new > release is a lack of developer time to do pre-release testing. > I have secured partial funding for my time to do this testing (thanks > to Keith Bostic). I’d like to discuss a plan; once we have developed > a concrete plan it will be easier for me to secure the rest of the > funding. > > As a first step, I have cloned Git trunk and run the bundled testsuite > on my personal workstation, which runs Debian unstable. I find only a > few problems. I already patched two failures in ‘make -k syntax-check’. > More seriously, I see two failures in the primary testsuite when run > from within ‘make distcheck’ with /bin/sh being dash: > > 77: Forced re-exec with CONFIG_SHELL FAILED (m4sh.at:68) > 78: Configure re-execs self with CONFIG_SHELL FAILED (m4sh.at:132) > > These don’t happen when /bin/sh is bash, or when I just run ‘make check’, > and it’s not a matter of whether the source and build directory are > the same. I’m still investigating this, but I expect it’s something > relatively minor. > > Now, obviously running the bundled testsuite on an up-to-date Debian > unstable box is not enough. I propose to do the following set of > tests: > > - Run the bundled testsuite (plain ‘make check’ only, not ‘make > distcheck’) on the following OS and CPU combinations, all of which > are readily accessible to me: > > aarch64-unknown-linux-gnu > armhf-unknown-linux-gnu > mips64-unknown-linux-gnu > powerpc-ibm-aix7.1.3.0 > powerpc64-unknown-linux-gnu > sparc-sun-solaris2.11 > x86_64-unknown-linux-gnu > - Debian unstable > - CentOS 5 (about the oldest Linux anyone still uses AFAIK). > x86_64-unknown-netbsd8.1 > … > > This list is shorter than I would like, particularly in the OS > department. I was hoping to get access to more “exotic” > environments via the GCC Compile Farm, but all of their more > interesting hosts are down as I write this. :-( > > I will cheerfully add to the above anything that someone is willing > to give me an unprivileged ssh account on. (Please make sure > autoconf’s build dependencies are present and there’s plenty of > scratch space.) I don’t think setting up VMs or scrounging > physical hardware for more different OSes is a good use of my time > for this project, though. > > - On the same set of computers, run the configure script that was > shipped in the tarball for the following list of packages, then > regenerate that script using autoconf development trunk, run it > again, and compare the new and old ‘config.status’. Investigate > any differences in the probe results. > > coreutils-8.31 > emacs-26.3 > gcc-9.2 (specifically gcc/configure) > glib-2.63.6 > python-3.8.2 > > I happen to know that these have particularly complicated configure > scripts. I will also cheerfully take suggestions for additional > packages to test in this manner. > > I also have plans to go through the Debian, Fedora, SUSE, and Arch > Linux packages of autoconf and see if they apply any patches that > should really be upstreamed before a new release happens, and to go > through the relatively short list of bugs at > https://savannah.gnu.org/support/?group=autoconf and check for > critical issues. > > I’ve seen people suggest that there is a backlog of patches that have > been submitted to this mailing list but not reviewed, but considering > that there’s already more git commits in between 2.69 and now than > there were between 2.68 and 2.69, I think it would be reasonable to > call 2.70 feature-complete at this point. That backlog can become the > meat of 2.71. :-) > > I’d like to ask whether the community thinks there are any important > holes in this test plan, and whether there’s anything else that ought > to happen before we could proceed to make a release of 2.70. I think > this covers everything in the testing part of the release checklist in > $srcdir/HACKING, but I don’t know when that was last updated; there > could be something missing? > > I need to get back to the people with the funding in the near future > with a detailed plan, so I would appreciate responses within the next > two weeks. > > zw > >
