The Stub installer (see above link) fails after it asks for proxy settings. Looks like it can't pull the xpi files.

added smoketest,blocker keywords Also occurs on the 25-08 build. The workaround is to use the full installer.

How does it fail? Does it throw an error message of any kind?

There are no error messages. The installer window just freezes. alt-open apple-esc to force quit out.

This appears to be because xpcom.xpi is missing: Protocol log shows Receive data (87 bytes). >0000013C> 550 /pub/netscape6/english/6.1/mac/macos8.5/xpi/xpcom.xpi: >00000177> No such file OR directory. WTF doesn't the installer handle a missing file? I would have thought that was a pretty essential error response to handle. And to have the installer just become unresponsive, and require killing. Well....

I've found a workaround via the config.ini file. I'm looking as to the cause of the problem.

Simon, Because of URL failovers. So it is handling it implicitly. It shouldn't hang though.

So, force-quitting the installer after that crashed my machine. Bug 87676 filed.

Samir is all over it. reassigning to him.

Works for me with debug but not a release build.

The regression was caused by changes that went into libxpnet last week. My local opt build worked fine without those changes. Once I updated libxpnet, rebuilt it, relinked it with the installer the Mac failovers stopped working.

When the file is not found (the retrieve command returns an E_CMD_FAIL) then we tryt to close() the data socket. Previously we used to shutdown() the data socket. This close() (of a valid socket descriptor) causes a hang. I will attach a patch to tide us over and get the tree open. Then we can reduce this from smoketest blocker to nsbeta1+.

Syd, Sean, Moving from shutdown() -> close() caused this regression. Any advice/help would be appreciated in combatting this regression. Syd, is this something you wouldn't mind look at for the real fix? Thanks.

Regarding patch id=39961: ssu, please r. sfraser or syd, please sr. jj, please give a. Thanks.

Will checkin to ns tree on both 092 branch and trunk.

sr=sfraser I think you should use bug 87676 for the real fix.

Have r=ssu

Fix checked in. Will continue tracking the close() problem in bug 87676.

Errr, marking FIXED even.

Catching up with this since I was not in the office yesterday. I would just like to mention that I disabled the automation code that generates an alternate Netscape installer stub (pointing to ftp.netscape.com instead of our internal ftp server) since the failover URL feature got implemented. Now that it's been disabled, I need to know if this feature will be back by RTM or if I need to resurrect the "aternate stub" code in the release automation. This will also affect the final push process which needs to know which stub to grab. Until failover URL is back, shouldn't bug 84122 be reopened? btw, I see r= and sr= marks, but no a= :-/

No, we shouldn't reopen bug 84122 cause the work was in the mac installer codebase and it's done. We need to address the real problem in bug 87676. And I sought an a= but was informed that since it was a smoketest blocker my temp fix was automatically deemed a=smoketest blocker.

verified on mac branch build 2001062603 adding vtrunk

samir - so does jj need to re-enable the external stub installer for 6.1 RTM or are we going to fix failover URLs on the mac by then?

Jon, That question should be directed to Syd. I will be going on sabbatical soon and have committed to other tasks up until the time I leave. Syd, Are we planning to fix the regression created by shutdown() -> close() on the mac? I think bug 87676 was dealing with that issue.

reopening -- have a patch that addresses the real issues

What's this: +#if defined(macintosh) && 0 ??

The workaround in place "works". Syd's patch is to fix the real bug so we can disable the workaround. Removing smoketest because this is currently not an issue. Also reassigning to Syd.

The #ifdefine macintosh && 0 will be removed -- the point is we are not calling shutdown, but instead close.

r=ssu for syd's patch, but his patch also needs my patch so it doesn't break windows.

r=dveditz for patches in attachments 42169 and 42231

Ok, final step is to take my stuff, and seans windows patch, and make sure Linux is ok. At that point, I'll go for a sr=

per email to PDT, marking this PDT+

Syd, we discussed getting a version of this without the CRC dependencies onto the branch. This PDT+ is for the minimal branch fix that makes failover work again. Thanks!

the failover url is currently commented out in the default mac config.ini it needs to be re-enabled too. hence patch http://bugzilla.mozilla.org/showattachment.cgi?attach_id=42254

works ok on Linux.

Ok, the ftp part of the patch: Index: wizard/libxpnet/src/nsFTPConn.cpp =================================================================== RCS file: /cvsroot/mozilla/xpinstall/wizard/libxpnet/src/nsFTPConn.cpp,v retrieving revision 1.10 diff -r1.10 nsFTPConn.cpp 202c202 < fileSize = atoi(&resp[4]); --- > fileSize = atoi(&resp[4]); // else ??? 266a267,272 > if ( err != OK && err != E_USER_CANCEL ) { > sprintf(cmd, "QUIT\r\n"); > IssueCmd(cmd, resp, kRespBufSize, mCntlSock); > FlushCntlSock(mCntlSock); > } > combined with Sean's patch for windows is all we need for this to work on the branch. I really need an sr= so we can get a little bake time on this stuff.

Syd assures me that since I can sr= for the Netscape internal tree, then I can do so for the Netscape branch. So sr=dveditz for ssu's patch, jj's patch, and the latest version from syd. This is not an sr= for the trunk, this is branch-only

changes landed on mozilla branch

Okay, now that I have a subset of this on the branch, we still need to fix the trunk. The last 3 patches about are the ones that have an r= and need to go into the trunk.

if syd would post -uw diffs of his patch, then I'll happily review this =). The last 2 patches look fine.

syd, I didn't understand this part: + // myConn->type = TYPE_UNDEF; + // free( myConn->URL ); + // myConn->URL = (char *) NULL; why add new lines of commented out code? Can we just leave that out?

sure, will remove them

sr=mscott then

Closing this down. Patches on this bug have been applied. Bug 87793 is the "error 13" bug and has a patch on it.

verified on Mac build 20010814