Homebrew-core: icu4c.rb compiling from source fyi

[Amgine0]

Attempting to upgrade, self-compiling, with domain resolution and security issues. Successful work-around implemented.

==> Upgrading 1 outdated package, with result:
icu4c 60.2
==> Upgrading icu4c 
==> Downloading https://ssl.icu-project.org/files/icu4c/60.2/icu4c-60_2-src.tgz

curl: (6) Could not resolve host: ssl.icu-project.org
Trying a mirror...
==> Downloading https://fossies.org/linux/misc/icu4c-60_2-src.tgz
######################################################################## 100.0%
Error: SHA256 mismatch
Expected: f073ea8f35b926d70bb33e6577508aa642a8b316a803f11be20af384811db418
Actual: 42db98fece7186daf9778ad8bc3fd2c5b51ecb1a8944e5e70a9c5f47709ad6a6
Archive: /Users/wsaewyc/Library/Caches/Homebrew/icu4c-60.2.tgz
To retry an incomplete download, remove the file above.

Did not follow the complete checklist for homebrew; I commented out fossies and homebrew successfully downloaded from sourceforge. Seems like the upstream repos may need review?

[ilovezfs]

The diff is

iMac-TMP:icu joe$ diff fossies/icu/source/i18n/calendar.cpp sf/icu/source/i18n/calendar.cpp
709,711c709
< fSkippedWallTime(UCAL_WALLTIME_LAST),
< validLocale(""),
< actualLocale("")
---
> fSkippedWallTime(UCAL_WALLTIME_LAST)
712a711,712
>     validLocale[0] = 0;
>     actualLocale[0] = 0;
737,739c737
< fSkippedWallTime(UCAL_WALLTIME_LAST),
< validLocale(""),
< actualLocale("")
---
> fSkippedWallTime(UCAL_WALLTIME_LAST)
740a739,740
>     validLocale[0] = 0;
>     actualLocale[0] = 0;
771,773c771
< fSkippedWallTime(UCAL_WALLTIME_LAST),
< validLocale(""),
< actualLocale("")
---
> fSkippedWallTime(UCAL_WALLTIME_LAST)
774a773,774
>     validLocale[0] = 0;
>     actualLocale[0] = 0;
832a833,834
>         validLocale[sizeof(validLocale)-1] = 0;
>         actualLocale[sizeof(validLocale)-1] = 0;
iMac-TMP:icu joe$ 

[ilovezfs]

@srl295 @jschleus any idea what happened here? It looks like fossies got a version of this tarball from the 11th and then icu reposted a different tarball with the same name on the 13th?

[ilovezfs]

@Amgine0 Thanks for reporting this. I have removed the fossies mirror.

[jschleus]

Sorry for that. @ilovezfs already has described the situation correctly. Since Fossies isn't a real mirror and detects new releases mainly on changes of version strings (and informations from announcement lists) that change was til now overseen. It's now corrected.

By the way it seems not a good idea by the authors to use the same tarball name after such a subsequent change (calendar.cpp). But I don't know the full history.

[ilovezfs]

Thanks @jschleus!

[srl295]

By the way it seems not a good idea by the authors to use the same tarball name after such a subsequent change (calendar.cpp). But I don't know the full history.

60.2 was not released until the 13th. It was an error to pull files down until actual release.

[srl295]

@Amgine0 are you still seeing this?

curl: (6) Could not resolve host: ssl.icu-project.org

[jschleus]

By the way it seems not a good idea by the authors to use the same tarball name after such a
subsequent change (calendar.cpp). But I don't know the full history.

60.2 was not released until the 13th. It was an error to pull files down until actual release.

Ok, formally you are right, I got the release mail at 14th.

[srl295]

@jschleus I wrote fossies asking if there's any best practice we should do here. I'll ask here also. Any suggestions? I will say that we'd rather not setup a whole staging area just to keep fossies from scraping intermediate stuff (we have a lot of links into the download files that need to be updated).

There's fresh, and then there's too fresh! In this case we found the validLocale("") breaks on some compilers, so we updated the release.

[Amgine0]

@Amgine0 are you still seeing this?

curl: (6) Could not resolve host: ssl.icu-project.org

@srl295 No, at least as of about 5 minutes ago.

[jschleus]

@jschleus I wrote fossies asking if there's any best practice we should do here. I'll ask here also. Any suggestions? I will say that we'd rather not setup a whole staging area just to keep fossies
from scraping intermediate stuff (we have a lot of links into the download files that need to be
updated).

There's fresh, and then there's too fresh! In this case we found the validLocale("") breaks on some compilers, so we updated the release.

There is a conflict for Fossies and its goal of freshness. Although I admit that the official release isn't done before sending the announcement, putting a tarball with an official release name on the official download area seems to me like a de facto release. Ok, often announcements are done only a few days after putting the release tarball on the official download area but just to ensure that really all project mirrors are synchronized (by the way most of the software projects on Fossies are never announced but just released by putting the release on its project download area). But although I prefer nevertheless in a special case like the current one a new tarball name (also normal users will have downloaded the problematic release file that probably wasn't recognizable as intermediate stuff) I see and accept your issue and we will exclude ICU releases now from the semi-automatic update procedure on Fossies and will try to do the updates manually after seeing a release announcement.

But if you prefer that we remove the ICU releases completely from Fossies please let me know that (since that is no longer really Homebrew related you may contact me again via [email protected]).

[srl295]

@jschleus No, I don't have any preferences to remove ICU from Fossies, nor even to remove it from automatic check. I think this is the first time that different files had been uploaded over more than one day. We have to be able to put something up to get the rest of the team to verify that yes, what's uploaded looks good. As mentioned, a staging area would work, but, that would break other internal links that we might verify. In this specific case, I uploaded some files as they were available, and prior to other tasks (that I should have done earlier in the cycle…) and so the breakage was found before the announcement was sent out, but not much before.

I guess also, post release, I could verify that Fossies mirror matches the actual release, iff a re upload is done.

[jschleus]

Ok. Just to classify such a faulty situation: In the 23 years of maintaining Fossies and far more than 100.000 offered release files I can remember only 2 or 3 similar incidents (a compliment for the diligence of the package maintainers and a .residual risk while using the freshness of Fossies)

[jschleus]

Still a small addition that may be also relevant to Homebrew users:

Fossies offers for all downloadable archive files (also for the alternative formats like tar.bz2, tar.xz or zip) according MD5, SHA1 and SHA256 checksums Just add _fossies.md5, _fossies.sha1 or _fossies.sha256 to an archive download URL (or more shortly just .md5, .sha1 or .sha256), for e.g.

https://fossies.org/linux/misc/icu4c-60_2-src.tgz_fossies.md5

The first variant makes it clearer that the checksums are not the original ones but are generated on Fossies. They mainly serve to check the archive integrity after a download from Fossies and to allow a comparison with the optionally available original ones.