Closed
Bug 541125
Opened 15 years ago
Closed 15 years ago
Fix wrong packaging issues on m-1.9.2, SeaMonkey part
Categories
(SeaMonkey :: Build Config, defect)
SeaMonkey
Build Config
Tracking
(Not tracked)
RESOLVED
FIXED
seamonkey2.1a1
People
(Reporter: sgautherie, Assigned: sgautherie)
References
Details
Attachments
(2 files, 1 obsolete file)
(deleted),
patch
|
kairo
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
Callek
:
review+
|
Details | Diff | Splinter Review |
No description provided.
Flags: in-testsuite-
Assignee | ||
Updated•15 years ago
|
Assignee | ||
Updated•15 years ago
|
Summary: Fix wrong packaging issues on m-1.9.2 → Fix wrong packaging issues on m-1.9.2, SeaMonkey part
Assignee | ||
Comment 1•15 years ago
|
||
Bug 512763 missed m-1.9.2 case :-(
Bug 523820 removed m-1.9.1 SM case.
Bug 530010 fixed it correctly, for TB only :-|
Attachment #422776 -
Flags: review?(kairo)
Updated•15 years ago
|
Attachment #422776 -
Flags: review?(kairo) → review+
Assignee | ||
Comment 2•15 years ago
|
||
Comment on attachment 422776 [details] [diff] [review]
(Av1) Don't package mozcpp19.dll
[Checkin: Comment 2]
http://hg.mozilla.org/comm-central/rev/5895e4caa1a1
Attachment #422776 -
Attachment description: (Av1) Don't package mozcpp19.dll → (Av1) Don't package mozcpp19.dll
[Checkin: Comment 2]
Assignee | ||
Comment 3•15 years ago
|
||
Bug 511849 missed m-1.9.2 case :-(
Bug 523820 removed m-1.9.1 SM case.
Bug 530010 fixed it correctly, for TB only :-|
Attachment #423392 -
Flags: review?(bugspam.Callek)
Updated•15 years ago
|
Attachment #423392 -
Flags: review?(bugspam.Callek) → review-
Comment 4•15 years ago
|
||
Comment on attachment 423392 [details] [diff] [review]
(Bv1) Restore mozbrwsr.xpt packaging
suite needs a 1.9.3 removed-files entry for this.
Assignee | ||
Comment 5•15 years ago
|
||
Bv1, with comment 4 suggestion(s).
(In reply to comment #4)
Does it? There was none before.
(Note I'm not saying there shouldn't have been one...)
Could you provide the history that explains why it's needed, for (MacOSX and) Unix+Windows?
(I mean that I suspect you could also file a bug for many more '.xpt'...)
Attachment #423392 -
Attachment is obsolete: true
Attachment #423485 -
Flags: review?(bugspam.Callek)
Updated•15 years ago
|
Attachment #423485 -
Flags: review?(bugspam.Callek) → review+
Comment 6•15 years ago
|
||
(In reply to comment #5)
> Created an attachment (id=423485) [details]
> (Bv2) Restore mozbrwsr.xpt packaging
>
> Bv1, with comment 4 suggestion(s).
>
> (In reply to comment #4)
>
> Does it? There was none before.
> (Note I'm not saying there shouldn't have been one...)
Before there didn't need to be one as we didn't package this anywhere...
But this bug is adding the file to 1_9_2 ONLY:
|#ifdef MOZILLA_1_9_2_BRANCH|
Thus we need a trunk removed-files entry. [to account for if we ever do a 1.9.2 release]
Assignee | ||
Comment 7•15 years ago
|
||
(In reply to comment #6)
No: this patch is _restoring_ previously-MOZILLA_1_9_1_BRANCH-only lines that should not have been removed!
See http://hg.mozilla.org/comm-central/rev/955b4e732760.
(Thus my comment 5 questions.)
Comment 8•15 years ago
|
||
(In reply to comment #7)
> (In reply to comment #6)
>
> No: this patch is _restoring_ previously-MOZILLA_1_9_1_BRANCH-only lines that
> should not have been removed!
Either way, file is not packaged currently, and needs to be removed; if your adding it back in for 1_9_2 we need to remove it for 1.9.3 only; if you don't add it back in for 1.9.2 we need to remove it for both; (But yes the patch I reviewed should land)
Assignee | ||
Comment 9•15 years ago
|
||
Comment on attachment 423485 [details] [diff] [review]
(Bv2) Restore mozbrwsr.xpt packaging on m-1.9.2, Add removal on m-c
[Checkin: Comment 9]
http://hg.mozilla.org/comm-central/rev/db60f2b46ffc
Attachment #423485 -
Attachment description: (Bv2) Restore mozbrwsr.xpt packaging → (Bv2) Restore mozbrwsr.xpt packaging on m-1.9.2, Add removal on m-c
[Checkin: Comment 9]
Assignee | ||
Comment 10•15 years ago
|
||
(In reply to comment #8)
> Either way, file [...] needs to be removed
Probably, but it also depends on the fact that most xpt files are merged during packaging on Unix+Windows now: thus wondering about when/how this xpt was initially added...
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Comment 11•15 years ago
|
||
I agree with Serge here, we don't need to remove an xpt that gets merged into either browser.xpt or mailnews.xpt anyhow and therefore is never installed in a nightly or release version.
Comment 12•15 years ago
|
||
(In reply to comment #11)
> I agree with Serge here, we don't need to remove an xpt that gets merged into
> either browser.xpt or mailnews.xpt anyhow and therefore is never installed in a
> nightly or release version.
Hmm I didn't realize these .xpt's were being merged for us now; any pointer on where and/or what they merge into for me for future?
Comment 13•15 years ago
|
||
(In reply to comment #12)
> Hmm I didn't realize these .xpt's were being merged for us now; any pointer on
> where and/or what they merge into for me for future?
The packaging process merges ("links" using an "xptlink" tool) all .xpt files inside every section of the relevant packages file, i.e. all .xpt files listed under [browser] get linked into browser.xpt, all under [mailnews] into mailnews.xpt.
Comment 14•15 years ago
|
||
Hrm, and actually, I just realized that we probably don't link XPTs on Mac, as we don't use a package manifest there right now - so we might need the removed-files entry after all...
Serge?
Comment 15•15 years ago
|
||
(In reply to comment #14)
> Hrm, and actually, I just realized that we probably don't link XPTs on Mac, as
> we don't use a package manifest there right now - so we might need the
> removed-files entry after all...
Patch as pushed has the removed-files entry here. Lets do remaining followup in another/other bug
Assignee | ||
Comment 16•15 years ago
|
||
(In reply to comment #14)
Usually, I'm kind of ignoring MacOSX (non-)packaging and xpt removals, until bug 521523.
In the case here though, I was implicitly wondering if adding an |#ifdef XP_MACOSX| would be appropriate.
(And you seemed to say "99% yes" over irc, iiuc.)
Of course, it's safer to let it as is until 100% sure.
(In reply to comment #15)
> Lets do remaining followup in another/other bug
Well, if you (both) want to discuss/investigate/answer it, I would say "as well continue here" now.
Comment 17•15 years ago
|
||
(In reply to comment #16)
> (In reply to comment #14)
> Usually, I'm kind of ignoring MacOSX (non-)packaging and xpt removals, until
> bug 521523.
Well, removed-files is used by the automatic update functionality, which also applies to Mac, so we need to care about it for those removals, but you are right on packaging.
You need to log in
before you can comment on or make changes to this bug.
Description
•