1019170 - no new hamachi/helix/nexus-4 updates since may 30th

Status: VERIFIED FIXED

(Release Engineering :: General, defect)

Description

[[e-mail] (:bhearsum)]

Someone in #b2g pointed this out. Current snippet looks like:
<updates><update type="minor" appVersion="32.0a1" version="32.0a1" extensionVersion="32.0a1" buildID="20140530040207" licenseURL="http://www.mozilla.com/test/sample-eula.html" detailsURL="http://www.mozilla.com/test/sample-details.html" isOSUpdate="true"><patch type="complete" URL="http://update.boot2gecko.org/hamachi/2.0.0/nightly/b2g_update_20140530040207.mar?build_id=20140530040207&version=32.0a1" hashFunction="SHA512" hashValue="1c7bd2d0c26f7bcc8d16cee2ad001e98a6bc58f18c79afd8f17b92fc934e8e4aab767d2cf2c6aba75dd5b6d5c0b4d44ac9451c9224f3f4eb0b37a7be28c8bea8" size="58710373"/></update></updates>

From http://update.boot2gecko.org/hamachi/2.0.0/nightly/update.xml

This seems unexpected to me, as the latest nightlies are running all of the updates steps successfully...

Comment 1

[[e-mail] (:bhearsum)]

Upload paths are messed up somehow:
[ec2-user@ip-10-39-70-110 2.0.0]$ pwd
/data/update-channels/hamachi/2.0.0
[ec2-user@ip-10-39-70-110 2.0.0]$ find . -type d
.
./nightly
./hamachi
./hamachi/2.0.0
./hamachi/2.0.0/nightly

Everything is going into hamachi/2.0.0/nightly now. It's possible that this is fallout from one of my Balrog related patches last week.

Comment 2

[[e-mail] (:bhearsum)]

I'm pretty sure this patch is the problem:
https://github.com/mozilla/build-mozharness/commit/b8c4aa4d15c4eb715e1d26a812f6710b6a23e537

Which I _think_ interferes with this publish_channel logic: https://github.com/mozilla/build-mozharness/blob/master/scripts/b2g_build.py#L1528.

B2G_UPDATE_CHANNEL gets added to env in query_build_env, which I'm pretty sure is a shared reference with the plain env:
https://github.com/mozilla/build-mozharness/blob/master/scripts/b2g_build.py#L414. I'm willing to bet there's something accidentally depending on that bug at this point, so I'm not going to risk changing that to fix this. I filed bug 1019190 for the issue though.

Looks like this affects all devices/versions still on the old update server (everything except Flame 2.0.0).

Currently looking for a workaround.

Comment 3

[[e-mail] (:bhearsum)]

Attachment: revert update channel logic in update creation/upload steps

This isn't a great solution, but this code is dying with update.boot2gecko.org, so I don't think it's worthwhile finding a better one.

Comment 4

[Nick Thomas [:nthomas] (UTC+12)]

Comment on attachment 8432755 [details] [diff] [review]
revert update channel logic in update creation/upload steps

May this code live a short time and not prosper. To the future!

Comment 5

[[e-mail] (:bhearsum)]

Comment on attachment 8432755 [details] [diff] [review]
revert update channel logic in update creation/upload steps

Landed on default+production

Comment 6

[[e-mail] (:bhearsum)]

Next round of updates should work fine...

Comment 7

[[e-mail] (:bhearsum)]

The snippets look fine to me now - they're pointing at nightlies from this morning rather than May 30. I also confirmed with mac- on IRC, who got an update to his Hamachi.

Sorry about this, folks.

Comment 9

[Josh Schmitt [Joshs]]

OTA update works on 1.4 Flame.

Environmental Variables:
Device: Flame
Build ID: 20140603000203
Gaia: d108159874cb594e7068a5c8384f05f0a8910bfd
Gecko: 42d80aea48e3
Version: 30.0 (1.4) 
Firmware Version: v10G-2

Comment 10

[Simone Bruno [:simone]]

In production with reconfig on 2014-06-03 00:53 PT