Closed Bug 608605 Opened 15 years ago Closed 14 years ago

No updates for mozilla-central Win64 nightlies

Categories

(Release Engineering :: General, defect)

Product:
Release Engineering
Component:
General
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: feagorn, Unassigned)

References

Details

User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0b8pre) Gecko/20101028 Firefox/4.0b8pre Build Identifier: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0b8pre) Gecko/20101028 Firefox/4.0b8pre Minefield does not get any new updates since it had been installed. Reproducible: Always Steps to Reproduce: 1. Open "About" dialog box. 2. It starts looking for updates. 3. Says "Minefield is up to date", but it cannot be truth, since new Minefield versions are there on Mozilla FTP server. Actual Results: Does not find updates. Expected Results: Find updates and install it.
Yep, seeing this too for de-DE: AUS:SVC Checker:getUpdateURL - update URL: https://aus3.mozilla.org/update/3/Firefox/4.0b8pre/20101028042244/WINNT_x86-msvc/de/nightly/Windows_NT%205.1/default/default/update.xml?force=1 ---------- AUS:SVC Checker:checkForUpdates - sending request to: https://aus3.mozilla.org/update/3/Firefox/4.0b8pre/20101028042244/WINNT_x86-msvc/de/nightly/Windows_NT%205.1/default/default/update.xml?force=1 ---------- AUS:SVC Checker:onLoad - request completed downloading document ---------- AUS:SVC Checker:onLoad - number of updates available: 0 http://tinderbox.mozilla.org/showbuilds.cgi?tree=Mozilla-l10n-de tells it's burning :( Wojciech, what's your Locale?
Status: UNCONFIRMED → NEW
Component: General → Release Engineering
Ever confirmed: true
Product: Firefox → mozilla.org
QA Contact: general → release
Summary: No updates are reported in the About dialog → No updates on MC available since 20101028
Version: unspecified → other
My system is quite a mixup. It's 64 bit English Windows 7 with German timezone, and Polish keyboard settings. But if you ask about Minefield locale, then it is just plain simple EN-US.
Wojciech, you're running the 64bit windows build ? Could you go into about:config and change the boolean prefs app.update.log to true, then Tools > Error Console, and check for updates. I'd like to see the https://aus3... link like in comment #1. XtC4UaLL, you're hitting a combination of a broken build slave (bug 608631) and bug 517947 again. Should come right tomorrow.
Since the Help -> Check for Updates... menu item has gone (bug596929 & bug596813), I could update to the latest nightly simply by going to Help -> About Minefield and then clicking on the 'Check for Updates' button. It's been a few days now that although new nightlies are available, I get no update. BTW: while at it... the new 'Check for Updates' button's function was to start downloading if an update was available without any prompt. So, I'm wondering if the 'Ask me what I want to do' option in the Advanced -> Update tab in fx settings has any meaning at all now(?). Anyone know of a bug already filed for that?
...forgot to say that I am on Greek Win7 64bit and I am using latest en-US 64bit build of fx. Timezone is Greek and keyboard standard US.
The updates for Win64 nightlies are currently broken. The nightlies are from a box set up to test the compile environment, and Win64 is not yet a supported platform. --> WONTFIX
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
Summary: No updates on MC available since 20101028 → No updates for mozilla-central Win64 nightlies
We are all aware that x64 is not supported yet, we're just trying to help with QA and eventually make it a supported platform. Are you saying that there is no way to fix it or that there is no intention to? I mean, we already spotted the time-frame that it started to break and it's only a few days back. If we don't at least spot what was the change that broke an already working feature now, then it will be harder once more changes are committed. Unless you are trying to say that this was a change done intentionally.
(In reply to comment #8) > We are all aware that x64 is not supported yet, we're just trying to help with > QA and eventually make it a supported platform. Are you saying that there is no > way to fix it or that there is no intention to? From our perspective, supported means that we have committed to keeping the machines up in a timely manner -- and we're not there yet. Until 64-bit Windows is a platform that we're actively developing for, and planning to release on, keeping the machines up is very low priority.
Fair enough Ben, but I am sure that you'll agree with me on the fact that postponing an issue that was reported by a certain number of users is a whole different thing than simply 'wontfixing' it. The first case shows that you respect people using those nightly builds and that you appreciate their effort in testing and providing QA in the long run. It tells them that there simply is not enough time/resources available or that development focus is someplace else right now, but you will eventually fix things or at least try to. Most of us have learned to wait. The second case, feels like slap in their face and punishment for using those builds. IOW I am not disappointed in the issue not being fixed or the platform not being supported. I am simply a bit upset by the reply. Get my drift? I am voluntarily helping fx improve and keep up with competition, so manually upgrading every 10 days or so doesn't seem much of a trouble. I won't argue on this any more since there's no point. This is entirely of-topic since it does not help the issue get solved anyways.
WONTFIX wasn't intended as a 'slap in the face', but I can see how it might feel like that. The situation is that we have an unsupported platform, which was set up in a non-production system, and the guy who worked on it is away at the start of the week, then busy for the rest of it as on-call for the whole slave infrastructure. And you can still download the 64bit builds manually, so you can still test them. I thought it would be a lot clearer to say that we weren't going to fix this than let it hang around. If the guy has time he'll reopen.
(In reply to comment #3) > Wojciech, you're running the 64bit windows build ? Could you go into > about:config and change the boolean prefs app.update.log to true, then Tools > > Error Console, and check for updates. I'd like to see the https://aus3... link > like in comment #1. > > XtC4UaLL, you're hitting a combination of a broken build slave (bug 608631) and > bug 517947 again. Should come right tomorrow. Well, i know, i am answering a bit late (i was not around for the last few days), but still... i did what you asked for, and there are the links: AUS:SVC Checker:getUpdateURL - update URL: https://aus3.mozilla.org/update/3/Firefox/4.0b8pre/20101028055046/WINNT_x86_64-msvc/en-US/nightly/Windows_NT%206.1/default/default/update.xml?force=1 AUS:SVC Checker:checkForUpdates - sending request to: https://aus3.mozilla.org/update/3/Firefox/4.0b8pre/20101028055046/WINNT_x86_64-msvc/en-US/nightly/Windows_NT%206.1/default/default/update.xml?force=1 Hope it helps... Cheers Wojtek Moch
I was nicely surprised to see only a few seconds ago that x64 updates work again. Lets hope they stay that way. Thanx.
Resolution: WONTFIX → FIXED
Works for me too. latest-trunk is also updated - there were no new version for 3 days. Thanks!!
...no updates again. Since March 29th :/
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Seems to me like we can expect updates here to be intermittent and that will be a known state until win64 is officially supported. It's not a good use of our resources to go digging every time a nightly update breaks for an unsupported platform.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 14 years ago
Resolution: --- → WONTFIX
I hear you Lukas and I completely understand that x64 is not officially supported yet, but if the reason behind the missing Winx64 builds is only because the x64 build bot "stuck" and all it takes is a restart, then that ain't that many resources spent now. Is it? Besides, from what I read in various official/unofficial roadmaps posted around the web: "...4.2 is just a place holder number (much like 3.7, which eventually became 4.0 once in the beta builds) for what will likely be Firefox 5". If that is true + the fact that 5.0 is aimed to ship Winx64 builds as well, then even if the breakage is code related I guess it is better to identify the regression early before we move way ahead. Don't you agree?
...by the way. They work again, so 'fixed' then.
Resolution: WONTFIX → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.