Closed Bug 1417414 Opened 2 years ago Closed 2 years ago

mozbuild.base.MozbuildObject.config_guess cannot execute config.guess


(Firefox Build System :: General, defect)

Not set


(firefox-esr52 unaffected, firefox57 unaffected, firefox58 unaffected, firefox59blocking fixed)

Tracking Status
firefox-esr52 --- unaffected
firefox57 --- unaffected
firefox58 --- unaffected
firefox59 blocking fixed


(Reporter: Pike, Assigned: Pike)


(Blocks 1 open bug)


(Whiteboard: [stockwell infra])


(1 file)

With the demise of, config.guess is now called from python in all situations, and not via $(shell ) from shows that this busts windows l10n 32 bit nightlies.

My suspicion is that we're triggering the magic foo of python on windows using shell or not depending on rather vague criteria.

So this isn't about the win32 l10n nightlies, but about the source path not triggering the shell=True code-path, I guess. is where the code is.
Trying something on try: without any patch to see if the issue reproduces on try. to see if shell=True fixes anything.
The `_normalize_command` call in there hides a secret:

That will run the command through a shell, and since that call passes `require_unix_environment=True`, it'll always do so. Now, the shell *detection* for this case might be broken.

I note that the environment listed in that log doesn't have SHELL set, but does have MOZILLABUILD set, so according to this code:

we're likely trying to use `C:/mozilla-build/msys/bin/sh.exe`
Looking at a log from a successful L10N Nightly repack from a few days ago:

Shows the environment being the same, and the configure output shows:
05:58:14     INFO -   0:08.10 checking for a shell... C:/mozilla-build/msys/bin/sh.exe that path really should work.
(In reply to Axel Hecht [:Pike] from comment #1)
> Trying something on try:
> jobs?repo=try&revision=5562d5fc467e9bec0d16e3874ec723bc2c67e638 without any
> patch to see if the issue reproduces on try.

This burns, in the same way that m-c does.

> jobs?repo=try&revision=b6a856ab1d21088970429fb597c70f8cd0789c4c to see if
> shell=True fixes anything.

This is green.

I pushed my patch to mozreview, but I'm not sure if that's actually "the fix" or just a 5th layer of wallpaper.
Whiteboard: [stockwell infra]
Comment on attachment 8928536 [details]
bug 1417414, force shell=True when running config.guess,

When I first saw this bug reported, this was the fix that popped into my mind. This fix isn't ideal for reasons I think I saw discussed. But it should preserve the old behavior of And that's what is important.
Attachment #8928536 - Flags: review+
Attachment #8928536 - Flags: review?(core-build-config-reviews)
Blocks: 1418036
Pushed by
force shell=True when running config.guess, r=gps
Assignee: nobody → l10n
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.