User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031016 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031016 mozilla-win32-installer.exe is trying to download data from a subdirectory of ftp://ftp.mozilla.org/pub/mozilla/nightly/ This directory is moved into ftp://ftp.mozilla.org/pub/mozilla/mozilla/nightly/ and hence the installer can't locate it. This problem has existed for a week or so now - at least. Reproducible: Always Steps to Reproduce: 1. Download the installer from ftp://ftp.mozilla.org/pub/mozilla/mozilla/nightly/latest/mozilla-win32-installer.exe 2. Run the installer. Actual Results: Installer will give up trying to download after a period of time, suggesting that the server is down and the user should try again later. Expected Results: Locate the files to download, download them and install the new version.

This is a browser issue. Yes, the paths did change. The browser needs to be fixed to find the correct paths. The correct path is ftp://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/

This is a blocker bug. We should not distribute any "stub installers" which have the wrong FTP path embedded in them. This applies to both the win32 stub installer and the unix/gtk stub installer. This is not caused by the mozilla source code. This is a function of the build scripts which call build.pl (in the win32 case) or deliver.pl (in the gtk case). These scripts supply an "archive URL" to the perl scrips which changes based on the nightly/release status of the build.

And that has what to do with Server Operations? Isn't this a problem with the process building the stub installers?

I was assuming mozilla.org servers included the machines that make nightly builds... this is a misconfiguration problem on those machines. Maybe it belongs in Mozilla.org->miscellaneous, but it's not a bug in the mozilla source code/installer, the problem is specific to stub installers build by the mozilla.org machines.

Ah, that could very well be. :) I don't know where they are or who takes care of them, but I bet Leaf does, and he's on this bug already. :)

Accepting. Unfortunately, for the moment, the release builds are produced on machines i can't access directly. I am migrating the release build process to tinderboxen, and this should be fixed then. I had *thought* the stub installers were using http links to ftp.mozilla.org, and that there was a redirect from the website for the old urls. If this is broken, i obviously have that much more incentive to get the builds migrated. Targetting for the end of this week at the latest.

there *are* redirects in place so the old URLs should still work via HTTP. So if the installer is using HTTP links, then the next question is: does the installer know how to follow redirects?

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

changing the summary to reflect that this affects all of the stub installers.

The limited networking code in the stub probably doesn't understand redirects

I've been using the Win32 stub installer for the past 3-4 days now without any problem. This seems to be resolved in the Win32 installer, anyway.

This bug is fixed in some way, but in some way not: The path is now correct (http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/), but stub installers from latest for example try to download files from http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/2003-11-24-09-trunk/windows-xpi But this folder doesnt exist, probably(?) it will be created tomorrow, any comments to this leaf?

I'm not sure what happened with the automation this weekend, but the previous week's builds all pointed to correct directories. I'll try and figure out what's gone wrong, but this effort will be impeded by my lack of access to those machines this week while i travel.

The staging server actually looks correct. It's possible that mirroring is failing for one or more of the mirrors. I will investigate further.

Ok, i've confirmed that this is a problem with the georgia tech mirror; the oregon state mirror is working correctly. This problem should be solved for people with stub installers by re-running (until they get a functioning mirror from the dns round robin) until the georgia tech mirror is updated. Leave assigned until the mirror is fixed.

Reassigning to Scott.

Am forwarding this to the Georgia Tech maintainer and will update when he gets back to me.

Upon further looking, it appears that the Georgia Tech mirror is correct now (unless I'm reading this bug wrong). This could be related to the fact that the GATech mirror was not updating correctly back in late November.