bump (tex)info to the the latest version, 7.2

[dimpase]

very new compilers such as gcc 15 don't grok our meanwhile old info package, thus we do a bump

📝 Checklist

• The title is concise and informative.
• The description explains in detail what this PR is about.
• I have linked a relevant issue or discussion.
• I have created tests covering the changes.
• I have updated the documentation and checked the documentation preview.

⌛ Dependencies

[cxzhong]

seems the ci failed. Why download error?

[dimpase]

seems the ci failed. Why download error?

that's a red herring, a CI bug (or feature :-)).

You should be able to verify manually that the file is where it's given in
build/pkgs/info/checksum.ini, where you replace VERSION by what's written in build/pkgs/info/package-version.txt, and verify that sha1sum and sha256sum are as given in build/pkgs/info/checksum.ini

[dimpase]

this tarfile is obviously not on our mirrors yet, as we don't have this upgrade in yet.

[github-actions]

Documentation preview for this PR (built with commit dd90324; changes) is ready! 🎉
This preview will update shortly after each push to this PR.

[dimpase]

in some of the logs I see incomplete download errors such as

[info-7.2]   Attempting to download from https://ftp.gnu.org/gnu/texinfo/texinfo-7.2.tar.xz
  [info-7.2]   [............................................xxxxxxxxxxxxxxxxxxxxxxxxxx]
  [info-7.2]   ERROR [transfer|run:135]: <urlopen error retrieval incomplete: got only 4103476 out of 6408432 bytes>

so it's just a flaky internet

[cxzhong]

Yes, the hash number is right. It might be the network problem.

[user202729]

while the network failure is certainly not your fault, if I understood correctly, this pull request if merged would break test-long on pull requests because:

1. tarball creation is not working.
2. GNU server won't magically become more reliable next week.

I suggest one of the following:

1. wait until tarball creation is restored.
2. look for some other more reliable upstream. for example passagemath texinfo is on 7.2, so that may be an option.

[dimpase]

while the network failure is certainly not your fault, if I understood correctly, this pull request if merged would break test-long on pull requests because:

1. tarball creation is not working.

I am not sure what you mean by this.

2. GNU server won't magically become more reliable next week.

it works for me all the time. I see no problem with this getting merged and the tarball added to our mirrors
(perhaps @vbraun can do this straight away)

I suggest one of the following:

1. wait until tarball creation is restored.

2. look for some other more reliable upstream. for example passagemath texinfo is on 7.2, so that may be an option.

We are not touching them, even with a very long stick.

[dimpase]

let's see if GNU mirrors work better

[vbraun]

is now on our mirror

[dimpase]

@vbraun - this PR isn't correctly closed (after being merged, as far as I see)

[vbraun]

I merged a785e47 when it was positively reviewed, and it tested fine. Then there was some unneeded mucking about with the branch. The new commit dd90324 is scheduled appear in a second merge commit in the next beta.

[user202729]

Attempting to download package texinfo-7.2.tar.xz from mirrors
https://github.com/sagemath/sage/releases/download/10.8/texinfo-7.2.tar.xz
[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
ERROR [transfer|run:137]: HTTP Error 404: Not Found
https://github.com/sagemath/sage/releases/download/10.7/texinfo-7.2.tar.xz
[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
ERROR [transfer|run:137]: HTTP Error 404: Not Found
https://github.com/sagemath/sage/releases/download/10.6/texinfo-7.2.tar.xz
[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
ERROR [transfer|run:137]: HTTP Error 404: Not Found
https://mirror.csclub.uwaterloo.ca/sage/spkg/upstream/info/texinfo-7.2.tar.xz
[......................................................................]

looks like texinfo-7.2 is now on one of the mirrors usable by the CI (well, as explained by dimpase above, so I guess I was wrong).

the new commit wouldn't be necessary then. (although it may be useful if the mirror is down and the user fallbacks from the upstream source?)