1147760 - Using mozpack.files.FileCopier in-place can fail with XPTFiles

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Comment 1

[Mike Hommey [:glandium]]

Attachment: In mozpack.files.FileCopier.copy, remove files after copying

Some file types, such as XPTFile, read their associated data during the
copy. In the case of XPTFiles, several original files are linked together
in one destination file. When a FileCopier is used in-place, those
original files are removed before XPTFile.copy is invoked, so XPTFile.copy
fails.

Generally speaking, there are many other reasons why FileCopier can fail
in-place, but the only active use of this mode is l10n repack code, which
actually doesn't do much of the dangerous uses. However, it can end up
linking XPTFiles for some reason, which fails for the reasons given above.

Comment 2

[Mike Hommey [:glandium]]

Philipp, fyi, this is what causes xpt errors for your repacks. Please note, though, that this also tells that somehow, what you're repacking hasn't been packed with the packager code from tip, because those xpt files should already be linked in the first place. With this patch + the patches from bug 1147207, an l10n repack using the three tarballs you gave me works, as long as you add "extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}=/path/to/the/l10n-addon" on the l10n-repack.py command line.

Comment 3

[Mike Hommey [:glandium]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/453c7f388d5a

Comment 4

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/453c7f388d5a

Comment 5

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Comment on attachment 8583634 [details] [diff] [review]
In mozpack.files.FileCopier.copy, remove files after copying

Approval Request Comment (for all 4 parts)
[Feature/regressing bug #]: Feature
[User impact if declined]: No way to package Lightning with Thunderbird using the build system. We'd like to package Lightning with Thunderbird 38.
[Describe test coverage new/current, TreeHerder]: Green builds on TH, this patch is already down to aurora.
[Risks and why]: Possible risks with release packaging? We'd find out eventually when this merges to beta next cycle, so I don't think that should be a reason to reject approval.
[String/UUID change made/needed]: none

Comment 6

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8583634 [details] [diff] [review]
In mozpack.files.FileCopier.copy, remove files after copying

Should be low risk for Firefox, we want to help our thunderbird friends, especially when 38 is an ESR.
Should be in 38 beta 2 or 3.

Comment 7

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/f6c18d1052d6

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/2bc3aac3094b