Closed Bug 1147760 Opened 5 years ago Closed 5 years ago

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

Categories

(Firefox Build System :: General, defect)

x86_64
Linux
defect
Not set

Tracking

(firefox38 fixed, firefox39 fixed, firefox40 fixed)

RESOLVED FIXED
mozilla40
Tracking Status
firefox38 --- fixed
firefox39 --- fixed
firefox40 --- fixed

People

(Reporter: glandium, Assigned: glandium)

Details

Attachments

(1 file)

No description provided.
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.
Attachment #8583634 - Flags: review?(gps)
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.
Attachment #8583634 - Flags: review?(gps) → review+
https://hg.mozilla.org/mozilla-central/rev/453c7f388d5a
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
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
Attachment #8583634 - Flags: approval-mozilla-beta?
Attachment #8583634 - Flags: approval-mozilla-aurora?
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.
Attachment #8583634 - Flags: approval-mozilla-beta?
Attachment #8583634 - Flags: approval-mozilla-beta+
Attachment #8583634 - Flags: approval-mozilla-aurora?
Attachment #8583634 - Flags: approval-mozilla-aurora+
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.