Update downstream packages to 2.17.14

[ismaell]

• --- @ncopa
• 
• --- @foutrelis
• Buildroot --- @ismaell
• CentOS
• --- @eribertomota
  • 
  • 
• 
• 
• 
• --- @slashbeast
• 
• 
• 
• 
• 
• 
• 
• 
• --- @gonzalo-
• OpenEmbedded (no package!)
• 
• OpenWRT / LEDE -- no package!
• 
• pkgsrc (NetBSD and others)
• --- @jostber
• Source Mage --- @ismaell
• --- @xeffyr
• --- @pullmoll
• 

[eribertomota]

Unfortunately, the Debian Stable/Testing/Unstable uses autoconf 2.71[1], so it is not possible to upload the newer version of axel. Please, consider downgrading autoconf version to allow the regular upload plus a possible backport to stable.

[1] https://tracker.debian.org/pkg/autoconf

Eriberto

[ismaell]

@eribertomota Any ideas on how to deal with the changes in AC_PROG_CC?

[eribertomota]

Sorry, I have no ideas about this point.

[soumyaDghosh]

@ismaell We're building the snap package and even with autoconf 2.72 it's complaining about the necessary version of autoconf.

snapcraft-axel-on-amd64-for-amd64-34324039 ../parts/axel# cd build/
build environment set for part 'parts'
snapcraft-axel-on-amd64-for-amd64-34324039 ../parts/axel/build# autoconf
configure.ac:13: error: Autoconf version 2.72 or higher is required
configure.ac:13: the top level
autom4te: error: /usr/bin/m4 failed with exit status: 63
snapcraft-axel-on-amd64-for-amd64-34324039 ../parts/axel/build# which autoconf
/root/stage/usr/bin/autoconf
snapcraft-axel-on-amd64-for-amd64-34324039 ../parts/axel/build# autoconf --version
autoconf (GNU Autoconf) 2.72
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
<https://gnu.org/licenses/gpl.html>, <https://gnu.org/licenses/exceptions.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David J. MacKenzie and Akim Demaille.
snapcraft-axel-on-amd64-for-amd64-34324039 ../parts/axel/build# 

[ismaell]

@ismaell We're building the snap package and even with autoconf 2.72 it's complaining about the necessary version of autoconf.

So... clarifying once again:

• the release tarball has a self-contained build system in it, use that tarball,
• the whole point of autotools is that.
• you're not ever supposed to re-generate it for builds;
• you certainly can/should verify the buildsystem generation is repeatable on your dev box,
• but that's another story, just stay away of autoconf/autoreconf on builds.

Just clarifying because adding some backwards compatibility isn't going to fix a broken approach to builds.

[ismaell]

@eribertomota have you tried making override_dh_autoreconf a no-op?