Closed Bug 1278812 Opened 3 years ago Closed 3 years ago

mach artifact install fails with "No such file or directory 'objdir-frontend/dist/bin/plugin-container'"


(Firefox Build System :: General, defect)

Not set


(firefox53 fixed)

Tracking Status
firefox53 --- fixed


(Reporter: johannh, Assigned: standard8)


(Blocks 1 open bug)



(1 file)

Full output

tl;dr my mach build command (after clobber) fails to run because it can not find "objdir-frontend/dist/bin/plugin-container".
Blocks: artifact
No longer blocks: 1277841
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.
Closed: 3 years ago
Resolution: --- → WORKSFORME
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.
Resolution: WORKSFORME → ---
Yeah me too on the latest central (f8e3b81a79f4)
It is interesting that in the objdir there is this empty directory: dist/bin/
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 This is almost certainly because that was a push head for the mozilla-central push/merge where universal os x builds were dropped.
Depends on: 1295375
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, it is looking for a 'public/build/firefox-(.*).mac.dmg' on taskcluster. However, taskcluster is now listing the opt builds as 'mac64' not 'mac':

Looking at, 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:

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.

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 `` 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.
Attachment #8818223 - Flags: review?(gps) → review+
Pushed by
Change default mac filename to be 'mac' rather than 'mac64' now that bug 1295375 has moved us away from universal builds. r=gps
Assignee: nobody → standard8
Closed: 3 years ago3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
I can confirm that this fixes the issue for me. Thanks for the fix.
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.