The final verification is green. Taking an example of http://download.mozilla.org/?product=seamonkey-2.49.1-partial-2.48&os=linux&lang=cs&force=1 Testing http://download.mozilla.org/?product=seamonkey-2.49.1-partial-2.48&os=linux&lang=cs&force=1 HTTP/1.1 302 Found Cache-Control: max-age=60 Content-Length: 139 Content-Type: text/html; charset=utf-8 Date: Sun, 05 Nov 2017 03:36:06 GMT Location: http://download.cdn.mozilla.net/pub/seamonkey/releases/2.49.1/update/linux-i686/cs/seamonkey-2.48-2.49.1.partial.mar Connection: keep-alive However, manually going to http://download.mozilla.org/?product=seamonkey-2.49.1-partial-2.48&os=linux&lang=cs&force=1 gives me a 404 error.

:Callek, I am confused as to what's going on. How can the same url give me two different responses? What am I missing?

oremj, any idea what's going on here ? The uptake [1] looks like this: Product OS Available Total seamonkey-2.49.1-complete win 1000100 2000100 seamonkey-2.49.1-complete osx 1000000 2000100 seamonkey-2.49.1-partial-2.48 win 1000100 2000100 The absence of linux for the complete, mac and linux for the partial, and all three for seamonkey-2.49.1 is unexpected. They were originally setup (by hand) in bug 1385794. I've checked the locations and they seem to be fine. Also cleaned out the list of products with Check now bit set (was 480+, now back to 110), to give sentry a lot less to do. It's been 10-20 minutes since I finished that an no improvement in the uptake. Would be good to know if the en-US checking Sentry is in staging or production too. [1] https://bounceradmin.mozilla.com/stats/uptake/?p=7905&p=7906&p=7907

Stage only at the moment.

OK. Probably what's happening is the CDNs have cached some of the fake files for the tr locale, which ewong had added for sentry and since removed. Right now the only live product+os combo is seamonkey-2.49.1-complete for mac, which could fit with that caching expiring. Certainly still possible something else is wrong, since I don't understand why it was originally fine in final verification but then the products ended up disabled. I suggest re-adding the fake tr keys, and waiting 10-15 minutes before rechecking the download.m.o urls. For reference the locations are: /pub/seamonkey/releases/2.49.1/mac/tr/pub/seamonkey 2.49.1.dmg /pub/seamonkey/releases/2.49.1/linux-i686/tr/pub/seamonkey-2.49.1.tar.bz2 /pub/seamonkey/releases/2.49.1/win32/tr/pub/seamonkey Setup 2.49.1.exe /pub/seamonkey/releases/2.49.1/update/mac/tr/pub/seamonkey-2.49.1.complete.mar /pub/seamonkey/releases/2.49.1/update/linux-i686/tr/pub/seamonkey-2.49.1.complete.mar /pub/seamonkey/releases/2.49.1/update/win32/tr/pub/seamonkey-2.49.1.complete.mar /pub/seamonkey/releases/2.49.1/update/mac/tr/pub/seamonkey-2.48-2.49.1.partial.mar /pub/seamonkey/releases/2.49.1/update/linux-i686/tr/pub/seamonkey-2.48-2.49.1.partial.mar /pub/seamonkey/releases/2.49.1/update/win32/tr/pub/seamonkey-2.48-2.49.1.partial.mar (copied and pasted from bouncer; replaced :lang with tr, and %20 with a space; prepended pub/). If that doesn't help we could ask oremj to purge the CDNs for /pub/seamonkey/releases/2.49.1/. Next stop after that is the Sentry logs.

(In reply to Nick Thomas [:nthomas] (UTC+13) from comment #4) > OK. Probably what's happening is the CDNs have cached some of the fake files > for the tr locale, which ewong had added for sentry and since removed. Right > now the only live product+os combo is seamonkey-2.49.1-complete for mac, > which could fit with that caching expiring. Certainly still possible > something else is wrong, since I don't understand why it was originally fine > in final verification but then the products ended up disabled. > > I suggest re-adding the fake tr keys, and waiting 10-15 minutes before > rechecking the download.m.o urls. For reference the locations are: > /pub/seamonkey/releases/2.49.1/mac/tr/pub/seamonkey 2.49.1.dmg > /pub/seamonkey/releases/2.49.1/linux-i686/tr/pub/seamonkey-2.49.1.tar.bz2 > /pub/seamonkey/releases/2.49.1/win32/tr/pub/seamonkey Setup 2.49.1.exe > /pub/seamonkey/releases/2.49.1/update/mac/tr/pub/seamonkey-2.49.1.complete. > mar > /pub/seamonkey/releases/2.49.1/update/linux-i686/tr/pub/seamonkey-2.49.1. > complete.mar > /pub/seamonkey/releases/2.49.1/update/win32/tr/pub/seamonkey-2.49.1.complete. > mar > /pub/seamonkey/releases/2.49.1/update/mac/tr/pub/seamonkey-2.48-2.49.1. > partial.mar > /pub/seamonkey/releases/2.49.1/update/linux-i686/tr/pub/seamonkey-2.48-2.49. > 1.partial.mar > /pub/seamonkey/releases/2.49.1/update/win32/tr/pub/seamonkey-2.48-2.49.1. > partial.mar > (copied and pasted from bouncer; replaced :lang with tr, and %20 with a > space; prepended pub/). I'm kinda confused why there's a "pub" there.. I don't recall adding that. Or is this something internal and not visible from the archive.mo page?

I added the empty tr/ files, waited ~ 1/2hr or more, ran final verification.. went green. While http://download.mozilla.org/?product=seamonkey-2.49.1-partial-2.48&os=linux&lang=cs&force=1 works.. https://download.mozilla.org/?product=seamonkey-2.49.1&os=win&lang=ja still gives me 404.

Yay, updates are working. I put the pub in because you'd need that when creating the keys (it's true they're not in the bouncer locations, but are part of the mirror definition there; the final redirect is mirror + location). The installer links need tr dirs too. Do watch out for the spaces in mac and windows paths, will need quoting if you're using a command line tool.

(In reply to Edmund Wong (:ewong) from comment #6) > https://download.mozilla.org/?product=seamonkey-2.49.1&os=win&lang=ja still gives me 404. That works for me (and so does the de variant I link to from the German-language site) but the Linux and Mac ones don't work (yet), at least for me: https://download.mozilla.org/?product=seamonkey-2.49.1&os=linux&lang=de https://download.mozilla.org/?product=seamonkey-2.49.1&os=osx&lang=de

This is fixed.