Last Comment Bug 556564 - Automated updates broken for 2.1a1pre nightlies since 20100329010643
: Automated updates broken for 2.1a1pre nightlies since 20100329010643
Status: VERIFIED FIXED
: regression
Product: SeaMonkey
Classification: Client Software
Component: Release Engineering (show other bugs)
: Trunk
: x86 Windows XP
: -- normal (vote)
: seamonkey2.1a1
Assigned To: Robert Kaiser
:
Mentors:
Depends on: 556321
Blocks: 555730
  Show dependency treegraph
 
Reported: 2010-04-01 11:11 PDT by Philip Chee
Modified: 2010-04-07 14:56 PDT (History)
6 users (show)
bugzillamozillaorg_serge_20140323: in‑testsuite-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Philip Chee 2010-04-01 11:11:33 PDT
http://forums.mozillazine.org/viewtopic.php?f=6&t=1831395

rsx11m:
Anybody else not getting trunk updates beyond 20100329 on Windows?
Checking the AUS XML manually it gives me buildID="20100329010643" as well. :?

From #seamonkey:

<Ratty>	KaiRo: is this a known problem wikth automatic updates with the latest nightlies? http://forums.mozillazine.org/viewtopic.php?f=6&t=1831395
<KaiRo>	Ratty: at least someome finally is testing, please get a bug filed
	Ratty: and mark it a regression from bug 555730
Comment 1 Robert Kaiser 2010-04-01 12:23:21 PDT
coop suspects bug 556321 to be a possible cause here, I'll try updating buildbotcustom to pull in that.
Comment 2 Robert Kaiser 2010-04-01 17:14:59 PDT
OK, I hope coop was right. I have now updated the buildmaster to current code that includes the bug 556321 fix and I hope that means this bug will be fixed with tomorrow's nightlies.
Comment 3 rsx11m 2010-04-02 03:59:40 PDT
Sorry, I'm still getting "No updates available" despite 20100402 nightly builds being available. AUS XML still refers to 20100329 build as well.
Comment 4 u331436 2010-04-03 05:23:04 PDT
Same here... automatic updates do not work
Comment 5 rsx11m 2010-04-03 06:16:49 PDT
Reopening, no luck with 20100403 either. I've manually installed 20100402 to see if seamonkey-2.1a1pre.en-US.win32.partial.20100402015622-20100403014456.mar is grabbed for the partial update, but nothing is happening on Help > Update.
Comment 6 Serge Gautherie (:sgautherie) 2010-04-04 20:55:17 PDT
(In reply to comment #0)
> Checking the AUS XML manually it gives me buildID="20100329010643" as well. :?

The url is
{
/suite/browser/browser-prefs.js
    * line 417 -- pref("app.update.url", "https://aus2-community.mozilla.org/update/1/%PRODUCT%/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/update.xml");
}

That AUS XML is
https://aus2-community.mozilla.org/update/1/SeaMonkey/2.1a1pre/2010040101/WINNT_x86-msvc/en-US/nightly/update.xml?force=1
{
<update type="minor" version="2.1a1pre" extensionVersion="2.1a1pre" buildID="20100329010643">
<patch type="complete" 
}

*****

The date seems to match:
bug 555730 http://hg.mozilla.org/build/buildbot-configs/rev/fe12ba9f6bfd
{
    1.26 -BRANCHES['comm-central-trunk']['aus2_base_upload_dir'] = '/opt/aus2/build/0/SeaMonkey/comm-central-trunk'
    1.29 +BRANCHES['comm-central-trunk']['aus2_base_upload_dir'] = '/opt/aus2/incoming/2/SeaMonkey/mozilla-central'
    1.30 +BRANCHES['comm-central-trunk']['aus2_base_upload_dir_l10n'] = '/opt/aus2/incoming/2/SeaMonkey/mozilla-central'
}
Are the new paths right?
build/0 -> incoming/2 ?
comm-central-trunk -> mozilla-central ?
Comment 7 Robert Kaiser 2010-04-05 03:53:12 PDT
(In reply to comment #6)
>     1.26 -BRANCHES['comm-central-trunk']['aus2_base_upload_dir'] =
> '/opt/aus2/build/0/SeaMonkey/comm-central-trunk'
>     1.29 +BRANCHES['comm-central-trunk']['aus2_base_upload_dir'] =
> '/opt/aus2/incoming/2/SeaMonkey/mozilla-central'
>     1.30 +BRANCHES['comm-central-trunk']['aus2_base_upload_dir_l10n'] =
> '/opt/aus2/incoming/2/SeaMonkey/mozilla-central'

Thanks for looking, I was somewhat expecting the problem to be in those paths, but didn't come around to check in details yet.

> Are the new paths right?
> build/0 -> incoming/2 ?

That was my first though, but coop assured me the change is just that we now put things directly where they should be, and don't rely on some internal automation forwarding build/0 somewhere else.

> comm-central-trunk -> mozilla-central ?

THAT is very probably it! D'Oh! Thanks for finding that one, will fix today!
Comment 8 Robert Kaiser 2010-04-05 04:39:07 PDT
Should be fixed in tommorrow's nightlies after the pushing of http://hg.mozilla.org/build/buildbot-configs/rev/afe2fcc3fcbd and reconfig of the master I just have done.
Comment 9 rsx11m 2010-04-06 06:31:02 PDT
Still no update for me, the AUS XML appears to be empty now...

> https://aus2-community.mozilla.org/update/1/SeaMonkey/2.1a1pre/2010040201/WINNT_x86-msvc/en-US/nightly/update.xml?force=1
<updates>
</updates>

as provided by http://update-watch.localgho.st/nightly/production/latest/
Comment 10 Serge Gautherie (:sgautherie) 2010-04-06 09:39:11 PDT
(Ftr, FF 3.7 uploads to aus2-staging.mozilla.org,
SM 2.1 to aus2-community.mozilla.org.)
Comment 11 Chris Cooper [:coop] 2010-04-06 10:01:09 PDT
It's quite possible you *don't* want to be uploading your final version snippets to incoming/2. The MoCo AUS server takes snippets from incoming/2 in staging and uses them to provide updates via update/3, e.g.

https://aus2.mozilla.org/update/3/Firefox/3.6.3/20100401064631/Darwin_Universal-gcc3/en-US/release/Darwin%2010.3.0/default/default/update.xml?force=1

If SeaMonkey is expecting updates via update/1, your final snippets may need a different aus2_base_upload_dir. 

Can you check the community patch generation script output to see where it was putting the final snippets before?
Comment 13 Robert Kaiser 2010-04-06 10:44:38 PDT
(In reply to comment #11)
> If SeaMonkey is expecting updates via update/1, your final snippets may need a
> different aus2_base_upload_dir. 

Hmm, I don't think that's actually the case, we just may have not switched to the right URLs in the client yet, then. But I don't think that the update URL versions actually have anything to do with this, as the only difference they should make is what info the URL contains.

Serge, btw, do you know if we have any open bug on moving to a newer update URL scheme?

> Can you check the community patch generation script output to see where it was
> putting the final snippets before?

We were putting them into build/0, just as you did before that work.
Comment 14 Robert Kaiser 2010-04-06 11:21:32 PDT
OK, I did some updates on the AUS server side, we're running a clean cvs HEAD version of the code now, and the URL in comment #9 actually returns something for me now. I hope this fixed it.
Comment 15 Robert Kaiser 2010-04-06 11:23:57 PDT
Oh, and using https://aus2-community.mozilla.org/update/1/SeaMonkey/2.1a1pre/20100405013957/WINNT_x86-msvc/en-US/nightly/update.xml?force=1 (build ID of yesterday's build) even gives me a partial update!
Comment 16 Serge Gautherie (:sgautherie) 2010-04-06 11:28:05 PDT
(In reply to comment #13)
> Serge, btw, do you know if we have any open bug on moving to a newer update URL
> scheme?

It doesn't look like we have.
(And, fwiw, I don't think I know anything about that subject/need.)
Comment 17 Robert Kaiser 2010-04-06 12:56:27 PDT
(In reply to comment #16)
> (In reply to comment #13)
> > Serge, btw, do you know if we have any open bug on moving to a newer update URL
> > scheme?
> 
> It doesn't look like we have.
> (And, fwiw, I don't think I know anything about that subject/need.)

I thought it might have popped up somewhere in the middle of the whole porting efforts. In any case, I already have filed bug 557583.
Comment 18 rsx11m 2010-04-06 16:24:15 PDT
Full update from 20100402 to Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a4pre) Gecko/20100406 SeaMonkey/2.1a1pre worked now, I'll mark this verified if tomorrow's partial update goes through as well.
Comment 19 rsx11m 2010-04-07 14:35:44 PDT
Update from 20100406 to 20100407032007 went fine and was a partial update with a 1156KB download size. Thus, verified fixed now - thanks!
Comment 20 Robert Kaiser 2010-04-07 14:56:12 PDT
Yay! Thanks for testing!

Note You need to log in before you can comment on or make changes to this bug.