1185602 - mozregression does not works under MSYS2 on Windows 8.1 x64

Status: RESOLVED FIXED

(Testing :: mozregression, defect)

Description

[Ed Morley [:emorley]]

STR:
1) Run mozregression using "mozregression --good 2014-08-01" n Windows 8.1 x64

Expected:
Runs without an unhandled exception.

Actual:

(mozregression)[~/src/tmp]$ mozregression --good 2014-08-01
 0:00.14 LOG: MainThread INFO No 'bad' date specified, using 2015-07-20
Traceback (most recent call last):
  File "/home/Ed/.virtualenvs/mozregression/bin/mozregression", line 11, in <module>
    sys.exit(cli())
  File "/home/Ed/.virtualenvs/mozregression/lib/python2.7/site-packages/mozregression/main.py", line 384, in cli
    sys.exit(bisect(runner, logger))
  File "/home/Ed/.virtualenvs/mozregression/lib/python2.7/site-packages/mozregression/main.py", line 278, in bisect_nightlies
    return runner.bisect_nightlies(good_date, bad_date)
  File "/home/Ed/.virtualenvs/mozregression/lib/python2.7/site-packages/mozregression/bisector.py", line 518, in bisect_nightlies
    result = self.do_bisect(handler, good_date, bad_date)
  File "/home/Ed/.virtualenvs/mozregression/lib/python2.7/site-packages/mozregression/main.py", line 212, in do_bisect
    return BisectRunner.do_bisect(self, handler, good, bad, **kwargs)
  File "/home/Ed/.virtualenvs/mozregression/lib/python2.7/site-packages/mozregression/bisector.py", line 514, in do_bisect
    return self.bisector.bisect(handler, good, bad, **kwargs)
  File "/home/Ed/.virtualenvs/mozregression/lib/python2.7/site-packages/mozregression/bisector.py", line 456, in bisect
    **kwargs)
  File "/home/Ed/.virtualenvs/mozregression/lib/python2.7/site-packages/mozregression/build_data.py", line 493, in __init__
    info_fetcher = BuildFolderInfoFetcher(fetch_config.build_regex(),
  File "/home/Ed/.virtualenvs/mozregression/lib/python2.7/site-packages/mozregression/fetch_configs.py", line 28, in build_regex
    return get_build_regex(self.app_name, self.os, self.bits) + '$'
  File "/home/Ed/.virtualenvs/mozregression/lib/python2.7/site-packages/mozregression/utils.py", line 170, in get_build_regex
    regex = '%s%s' % (name, suffix)
UnboundLocalError: local variable 'suffix' referenced before assignment


(mozregression)[~/src/tmp]$ pip show mozregression
---
Metadata-Version: 2.0
Name: mozregression
Version: 0.39
Summary: Regression range finder for Mozilla nightly builds
Home-page: http://github.com/mozilla/mozregression
Author: Mozilla Automation and Tools Team
Author-email: [e-mail]
License: MPL 1.1/GPL 2.0/LGPL 2.1
Location: /home/Ed/.virtualenvs/mozregression/lib/python2.7/site-packages
Requires: mozrunner, redo, mozprofile, mozdevice, BeautifulSoup, mozlog, mozinstall, futures, requests, cachecontrol, mozfile, taskcluster, mozversion, mozinfo

Comment 1

[Julien Pagès (:parkouss)]

Oh, really interesting. Sounds like a mozinfo bug to me. Could you issue the command:

python -c 'import mozinfo; print mozinfo.os'

And paste the result ? I believe you have something else than "win" that will be printed.

Comment 2

[Ed Morley [:emorley]]

Indeed :-)

(mozregression)[~/src/tmp]$ python -c 'import mozinfo; print mozinfo.os'
UNKNOWN

(mozregression)[~/src/tmp]$ python -c 'import platform; print platform.uname()[0]'
MINGW32_NT-6.3

Which doesn't match:
https://hg.mozilla.org/mozilla-central/file/b894570f9083/testing/mozbase/mozinfo/mozinfo/mozinfo.py#l40

I'm using MSYS2.

Comment 3

[Ed Morley [:emorley]]

Seems like we need two fixes:
1) Make mozinfo recognise MSYS environments, see:
http://stackoverflow.com/a/17072017
2) Make mozregression print a nicer error when run on an OS of "unknown"

Comment 4

[Julien Pagès (:parkouss)]

Attachment: exit cleanly with a nice error message is os is unknown/unsupported

So this is the first round for fixing this bug. This just add a clean exit when such thing happen. :)

We should consider also updating mozinfo dependency version once it is resolved on the mozinfo side, and I propose to track that from this bug also.

Comment 5

[William Lachance (:wlach)]

Comment on attachment 8636503 [details] [review]
exit cleanly with a nice error message is os is unknown/unsupported

lgtm!

Comment 6

[Julien Pagès (:parkouss)]

Thanks Will!

Merged in:

https://github.com/mozilla/mozregression/commit/9a5f0aad2f991f3ea116ba2a88c9d2e1ba130b3c

Leaving this bug open until this is fixed on mozinfo side, so we can update the dependency version.

Comment 7

[Ed Morley [:emorley]]

I'm now getting:

(mozregression)[~/src/treeherder]$ mozregression --good=2015-08-01
Traceback (most recent call last):
  File "/home/Ed/.virtualenvs/mozregression/bin/mozregression", line 7, in <module>
    from mozregression.main import main
  File "/home/Ed/.virtualenvs/mozregression/lib/python2.7/site-packages/mozregression/main.py", line 26, in <module>
    from mozregression.launchers import REGISTRY as APP_REGISTRY
  File "/home/Ed/.virtualenvs/mozregression/lib/python2.7/site-packages/mozregression/launchers.py", line 15, in <module>
    from mozrunner import Runner
  File "/home/Ed/.virtualenvs/mozregression/lib/python2.7/site-packages/mozrunner/__init__.py", line 4, in <module>
    from .cli import *
  File "/home/Ed/.virtualenvs/mozregression/lib/python2.7/site-packages/mozrunner/cli.py", line 11, in <module>
    from .runners import runners
  File "/home/Ed/.virtualenvs/mozregression/lib/python2.7/site-packages/mozrunner/runners.py", line 11, in <module>
    from .base import DeviceRunner, GeckoRuntimeRunner
  File "/home/Ed/.virtualenvs/mozregression/lib/python2.7/site-packages/mozrunner/base/__init__.py", line 1, in <module>

    from .runner import BaseRunner
  File "/home/Ed/.virtualenvs/mozregression/lib/python2.7/site-packages/mozrunner/base/runner.py", line 13, in <module>
    import mozcrash
  File "/home/Ed/.virtualenvs/mozregression/lib/python2.7/site-packages/mozcrash/__init__.py", line 8, in <module>
    from mozcrash import *
  File "/home/Ed/.virtualenvs/mozregression/lib/python2.7/site-packages/mozcrash/mozcrash.py", line 349, in <module>
    kernel32 = ctypes.windll.kernel32
AttributeError: 'module' object has no attribute 'windll'

(mozregression)[~/src/treeherder]$ pip freeze
You are using pip version 7.1.0, however version 7.1.2 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
BeautifulSoup==3.2.1
blessings==1.6
CacheControl==0.11.5
configobj==5.0.6
futures==3.0.3
lockfile==0.10.2
manifestparser==1.1
mozcrash==0.16
mozdevice==0.46
mozfile==1.2
mozinfo==0.8
mozInstall==1.12
mozlog==3.0
moznetwork==0.27
mozprocess==0.22
mozprofile==0.27
mozregression==1.0.1
mozrunner==6.10
mozversion==1.4
PyHawk-with-a-single-extra-commit==0.1.5
redo==1.5
requests==2.7.0
six==1.9.0
slugid==1.0.6
taskcluster==0.0.26
wheel==0.24.0

Comment 8

[Ed Morley [:emorley]]

(In reply to Ed Morley [:emorley] from comment #7)
> "/home/Ed/.virtualenvs/mozregression/lib/python2.7/site-packages/mozcrash/
> mozcrash.py", line 349, in <module>
>     kernel32 = ctypes.windll.kernel32
> AttributeError: 'module' object has no attribute 'windll'

Regressed by bug 890026.

Btw the packages listed by pip freeze above are *just* what `pip install -U mozregression` pulled in - there's an awful lot of unnecessary stuff there for me to use mozregression :-(

Comment 9

[Ed Morley [:emorley]]

Thoughts:
1) The list of packages pulled in to use mozregression is too large - we really shouldn't need to install "taskcluster" etc
2) mozrunner should have an option to not import mozcrash
3) mozregression should have the option to set OS/platform etc so it doesn't have to use mozinfo (that way we don't need mozinfo to support every edge case env)

#2+#3 would be enough for me to be able to use mozregression, #1 would just be a bonus.

Comment 10

[Julien Pagès (:parkouss)]

(In reply to Ed Morley [:emorley] from comment #9)
> Thoughts:
> 1) The list of packages pulled in to use mozregression is too large - we
> really shouldn't need to install "taskcluster" etc

You list is wrong. An install in a clean virtualenv:

BeautifulSoup==3.2.1
PyHawk-with-a-single-extra-commit==0.1.5
argparse==1.2.1
blessings==1.6
configobj==5.0.6
mozInstall==1.12
mozcrash==0.16
mozdevice==0.46
mozfile==1.2
mozinfo==0.8
mozlog==3.0
moznetwork==0.27
mozprocess==0.22
mozprofile==0.27
mozregression==1.0.1
mozrunner==6.10
mozversion==1.4
redo==1.5
requests==2.7.0
six==1.9.0
slugid==1.0.6
taskcluster==0.0.26
wsgiref==0.1.2

I have tried to remove plenty of dependencies like CacheControl, futures, lockfile, manifestparser and so on with bugs like
bug 1189858. That is 22 deps instead of 26 (and argparse is listed in my list, not sure why).

six==1.9.0
slugid==1.0.6
taskcluster==0.0.26
wsgiref==0.1.2
PyHawk-with-a-single-extra-commit==0.1.5

are required by taskcluster - but without taskcluster, we can't go to inbound, so I don't see the
point of not requiring that ? Maybe we can investigate why taskcluster requires that.

> 2) mozrunner should have an option to not import mozcrash

Agreed, see bug 1190371.

Basically, I think that mozbase dependencies are not really good - I am not
sure why moznetwork or mozcrash are required, you're right.

> 3) mozregression should have the option to set OS/platform etc so it doesn't
> have to use mozinfo (that way we don't need mozinfo to support every edge
> case env)

Well, it does not make sense to me to let the user choose the os... This is basically
a mozinfo bug. Though I don't mind writing an exception in mozregression (e.g. reading from platform
or something if mozinfo.OS is UNDEFINED) since it seems hard to accept that directly in mozinfo.
But we will have to fix the mozrunner issue that tries to import mozcrash (maybe with bug 1190371).



Ok, but anyway I don't like the idea of a non usable mozregression because there is something
that the harnesses does not support! :emorley, thanks for the comments, I will find some time to make this work. :)

Comment 11

[Ed Morley [:emorley]]

(In reply to Julien Pagès from comment #10)
> You list is wrong. An install in a clean virtualenv:
...
> I have tried to remove plenty of dependencies like CacheControl, futures,
> lockfile, manifestparser and so on with bugs like
> bug 1189858. 

Ah this was an |pip install -U|, so didn't take into account bug 1189858.

> > 2) mozrunner should have an option to not import mozcrash
> 
> Agreed, see bug 1190371.

Ah I'd forgotten that bug (I'm even CCed hehe).

> Well, it does not make sense to me to let the user choose the os... This is
> basically
> a mozinfo bug. 

Agreed

> Ok, but anyway I don't like the idea of a non usable mozregression because
> there is something
> that the harnesses does not support! :emorley, thanks for the comments, I
> will find some time to make this work. :)

No problem - thank you :-)

Comment 12

[Julien Pagès (:parkouss)]

:emorley, could you try with the master branch and the following patch applied:

https://github.com/parkouss/mozregression/commit/6c7f29ca913a499c16ba3230c2207cb4c547ba90.patch

Be sure to test this in a new virtualenv, or at least update the mozrunner version.

I am wondering, does

> python -c 'import mozinfo; print mozinfo.bits'

works well in your case ?

Thanks!

Comment 13

[Ed Morley [:emorley]]

(In reply to Julien Pagès (:parkouss) from comment #12)
> :emorley, could you try with the master branch and the following patch
> applied:
> 
> https://github.com/parkouss/mozregression/commit/
> 6c7f29ca913a499c16ba3230c2207cb4c547ba90.patch
> 
> Be sure to test this in a new virtualenv, or at least update the mozrunner
> version.

Seems to work now, thank you :-)

(test2)[~/src/treeherder]$ pip install https://github.com/parkouss/mozregression/archive/6c7f29ca913a499c16ba3230c2207c b4c547ba90.zip
...
(test2)[~/src/treeherder]$ mozregression --good 2014-08-01
**********
You should use a config file. Please use the --write-config command line flag to help you create one.
**********

 0:00.08 LOG: MainThread WARNING You are using mozregression version 1.0.1, however version 1.0.5 is available.
 0:00.08 LOG: MainThread WARNING You should consider upgrading via the 'pip install --upgrade mozregression' command.
 0:00.08 LOG: MainThread INFO bits option not specified, using 64-bit builds.
 0:00.09 LOG: MainThread INFO No 'bad' date specified, using 2015-10-29
 0:18.11 LOG: MainThread Bisector INFO Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=104254bd1fc8&tochange=f7b746b4e91307448cb0746a41f677bfc23908b0

 0:18.11 LOG: MainThread download INFO Downloading build from: http://ftp-origin-scl3.mozilla.org/pub/firefox/nightly/2015/03/2015-03-12-03-02-48-mozilla-central/firefox-39.0a1.en-US.win64.zip
===== Downloaded 15% =====
...

> I am wondering, does
> 
> > python -c 'import mozinfo; print mozinfo.bits'
> 
> works well in your case ?

Yeah I get:
(test2)[~/src/treeherder]$ python -c 'import mozinfo; print mozinfo.bits'
64

(with mozinfo 1.2)

Comment 14

[Julien Pagès (:parkouss)]

Awesome! Let's land this soon.

Comment 15

[Julien Pagès (:parkouss)]

Attachment: allow mozreg to run on Win/MSYS2

Comment 16

[Julien Pagès (:parkouss)]

FYI, mozcrash is no more a required dependency of mozrunner, so mozregression won't download it starting from next release. :)

Comment 17

[William Lachance (:wlach)]

Comment on attachment 8680796 [details] [review]
allow mozreg to run on Win/MSYS2

I have no problem with you landing this, but I'm not sure why you decided not to patch mozinfo upstream for this case?

Comment 18

[Julien Pagès (:parkouss)]

(In reply to William Lachance (:wlach) from comment #17)
> Comment on attachment 8680796 [details] [review]
> allow mozreg to run on Win/MSYS2
> 
> I have no problem with you landing this, but I'm not sure why you decided
> not to patch mozinfo upstream for this case?

Good question. :)

Hm, I think I was a bit scared about the comment in bug 1185632 comment 4. I thought that ted's wanted to say something like: if we allow msys2 on mozinfo, we *should* allow msys2 in all mozbase - and I don't have the time for that :(.

But maybe I misunderstood the comment, so if you agree to fix the issue upstream with two lines of code (change a regexp or add a new case for the os only) then I'm totally fine with that.

In fact now that you ask, I would totally go for it. Make the change in mozinfo. This don't imply that we need to make mozbase fully compatible with MSYS2, right ?

If you agree, I'll take that road. Thanks for asking that question Will.

Comment 19

[William Lachance (:wlach)]

(In reply to Julien Pagès (:parkouss) from comment #18)
> (In reply to William Lachance (:wlach) from comment #17)
> > Comment on attachment 8680796 [details] [review]
> > allow mozreg to run on Win/MSYS2
> > 
> > I have no problem with you landing this, but I'm not sure why you decided
> > not to patch mozinfo upstream for this case?
> 
> Good question. :)
> 
> Hm, I think I was a bit scared about the comment in bug 1185632 comment 4. I
> thought that ted's wanted to say something like: if we allow msys2 on
> mozinfo, we *should* allow msys2 in all mozbase - and I don't have the time
> for that :(.

Yeah, I don't think that's what Ted meant, necessarily. I think he was just saying that there's more work needed than just this to make things work well under msys2.

> But maybe I misunderstood the comment, so if you agree to fix the issue
> upstream with two lines of code (change a regexp or add a new case for the
> os only) then I'm totally fine with that.
> 
> In fact now that you ask, I would totally go for it. Make the change in
> mozinfo. This don't imply that we need to make mozbase fully compatible with
> MSYS2, right ?

I don't think it does, no. We can fix things up there on a case by case basis.

Comment 20

[(not currently active) Ted Mielczarek]

I really think you're going to fall down a rabbit hole here, and it might be easier to just say that MSYS Python is not supported.

Comment 21

[Julien Pagès (:parkouss)]

(In reply to Ted Mielczarek [:ted.mielczarek] from comment #20)
> I really think you're going to fall down a rabbit hole here, and it might be
> easier to just say that MSYS Python is not supported.

Ok - we can still change our decision later if we have too many issues.

Landed in https://github.com/mozilla/mozregression/commit/ccc014055238994633e65702b18170b13492eba5. I don't think that needs a review, only version changes in the setup.py and travis/appveyor are green.