[tz] make traditional_tarballs fails on macOS for 2022b

[Deborah Goldsmith]

macOS (and FreeBSD) use onetrueawk (https://github.com/onetrueawk/awk.git). I tried this with their latest commit, and the same failure occurs. So 2022b is incompatible with any platform that uses onetrueawk. This includes FreeBSD 13.1 and macOS (I don’t know what other platform-clients might be).

I filed this issue against onetrueawk, but there is no guarantee it will be fixed any time soon: https://github.com/onetrueawk/awk/issues/149

Meanwhile, there is no way to get rearguard_tarballs on those platforms.

Debbie

> On Aug 11, 2022, at 12:15 AM, Deborah Goldsmith via tz <tz at iana.org> wrote:
> 
> We don’t modify the source. We do make the rearguard tarballs, which suffer from the same awk problem, and which can’t be downloaded.
> 
> As of macOS 13 public betas, it appears that nroff is no longer distributed as part of macOS. macOS 13 public betas include mandoc. (I can’t speak to what the final content of macOS 13 GM will be.)
> 
> Debbie
> 
> 
>> On Aug 11, 2022, at 12:08 AM, Paul Eggert <eggert at CS.UCLA.EDU> wrote:
>> 
>> On 8/10/22 23:44, Deborah Goldsmith wrote:
>>> Given that this is a bug that affects multiple systems (macOS, FreeBSD 13.1) please consider releasing a new version with the fix.
>> 
>> Before doing a new release could you explain a bit more what went wrong? I wonder whether we're merely papering over a deeper problem.
>> 
>> macOS users don't need to run "make traditional_tarballs" to get traditional tarballs, as they can get these tarballs prebuilt from upstream:
>> 
>> https://data.iana.org/time-zones/releases/tzcode2022b.tar.gz
>> https://data.iana.org/time-zones/releases/tzdata2022b.tar.gz
>> 
>> So I expect there's something more going on, such as modifying the code or data before generating the traditional tarballs as part of some script. What sort of modifications or script is that? And some process is modifying the source or data, can't that process also apply the patch as part of the modification?
>> 
>> Also, I'm puzzled by why workman.sh was invoked, as I mentioned in my recent email to Guy. Is that due to the modifications mentioned above?
>