Closed Bug 474703 Opened 15 years ago Closed 15 years ago

mochitest broken when TOPSRCDIR is relative

Categories

(Firefox Build System :: General, defect)

x86
macOS
defect
Not set
normal

Tracking

(status1.9.1 ?)

RESOLVED FIXED
mozilla1.9.2a1
Tracking Status
status1.9.1 --- ?

People

(Reporter: dcamp, Assigned: dcamp)

References

Details

(Keywords: fixed1.9.1, Whiteboard: [fixed1.9.1b4])

Attachments

(1 file, 2 obsolete files)

I don't use client.mk (preferring to manually configure and make), which ends up leaving SRCDIR a relative path.

The patch for bug 470963 changes automation.py to point at $(SRCDIR)/certs/, with SRCDIR = $(TOPSRCDIR)/build/pgo.  But mochitest runs automation.py at a different depth (/_tests/testing/mochitest), so when TOPSRCDIR is a relative path, it's at the wrong depth.
Attached patch workaround (obsolete) — Splinter Review
This slightly ugly patch makes the pointer to the cert dir absolute if it isn't already.
Attachment #358090 - Flags: review?(ted.mielczarek)
Attachment #358090 - Flags: review?(ted.mielczarek) → review+
Comment on attachment 358090 [details] [diff] [review]
workaround

+ifeq (,$(patsubst /%,,$(srcdir)))

$(filter /%,$(srcdir)) is somewhat simpler. (And we use it elsewhere.)

+PWD = $(shell pwd)
+ABSOLUTE_SRCDIR = $(PWD)/$(srcdir)

You can just use $(CURDIR) here instead of the PWD stuff. (Unfortunately we haven't fixed that in other places in the tree yet.)

Isn't it awesome how you have to fix this crap in three places?

r=me with those changes
Assignee: nobody → dcamp
With neither the patch attched here as written, or with the patch including Ted's suggested changes, do I get a runnable mochitest locally here. The error does change, so now it complains about:

WARNING: failed to bind socket: file ../../../../mozilla/netwerk/base/src/nsServerSocket.cpp, line 317
uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIServerSocket.init]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: ./httpd.js :: anonymous :: line 425"  data: no]

instead. Different bug presumably, or is that related to this?
I'd say you experience bug 464191.
"ps auxw | grep ssl" doesn't show any such processes running :(
Actually that output sounds like you have a lingering xpcshell process (running httpd.js).
Confirming this patch builds on win,mac and linux. Mochitest and leaktest work. I could not compile PGO build on mac but definitely not because of this patch.
Attached patch updated patch (obsolete) — Splinter Review
Are you going to push this?
Will land this one shortly.
http://hg.mozilla.org/mozilla-central/rev/9f3f8b980b7a
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Does this need to land on 1.9.1? Did we take the patch that broke this there? Serge: do you know?
Attachment #362807 - Attachment description: updated to trunk → updated to trunk [Checkin: Comment 12]
(In reply to comment #13)
> Does this need to land on 1.9.1?

I don't know but I assume it would.

> Did we take the patch that broke this there?

It looks like so: bug 470963 comment 10.
Target Milestone: --- → mozilla1.9.2a1
Version: unspecified → Trunk
Ok, let's get this onto 1.9.1 then. Mano mentioned that he can't run mochitests on 1.9.1 currently because of this.
Whiteboard: [needs 1.9.1 landing]
Attachment #361462 - Attachment is obsolete: true
Attachment #358090 - Attachment is obsolete: true
Depends on: 476163
Whiteboard: [needs 1.9.1 landing] → [needs 1.9.1 landing: after bug 476163]
I have bug 476163 queued up for a branch landing, I'll just land this along with it. I was planning on landing it today anyway.
Pushed to 1.9.1:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/c4a1a1d2e56a
Keywords: fixed1.9.1
Whiteboard: [needs 1.9.1 landing: after bug 476163]
Attachment #362807 - Attachment description: updated to trunk [Checkin: Comment 12] → updated to trunk [Checkin: Comment 12 & 17]
Whiteboard: [fixed1.9.1b4]
http://hg.mozilla.org/mozilla-central/rev/6eb615f284e0
Followup to bug 474703 for pymake: use core_abspath to get Windows-style absolute paths correct

***

Any reason not to land this bug on m-1.9.1, if/when bug 483856 lands there?
status1.9.1: --- → ?
Depends on: 483856
Flags: in-testsuite-
No longer depends on: 483856
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: