From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6+) Gecko/20011127 BuildID: 2001120206 Third day in a row now. I get the 11-megabyte tarball and untar. Run mozilla-installer (which used to just install) now insists on re-downloading all the components a second time and then proceeds to segfault at line 55: 2656. This should be a no-brainer, guys! Three days ago somebody screwed up the way the tarball is put together--please fix it! Reproducible: Always Steps to Reproduce: 1.Untar the linux-sea edition. 2.Run ./mozilla-installer. 3.Watch it crash after re-fetching all the components needlessly.
I see this too. This is only a problem if I select full install. Doing a typical install does not download anything. The crash problem is 112831. This bug is still a serious issue, separate from bug 112831. We should not be downloading for a SEA installer.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Okay, here's the solution: if I delete the line "C10=Component10" from the file config.ini the installer works like it used to, and doesn't crash. I should mention that I've been doing "Complete" installs all along. It appears that Component10 was added to config.ini about 3-4 days ago but the corresponding file 'inspector.xpi' was *not* included in the tarball.
As stated in bug 112831, it only tries to download .xpis if you select the inspector. inspector.xpi is not in the tarball. So of course it goes looking for it via FTP or whatever. Make inspector.xpi build and include it in the tarball, and I'm pretty sure a full install will work as it always has. IMHO this is a dupe of bug 112831.
16 years ago
Depends on: 112831
I agree with comment #3 except to add that it seems silly for the installer to download the *entire* set of xpi files just because one is missing. As to the crash problem, yes it probably is a duplication of the earlier report. Oh, I went looking for inspector.xpi in the xpi directories on the ftp serveer and I don't find it there. Was it removed--or never there?
About .xpi on FTP areas: read comment 5 of bug 112831. And, the installer should probably just try to download the .xpi it's missing. Should probably change the summary then, to something like "Installer should only try to download _missing_ .xpis" ?
Looks like nsXIEngine::ExistAllXPIs() should do currComp->SetDownloaded(TRUE) for each file that *does* exist, instead of just looking to see if any files *don't* exist and then downloading them all. Anyone want to try out my patch and see if it fixes things? I don't have a Linux system I can build on at the moment but I think it'll do the trick.
Summary: mozilla-i686-pc-linux-gnu-sea.tar.gz using wrong installer!! → Linux installer should only download missing archives
Comment on attachment 60213 [details] [diff] [review] remember files we've found in the blob r=sgehani
Attachment #60213 - Flags: review+
Taking this one.
Assignee: syd → dveditz
Comment on attachment 60213 [details] [diff] [review] remember files we've found in the blob sr=darin, but what if one of the downloaded files is corrupt? iirc, this is handled when we start to install the files... that we'll try to redownload corrupt files or something like that.
The CRC check appears to be done after we download the xpis: <http://lxr.mozilla.org/seamonkey/source/xpinstall/wizard/unix/src2/nsXIEngine.cpp#343>
Fix checked in
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Verified code fix
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.