switch from ftp to http in config.ini

VERIFIED FIXED in mozilla1.3alpha


17 years ago
8 years ago


(Reporter: sspitzer, Assigned: jj.enser)


Mac System 9.x

Firefox Tracking Flags

(Not tracked)



(1 attachment)

mac stub installer (11-15-2002) fails

if you are behind the firewall, see

note, the full installer works.


17 years ago
Target Milestone: --- → mozilla1.3alpha


17 years ago
Severity: normal → blocker

Comment 1

17 years ago
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.

Comment 2

17 years ago
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.

Comment 3

17 years ago
I'm actually replacing xpcom.xpi on ftp just to check if the installer I already
have on my machine works better afterwards

Comment 4

17 years ago
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 :-)

Comment 5

17 years ago
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.

Comment 6

17 years ago
darin, any ideas? did anything change in networking recently that would make ftp
fail? maybe in nspr? did the nspr tag change recently?

Comment 7

17 years ago
necko is not used by the stub installer.  it uses its own specific FTP

Comment 8

17 years ago
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:
Assignee: jj → asa

Comment 9

17 years ago
Yup JJ, you are right. using teh same stub build, it NOW works.
No error, no  pausing..


Comment 10

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

copy of xpcom-corrupt.xpi

file from original morning build

test file that jj uploaded at 16:52

Comment 11

17 years ago
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. 

Comment 12

17 years ago
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
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.


17 years ago
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.

Comment 16

17 years ago
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.

Comment 18

17 years ago
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.

Comment 19

17 years ago
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)

Attachment #106705 - Flags: superreview+

Comment 21

17 years ago
Comment on attachment 106705 [details] [diff] [review]
patch for mac nightly builds (switch to http protocol for xpi download)

Attachment #106705 - Flags: review+

Comment 22

17 years ago
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?
Last Resolved: 17 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+

Comment 25

17 years ago
checked in on the 1.2 branch

Comment 26

17 years ago
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.