* beetmover should copy it * add bouncer entries for it Both are in-tree changes and can ride the trains.

What's the beetmover part ? Looks like there is just one stub that makes a runtime choice about which arch to d/l, so we need a win64 location for firefox-latest and friends. What am I missing ? See also https://wiki.mozilla.org/ReleaseEngineering/How_To/Enable_or_Disable_Updates_on_Aurora#Update_bouncer

The following beetmover configs handle win32 stub. Copying them to the win64 section should be sufficient. https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/configs/beetmover/en_us.yml.tmpl#43-47 https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/configs/beetmover/repacks.yml.tmpl#28-32 Good point regarding the aurora bouncer entry.

Matt just landed bug 797208 to make the stub installer automatically select Win32 or Win64 Firefox builds. There will be no Win32-only or Win64-only stub installers. We will have one 32/64-bit-aware stub installer and the existing 32-bit and 64-bit full installers. Rail, are these beetmover and bouncer changes still necessary?

We don't need to do anything if https://dxr.mozilla.org/mozilla-central/rev/0ddfec7126ec503b54df9c4b7c3b988906f6c882/browser/confvars.sh#18-27 builds the stub installer only for 32bit builds.

My uninformed reading of that confvars.sh code looks like it will do the right thing. Matt, have you confirmed that Win64 builds produce a full installer and not a 64-bit-only stub installer? I think we can resolve this automation bug as WORKSFORME then.

Win64 builds currently produce only a full installer and not a stub, and my intention was for that to continue. I modified the 32-bit stub installer so that it can install either build.

Sweet! I like patches which don't introduce more work for releng. :P Thank you Matt! I think we are safe to close this bug.