This appears to be fallout from bug 746545 Running xpcshell tests on a new local clone fails because it can't find mozinfo.py: > make SOLO_FILE=test_authentication.js -C obj-ff-dbg/netwerk/test/ check-one make: Entering directory `/home/hurley/src/mozilla/mchg/obj-ff-dbg/netwerk/test' /usr/bin/python2.7 -u /home/hurley/src/mozilla/mchg/config/pythonpath.py \ -I/home/hurley/src/mozilla/mchg/build \ /home/hurley/src/mozilla/mchg/testing/xpcshell/runxpcshelltests.py \ --symbols-path=../../dist/crashreporter-symbols \ --build-info-json=../../mozinfo.json \ --test-path=test_authentication.js \ --profile-name=firefox \ --verbose \ \ /home/hurley/src/mozilla/mchg/obj-ff-dbg/dist/bin/xpcshell \ ../../_tests/xpcshell/netwerk/test/unit ../../_tests/xpcshell/netwerk/test/unit_ipc Traceback (most recent call last): File "/home/hurley/src/mozilla/mchg/config/pythonpath.py", line 52, in <module> main(sys.argv[1:]) File "/home/hurley/src/mozilla/mchg/config/pythonpath.py", line 44, in main execfile(script, frozenglobals) File "/home/hurley/src/mozilla/mchg/testing/xpcshell/runxpcshelltests.py", line 48, in <module> import mozinfo ImportError: No module named mozinfo make: *** [check-one] Error 1 make: Leaving directory `/home/hurley/src/mozilla/mchg/obj-ff-dbg/netwerk/test' Running tests in an old directory (one where you already ran xpcshell tests) works fine because there's a cached .pyc in build/ that runxpcshelltests.py is able to import.
I don't know if this is the right place to look for mozinfo, but it does allow me to run the tests. Why do we copy everything into $obj/_tests and run it from there?
Attachment #619707 - Flags: review?(ted.mielczarek)
Comment on attachment 619707 [details] [diff] [review] Help 'make xpcshell-tests' find 'mozinfo' Python module. Review of attachment 619707 [details] [diff] [review]: ----------------------------------------------------------------- Files get copied around mostly for historical reasons, but partly because lots of tests want to load things like test XPCOM components. We could presumably refactor things to run mostly from the srcdir and just copy files as needed to the objdir, we just haven't gotten around to it. ::: config/rules.mk @@ -112,4 @@ > # See also testsuite-targets.mk 'xpcshell-tests' target for global execution. > xpcshell-tests: > $(PYTHON) -u $(topsrcdir)/config/pythonpath.py \ > - -I$(topsrcdir)/build \ There are a couple of invocations below that you'll need to fix as well. (check-one, check-interactive).
Attachment #619707 - Flags: review?(ted.mielczarek) → review+
https://hg.mozilla.org/integration/fx-team/rev/cbd9979748e4 Landed in fx-team, as mozilla-inbound is closed for Windows linker memory consumption; if this causes trouble, please let me know.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla15
Is there a particular reason this was landed in fx-team instead of m-c? m-c is approval required, and given that (1) this won't alter the size of libxul, and (2) the patch solves a problem that could easily be seen by people cloning m-c, it seems to make more sense to get approval to land on m-c instead of a repo that not everyone works off of.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Backed out the latest fx-team merge whole-sale because of Ts regressions: https://hg.mozilla.org/mozilla-central/rev/b0200dab0ccc Please reland only after investigating and fixing the regression. Thanks!
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I messed up and backed out the wrong range, sorry about that. I backed out my backout, so this is still on mozilla-central: https://hg.mozilla.org/mozilla-central/rev/dec5b367c421
Status: REOPENED → RESOLVED
Closed: 7 years ago → 7 years ago
Resolution: --- → FIXED
I have a similar problem with running xpcshell tests on windows with Thunderbird. I've tried making a similar change to our rules.mk, but so far, no luck.
(In reply to David :Bienvenu from comment #8) > I have a similar problem with running xpcshell tests on windows with > Thunderbird. I've tried making a similar change to our rules.mk, but so far, > no luck. David, let's track the comm-central failure on https://bugzilla.mozilla.org/show_bug.cgi?id=752252 if you don't already have a bug for it.
You need to log in before you can comment on or make changes to this bug.