bhearsum@mozilla.com (:bhearsum) Assignee
	Description • 9 years ago

It caused us to start stripping stuff away from the platform, which means that "flame-kk" ends up being "flame", which means it submits to the B2G-mozilla-central-nightly-latest instead of the kitkat version.

This is what we get for having hacks like the kitkat one, I guess.

	bhearsum@mozilla.com (:bhearsum) Assignee
	Comment 1 • 9 years ago

I'm not confident this didn't break other things, so here's a much more targeted fix for Graphene.

	Jordan Lund (:jlund)
	Comment 2 • 9 years ago

Comment on attachment 8575384 [details] [diff] [review]
use more targeted fix for graphene

Review of attachment 8575384 [details] [diff] [review]:
-----------------------------------------------------------------

I'm okay with something like this. it's too bad we have to hard code platform names in the script. maybe take a look at my idea (in line comment) and see if you think that's less hacky

::: mozharness/mozilla/updates/balrog.py
@@ +36,5 @@
>          )))
> +        # XXX: hack alert, turn fake graphene platforms into real ones. This
> +        # was done more generically originally (bug 1140437), but it broke
> +        # flame-kk updates (bug 1141633)
> +        balrog_props["properties"]["platform"] = balrog_props["properties"]["platform"].replace("_graphene", "")

what about making this configurable? maybe something like

if c.get('balrog_platform'):
    balrog_props["properties"]["platform"] = c['balrog_platform']


then add balrog_platform to: http://mxr.mozilla.org/build/find?string=graphene&tree=build&hint=

	bhearsum@mozilla.com (:bhearsum) Assignee
	Comment 3 • 9 years ago

I transplanted this patch to production. This should be fixed after the next set of nightlies.

	Peter Bylenga [:PBylenga]
	Comment 4 • 9 years ago

Adding qawanted to test the 4pm nightlies for mozilla-central when they're available.

	bhearsum@mozilla.com (:bhearsum) Assignee
	Comment 5 • 9 years ago

Ack. I forgot that the mozharness revision is pinned in the tree now. I'll need to update that before these are fixed too :(.

	bhearsum@mozilla.com (:bhearsum) Assignee
	Comment 6 • 9 years ago

Looks like this picks up much more than I need, but I don't really have a choice...

	bhearsum@mozilla.com (:bhearsum) Assignee
	Comment 7 • 9 years ago

Comment on attachment 8575953 [details] [diff] [review]
bump mozharness rev

I'm r+'ing my own patch because prior to in-tree mozharness revs, I wouldn't have needed this patch at all. AFAICT we don't have any policy around what to do here yet, so I don't want to block this fix unnecessarily.

https://hg.mozilla.org/mozilla-central/rev/bc6aeea72290

	bhearsum@mozilla.com (:bhearsum) Assignee
	Comment 8 • 9 years ago

I triggered a new kitkat nightly to expedite fixing these. I'll update the bug after I've confirmed that it worked.

	bhearsum@mozilla.com (:bhearsum) Assignee
	Comment 9 • 9 years ago

The latest nightly reported in correctly. No-Jun, I'll leave it up to you to re-enable updates - I'm not sure if there's additional verification you want to do.

	Martin Shuman [:Marty]
	Comment 10 • 9 years ago

Verified Fixed, we can now successfully update to the latest build in the nightly mozilla-central channel.

Environmental Variables:
Device: Flame 3.0
Build ID: 20150311110236
Gaia: 2b87ee8e7e2ec30a9851b6b59a899006a98767ab
Gecko: bc6aeea72290
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 39.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0

	Chris Cooper [:coop] (he/him)
	Comment 11 • 9 years ago

mozharness production tag moved to: https://hg.mozilla.org/build/mozharness/rev/f18e70492ade