The default bug view has changed. See this FAQ.

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.