840926 - mozinstall.exe triggers UAC on the win8 machines

Status: RESOLVED DUPLICATE of bug 844982

(Infrastructure & Operations Graveyard :: CIDuty, task)

Description

[Carsten Book [:Tomcat]]

We have set w864-002 with elevated rights for buildbot, thats all fine. 

However we seem to have still problems here.

Running Tests with dev-master01 and the -002 returns in 

01:56:06     INFO - Copy/paste: c:\talos-slave\test\build\venv\Scripts\mozinstall -h
Traceback (most recent call last):
  File "scripts/scripts/desktop_unittest.py", line 364, in <module>
    desktop_unittest.run()
  File "C:\slave\test\scripts\mozharness\base\script.py", line 735, in run
    self._possibly_run_method(method_name, error_if_missing=True)
  File "C:\slave\test\scripts\mozharness\base\script.py", line 694, in _possibly_run_method
    return getattr(self, method_name)()
  File "C:\slave\test\scripts\mozharness\mozilla\testing\testbase.py", line 250, in install
    output = self.get_output_from_command(cmd + ['-h'])
  File "C:\slave\test\scripts\mozharness\base\script.py", line 591, in get_output_from_command
    cwd=cwd, stderr=tmp_stderr, env=env)
  File "c:\mozilla-build\python\lib\subprocess.py", line 679, in __init__
    errread, errwrite)
  File "c:\mozilla-build\python\lib\subprocess.py", line 893, in _execute_child
    startupinfo)
WindowsError: [Error 740] The requested operation requires elevation.

I looked into the problem and found one possible issue:

Comment 1

[Carsten Book [:Tomcat]]

Attachment: default window after system reboot

this is the terminal/cmd.exe that comes up by default after a system reboot.

This configuration will fail because of complaining missing elevated rights

Comment 2

[Carsten Book [:Tomcat]]

Attachment: run as terminal that will work

this is the screenshot when you run talos-start as administrator - also note the administrator:cmd.exe text above the terminal.

This configuration will run the test, so we have still some problem here

Comment 3

[Carsten Book [:Tomcat]]

maybe some kind of mix between runas and putting the startprogramm into \ProgramData\Microsoft\Windows\Start Menu\Programs\Startup would be a solution

Comment 4

[Carsten Book [:Tomcat]]

marking as blocker since this is preventing tests from running succesful

Comment 5

[Carsten Book [:Tomcat]]

(In reply to Carsten Book [:Tomcat] from comment #3)
> maybe some kind of mix between runas and putting the startprogramm into
> \ProgramData\Microsoft\Windows\Start Menu\Programs\Startup would be a
> solution

http://technet.microsoft.com/en-us/library/bb490994.aspx for runas - but however this brings us back to be running as admin :( which is no solution

Comment 6

[Carsten Book [:Tomcat]]

some more debugging with 

runas /user:cltbld cmd.exe and then from the new command window startTalos.bat also resulted in the same error - so running as cltbld user seems the problem


03:47:01     INFO - Return code: 0
03:47:01     INFO - Done creating virtualenv c:/talos-slave/test/build/venv.
03:47:01     INFO - #####
03:47:01     INFO - ##### Running install step.
03:47:01     INFO - #####
03:47:01     INFO - Getting output from command: ['c:\\talos-slave\\test\\build\\venv\\Scripts\\pip', 'freeze']
03:47:01     INFO - Copy/paste: c:\talos-slave\test\build\venv\Scripts\pip freeze
03:47:01     INFO - Reading from file tmpfile_stdout
03:47:01     INFO - Detecting whether we're running mozinstall >=1.0...
03:47:01     INFO - Getting output from command: ['c:\\talos-slave\\test\\build\\venv\\Scripts\\mozinstall', '-h']
03:47:01     INFO - Copy/paste: c:\talos-slave\test\build\venv\Scripts\mozinstall -h
Traceback (most recent call last):
  File "scripts/scripts/desktop_unittest.py", line 364, in <module>
    desktop_unittest.run()
  File "C:\slave\test\scripts\mozharness\base\script.py", line 735, in run
    self._possibly_run_method(method_name, error_if_missing=True)
  File "C:\slave\test\scripts\mozharness\base\script.py", line 694, in _possibly_run_method
    return getattr(self, method_name)()
  File "C:\slave\test\scripts\mozharness\mozilla\testing\testbase.py", line 250, in install
    output = self.get_output_from_command(cmd + ['-h'])
  File "C:\slave\test\scripts\mozharness\base\script.py", line 591, in get_output_from_command
    cwd=cwd, stderr=tmp_stderr, env=env)
  File "c:\mozilla-build\python\lib\subprocess.py", line 679, in __init__
    errread, errwrite)
  File "c:\mozilla-build\python\lib\subprocess.py", line 893, in _execute_child
    startupinfo)
WindowsError: [Error 740] The requested operation requires elevation

Comment 7

[Dustin J. Mitchell [:dustin] (he/him)]

What operation is it requesting?  I'm fairly certain we want to run as a non-administrator -- we need to simulate a "normal" user environment, after all -- but we could probably make exceptions for specific tasks.

Comment 8

[Carsten Book [:Tomcat]]

(In reply to Dustin J. Mitchell [:dustin] from comment #7)
> What operation is it requesting?  I'm fairly certain we want to run as a
> non-administrator -- we need to simulate a "normal" user environment, after
> all -- but we could probably make exceptions for specific tasks.

i guess its because running mozinstall.exe -h as example fires the UAC Prompt because of an unknown publisher, that might cause the problems

Comment 9

[Carsten Book [:Tomcat]]

(In reply to Carsten Book [:Tomcat] from comment #6)
btw, comparing to comment #6, this is what is expected

01:55:45     INFO - Getting output from command: ['c:\\talos-slave\\test\\build\\venv\\Scripts\\mozinstall', '-h']
01:55:45     INFO - Copy/paste: c:\talos-slave\test\build\venv\Scripts\mozinstall -h
01:55:45     INFO - Reading from file tmpfile_stdout
01:55:45     INFO - Output received:
01:55:45     INFO -  Usage: mozinstall-script.py [options] installer
01:55:45     INFO -  Options:
01:55:45     INFO -    -h, --help            show this help message and exit
01:55:45     INFO -    -d DEST, --destination=DEST
01:55:45     INFO -                          Directory to install application into. [default:
01:55:45     INFO -                          "C:\slave\test"]
01:55:45     INFO -    --app=APP             Application being installed. [default: firefox]
01:55:45     INFO - mkdir: C:\slave\test\build\application
01:55:45     INFO - Getting output from command: ['c:\\talos-slave\\test\\build\\venv\\Scripts\\mozinstall', 'C:\\slave\\test\\build\\installer.zip', '--destination', 'C:\\slave\\test\\build\\application']
01:55:45     INFO - Copy/paste: c:\talos-slave\test\build\venv\Scripts\mozinstall C:\slave\test\build\installer.zip --destination C:\slave\test\build\application
01:55:53     INFO - Reading from file tmpfile_stdout
01:55:53     INFO - Output received:
01:55:53     INFO -  C:\slave\test\build\application\firefox\firefox.exe

Comment 10

[Dustin J. Mitchell [:dustin] (he/him)]

I suspect this is trying to install the Mozilla Maintenance Service.  That service is *not* yet installed on the hosts (I only got data on how to do so on Friday).  If you can confirm that this is the problem - best done by installing MMS by hand using the instructions in the google doc - then we know we have the solution planned; if not, then we will need to get better detail on *which* operation requires elevation.

Comment 11

[Carsten Book [:Tomcat]]

(In reply to Dustin J. Mitchell [:dustin] from comment #10)
> I suspect this is trying to install the Mozilla Maintenance Service.  That
> service is *not* yet installed on the hosts (I only got data on how to do so
> on Friday).  If you can confirm that this is the problem - best done by
> installing MMS by hand using the instructions in the google doc - then we
> know we have the solution planned; if not, then we will need to get better
> detail on *which* operation requires elevation.

yeah i will install it manually and will get back if its causing the problem

Comment 12

[Armen [:armenzg]]

mozinstall is simply a tool by the a-team that unifies installing binaries across various OSes (exe vs dmg vs rpm).
It has nothing to do with the Mozilla Maintenance Service.

Comment 13

[Carsten Book [:Tomcat]]

hm so installed process monitor and process explorer from systeminternals and did some exploring into this but didn't helped much (logs are in the cltbld download directory under explorer/monitor btw

also started to install now the maintaince service - so far till the regkeys, will see what this result in

http://dev-master01.build.scl1.mozilla.com:8042/builders/Rev3%20WINNT%206.2%20cedar%20opt%20test%20mochitest-other/builds/30/steps/run_script/logs/stdio is btw the log of the succesful run

Comment 14

[Dustin J. Mitchell [:dustin] (he/him)]

So the plan here is to image two of the new machines with the latest task sequence from bug 780050, using Chris's scheduled task configuration on one, and "runas cltbld, elevated privleges" manually configured on the other.  Armen will run the test on both tomorrow and we'll have at least 2 bits of additional data.

Comment 15

[Dustin J. Mitchell [:dustin] (he/him)]

I've imaged the two machines, but I can't for the life of me find the talos scheduled task (or the MMS one, for that matter).  

Armen, if you're up before me, please run a test on t-w864-ix-001 to see if the privs work there. Please also have a look and see if you can adjust the scheduled task on 002 - maybe I'm missing something obvious.  If not, I'll ask Chris when he and I are online.

Comment 16

[Armen [:armenzg]]

Could Win8 not be respecting that the job is already with the highest privilege?

The file is called mozinstall.exe which I assume it triggers UAC automatically because it has "install" in the filename.

http://msdn.microsoft.com/en-us/library/aa905330.aspx#wvduac_topic3

Comment 17

[Armen [:armenzg]]

I have deployed a python package called mozDeploy which is really mozInstall.
This is temporary until bug 841777 gets resolved.
http://hg.mozilla.org/users/cbook_mozilla.com/build

Jobs can actually run tests now with this workaround:
http://dev-master01.build.scl1.mozilla.com:8042/builders/Rev3%20WINNT%206.2%20cedar%20opt%20test%20mochitest-other

Comment 18

[Carsten Book [:Tomcat]]

(In reply to Armen Zambrano G. [:armenzg] from comment #17)
> I have deployed a python package called mozDeploy which is really mozInstall.
> This is temporary until bug 841777 gets resolved.
> http://hg.mozilla.org/users/cbook_mozilla.com/build
> 
> Jobs can actually run tests now with this workaround:
> http://dev-master01.build.scl1.mozilla.com:8042/builders/Rev3%20WINNT%206.
> 2%20cedar%20opt%20test%20mochitest-other

seems this caused a regression :( since builds don't even reach that far for the elevation problem and now stop with

  SYSTEMROOT=C:\windows
  TEMP=C:\Users\cltbld\AppData\Local\Temp
  TMP=C:\Users\cltbld\AppData\Local\Temp
  USERDOMAIN=IX-MN-W864-002
  USERDOMAIN_ROAMINGPROFILE=IX-MN-W864-002
  USERNAME=cltbld
  USERPROFILE=C:\Users\cltbld
  WINDIR=C:\windows
 using PTY: False
The system cannot find the path specified.
program finished with exit code 1
elapsedTime=0.102000

http://dev-master01.build.scl1.mozilla.com:8042/builders/Rev3%20WINNT%206.2%20cedar%20opt%20test%20mochitest-4/builds/8/steps/run_script/logs/stdio 

(thats the same error btw as for the shutdown problem, investigating)

Comment 19

[Carsten Book [:Tomcat]]

seems this affect also running mozinstall as admin :/ not sure why 

http://dev-master01.build.scl1.mozilla.com:8042/builders/Rev3%20WINNT%206.2%20cedar%20opt%20test%20mochitest-other/builds/65/steps/run_script/logs/stdio

Comment 20

[Carsten Book [:Tomcat]]

So another 2 points i noticed:

-> On reboots we get now UAC prompts for the mozinstall app asking for the admin password

-> (thanks to callek) one workaround/fix could be that instead of using mozinstall.exe using python mozinstall-script.py since running python mozinstall-script.py -h gives me the expected output without any UAC etc prompt

Comment 21

[Armen [:armenzg]]

Passing it back to Tomcat. I was filling in while he was on PTO.

Comment 22

[Carsten Book [:Tomcat]]

seems the problem is not fixed which what i tried with the manifest (or i did it wrong) sending mail to the windows gurus in bug https://bugzilla.mozilla.org/show_bug.cgi?id=841777 for help

Comment 23

[Armen [:armenzg]]

I landed a bunch of mozharness changes in:
http://hg.mozilla.org/users/cbook_mozilla.com/build

We can now run the tests on staging. We're working around the mozinstall issue. Reboot is also working.
http://dev-master01.build.scl1.mozilla.com:8042/one_line_per_build

Tomcat, can you please take care of comparing your mozharness repo with the official one and prepare patches for me/aki to deal with?

Comment 24

[Carsten Book [:Tomcat]]

(In reply to Armen Zambrano G. [:armenzg] from comment #23)
> I landed a bunch of mozharness changes in:
> http://hg.mozilla.org/users/cbook_mozilla.com/build
> 
> We can now run the tests on staging. We're working around the mozinstall
> issue. Reboot is also working.
> http://dev-master01.build.scl1.mozilla.com:8042/one_line_per_build
> 
> Tomcat, can you please take care of comparing your mozharness repo with the
> official one and prepare patches for me/aki to deal with?

ok done 

cbook-1119:mozharness cbook$ hg incoming ../../hg/build/
comparing with ../../hg/build/
searching for changes
changeset:   1327:873d39e38176
branch:      production
user:        Armen Zambrano Gasparnian <[e-mail]>
date:        Thu Feb 14 10:11:40 2013 -0500
summary:     changes

changeset:   1328:4b71209f1358
parent:      1325:7e55fc43828f
parent:      1327:873d39e38176
user:        Armen Zambrano Gasparnian <[e-mail]>
date:        Thu Feb 14 10:25:34 2013 -0500
summary:     Merge production to default

changeset:   1329:4978b7bcb11f
user:        Armen Zambrano Gasparnian <[e-mail]>
date:        Fri Feb 15 11:59:00 2013 -0500
summary:     try mozdeploy

changeset:   1330:eb5aec522d2c
user:        Armen Zambrano Gasparnian <[e-mail]>
date:        Fri Feb 15 12:08:53 2013 -0500
summary:     mozdeploy

changeset:   1331:67c5c8d99709
user:        Armen Zambrano Gasparnian <[e-mail]>
date:        Fri Feb 15 12:21:32 2013 -0500
summary:     test

changeset:   1332:f357ec224c8f
user:        Armen Zambrano Gasparnian <[e-mail]>
date:        Fri Feb 15 12:52:59 2013 -0500
summary:     more

changeset:   1333:bac13aecabf6
user:        Armen Zambrano Gasparnian <[e-mail]>
date:        Fri Feb 15 12:59:12 2013 -0500
summary:     revert

changeset:   1334:9cd4ff0a7793
user:        Armen Zambrano Gasparnian <[e-mail]>
date:        Fri Feb 15 13:09:22 2013 -0500
summary:     new MozInstall

changeset:   1335:20a6309b8d15
user:        Armen Zambrano Gasparnian <[e-mail]>
date:        Fri Feb 15 14:51:59 2013 -0500
summary:     mozdeploy

changeset:   1336:b58674b9e6f7
user:        Armen Zambrano Gasparnian <[e-mail]>
date:        Fri Feb 15 14:58:57 2013 -0500
summary:     mozdeploy

changeset:   1337:876b22c17a42
user:        Armen Zambrano Gasparnian <[e-mail]>
date:        Wed Feb 20 14:37:17 2013 -0500
summary:     Try new mozInstall

changeset:   1338:e9917b3ee0f7
user:        Armen Zambrano Gasparnian <[e-mail]>
date:        Wed Feb 20 14:40:06 2013 -0500
summary:     Use mozInstall from people

changeset:   1339:a01aa5bfd4c8
user:        Armen Zambrano Gasparnian <[e-mail]>
date:        Wed Feb 20 15:38:10 2013 -0500
summary:     Switch back to mozInstall from mozDeploy

changeset:   1340:1ea8d237c398
user:        Armen Zambrano Gasparnian <[e-mail]>
date:        Wed Feb 20 16:07:32 2013 -0500
summary:     workaround

changeset:   1341:80802dccc3ac
user:        Armen Zambrano Gasparnian <[e-mail]>
date:        Wed Feb 20 16:08:22 2013 -0500
summary:     typo

changeset:   1342:e85f7f57e913
user:        Armen Zambrano Gasparnian <[e-mail]>
date:        Wed Feb 20 16:12:54 2013 -0500
summary:     absolute path to mozinstall

changeset:   1343:a019b7f1077e
user:        Armen Zambrano Gasparnian <[e-mail]>
date:        Wed Feb 20 16:19:59 2013 -0500
summary:     run mozdeploy

changeset:   1344:15c8bd420c2c
user:        Armen Zambrano Gasparnian <[e-mail]>
date:        Wed Feb 20 17:21:49 2013 -0500
summary:     Try another approach

changeset:   1345:55d66c53c48d
user:        Armen Zambrano Gasparnian <[e-mail]>
date:        Wed Feb 20 17:26:48 2013 -0500
summary:     more

changeset:   1346:2c94ce0b544c
user:        Armen Zambrano Gasparnian <[e-mail]>
date:        Wed Feb 20 17:27:33 2013 -0500
summary:     typo

changeset:   1347:511ac5ec1381
tag:         tip
user:        Armen Zambrano Gasparnian <[e-mail]>
date:        Wed Feb 20 22:01:59 2013 -0500
summary:     Try 1.4

Comment 25

[Carsten Book [:Tomcat]]

Attachment: more detailed diff

armen here is a more detailed diff, but not sure how to get it into the official repo

Comment 26

[Carsten Book [:Tomcat]]

Attachment: patch

Comment 27

[Armen [:armenzg]]

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

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

r- to adjust those things I mentioned.

Can you please push this change to http://hg.mozilla.org/users/asasaki_mozilla.com/ash-mozharness and make sure that the Windows unit tests go green in:
https://tbpl.mozilla.org/?tree=Ash&jobname=WINNT

To trigger jobs in there you can push a new head from a mozilla-central checkout to http://hg.mozilla.org/projects/ash.
That tree uses Aki's ash-mozharness repo rather than the official one.

::: configs/unittests/win_unittest.py
@@ +8,4 @@
>  XPCSHELL_NAME = 'xpcshell.exe'
>  DISABLE_SCREEN_SAVER = False
>  ADJUST_MOUSE_AND_SCREEN = True
> +VENV_PATH = 'c:/talos-slave/test/build/venv'

I'm surprised this is actually even working since we C:/slave rather than C:/talos-slave.

@@ +29,2 @@
>      "simplejson_url": "http://puppetagain.pub.build.mozilla.org/data/python/packages/simplejson-2.1.3.tar.gz",
> +    "mozInstall_url": "http://puppetagain.pub.build.mozilla.org/data/python/packages/mozInstall-1.4.tar.gz",

This is only necessay because on virtualenv_modules we added "mozinstall" and removed "{'mozinstall': os.path.join('tests', 'mozbase', 'mozinstall')},".

This is not anymore needed since we don't have to test a custom made mozInstall package.

You can remove this line, line 71 ("mozsintall",) and add back "{'mozinstall': os.path.join('tests', 'mozbase', 'mozinstall')},"

::: scripts/desktop_unittest.py
@@ +68,4 @@
>  
>      virtualenv_modules = [
>          "simplejson",
> +        "mozInstall",

Remove this.

@@ +72,4 @@
>          {'mozlog': os.path.join('tests', 'mozbase', 'mozlog')},
>          {'mozinfo': os.path.join('tests', 'mozbase', 'mozinfo')},
>          {'mozhttpd': os.path.join('tests', 'mozbase', 'mozhttpd')},
>          {'mozfile': os.path.join('tests', 'mozbase', 'mozfile')},

Add back the removed line.

Comment 28

[Carsten Book [:Tomcat]]

Attachment: review adressed

Comment 29

[Carsten Book [:Tomcat]]

(In reply to Armen Zambrano G. [:armenzg] from comment #27)
> Comment on attachment 716491 [details] [diff] [review]
> patch
> 
> Review of attachment 716491 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> r- to adjust those things I mentioned.
> 
> Can you please push this change to
> http://hg.mozilla.org/users/asasaki_mozilla.com/ash-mozharness and make sure
> that the Windows unit tests go green in:
> https://tbpl.mozilla.org/?tree=Ash&jobname=WINNT
> 

done! https://hg.mozilla.org/users/asasaki_mozilla.com/ash-mozharness/rev/f518d980c8b6

Comment 30

[Armen [:armenzg]]

Comment on attachment 716511 [details]
review adressed

This looks good but I would need to see a run on the Ash tree to make sure it works for Win7 and WinXP.

Comment 31

[Aki Sasaki (not active)]

Comment on attachment 716511 [details]
review adressed

> +VENV_PATH = 'c:/slave/test/build/venv'

This is a win8-ism, right?  However this config file is used in every windows slave, so landing this will bust xp and win7.

You may be able to use os.getcwd() here ftw, since venv will probably be ./build/venv .

Either way, I'd love for you to doublecheck xp and win7 on ash when testing.

> +                sys.executable, "../scripts/external_tools/mouse_and_screen_resolution.py",

Does mouse_and_screen_resolution.py rely on pywin32?
If that's not installed system-wide, you should probably use the python in the venv for this.

I think we'll be good with those two fixes, but would also like ash tests.

Comment 32

[Armen [:armenzg]]

I've triggered tests on Ash:
https://tbpl.mozilla.org/?tree=Ash&jobname=WINNT

Tomcat, please have at the test results for Win7 and WinXP.
You can try mozharness fixes by keep on pushing to http://hg.mozilla.org/users/asasaki_mozilla.com/ash-mozharness.

Once you push a spot fix to ash-mozharness, you can then re-trigger a WinXP/Win7 job by clicking on the job and clicking on the "+" sign. It will ask you for your LDAP credentials.
That should re-trigger the job and cleanly checkout ash-mozharness with your spot fix.

You can see the "+" sign on this screenshot:
http://cl.ly/N4o2

It only shows up after I clicked on the job represented by a green "2".
Any job on tbpl after you click on it should show you that summary at the bottom left.

After you re-trigger a job you can then go to the buildbot-master where it is running to see the logs running live.
You can do that by using this bookmarklet:
http://www.pastebin.mozilla.org/2164200
edmorley wrote it and it allow us to go from a "running job" on tbpl to the actual buildbot-master that is running it on the back.

I know. Lots of stuff :)

Comment 33

[Carsten Book [:Tomcat]]

(In reply to Aki Sasaki [:aki] from comment #31)
> Comment on attachment 716511 [details]
> review adressed
> 
> > +VENV_PATH = 'c:/slave/test/build/venv'
> 
> This is a win8-ism, right?  However this config file is used in every
> windows slave, so landing this will bust xp and win7.

So different configs for xp/win7 vs. win8 right ?

Comment 34

[Dustin J. Mitchell [:dustin] (he/him)]

It's a new-slave-ism, meaning the new xp and win7 will also use c:\slave.  But since we're not deploying the new xp/win7, yes, it would bust them.

Comment 35

[Armen [:armenzg]]

If you load tbpl you can see that all of them went red:
https://tbpl.mozilla.org/?tree=Ash&jobname=WINNT

Comment 36

[Carsten Book [:Tomcat]]

(In reply to Armen Zambrano G. [:armenzg] from comment #35)
> If you load tbpl you can see that all of them went red:
> https://tbpl.mozilla.org/?tree=Ash&jobname=WINNT

03:53:04     INFO - Copy/paste: c:/slave/test/build/venv/scripts/python c:/slave/test/build/venv/scripts/mozinstall-script.py -h
Traceback (most recent call last):
  File "scripts/scripts/desktop_unittest.py", line 364, in <module>
    desktop_unittest.run()
  File "C:\talos-slave\test\scripts\mozharness\base\script.py", line 735, in run
    self._possibly_run_method(method_name, error_if_missing=True)
  File "C:\talos-slave\test\scripts\mozharness\base\script.py", line 694, in _possibly_run_method
    return getattr(self, method_name)()
  File "C:\talos-slave\test\scripts\mozharness\mozilla\testing\testbase.py", line 250, in install
    output = self.get_output_from_command(cmd + ['-h'])
  File "C:\talos-slave\test\scripts\mozharness\base\script.py", line 592, in get_output_from_command
    cwd=cwd, stderr=tmp_stderr, env=env)
  File "c:\mozilla-build\python27\lib\subprocess.py", line 679, in __init__
    errread, errwrite)
  File "c:\mozilla-build\python27\lib\subprocess.py", line 896, in _execute_child
    startupinfo)
WindowsError: [Error 3] The system cannot find the path specified

Comment 37

[Aki Sasaki (not active)]

(In reply to Carsten Book [:Tomcat] from comment #33)
> (In reply to Aki Sasaki [:aki] from comment #31)
> > Comment on attachment 716511 [details]
> > review adressed
> > 
> > > +VENV_PATH = 'c:/slave/test/build/venv'
> > 
> > This is a win8-ism, right?  However this config file is used in every
> > windows slave, so landing this will bust xp and win7.
> 
> So different configs for xp/win7 vs. win8 right ?

If you mean we should use different mozharness config files, we can probably work around this via os.path.join(os.getcwd(), "build", "venv") or something.

If you mean that the slaves are configured differently, that's correct.

Comment 38

[Armen [:armenzg]]

We're calling directly the ptyhon script rather than the exe file (remove bug 841777 from the dependency list).

Comment 39

[Armen [:armenzg]]

Too many patches in too many places.

I'm moving all mozharness win8 bugs to bug 844982.

Comment 40

[Armen [:armenzg]]

FTR another mozinstall bug is being fixed in bug 1155743 to prevent hitting the UAC prompt.