855709 - [mach] mochitest-browser doesn't work anymore

Status: RESOLVED FIXED

(Testing :: Mochitest, defect)

Description

[Mike de Boer [:mikedeboer]]

Steps to reproduce:

1) Update your mac to OSX 10.8.3 (this will get you kernel 12.3.0 and Python 2.7.2)
2) Update to the latest mozilla-central HEAD
3) Run ANY mochi test, for example: `./mach mochitest-browser browser/base/content/test/browser_aboutHome.js`

You will end up with the following error:

OSError: [Errno 2] No such file or directory:
                        '/Users/mdeboer/Projects/mozilla-central/obj-x86_64-apple-darwin12.3.0/obj-x86_64-apple-darwin12.3.0/_tests/testing/mochitest'

(notice the double occurrence of the object dir)

When I put the mach script into /usr/local/bin/ and execute it (from any directory) I get:

'ImportError: No module named automation'

I will reference two bugs that are related (I think) which both landed March 27th (yesterday).

Comment 1

[Matt Brubeck (:mbrubeck)]

Attachment: untested patch

I couldn't reproduce the error (on Linux or Windows), but here's a blind stab at fixing it.  Does this fix or change things in any way?

Comment 2

[Brandon Benvie [:benvie]]

(In reply to Matt Brubeck (:mbrubeck) from comment #1)

> I couldn't reproduce the error (on Linux or Windows), but here's a blind
> stab at fixing it.  Does this fix or change things in any way?

Unfortunately it doesn't work.

    ImportError: No module named automation

Moving the changed line directly after "from automation import Automation" causes the original error.

Comment 3

[Brandon Benvie [:benvie]]

(In reply to Matt Brubeck (:mbrubeck) from comment #1)

> I couldn't reproduce the error (on Linux or Windows), but here's a blind
> stab at fixing it.  Does this fix or change things in any way?

Note, I have reproduced this on Windows.

    WindowsError: [Error 3] The system cannot find the path specified: 'c:\\src\\fx-team\\obj-i686-pc-mingw32\\obj-i686-pc-mingw32\\_tests\\testing\\mochitest'

Comment 4

[Gregory Szorc [:gps]]

I find it interesting that everybody who has seen this appears to use config.guess for the default objdir. I bet somewhere we're resolving topobjdir from inside topobjdir and that results in double append. Should be easy enough to test...

Comment 5

[Brandon Benvie [:benvie]]

Attachment: fix for abspath

This fixes the problem

Comment 6

[Matt Brubeck (:mbrubeck)]

Attachment: patch

This is equivalent to attachment 730919 [details] [diff] [review], but applies on top of bug 855563 (which has landed on inbound).

Alternately, we could make MozbuildObject.topobjdir always return an absolute path...

Comment 7

[Gregory Szorc [:gps]]

Comment on attachment 730921 [details] [diff] [review]
patch

Review of attachment 730921 [details] [diff] [review]:
-----------------------------------------------------------------

*sigh*. I was tempted to cancel review and say we should make topobjdir always return absolute paths. However, that is a little more risky. We can do that in a follow-up bug.

Comment 8

[Matt Brubeck (:mbrubeck)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/1a5385e4ee44

Comment 9

[Mike de Boer [:mikedeboer]]

I can confirm this working/ fixed on inbound. Let's move it to central asap!

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/1a5385e4ee44