Steps to reproduce: 1. download installer -for build 2000091506M18 2. Install complete setup type Actual results: error message saying -621 .xpi file did not install (did not mention which one, installer was in psm module N6 did not launch Expected results: all xpi files installed, launch *Note Mozilla installer complete without error message but also did not launch, will attach install logs

fyi, If I download the netscape-i686-pc-linux-gnu.tar.gz file, I can successfull run the commercial build. This bug is hold up verification of bug 52716.

error message in console when trying to launch typical install *** QfaServices is being registered *** Deferring registration of sample JS components ************************************************************ * Call to xpconnect wrapped JSObject produced this error: * [Exception... "Factory not registered (may be tried again) [nsIModule::registerSelf]" nsresult: "0x80040155 (NS_ERROR_FACTORY_REGISTER_AGAIN)" location: "<unknown>" data: no] ************************************************************ -*- filepicker: registering (all right -- a JavaScript module!) *** Registering sample JS components ProfileManager : CreateNewProfile Profile Name: default Profile Dir: /u/gbush/.mozilla I am inside the initialize Hey : You are in QFA Startup (QFA)Talkback loaded Ok.

PSM installed fine. Looking at the install.log this is chrome registration of JARs. CC'ing dprice since he enabled it on unix. CC'ing dveditz since he is the original author of and is familiar with the chrome registration code. Nominating for nsbeta3. dprice, Did you successfully test chrome registration of JARs through XPInstall on Unix before landing your changes?

*** Bug 52793 has been marked as a duplicate of this bug. ***

PDT, management, This makes an installed build completely unusable since the chrome isn't registered.

This is happening because the jars don't exist in the zippies. For example: {orb} /u/sgehani/zzz > unzip -l browser.xpi | grep -n core.jar {orb} /u/sgehani/zzz > Blank!

Changing component to "Build Config" since this is an issue with the packaging process. Doing a fresh build and running the packaging scripts now.

Ack! The whole chrome directory is missing! Unzipping browser.xpi resulted in: drwxr-xr-x 2 sgehani wheel 4096 Sep 15 09:47 components/ drwxr-xr-x 4 sgehani wheel 4096 Sep 15 09:47 defaults/ drwxr-xr-x 2 sgehani wheel 4096 Sep 15 09:47 icons/ -rwxrwxr-x 1 sgehani wheel 39780 Sep 15 09:47 libcmt.so* -rwxrwxr-x 1 sgehani wheel 175604 Sep 15 09:47 libgkgfx.so* -rwxrwxr-x 1 sgehani wheel 13788 Sep 15 09:47 libgtksuperwin.so* -rwxrwxr-x 1 sgehani wheel 11152 Sep 15 09:47 libgtkxtbin.so* -rwxrwxr-x 1 sgehani wheel 67320 Sep 15 09:47 libjpeg.so* -rwxrwxr-x 1 sgehani wheel 92136 Sep 15 09:47 libjsj.so* -rwxrwxr-x 1 sgehani wheel 275224 Sep 15 09:47 libmsgbaseutil.so* -rwxrwxr-x 1 sgehani wheel 17168 Sep 15 09:47 libprotocol.so* -rwxrwxr-x 1 sgehani wheel 56968 Sep 15 09:47 mozilla-bin* -rwxrwxr-x 1 sgehani wheel 1656 Sep 15 09:47 netscape* -rw-rw-r-- 1 sgehani wheel 52 Sep 15 09:47 netscape.cfg -rwxrwxr-x 1 sgehani wheel 18580 Sep 15 09:47 regExport* -rwxrwxr-x 1 sgehani wheel 7360 Sep 15 09:47 regxpcom* drwxr-xr-x 6 sgehani wheel 4096 Sep 15 09:47 res/ -rwxrwxr-x 1 sgehani wheel 7085 Sep 15 09:47 run-mozilla.sh* -rw-rw-r-- 1 sgehani wheel 208792 Sep 15 09:47 splash.xpm -rw-rw-r-- 1 sgehani wheel 33661 Sep 15 09:47 systemSignature.jar

Taking the liberty to mark dogfood+ as per Samir's comments about usability of the chrome.

OK, we know the problem: JAR packaging is off by default. So the release machines are not building jars yet dprice's changes expect jars to be present to install. We need to do the following: 1> Make sure the unix build works with jars. 2> Turn jar packaging on by default (or at least convince release to do so on their machines for now). Changing summary to reflect real problem. Reassiginging to dprice. Not much I can do. Also, cc'ing cls who is ever so clueful about what's going on. Changing severity: this'll block QA from testing installed builds (which have notoriously been known to exhibit different behavior than tarball builds).

The other option is to back out dprice's xpinstall changes that expect chrome in jars (package lists and install scripts, mozilla and commercial). Which is easier I'll leave up to him.

this should have been a smoketest blocker and we shd keep the tree closed for it. Vishy

gag - this shd have been a smoketest blocker - we shdnt reopen the mozilla tree when essentially the build doesnt start on one platform. also whoever fixes this up, please test commercial as well (i.e. installers and installed build). I'd be glad to try and help. thanks, Vishy

This bug blocks me in AIM QA from verifying and logging bugs as Aim won't register the same way in the chrome without running installer. I can't "trust" what I see if running the uncompressed bits instead of installer because of this. Setting smoketest for this reason. We are so close to release we really ought to be setting these as smoketest blockers at this juncture (IMHO). Customers won't be unstuffing bits, they will be running the installer.

*** Bug 52823 has been marked as a duplicate of this bug. ***

yesterday I checked in some changes. I enabled jar packaging for linux and modified the installer to pick up the new jar files. After talking with warren, I disabled the jar packaging in preparation for his landing of major chrome/jar changes last night. Something delayed his landing and the changes to the installer never took place. I'm trying to get a hold of him to see which solution is better.

backed out my changes, samir is testing. marking as fixed.

verfierd installer successful on linux build 2000-09-18-06-M18

Verified on same build on my system