OTR library sources are corrupt as imported
Categories
(Chat Core :: Security: OTR, defect)
Tracking
(thunderbird_esr6870+ fixed)
People
(Reporter: rjl, Assigned: KaiE)
References
Details
Attachments
(4 files)
14.58 KB,
image/png
|
Details | |
887.94 KB,
patch
|
KaiE
:
review+
jorgk-bmo
:
approval-comm-esr68+
|
Details | Diff | Splinter Review |
76.09 KB,
patch
|
KaiE
:
review+
jorgk-bmo
:
approval-comm-esr68+
|
Details | Diff | Splinter Review |
3.36 KB,
patch
|
KaiE
:
review+
jorgk-bmo
:
approval-comm-esr68+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•5 years ago
|
||
Assignee | ||
Comment 2•5 years ago
|
||
Assignee | ||
Comment 3•5 years ago
|
||
Assignee | ||
Comment 4•5 years ago
|
||
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.
Assignee | ||
Comment 5•5 years ago
|
||
These files aren't part of the default Thunderbird build, there won't be any impact on treeherder builds/tests.
Comment 6•5 years ago
|
||
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
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Comment 8•5 years ago
|
||
DONTBUILD?
Assignee | ||
Comment 9•5 years ago
|
||
Look at the commits, I added DONTBUILD
Comment 10•5 years ago
|
||
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 "????"
:-(
Assignee | ||
Comment 11•5 years ago
|
||
(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.
Assignee | ||
Comment 12•5 years ago
|
||
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
Comment 13•5 years ago
•
|
||
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.
Assignee | ||
Comment 14•5 years ago
|
||
sure, let's wait
Comment 15•5 years ago
|
||
The ESR uplift slipped through the cracks since the query didn't find the bug since it had no target :-(
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Comment 16•5 years ago
|
||
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?
Comment 17•5 years ago
|
||
I guess it missed 68.1.1, so it will be 68.2, not that it matters.
Updated•5 years ago
|
Description
•