When we switch over to being a MOZ_XUL_APP we'll need to have made sure that the installers will install all the files we need. This bug is the one that will capture the necessary changes.

This patch adds the missing items for unix based systems. This gets suiterunner to a state where it can actually run and work to a similar standard as developer builds. Note that this doesn't include items for DOM Inspector - I haven't got the xpi successfully installing yet, but this at least will get us running on linux.

Comment on attachment 225910 [details] [diff] [review] Add missing items for unix based systems part 1 >-bin/chrome/modern.jar >-bin/chrome/classic.jar These need to stay so that non-toolkit builds continue working.

(In reply to comment #2) > (From update of attachment 225910 [details] [diff] [review] [edit]) > >-bin/chrome/modern.jar > >-bin/chrome/classic.jar > > These need to stay so that non-toolkit builds continue working. > They do - they are just moved up the file a little bit so that all the theme related items are together.

Comment on attachment 225910 [details] [diff] [review] Add missing items for unix based systems part 1 Right! In addition to what you've added, I see (on nye suiterunner): bin/components/FeedProcessor.js bin/components/libmozgnome.so bin/components/libsuiteprofile.so bin/components/mozgnome.xpt bin/components/nsBrowserContentHandler.js bin/components/nsDefaultCLH.js bin/components/nsExtensionManager.js bin/components/pluginGlue.js bin/chrome/app-chrome.manifest You added these (which is good!), but they aren't associtated with MOZ_XUL_APP. We should be packaging them in non-suiterunner builds (trunk and branch) bin/components/xuldoc.xpt bin/components/xultmpl.xpt bin/components/xremoteservice.xpt And you have libsuite.so, which I don't see in components/. I'm guessing that was supposed to be libsuiteprofile.so. :)

(In reply to comment #4) > In addition to what you've added, I see (on nye suiterunner): > bin/components/nsBrowserContentHandler.js > bin/components/nsExtensionManager.js These are already in the file elsewhere > bin/components/nsDefaultCLH.js > bin/components/pluginGlue.js Opps, new I kept on forgetting to add some. Actually, nsDefaultCLH.js probably isn't required, as nsBrowserContentHandler.js should do its job, but we'll include it just in case. > bin/chrome/app-chrome.manifest This is a file ff & tb don't package, so I assume we don't need to either: http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/installer/packager.mk#224 > You added these (which is good!), but they aren't associtated with MOZ_XUL_APP. > We should be packaging them in non-suiterunner builds (trunk and branch) > bin/components/xuldoc.xpt > bin/components/xultmpl.xpt > bin/components/xremoteservice.xpt Ok I'll move them. > > And you have libsuite.so, which I don't see in components/. I'm guessing that > was supposed to be libsuiteprofile.so. :) > Well actually, it will be libsuite.so once the patch on bug 329744 has been implemented... I'll change it to libsuiteprofile.so for now.

Comment on attachment 225910 [details] [diff] [review] Add missing items for unix based systems part 1 > These are already in the file elsewhere So they are. Can you move them into one of the MOZ_XUL_APP blocks? Looking at the firefox package, I notice they also don't package nsDefaultCLH.js (even in the non-installer tarball), although I don't see anything that prevents it. So the patch is OK with stuff moved around (although I'd like to know what's up with nsDefaultCLH.js) I'm also remembering now that the installer runs ./run-mozilla.sh ./regxpcom and ./run-mozilla.sh ./regchrome after installation. The new way to do that is "seamonkey -register", right? suiterunner still has regxpcom, but doesn't even have regchrome. I don't know how to handle that without breaking the XPFE installer. We'd need a different config.ini. The firefox installer fires up the full firefox app after installation (bad!).

I'll check this in (xuldoc.xpt and xultmpl.xpt were actually already there... dunno why we both missed them before)

OK, the linux installer build works ok now, but only if run once by the owner of the files. The chrome/app-chrome.manifest file needs to be generated (in the app directory), which happens when starting the app or when running "seamonkey -register". So we really need a separate config.ini so that it can run seamonkey -register.

(In reply to comment #8) > So we really need a separate config.ini so that it can > run seamonkey -register. > A separate config.it/ini sounds reasonable. We could put it in /suite/installer/unix/. That just leaves the matter of how to switch between the two. I think adding an action to copy the relevant config.it into $objdir/somewhere and then generating it from there into config.ini might be best, though we'll have to change the perl files to accomodate that I think.

This patch fixes the unix based registration process in the installer to use -register. As doing this requires two config.it files for us until we switch, I'm proposing we just insert the new config.it file as a new file rather than a copy. The new config.it file only differs from the old by the post-install run options.

Comment on attachment 227091 [details] [diff] [review] Fix the unix installer registration process (checked in) > # Make sure there are at least six arguments >-if(@ARGV < 6) >+if(@ARGV < 7) seven! > { >- die "usage: $0 <default version> <URL path> <staging path> <dist install path> <app name> <app display name> >+ die "usage: $0 <default version> <URL path> <staging path> <dist install path> <app name> <app display name> <config it location> config.it ^

The config.it location patch broke tinderboxen packaging scripts because the path has a "." and makecfgini.pl assumes the first "." is the one it wants and chops the rest off. Previously, the config.it location was just "config.it". I'll commit this shortly as a bustage fix so we have working installers, but I'm happy to fix it up if my perl-fu is lacking.

(In reply to comment #12) > Created an attachment (id=227350) [edit] > fix tinderbox bustage > > The config.it location patch broke tinderboxen packaging scripts because the > path has a "." and makecfgini.pl assumes the first "." is the one it wants and > chops the rest off. Previously, the config.it location was just "config.it". Weird, I thought I had checked that and came to the conclusion that it was working alright. Oh well.

I guess this is fallout from the help moving, I just noticed we're missing the help.manifest.

This adds most of the missing packages that we need for suiterunner builds to the windows installer. DOMI still won't work, but we'll at least be capable of the same installation level as the unix installer for the time being. I'd really like someone to test this and compare an installed directory structure to a zip one on windows before I request reviews though.

(In reply to comment #15) > I'd really like someone to test this and compare an installed directory > structure to a zip one on windows before I request reviews though. Note: the registration process on windows won't work properly just yet - we need to modify something to call seamonkey -register for that to work (I haven't thought about that patch yet).

(In reply to comment #14) > I guess this is fallout from the help moving, I just noticed we're missing the > help.manifest. Umm, we shouldn't use help.manifest (and help.jar) any more once we've fixed bug 344243 and are using toolkit help viewer instead of our own, so basically, this file is only of temporary existance in suiterunner...

This adds the new components/items for SeaMonkey with MOZ_XUL_APP set to the os2 installer packaging list (and incorporates the os2 fix for bug 349159). I haven't tested these as I don't have os2, but the additions list is the same as per the unix & windows patches on this bug.

Comment on attachment 234427 [details] [diff] [review] Add missing items to os2 installer part 1 v1 (checked in) are there files that went away that ned to be deleted as part of the install.js stuff?

(In reply to comment #19) > (From update of attachment 234427 [details] [diff] [review] [edit]) > are there files that went away that ned to be deleted as part of the install.js > stuff? I'm not sure waht you mean be the "install.js stuff"?

(In reply to comment #20) > (In reply to comment #19) > > (From update of attachment 234427 [details] [diff] [review] [edit] [edit]) > > are there files that went away that ned to be deleted as part of the install.js > > stuff? > > I'm not sure waht you mean be the "install.js stuff"? > http://lxr.mozilla.org/seamonkey/source/xpinstall/packager/windows/browser.jst#375

(In reply to comment #21) > (In reply to comment #20) > > (In reply to comment #19) > > > (From update of attachment 234427 [details] [diff] [review] [edit] [edit] [edit]) > > > are there files that went away that ned to be deleted as part of the install.js > > > stuff? > > > > I'm not sure waht you mean be the "install.js stuff"? > > > > http://lxr.mozilla.org/seamonkey/source/xpinstall/packager/windows/browser.jst#375 > Thanks, there will be some redundant packages, but until we throw the switch on trunk formally, I don't want to add them into the removal lists as that'll break the current trunk xpfe builds - so I've filed bug 349295 to remind us once we've switched that we need to check the lists.

I'm putting this over to helpwanted - its just the installation of DOMI that needs sorting out. I haven't figured out how to do this, as I'm concentrating on other areas. http://wiki.mozilla.org/ChatZilla:Suiterunner may be of interest also.

The xpinstall-based installers are probably being killed from trunk completely very soon now, and for Windows we have the NSIS installer anyways, see bug 351917

Comment on attachment 227350 [details] [diff] [review] fix tinderbox bustage This never got committed afaict. However, given that all our installers are running fine and we've shipped SM 2. I don't think this is necessary any longer - if it is, then we should move it to a separate bug.