Closed Bug 1417414 Opened 2 years ago Closed 2 years ago
.base .Mozbuild Object .config _guess cannot execute config .guess
59 bytes, text/x-review-board-request
With the demise of client.mk, config.guess is now called from python in all situations, and not via $(shell ) from client.mk. https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&revision=45715ece25fcb064eee4f977ebd842d44a87f22b&filter-searchStr=night&selectedJob=144944414 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. https://hg.mozilla.org/mozilla-central/annotate/fc194660762d1b92e1679d860a8bf41116d0f54f/python/mozbuild/mozbuild/base.py#l458 is where the code is.
Trying something on try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=5562d5fc467e9bec0d16e3874ec723bc2c67e638 without any patch to see if the issue reproduces on try. https://treeherder.mozilla.org/#/jobs?repo=try&revision=b6a856ab1d21088970429fb597c70f8cd0789c4c to see if shell=True fixes anything.
The `_normalize_command` call in there hides a secret: https://dxr.mozilla.org/mozilla-central/rev/fc194660762d1b92e1679d860a8bf41116d0f54f/python/mach/mach/mixin/process.py#152 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: https://dxr.mozilla.org/mozilla-central/rev/fc194660762d1b92e1679d860a8bf41116d0f54f/python/mach/mach/mixin/process.py#22 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: https://public-artifacts.taskcluster.net/GZXXBoqmTCWVK8Ry0RhwdQ/0/public/logs/live_backing.log 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 ...so that path really should work.
(In reply to Axel Hecht [:Pike] from comment #1) > Trying something on try: > > https://treeherder.mozilla.org/#/ > 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. > https://treeherder.mozilla.org/#/ > 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.
Comment on attachment 8928536 [details] bug 1417414, force shell=True when running config.guess, https://reviewboard.mozilla.org/r/199792/#review205528 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 client.mk. And that's what is important.
Attachment #8928536 - Flags: review+
Attachment #8928536 - Flags: review?(core-build-config-reviews)
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/3a3080a142d0 force shell=True when running config.guess, r=gps
You need to log in before you can comment on or make changes to this bug.