Closed Bug 180374 Opened 18 years ago Closed 18 years ago

switch from ftp to http in config.ini

Categories

(SeaMonkey :: Installer, defect)

x86
Mac System 9.x
defect
Not set
critical

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.3alpha

People

(Reporter: sspitzer, Assigned: jj.enser)

Details

Attachments

(1 file)

mac stub installer (11-15-2002) fails

if you are behind the firewall, see
http://bugscape.nscp.aoltw.net/show_bug.cgi?id=21411

note, the full installer works.
Target Milestone: --- → mozilla1.3alpha
Severity: normal → blocker
actually, bugscape bug 21411 is different (chrome issue, not installer related).

the problem here is that the install wizard starts downloading the selected
components but "pauses" many times. Clicking the "resume" several times
eventually causes the fatal error messages "Installation failed due to error -805".

All this happens apparently while downloading xpcom.xpi

A full installer (with a local xpcom.xpi) works fine.
Status: NEW → ASSIGNED
Internal netscape installer works fine, only difference is going to be the xpis
or the ftp server (we don't use ftp.mozilla.org for netscape nightlies). Are the
ftp server logs showing any problems? pause/Resume like behaviour like this
makes me think there might be a problem.
I'm actually replacing xpcom.xpi on ftp just to check if the installer I already
have on my machine works better afterwards
It's not that, we are still trying to just download XPIs.

-805 translates to "FTP command error" (we don't display error text for fear it
will confuse people :-)
Dawn, Asa, Syd says error -805 we're seeing mean a possible network/ftp problem
on ftp.moz.org.
replacing xpcom.xpi on f.m.o didn't help.
darin, any ideas? did anything change in networking recently that would make ftp
fail? maybe in nspr? did the nspr tag change recently?
necko is not used by the stub installer.  it uses its own specific FTP
implementation.
Seth, can you try again your mac installer (no need to re-download it, just
re-run it)
today's mozilla stub installer works for me now.

After replacing xpcom.xpi in the mac-xpi dir on ftp.mozilla.org, the problem
seemed to go away. download and installation now complete. But Syd says error
-805 cannot happen due to a corrupted file but is due to a network/server problem...

Reassigning to asa.

note that I left the xpcom.xpi file that was originally uploaded and was
exposing (if not causing) the problem:
ftp://ftp.mozilla.org/pub/mozilla/nightly/2002-11-15-09-trunk/mac-xpi/xpcom-corrupt.xpi
Assignee: jj → asa
Status: ASSIGNED → NEW
Yup JJ, you are right. using teh same stub build, it NOW works.
No error, no  pausing..

Weird.
at syd's request i put the original xpcom.xpi back in place.
we now have:


ftp://ftp.mozilla.org/pub/mozilla/nightly/2002-11-15-09-trunk/mac-xpi/xpcom.xpi
copy of xpcom-corrupt.xpi

ftp://ftp.mozilla.org/pub/mozilla/nightly/2002-11-15-09-trunk/mac-xpi/xpcom-corrupt.xpi
file from original morning build

ftp://ftp.mozilla.org/pub/mozilla/nightly/2002-11-15-09-trunk/mac-xpi/xpcom.xpi.good
test file that jj uploaded at 16:52
again, i don't think the XPI is the issue. in fact, I was able to fail in the
same way in browser.xpi. what does seem clear is that the http protocol behaves
much better for some reason. 
Now that we're pretty sure it's some kind of network or server problem, I'm
downgrading this bug to critical so that it doesn't keep the tree closed.

Should require more investigation on the server side as to what causes these
glitches.
if we conclude that http is the preferred protocol for nightlies (it is already
for public releases) then I'll submit the appropriate patch here.
Severity: blocker → critical
We should just use HTTP.
QA Contact: bugzilla → ktrina
if we use http in official builds, let's switch to that for nightly.

syd, ssu, dveditz, any reason not to switch from ftp to http?

re-assign to jj
Assignee: asa → jj
Summary: mac stub installer (11-15-2002) fails → switch from ftp to http in config.ini
These sound exactly like the symptoms that caused us to switch releases from FTP
to HTTP, I don't know why we wouldn't have switched nightlies at the same time
as releases since they use the same servers.
There must have been a reason why we kept using ftp for nithglies, and add the
extra step to switch to http for public releases ... but I don't know what it is.
cc'ing more installer people, who might actually remember :-)

After verification, it seems lile both Windows and Linux use http in nightly
builds. Patch coming up to use http in mac builds as well.
Status: NEW → ASSIGNED
I know of no reason not to use http: for the mozilla stub installers.  We should
make sure to change all platforms, not just mac.
I already checked Windows and Linux automations and they already use http.

r/sr anyone?
Comment on attachment 106705 [details] [diff] [review]
patch for mac nightly builds (switch to http protocol for xpi download)

sr=dveditz
Attachment #106705 - Flags: superreview+
Comment on attachment 106705 [details] [diff] [review]
patch for mac nightly builds (switch to http protocol for xpi download)

r=syd
Attachment #106705 - Flags: review+
fixed. patch checked in on the trunk.
I think this is safe enough to go on the 1.2 branch. Asa, can I just update the
target milestone and add the mozilla1.2 keyword for it to show on the 1.2 radar?
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Keywords: mozilla1.2
Resolution: --- → FIXED
Comment on attachment 106705 [details] [diff] [review]
patch for mac nightly builds (switch to http protocol for xpi download)

jj wants this for 1.2 branch.
Attachment #106705 - Flags: approval?
Comment on attachment 106705 [details] [diff] [review]
patch for mac nightly builds (switch to http protocol for xpi download)

a=asa for checkin to 1.2 branch
Attachment #106705 - Flags: approval? → approval+
checked in on the 1.2 branch
Verified
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.