autoconf: 2.69 -> 2.70

[alyssais]

Motivation for this change

First release in 6 years! I expect this will take a lot of fixing up packages. For now, I think we should just keep 2.69 around and pin it for anything that fails with 2.70. I’ll look into getting a Hydra jobset or something so we can identify all the packages that need that before applying this.

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[FRidh]

@vcunat could you make a hydra job for this.

[vcunat]

Here it is: https://hydra.nixos.org/jobset/nixpkgs/autoconf-2.70 (just a single platform for now)

[vcunat]

News: https://lwn.net/Articles/839395/

:-)

The macro AC_OBSOLETE is obsolete.

[alyssais]

I think this is ready now. I've addressed every autoconf-related Hydra failure. Any objections before I merge?

[jonringer]

I think the attrs should have been called autoconf_2_{69,70} as this is more aligned established versioning conventions.

But LGTM otherwise.

it would be a lot of tedious work to change it now

other regressions and be dealt with in staging-next.

[alyssais]

I think the attrs should have been called autoconf_2_{69,70} as this is more aligned established versioning conventions.

I agree in general, although in this case other autoconf versions used the scheme without underscores so I thought it was better to stick to that here.

[jonringer]

although in this case other autoconf versions used the scheme without underscores

perhaps autoconf versions pre-dates coming to a consensus about version numbers.

[vcunat]

Hydra OK at a quick look. In case some regression was missed, most likely it will be simply fixed by switching version for the failing package...

[flokli]

This broke the hidapi (a dependency of openssh) cross-build (pkgsCross.aarch64-multiplatform.hidapi)

these derivations will be built:
  /nix/store/952z8zv4j0m9nl41dwv29csl15zim6vk-hidapi-0.10.1-armv6l-unknown-linux-gnueabihf.drv
building '/nix/store/952z8zv4j0m9nl41dwv29csl15zim6vk-hidapi-0.10.1-armv6l-unknown-linux-gnueabihf.drv'...
unpacking sources
unpacking source archive /nix/store/p8nb0nlfffkl9ks12qqlrvc9zgsfvn91-source
source root is source
patching sources
autoreconfPhase
autoreconf: export WARNINGS=
autoreconf: Entering directory '.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
configure.ac:16: error: AC_CONFIG_MACRO_DIR can only be used once
./lib/autoconf/general.m4:1969: AC_CONFIG_MACRO_DIR is expanded from...
configure.ac:16: the top level
autom4te: error: /nix/store/h79jdfbmk9kzb4zyh1vs035z3w62cva6-gnum4-1.4.18/bin/m4 failed with exit status: 1
aclocal: error: /nix/store/c1crh9yn453zm3kyvl3zy6j3nbmxna26-autoconf-2.70/bin/autom4te failed with exit status: 1
autoreconf: error: aclocal failed with exit status: 1
builder for '/nix/store/952z8zv4j0m9nl41dwv29csl15zim6vk-hidapi-0.10.1-armv6l-unknown-linux-gnueabihf.drv' failed with exit code 1
error: build of '/nix/store/952z8zv4j0m9nl41dwv29csl15zim6vk-hidapi-0.10.1-armv6l-unknown-linux-gnueabihf.drv' failed

git bisect start
# bad: [8106eefd9851d3246ae0b355386444abe4d9b8f4] Merge remote-tracking branch 'origin/master' into nixpkgs-cross-fixes
git bisect bad 8106eefd9851d3246ae0b355386444abe4d9b8f4
# good: [4b210ca92afaba35a2f17bbd1db534f33ffa1d9f] Merge pull request #107282 from 0x4A6F/master-dasel
git bisect good 4b210ca92afaba35a2f17bbd1db534f33ffa1d9f
# bad: [b9ede6493f7871d0cd7df6a666fdaf37762ba0f3] iproute2: Update the source hash
git bisect bad b9ede6493f7871d0cd7df6a666fdaf37762ba0f3
# bad: [5586017246edebf348cf0e3e120318138a94f04e] eid-mw: use autoconf 2.69
git bisect bad 5586017246edebf348cf0e3e120318138a94f04e
# bad: [7787b860b99391f3cd18e2c9c1bf892682cc21ad] libcryptui: use autoconf 2.69
git bisect bad 7787b860b99391f3cd18e2c9c1bf892682cc21ad
# bad: [cb87a87ec96673e18d19de9028220eab39a3fae0] hidapi: use autoconf 2.69
git bisect bad cb87a87ec96673e18d19de9028220eab39a3fae0
# good: [e7b88d10a3426924008ec16fe4e56e61287fa5ed] Merge pull request #105817 from primeos/mesa-next
git bisect good e7b88d10a3426924008ec16fe4e56e61287fa5ed
# bad: [3f42dfe7d9b0e2cc1485cede6e82b59b09d60838] autoconf: 2.69 -> 2.70
git bisect bad 3f42dfe7d9b0e2cc1485cede6e82b59b09d60838
# good: [c434c60b3957f8599c4bfd59b56f24326492d8c9] autoconf270: init at 2.70
git bisect good c434c60b3957f8599c4bfd59b56f24326492d8c9
# first bad commit: [3f42dfe7d9b0e2cc1485cede6e82b59b09d60838] autoconf: 2.69 -> 2.70

[flokli]

Curious, this PR already did set autoreconfHook = autoreconfHook269 in all-packages.nix. If I remove it from there, I get the same error log. I wonder how we managed to make this a cross-only regression.

[flokli]

@Ericson2314 could this be triggered via 4b2ab66, by any chance?

[flokli]

I consider being able to build a minimal nixos image for aarch64, from a x86_64 workstation somewhat important.

As written, autoconf had no release for some years, we don't need to rush merging this to master, but can block until we don't break cross.

[jonringer]

Agreed, probably should have just exposed autoconf270; and switch the default much later.

[FRidh]

hidapi fix #108025

[alyssais]

Agreed, probably should have just exposed autoconf270; and switch the default much later.

I disagree. That’s just how we get stuck on old versions of things for years. There’s no reason to think that waiting a year or whatever would have made any difference to one package failing because nobody thought to test a cross image.

[alyssais]

I consider being able to build a minimal nixos image for aarch64, from a x86_64 workstation somewhat important.

I agree -- I was trying to be careful about failures, but assumed that Hydra would test everything important. Would it be feasible to have that as something Hydra would test?

[FRidh]

Would it be feasible to have
that as something Hydra would test?

Yes and its one of those topics that's been open for years. We need to revisit release.nix and the Hydra jobs we have, but there's only few people with those permissions to adjust jobs and nothing happens there.

[FRidh]

In bf46afd and 136c0d0 I changed all the overrides to use buildPackages to fix cross-compilation.