Mac Chatzilla manifest is different causing unify to fail, and mac builds to be red.

RESOLVED FIXED in seamonkey2.1a3

Status

SeaMonkey
Build Config
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: Callek, Assigned: Robert Kaiser)

Tracking

unspecified
seamonkey2.1a3

Firefox Tracking Flags

(blocking-seamonkey2.1 a3+)

Details

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
The mac builds of SeaMonkey are failing due to chatzilla not building correctly on both arch's. I logged into our mac builder and diff'd the two files. [note that unify sorts the files first]

--- objdir/ppc/mozilla/dist/seamonkey/SeaMonkey.app/Contents/MacOS/extensions/{59c81df5-4b7a-477b-91
2d-4e0fdf64e5f2}/chrome.manifest        2010-08-10 19:00:26.000000000 -0700
+++ objdir/i386/mozilla/dist/seamonkey/SeaMonkey.app/Contents/MacOS/extensions/{59c81df5-4b7a-477b-9
12d-4e0fdf64e5f2}/chrome.manifest       2010-08-10 19:00:36.000000000 -0700
@@ -5,22 +5,21 @@
 contract @mozilla.org/network/protocol;1?name=irc {f21c35f4-1dd1-11b2-a503-9bf8a539ea39}
 overlay chrome://browser/content/browser.xul chrome://chatzilla/content/browserOverlay.xul application={ec8030f7-c20a-464f-9b0e-13a3a9e97384}
 contract @mozilla.org/network/protocol;1?name=ircs {f21c35f4-1dd1-11b2-a503-9bf8a539ea39}
 overlay chrome://songbird/content/xul/layoutBaseOverlay.xul chrome://chatzilla/content/browserOverlay.xul application=songbird@songbirdnest.com
 component {38a95514-1dd2-11b2-97e7-9da958640f2c} components/chatzilla-service.js
 content chatzilla-sm jar:chrome/chatzilla.jar!/content/chatzilla/sm/
 overlay chrome://communicator/content/pref/preferences.xul chrome://chatzilla/content/prefsOverlay.xul application={92650c4d-4b8e-4d2a-b7eb-24ecf4f6b63a}
 style   chrome://global/content/customizeToolbar.xul chrome://chatzilla/skin/browserOverlay.css
+overlay chrome://browser/content/browser.xul chrome://chatzilla/content/browserOverlay.xul application={a463f10c-3994-11da-9945-000d60ca027b}
 content chatzilla            jar:chrome/chatzilla.jar!/content/chatzilla/
-content chatzilla-ff jar:chrome/chatzilla.jar!/content/chatzilla/ff/
 overlay chrome://communicator/content/pref/pref-appearance.xul chrome://chatzilla/content/prefsOverlay.xul application={92650c4d-4b8e-4d2a-b7eb-24ecf4f6b63a}
 contract @mozilla.org/commandlinehandler/general-startup;1?type=chat {38a95514-1dd2-11b2-97e7-9da958640f2c}
 overlay chrome://editor/content/editorTasksOverlay.xul chrome://chatzilla/content/chatzillaOverlay.xul application={92650c4d-4b8e-4d2a-b7eb-24ecf4f6b63a}
 skin    chatzilla modern/1.0 jar:chrome/chatzilla.jar!/skin/modern/chatzilla/
-manifest chrome/chatzilla.manifest
-overlay chrome://browser/content/browser.xul chrome://chatzilla/content/browserOverlay.xul application={a463f10c-3994-11da-9945-000d60ca027b}
+content chatzilla-ff jar:chrome/chatzilla.jar!/content/chatzilla/ff/
 locale chatzilla en-US jar:chrome/chatzilla.jar!/locale/en-US/chatzilla/
 overlay chrome://chatzilla/content/menus.xul chrome://communicator/content/tasksOverlay.xul application={92650c4d-4b8e-4d2a-b7eb-24ecf4f6b63a}
 category command-line-handler m-irc @mozilla.org/commandlinehandler/general-startup;1?type=chat
 style   chrome://songbird/content/xul/layoutBaseOverlay.xul chrome://chatzilla/skin/browserOverlay.css
 overlay chrome://chatzilla/content/chatzilla.xul chrome://communicator/content/utilityOverlay.xul application={92650c4d-4b8e-4d2a-b7eb-24ecf4f6b63a}
 overlay chrome://navigator/content/navigator.xul chrome://chatzilla/content/browserOverlay.xul application={92650c4d-4b8e-4d2a-b7eb-24ecf4f6b63a}

Which means that ONLY ppc is getting the |manifest chrome/chatzilla.manifest| line somehow, which looks inherently wrong anyway.  I did not yet investigate more.
(Reporter)

Updated

7 years ago
blocking-seamonkey2.1: --- → ?
(Assignee)

Comment 1

7 years ago
It worked after a clobber once and then failed again, which smells funny.

Comment 2

7 years ago
Sounds like a race condition between the various jar.mn files...
(Assignee)

Updated

7 years ago
Depends on: 579178
(Assignee)

Comment 3

7 years ago
Created attachment 465226 [details] [diff] [review]
don't use BOTH_MANIFESTS for real extensions

I think removing BOTH_MANIFESTS for the real extensions should do the trick. On a local L10n build, both the ChatZilla packages as well as the ChatZilla L10n pack look good on manifest inspection with this patch applied.
Attachment #465226 - Flags: review?(neil)

Updated

7 years ago
Attachment #465226 - Flags: review?(neil) → review+
(Assignee)

Comment 4

7 years ago
Markings as blocking as it's bustage.
blocking-seamonkey2.1: ? → a3+
Target Milestone: --- → mozilla2.0b4
(Assignee)

Comment 5

7 years ago
Pushed as http://hg.mozilla.org/comm-central/rev/8aa03e83218c - waiting for builds to see if things clear up. Probably will need a few builds to verify as first we need to clean chatzilla on all slaves to get the line removed.
(Assignee)

Comment 6

7 years ago
Urgh, I messed up the patch and Neil also didn't spot that I deleted those semicolons that still are needed.
Fixed in http://hg.mozilla.org/comm-central/rev/f9f4b09d470d
(Assignee)

Comment 7

7 years ago
It looks very much like this fixed it, and that also means that this is not a ChatZilla bug after all but a SeaMonkey one.
Assignee: rginda → nobody
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Component: ChatZilla → Build Config
Product: Other Applications → SeaMonkey
QA Contact: chatzilla → build-config
Resolution: --- → FIXED
Target Milestone: mozilla2.0b4 → ---
(Assignee)

Updated

7 years ago
Assignee: nobody → kairo
Target Milestone: --- → seamonkey2.1a3
(Assignee)

Updated

7 years ago
OS: Windows XP → All
Hardware: x86 → All
You need to log in before you can comment on or make changes to this bug.