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.
Created attachment 358090 [details] [diff] [review] workaround 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
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.
Are you going to push this?
Created attachment 362807 [details] [diff] [review] updated to trunk [Checkin: Comment 12 & 17] Will land this one shortly.
Status: NEW → RESOLVED
Last Resolved: 9 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
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]
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
You need to log in before you can comment on or make changes to this bug.