Hi, Thanks for the fix! I am trying to pull from your GitHub repository, but it’s not showing anything new since 2020e. I looked on GitHub.com and no commits show past the 2020e tag. I can apply the patch manually, of course, but it sounds like you’d committed it? I will talk to our CI folks and see if I can get something set up along the lines you suggest. Right now I have to make manual changes to the tarballs because our zic is not up to date, and I need to add yearistype.sh back in in order for everything to build. I’ll try to automate that, too. I’m also trying to get our zic updated. Thanks, Deborah
On Dec 23, 2020, at 11:23 AM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:
On 12/22/20 11:06 PM, Deborah Goldsmith via tz wrote:
I verified that introducing a rule to set zone to empty when encountering “End of rearguard section" fixes the problem, and does not introduce any other changes to the output.
Thanks for the problem report and diagnosis. I installed into the development repository the attached proposed patch, which is a bit fancier, as setting the zone to empty would mean we couldn't have multiple sections per Zone. The attached patch also adds some code to "make check_public" (which I run before distributing any release) so that similar problems will be caught before future releases.
The new "make check_public" rule won't catch all rearguard issues, just simple ones like the one you ran into. I don't test the rearguard as much as the main data, and even if I did more tests I undoubtedly would miss things that you'd catch with your tests within Apple. Is there some way you could create a buildbot at Apple that tracks the development repository and periodically runs Apple's tests on it? The problem you ran into was due to a commit dated December 10, and if Apple ran their checks every now and then we would have caught this problem before 2020e came out.
At any rate it looks like we'll need a 2020f soon, assuming the attached patch works for you. <0001-Fix-rearguard.zi-corruption-in-2020e.patch>