Temporarily disable geckodriver until it is made opt-in

RESOLVED FIXED in Firefox 55

Status

enhancement
P1
blocker
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: ato, Assigned: ato)

Tracking

Version 3
mozilla55
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox55 fixed)

Details

Attachments

(1 attachment, 1 obsolete attachment)

Windows developers are having issues compiling Firefox due as described in https://bugzilla.mozilla.org/show_bug.cgi?id=1367995.  Instead of backing out the patches landed in https://bugzilla.mozilla.org/show_bug.cgi?id=1340637, which amount to several hundred thousand lines of code, we can disable geckodriver building temporarily by commenting out DIRS += ["testing/geckodriver"] in toolkit/toolkit.mozbuild until https://bugzilla.mozilla.org/show_bug.cgi?id=1368035 has been fixed to make it opt-in for local developers.
Assignee: nobody → ato
Severity: normal → blocker
Status: NEW → ASSIGNED
Priority: -- → P1
Blocks: 1367995
I’m apparently not authorised to push this patch to m-c:

> % git push
> 
> Bundling 1 changesets
> Bundling 1 changesets
> Bundling 1 manifests
> Bundling 1 manifests
> 
> Bundling 0 files
> Bundling 1 files
> Traceback (most recent call last):
>   File "/usr/local/libexec/git-core/git-remote-hg", line 46, in <module>
>     run(main)
>   File "/usr/local/libexec/git-core/pythonlib/cinnabar/util.py", line 517, in run
>     retcode = func(sys.argv[1:])
>   File "/usr/local/libexec/git-core/git-remote-hg", line 40, in main
>     helper.run()
>   File "/usr/local/libexec/git-core/pythonlib/cinnabar/remote_helper.py", line 88, in run
>     func(*args)
>   File "/usr/local/libexec/git-core/pythonlib/cinnabar/remote_helper.py", line 393, in push
>     self._branchmap.names(), self._dry_run)
>   File "/usr/local/libexec/git-core/pythonlib/cinnabar/hg/repo.py", line 711, in push
>     reply = repo.unbundle(cg, repo_heads, '')
>   File "/usr/lib/python2.7/dist-packages/mercurial/wireproto.py", line 457, in unbundle
>     stream = self._calltwowaystream('unbundle', cg, heads=heads)
>   File "/usr/lib/python2.7/dist-packages/mercurial/httppeer.py", line 265, in _calltwowaystream
>     return self._callstream(cmd, data=fp_, headers=headers, **args)
>   File "/usr/lib/python2.7/dist-packages/mercurial/httppeer.py", line 157, in _callstream
>     raise error.Abort(_('authorization failed'))
> mercurial.error.Abort: authorization failed
> error: failed to push some refs to 'hg::https://hg.mozilla.org/mozilla-central'

I’ve attached the patch to this bug.
Flags: needinfo?(ryanvm)
Pushed by atolfsen@mozilla.com:
https://hg.mozilla.org/mozilla-central/rev/1bfa4578aa56
Temporarily disable building testing/geckodriver; r=me a=RyanVM
Oops, I was pushing to https: instead of ssh:.  Landed this in m-c:

https://hg.mozilla.org/mozilla-central/rev/1bfa4578aa56
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Glad you figured it out. Thanks for getting this done.
Flags: needinfo?(ryanvm)
Target Milestone: --- → mozilla55
Well I am really not sure that is the real issue here.  cl.exe exists on the system and is in the command search path.  I think the code in bug 1340637 is just wrong!
Hint try the Which command as in "which cl" to find the correct path to the command.
You need to log in before you can comment on or make changes to this bug.