Upstream dev-python/charset_normalizer-2.1.1.tar.gz replaced

[mmogilvi]

I don't know if this should be considered a problem worth changing anything for or not, but:

If I download the original SRC_URI indicated in the dev-python/charset-normalizer-2.1.1 ebuild ( https://github.com/Ousret/charset_norma ... 1.1.tar.gz ), it is currently a 86023 byte file. If emerge ends up trying to use this version, it generates a size mismatch error (not consistent with Manifest) and fails.

In contrast, emerge normally downloads it from gentoo mirrors, which is getting me a 86024 byte file, which matches the Manifest file.

If I unpack both and do a recursive diff, there is exactly one character different:

diff -r cm-fromGentoo-wrongVersionPyFile/charset_normalizer/version.py charset_normalizer-2.1.1/charset_normalizer/version.py
5c5
< __version__ = "2.1.0"
---
> __version__ = "2.1.1"

Presumably (guessing) upstream released it with it the wrong internal version number, a gentoo developer grabbed and cached that version of the file, but then upstream replaced it in-place (same URL) with a fixed version.

Workaround: Obviously an immediate workaround is to just make sure your distfiles has the version from portage mirrors, that matches the Manifest file, despite the incorrect internal version. However, I don't know if this is really the "right" long-term solution. (Although watch out for the rename adding a ".gh" in the middle of the filename.)

Question: Does it makes sense for someone to update the gentoo mirrors, ebuild, and/or Manifest somehow? (Which might cause a window of time when there are difficulties when various distributed cached copies of the file and the Manifest being inconsistent with each other.)

(I stumbled over this unintentionally because I was getting weird repeated reset connections after only a few kbytes for this file, probably because of some combination of $DAYJOB's corporate firewall, the mirror I was using ( http://www.gtlib.gatech.edu/pub/gentoo , I think ), and my continued usage of a tweaked version of the the old long-treecleaned http-replicator proxy cache package. From emerge-fetch.log, it was erring out on the partial downloads and retrying (much slower than usual), and eventually emerge fell back on downloading from the original SRC_URI, ending up with an unexpected slightly different file...)

[Josef.95]

It is probably already fixed, see https://bugs.gentoo.org/873277

[Hu]

In my opinion, yes, this is worth fixing. I think anyone who sets GENTOO_MIRRORS="" (discouraged, but not specifically prohibited) or who, like you, experiences repeated errors with mirrors not offering the file, will hit this. I think the correct solution is to [bug=]file a bug[/bug] reporting that upstream changed the content of their tarball without changing its filename. A Gentoo maintainer can then grab the re-released file, rebuild the manifest, and upload those in place over the existing version.

[Ionen]

Yeah, ideally if there's a screw up they should just have done 2.1.2 release rather than try to sneak in fixes in 2.1.1. Reporting upstream to give them an earful and hopefully not do retagging again is appreciated

But Gentoo will still update those if informed though (or at least I do when need be and welcome bug reports, in a recent case I had to deal with the old same-version tag was missing a rather important fix), it's also good to verify these in case it was something malicious (not that I've seen this so far).

Cases like upstream files going missing may be less interesting if mirror'ed though (one of the main point of mirrors). At best can change the SRC_URI to force mirrors so it works even for those without proper setup, but well... do keep a working GENTOO_MIRRORS