Full output https://pastebin.mozilla.org/8875802 tl;dr my mach build command (after clobber) fails to run because it can not find "objdir-frontend/dist/bin/plugin-container".

It's weird, but after trying to bisect the change that broke artifact builds I no longer get this error on fx-team tip (in the same cset where I used to get it).

Not getting this on fx-team anymore either. Should we close the bug?

I guess so. I wonder if it was a case where the downloaded artifacts weren't recent enough for the local build to pass.

For reference, the patch that recently landed for bug 1114647 didn't change the set of installed files, so in theory it shouldn't have caused this. (An earlier attempt in April — bug 1114647 comment #59 through 75 — did rename plugin-container but was backed out.)

I hit this again today.

Yeah me too on the latest central (f8e3b81a79f4)

It is interesting that in the objdir there is this empty directory: dist/bin/plugin-container.app/Contents/MacOS/

Hit this again today on central and inbound.

My colleague aswan and I are both seeing this today with artifact builds on OS X. They fail with this same error message.

The timing sounds like it may be related to bug 1295375. However, `hg bisect` says it is from https://hg.mozilla.org/mozilla-central/rev/88e0fb654a10. This is almost certainly because that was a push head for the mozilla-central push/merge where universal os x builds were dropped.

What branch+revision is the artifact build grabbing? I took a quick look at a random package before and after the universal build change and both have the same paths for plugin-container, so I'm not sure why this would start failing now.

I took a look and here's what is happening. According to artifacts.py, it is looking for a 'public/build/firefox-(.*).mac.dmg' on taskcluster. However, taskcluster is now listing the opt builds as 'mac64' not 'mac': https://tools.taskcluster.net/index/artifacts/#gecko.v2.mozilla-central.latest.firefox/gecko.v2.mozilla-central.latest.firefox.macosx64-opt Looking at http://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-central/, we can also see that the nightly builds have changed from 'mac' to 'mac64' (there's both sets in there currently). I'm guessing that change is wrong and is going to upset everyone. Due to the switch away from universal binaries, we're now hitting the else part of the ifdef here: https://dxr.mozilla.org/mozilla-central/rev/8103c612b79c2587ea4ca1b0a9f9f82db4b185b8/toolkit/mozapps/installer/package-name.mk#33 I think the simple solution is just to update that ifdef. I'll get a patch up in a few.

My local builds & the try builds appear to be ok with this change.

Comment on attachment 8818223 [details] Bug 1278812 - Change default mac filename to be 'mac' rather than 'mac64' now that bug 1295375 has moved us away from universal builds. https://reviewboard.mozilla.org/r/98370/#review98610 Good catch. This does mean we'll be unable to find artifacts across TC index renames. But this should be rare, so hopefully we can ignore this edge case. Also, the `package-name.mk` should have ideally been split to its own commits, as it has more to do with cleaning up recently-unused code. But meh. Happy to see all references to the old platform name nuked.

Pushed by gszorc@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/5436f5de7305 Change default mac filename to be 'mac' rather than 'mac64' now that bug 1295375 has moved us away from universal builds. r=gps

I can confirm that this fixes the issue for me. Thanks for the fix.