[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Making Autoconf 2.70 happen in the near future

From: Nicholas Clark
Subject: Re: Making Autoconf 2.70 happen in the near future
Date: Mon, 9 Mar 2020 14:35:38 -0600

Thanks for tackling this! Autoconf definitely needs a new release.

On Mon, Mar 9, 2020 at 2:23 PM Zack Weinberg <address@hidden> 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 (
>  78: Configure re-execs self with CONFIG_SHELL       FAILED (
> 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
> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]