Closed Bug 519068 Opened 15 years ago Closed 15 years ago

[SeaMonkey 2.1, Windows] Shared/Hourly builds don't start anymore: packaging issue

Categories

(SeaMonkey :: Build Config, defect)

Product:
SeaMonkey
Component:
Build Config
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
seamonkey2.1a1

People

(Reporter: sgautherie, Assigned: sgautherie)

References

Details

(Keywords: crash, regression, Whiteboard: [Fixed by blocking bugs...]) 

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.3a1pre) Gecko/20090925 SeaMonkey/2.1a1pre] (nightly) (W2Ksp4)

Works fine.

***

/pub/seamonkey/nightly/2009/09/2009-09-25-01-comm-central-trunk

Error dialog during startup:
{
JavaScript Application
Error launching browser window:no XBL binding for browser
}

It can also crash with some parameters: I sent a few crash reports.

***

/pub/seamonkey/tinderbox-builds/comm-central-trunk-win32/1253914288 (26 00:05)
/pub/seamonkey/tinderbox-builds/comm-central-trunk-win32/1253955519 (26 12:03)
/pub/seamonkey/tinderbox-builds/comm-central-trunk-win32/1253998624 (26 23:59)

Start to load then process just dies: no error, no nothing :-(
(In reply to comment #0)
> Error dialog during startup:
> {
> JavaScript Application
> Error launching browser window:no XBL binding for browser
> }

Same with:
/pub/seamonkey/nightly/2009/09/2009-09-27-00-comm-central-trunk
Summary: SeaMonkey 2.1 don't load (at all) anymore → SeaMonkey 2.1 don't load (at all) anymore: "Error launching browser window:no XBL binding for browser"
(In reply to comment #0)
> /pub/seamonkey/nightly/2009/09/2009-09-25-01-comm-central-trunk

/pub/seamonkey/nightly/2009/09/2009-09-26-00-comm-central-trunk !

***

Regression timeframe:
nightlies: (17h25)
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=def6be3d8b6b&tochange=e109f9a3b6ee
tinderboxes: (11h08)
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=def6be3d8b6b&tochange=1aaedcad1634
local: (4h32, but failure not yet reproduced)
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=614e3c4ba3c1&tochange=1aaedcad1634
(In reply to comment #2)
> local: (4h32, but failure not yet reproduced)
> http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=614e3c4ba3c1&tochange=1aaedcad1634

local: (4mn, 2 changesets)
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3ef7c0074486&tochange=1aaedcad1634
Hum, quite unlikely.
Would it be a packaging issue?
(In reply to comment #3)

> change=614e3c4ba3c1
> change=3ef7c0074486
> Would it be a packaging issue?

Indeed: run from dist/bin, fail from dist/seamonkey.
Then my first guess was right: bug 514665.

And it even seems it was expected :-/
{
Comment #13 From  Phil Ringnalda (:philor)   2009-09-27 13:18:28 PDT

Both of suite's manifests need more, yeah, but I intentionally only fixed
suite's issues that were fallout from this bug, so only Windows.
}
Blocks: CcMcBuildIssues, 514665
Component: General → Build Config
QA Contact: general → build-config
Oh, I didn't pay attention but the c-c patch there just landed a moment ago ;->

Phil, Mark, what would be the additional things to do here?
(In reply to comment #6)
> Oh, I didn't pay attention but the c-c patch there just landed a moment ago ;->
> 
> Phil, Mark, what would be the additional things to do here?

Assuming this bustage was caused by that patch - then in theory this bug should be fixed. So nothing more to do.

At some stage looking at the package-compare output it looks like SeaMonkey's packages file needs some TLC for trunk at least, although considering they are built with tests it may take a bit to unpick what is test code and what isn't.
Oh, I didn't fix packaging of shared builds, because I can't make it stick in my head that you actually ship static nightlies and shared hourlies. Maybe if you rebranded them to be named Footgun it would be easier to remember that that's what they are?

So, since your tinderbox package-compare is pretty much useless, what someone (who is not me) needs to do is update, clobber their objdir, build --enable-shared, --disable-tests, make installer, make package-compare and find the things like tkitcmps.dll -> toolkitcomps.dll that aren't being packaged, add them to packages, and add the old things to removed-files.in ifdeffed so that you cover all the paths:

static 1.9.1 -> static mozilla-central
static 1.9.1 -> shared mozilla-central
static 1.9.1 -> shared 1.9.1
shared 1.9.1 -> static 1.9.1
shared 1.9.1 -> shared mozilla-central
shared 1.9.1 -> static mozilla-central

which you can then test by building all four installers, shared and static for both 1.9.1 and mozilla-central, install all four, then install them again and install the others over the top (because that's an easier way of testing removed-files.in than building updates), and diff -r the clean install and the over the top to be sure they wind up the same: install C:\shared-mozilla-central\, install a static 1.9.1 in C:\static-191-to-shared-mc\, install a shared mozilla-central on top, diff -r C:\static-191-to-shared-mc\ C:\shared-mozilla-central\, repeat with the other five.
We don't really care about shared builds in removed-files.in, it would only affect people who run the installer on hourlies to install over an old hourly, and those people are able to clobber their application directory once in a while.
Anyone on nightlies or releases after the point where we introduced static builds (2.0 alphas are at least to a part shared), whether he uses updater or installer, runs on static builds, and removed-files.in only needs to care about nightlies or releases.
I'm unsure of the relevance, if any, but as well as Seamonkey 2.1a1pre not loading for me, Shredder 3.1a1pre is also not loading. The crash reports are, to my untrained eye, very similar.

[url=http://crash-stats.mozilla.com/report/index/d6e6288f-9a8a-4be6-b936-a1b7f2090928]SM 2.1a1pre Crash Report[/url]
[url=http://crash-stats.mozilla.com/report/index/7cbfafc3-7a4e-4a7a-ac5d-cf28e2090928]Shredder crash Report[/url]
cannot reproduce with SM/20090928012538-trunk/WinXP

Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.3a1pre) Gecko/20090928 SeaMonkey/2.1a1pre
As expected:

(In reply to comment #8)
> I didn't fix packaging of shared builds, because I can't make it stick in
> my head that you actually ship static nightlies and shared hourlies.

/pub/seamonkey/tinderbox-builds/comm-central-trunk-win32/1254139741 (28 14:53)
"Hourly" still dies silently.

(In reply to comment #12)
> cannot reproduce with SM/20090928012538-trunk/WinXP

/pub/seamonkey/nightly/2009/09/2009-09-28-01-comm-central-trunk
I confirm nightly is fixed :-)
Severity: blocker → critical
Keywords: crash
Summary: SeaMonkey 2.1 don't load (at all) anymore: "Error launching browser window:no XBL binding for browser" → [SeaMonkey 2.1, Windows] Shared/Hourly builds don't start anymore: packaging issue
[] (comm-central-trunk-win32/1256246281) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/8d79c4a770ea
 +http://hg.mozilla.org/comm-central/rev/558474146a03)

"Hourly" still dies silently.
[] (comm-central-trunk-win32/1256776662) (W2Ksp4)

Bug still there. (after first packaging clean-ups, much more to come...)
[] (comm-central-trunk-win32/1257988947) (W2Ksp4)

Bug still there. (after 2 more packaging clean-ups, much more to come...)
The fun things is that we're routinely running package-compare on our normal build cycles but nobody seems to analyze the logs.

Here we go:

WINNT 5.2 comm-central-trunk build:
--- ../../mozilla/dist/pack-list.txt	2009-12-11 10:42:13 -0800
+++ ../../mozilla/dist/bin-list.txt	2009-12-11 10:42:13 -0800
-bin/components/appshell.dll
-bin/components/cmdlines.dll
+bin/components/commandlines.dll
-bin/components/gkparser.dll
+bin/components/htmlpars.dll
+bin/components/jsctypes.dll
+bin/components/msgAsyncPrompter.js
+bin/components/nsappshell.dll
-bin/components/perms.dll
+bin/components/permissions.dll
+bin/components/spellchecker.dll
-bin/components/spellchk.dll
-bin/components/strgcmps.dll
+bin/components/storagecomps.dll
-bin/components/tkautoc.dll
-bin/components/tkitcmps.dll
+bin/components/tkautocomplete.dll
+bin/components/toolkitcomps.dll
+bin/components/windowsproxy.dll
-bin/components/xpautoc.dll
+bin/components/xpautocomplete.dll
+bin/dependentlibs.list
+bin/extensions/inspector@mozilla.org/components/components.list
+bin/extensions/{59c81df5-4b7a-477b-912d-4e0fdf64e5f2}/components/components.list
+bin/extensions/{f13b157f-b174-47e7-a34d-4815ddfdfeb8}/components/components.list
-bin/jsj3250.dll

Linux comm-central-trunk build:
--- ../../mozilla/dist/pack-list.txt	2009-12-11 10:02:49.000000000 -0800
+++ ../../mozilla/dist/bin-list.txt	2009-12-11 10:02:49.000000000 -0800
+bin/components/libjsctypes.so
+bin/components/msgAsyncPrompter.js
+bin/dependentlibs.list
+bin/extensions/{59c81df5-4b7a-477b-912d-4e0fdf64e5f2}/components/components.list
+bin/extensions/{f13b157f-b174-47e7-a34d-4815ddfdfeb8}/components/components.list
+bin/extensions/inspector@mozilla.org/components/components.list
-bin/libjsj.so

WINNT 5.2 comm-central-trunk nightly:
--- ../../mozilla/dist/pack-list.txt	2009-12-11 02:36:50 -0800
+++ ../../mozilla/dist/bin-list.txt	2009-12-11 02:36:50 -0800
@@ -1,7 +1,8 @@
-bin/components/jar50.dll
+bin/components/msgAsyncPrompter.js
+bin/dependentlibs.list
+bin/extensions/inspector@mozilla.org/components/components.list
+bin/extensions/{59c81df5-4b7a-477b-912d-4e0fdf64e5f2}/components+bin/extensions/{f13b157f-b174-47e7-a34d-4815ddfdfeb8}/components/components.list

Linux comm-central-trunk nightly:
--- ../../mozilla/dist/pack-list.txt	2009-12-11 01:49:59.000000000 -0800
+++ ../../mozilla/dist/bin-list.txt	2009-12-11 01:49:59.000000000 -0800
-bin/components/libjar50.so
+bin/components/msgAsyncPrompter.js
+bin/dependentlibs.list
+bin/extensions/{59c81df5-4b7a-477b-912d-4e0fdf64e5f2}/components/components.list
+bin/extensions/{f13b157f-b174-47e7-a34d-4815ddfdfeb8}/components/components.list
+bin/extensions/inspector@mozilla.org/components/components.list


I cleaned out all things that I know are no concern. I'm pretty sure we need all the *.list files to make the stuff listed in them load at all.
No longer blocks: 514665
Depends on: 514665
Depends on: 528806
Depends on: 534410
(In reply to comment #17)
> +bin/components/msgAsyncPrompter.js

I filed bug 534528.
There are remaining packaging issues to fix,
but, after (previous bugs/fixes and) bug 534410, this bug is mainly fixed: the tinderbox-builds start again :-)
Assignee: nobody → sgautherie.bz
Status: NEW → RESOLVED
Closed: 15 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Whiteboard: [Fixed by blocking bugs...]
Target Milestone: --- → seamonkey2.1a1
V.Fixed, by testing a few "hourlies" locally.
Status: RESOLVED → VERIFIED
(In reply to comment #19)
> There are remaining packaging issues to fix

Could you file bugs for those? I mainly wonder about the *.list files in my analysis and the removal of the jsj/jar50 libraries - and then the addition of the jsctypes binary component on the shared builds.
(In reply to comment #21)
> Could you file bugs for those?

That's what I've been doing for some time now ... but I file bugs when I have figured out what each case is only!
(In reply to comment #17)
> -bin/jsj3250.dll
> -bin/libjsj.so

I attached a patch to bug 521624.
(In reply to comment #17)
> -bin/components/jar50.dll
> -bin/components/libjar50.so

I filed bug 534726.
(In reply to comment #17)
> +bin/components/windowsproxy.dll

I filed bug 534917.
(In reply to comment #17)
> +bin/components/jsctypes.dll
> +bin/components/libjsctypes.so

I filed bug 535231.
(In reply to comment #17)
> +bin/extensions/inspector@mozilla.org/components/components.list
> +bin/extensions/{59c81df5-4b7a-477b-912d-4e0fdf64e5f2}/components/components.list
> +bin/extensions/{f13b157f-b174-47e7-a34d-4815ddfdfeb8}/components/components.list

I filed bug 535320.
(In reply to comment #17)

> The fun things is that we're routinely running package-compare on our normal
> build cycles but nobody seems to analyze the logs.

Sure, I would have expected it to warn/fail when there is something that needs attention :-/

> +bin/dependentlibs.list

I filed bug 535342.

> I'm pretty sure we need
> all the *.list files to make the stuff listed in them load at all.

No, see bug 526764 (related to comment 37).

***

NB: That's all for this list of files. I prefer when you fill separate bugs...
Thanks for working through the list, I'll try to get to the reviews as fast as I can.
You need to log in before you can comment on or make changes to this bug.