It looks like Phabricator messed up the encoding on the sources imported into third_party for OTR in bug 1518164. See screenshot.
Jörg suspects bug 1556381 is the culprit. But the thing with that, the original files in the tars seem to be utf-8 which is what Phab supposedly works with.

In any case, I can't compile libgpg-error with the sources as they are, so this needs fixing.

I will download the original tar files and unpack them again and go from there.

Jörg, maybe it's best if I commit the source from the verified archive directly, to avoid that patches mess up any binary or file permission changes? If you're OK, then I'd like to commit these patches to comm-central, and also to comm-esr68.

These files aren't part of the default Thunderbird build, there won't be any impact on treeherder builds/tests.

OK, please with DONTBUILD and a decent commit message ;-)

Pushed by kaie@kuix.de:
https://hg.mozilla.org/comm-central/rev/7b3dc0779dbd
Fix encoding corruptions in imported libgpg-error library. r=me
https://hg.mozilla.org/comm-central/rev/2984dbf516e6
Fix encoding corruptions in imported libgcrypt library. r=me
https://hg.mozilla.org/comm-central/rev/1592f9f86df5
Fix encoding corruptions in imported libotr library. r=me

DONTBUILD?

Look at the commits, I added DONTBUILD

Where?

https://hg.mozilla.org/comm-central/rev/7b3dc0779dbd
Fix encoding corruptions in imported libgpg-error library. r=me
https://hg.mozilla.org/comm-central/rev/2984dbf516e6
Fix encoding corruptions in imported libgcrypt library. r=me
https://hg.mozilla.org/comm-central/rev/1592f9f86df5
Fix encoding corruptions in imported libotr library. r=me

Anyway, I don't know whether this would have triggered a build.

More worrying is that they got corrupted in the first place. Now we're returning everything to UTF-8, so if the patches were UTF-8 to start with in bug 1518164, where did things go wrong?

I can see it: The files are already corrupted in https://phabricator.services.mozilla.com/D37324.
Check for example: third_party/libgpg-error/po/zh_CN.po
#: src/err-sources.h:28
msgid "Unspecified source"
msgstr "????"

:-(

(In reply to Jorg K (GMT+2) from comment #10)

Where?

Second line of commit messages. Just click one of the commit links, and you'll see it.

I see there are builds running in treeherder.

I've always used DONTBUILD on a separate line in the past for mozilla-central builds, and it always worked.
Does comm-central use a different parser?

I'll add DONTBUILD to the first line when commiting to esr68

No problem, yes, we add it to the commit message " ... r=Mickey a=Goofy CLOSED TREE DONTBUILD" of the last changeset.

Let's wait until TB 68.1 has shipped OK?

EDIT: The builds are the Daily run which started later.

sure, let's wait

The ESR uplift slipped through the cracks since the query didn't find the bug since it had no target :-(

https://hg.mozilla.org/releases/comm-esr68/rev/b95c6484e623534a5eec93e0d89aedf0605a6cb8
https://hg.mozilla.org/releases/comm-esr68/rev/e1381f3f3a369f0c1b79d815e7a69e54fba5a04a
https://hg.mozilla.org/releases/comm-esr68/rev/584593b3aa505aa600a6ef299a7f7b654442340b

Looks like I don't have permission to set the tracking flag. Jörg, could you please set as required?

I guess it missed 68.1.1, so it will be 68.2, not that it matters.