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?

[eribertomota]

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

Hi @ismaell,

autoconf 2.72 arrived today to Debian unstable. I just moved axel 2.17.14 from experimental to unstable.

[ismaell]

autoconf 2.72 arrived today to Debian unstable. I just moved axel 2.17.14 from experimental to unstable.

You should really try to override the autoreconf rule anyway, it's harmful, and Debian is wrong here, they need to verify the files, not blindly recreate everything, because that can fail in many ways and isn't any safer if nobody is checking the input files anyway.

[eribertomota]

autoconf 2.72 arrived today to Debian unstable. I just moved axel 2.17.14 from experimental to unstable.

You should really try to override the autoreconf rule anyway, it's harmful, and Debian is wrong here, they need to verify the files, not blindly recreate everything, because that can fail in many ways and isn't any safer if nobody is checking the input files anyway.

I will keep the current packaging method. Have a nice day.

[xkszltl]

@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.

I'm building and packaging axel and many other tools, and always found it better to run autoconf, because this way we can always rely solely on git repo and all its metadata/tags for versioning.
It's much easier and safer to host/retrieve git repo in standardized ways than pulling tarball from various http servers, and it can be mirrored to support offline build transparently.

[ismaell]

I'm building and packaging axel and many other tools, and always found it better to run autoconf, because this way we can always rely solely on git repo and all its metadata/tags for versioning. It's much easier and safer to host/retrieve git repo in standardized ways than pulling tarball from various http servers, and it can be mirrored to support offline build transparently.

1. It's against the design of autotools.
2. You can not rely on the repo because the process of producing the buildsystem isn't self-contained.

I'm not saying it's good the way it is, but to do that we would need to first make the process fully repeatable and possibly self-contained, and the community is definitely not there yet...