Last Comment Bug 519068 - [SeaMonkey 2.1, Windows] Shared/Hourly builds don't start anymore: packaging issue
: [SeaMonkey 2.1, Windows] Shared/Hourly builds don't start anymore: packaging ...
Status: VERIFIED FIXED
[Fixed by blocking bugs...]
: crash, regression
Product: SeaMonkey
Classification: Client Software
Component: Build Config (show other bugs)
: Trunk
: x86 Windows 2000
: -- critical (vote)
: seamonkey2.1a1
Assigned To: Serge Gautherie (:sgautherie)
:
Mentors:
Depends on: 514665 528806 534410
Blocks: CcMcBuildIssues
  Show dependency treegraph
 
Reported: 2009-09-26 15:26 PDT by Serge Gautherie (:sgautherie)
Modified: 2009-12-16 13:10 PST (History)
7 users (show)
bugzillamozillaorg_serge_20140323: in‑testsuite-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Serge Gautherie (:sgautherie) 2009-09-26 15:26:06 PDT
[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 :-(
Comment 1 Serge Gautherie (:sgautherie) 2009-09-27 08:31:11 PDT
(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
Comment 2 Serge Gautherie (:sgautherie) 2009-09-27 10:40:20 PDT
(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
Comment 3 Serge Gautherie (:sgautherie) 2009-09-27 11:18:33 PDT
(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?
Comment 4 Serge Gautherie (:sgautherie) 2009-09-27 13:02:51 PDT
(In reply to comment #3)

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

Indeed: run from dist/bin, fail from dist/seamonkey.
Comment 5 Serge Gautherie (:sgautherie) 2009-09-27 13:50:19 PDT
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.
}
Comment 6 Serge Gautherie (:sgautherie) 2009-09-27 14:03:49 PDT
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?
Comment 7 Mark Banner (:standard8) 2009-09-27 14:18:28 PDT
(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.
Comment 8 Phil Ringnalda (:philor) 2009-09-27 15:29:12 PDT
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.
Comment 9 Robert Kaiser 2009-09-28 03:28:15 PDT
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.
Comment 10 Willie Reid 2009-09-28 03:43:11 PDT
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]
Comment 12 baffclan 2009-09-28 03:48:06 PDT
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
Comment 13 Serge Gautherie (:sgautherie) 2009-09-28 07:42:29 PDT
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 :-)
Comment 14 Serge Gautherie (:sgautherie) 2009-10-22 18:19:13 PDT
[] (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.
Comment 15 Serge Gautherie (:sgautherie) 2009-10-28 20:08:54 PDT
[] (comm-central-trunk-win32/1256776662) (W2Ksp4)

Bug still there. (after first packaging clean-ups, much more to come...)
Comment 16 Serge Gautherie (:sgautherie) 2009-11-11 20:16:38 PST
[] (comm-central-trunk-win32/1257988947) (W2Ksp4)

Bug still there. (after 2 more packaging clean-ups, much more to come...)
Comment 17 Robert Kaiser 2009-12-11 12:05:05 PST
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.
Comment 18 Serge Gautherie (:sgautherie) 2009-12-13 10:51:15 PST
(In reply to comment #17)
> +bin/components/msgAsyncPrompter.js

I filed bug 534528.
Comment 19 Serge Gautherie (:sgautherie) 2009-12-13 16:44:47 PST
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 :-)
Comment 20 Serge Gautherie (:sgautherie) 2009-12-13 16:46:05 PST
V.Fixed, by testing a few "hourlies" locally.
Comment 21 Robert Kaiser 2009-12-13 18:25:13 PST
(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.
Comment 22 Serge Gautherie (:sgautherie) 2009-12-13 19:12:45 PST
(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!
Comment 23 Serge Gautherie (:sgautherie) 2009-12-13 21:13:42 PST
(In reply to comment #17)
> -bin/jsj3250.dll
> -bin/libjsj.so

I attached a patch to bug 521624.
Comment 24 Serge Gautherie (:sgautherie) 2009-12-14 13:34:33 PST
(In reply to comment #17)
> -bin/components/jar50.dll
> -bin/components/libjar50.so

I filed bug 534726.
Comment 25 Serge Gautherie (:sgautherie) 2009-12-15 10:50:48 PST
(In reply to comment #17)
> +bin/components/windowsproxy.dll

I filed bug 534917.
Comment 26 Serge Gautherie (:sgautherie) 2009-12-16 08:41:54 PST
(In reply to comment #17)
> +bin/components/jsctypes.dll
> +bin/components/libjsctypes.so

I filed bug 535231.
Comment 27 Serge Gautherie (:sgautherie) 2009-12-16 11:20:08 PST
(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.
Comment 28 Serge Gautherie (:sgautherie) 2009-12-16 12:11:35 PST
(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...
Comment 29 Robert Kaiser 2009-12-16 13:10:57 PST
Thanks for working through the list, I'll try to get to the reviews as fast as I can.

Note You need to log in before you can comment on or make changes to this bug.