Repository navigation
texlive fetch #279
Description
Activity
Unfortunately, this is still reproducible with
app-text/texlive-core-2026-r3.The currently referenced distfile
texlive-scripts.r80004.tar.xzcannot be fetched. Portage tried the Gentoo distfile mirror,
dev.gentoo.org, the TL2026tlnet-finalarchive, and the live CTANtlnet/archive; the available HTTP endpoints returned 404.The emerge fails with:
!!! Couldn't download 'texlive-scripts.r80004.tar.xz'. Aborting.This looks like the same underlying problem as the original
m-tx.r78106.tar.xzfailure: the ebuild references a revisioned file from rollingtlnetwhich has subsequently disappeared.Could
texlive-core-2026-r3please be updated, ideally with a way of keeping these revisioned distfiles available aftertlnetadvances?- added 20 commits that reference this issue
on Sep 11, 2026 well, the main issue (and why it used to work, and doesn't work anymore) -- there is generic anti-AI/spam block on main mirror that doesn't allow downloading arbitratry 2026-rXXXX package (they have cache for some number of version though). As a result packages named and hashed ebuild and manifest get stale pretty fast.
I bumped them right now (please update, should work!) and will work for more sustained solution over the weekend.And thank you for reporting! Now I see that there are more then 2 people using LaTeX here :)
Fixed in 699b70b
Update on the "more sustained solution": the 2026 packages should now keep fetching after tlnet moves on, without a resync every few weeks.- A durable source. texlive.info (Norbert Preining's daily archive of tlnet) keeps every revision, but its anti-bot protection used to answer Portage with an HTML challenge page instead of the tarball. I asked Norbert, and he now lets Portage's default User-Agent through. Many thanks to him!
- The eclass uses it as a last resort. Every 2026 ebuild (all dev-texlive/*, plus texlive-core, kpathsea, dvipsk and bibtexu) now names the texlive.info snapshot from 2026-09-11. That snapshot holds every revision they pin. If CTAN no longer has a file, Portage falls back to the snapshot, and the Manifest checksums still guarantee it's the same file.
- A fetch-order fix. Portage turns out to try the plain SRC_URI locations last-listed first, so CTAN was being asked last. The list is reversed now: CTAN first, then the TUG historic archive (Chemnitz, then Utah), then flow's dev.gentoo.org mirror, and texlive.info only when all of those miss.
I tested this with a fresh fetch of
texlive-basic. unicode-data.r79913, which tlnet already returns 404 for, came from texlive.info, and everything else came from CTAN.One caveat: the exception covers Portage's default
FETCHCOMMANDUser-Agent. If you've customised `FETCHCOMMAND to send a different User-Agent, the fallback will still get the challenge page.It's in the overlay now, so please sync (
emaint sync -r stuff). If a fetch still fails for you after that, please post the file name here. Otherwise I'll close this in a week or so.Reacted by axyswertThanks for fixing this and for taking the time to work out a longer-term solution! Sorry for the delayed confirmation: the earlier patch already resolved my fetch failure, and when I had to rebuild
@worldwith--empty-treeyesterday for unrelated reasons, everything went smoothly as well.As far as I’m concerned, this is resolved. Thanks again for maintaining the overlay! 😃
Reacted by Ivan S. TitovHappy to hear that, thank you very much!
Package
app-text/texlive-core-2026-r1
What happened
fetch failed - 'm-tx.r78106.tar.xz' is not fetching
Expected behaviour
No response
emerge --info
Build log (or relevant tail)
Upstream bug report
No response
Additional context
No response