| msg117230 - (view) |
Author: Hirokazu Yamamoto (ocean-city) *  |
Date: 2010-09-23 20:27 |
| test_ttk_guionly hangs on x86 XP5 buldbot. But it doesn't hang on test_tk. Former shows widget but latter doesn't on my machine. http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/1348/steps/test/logs/stdio |
|
|
| msg120404 - (view) |
Author: Hirokazu Yamamoto (ocean-city) * |
Date: 2010-11-04 13:44 |
| I've created the patch to fix this. (This patch comes from #9055) |
|
|
| msg127549 - (view) |
Author: Paul Moore (paul.moore) * |
Date: 2011-01-30 20:44 |
| Patch looks good to me. Can this be applied? As a temporary workaround I have set my buildbot to run interactively. Once the fix is applied, I will switch back to running as a service. |
|
|
| msg127556 - (view) |
Author: David Bolen (db3l) * |
Date: 2011-01-30 21:52 |
| Perhaps somewhat orthogonal to the patch, but in terms of the original hang issue, does your service definition have the "interact with desktop" option checked? That ought to permit any normal UI processing to take place as if you were running it interactively. |
|
|
| msg127560 - (view) |
Author: Paul Moore (paul.moore) * |
Date: 2011-01-30 23:06 |
| > Perhaps somewhat orthogonal to the patch, but in terms of the original hang issue, does your service definition have the "interact with desktop" option checked? That ought to permit any normal UI processing to take place as if you were running it interactively. It runs as a specific user, not as LocalSystem (and only LocalSystem has the "interact with desktop" checkbox, so yes, I think it does...) |
|
|
| msg127561 - (view) |
Author: David Bolen (db3l) * |
Date: 2011-01-30 23:16 |
| If I recall correctly, if you're not using localsystem then its much tougher, as by default it won't have access to your interactive desktop, just something internal that you won't see, maybe just a hidden windows station. You're right that the interact setting is only for localsystem. It's been many years, but I think I had some code that located and attached to the interactive desktop (if one was currently available) from within a background service that I used in a remote management system. Our remote service (functioned similarly to rshd) also ran under a specific user. At least in theory I think you might be able to tweak the local buildbot code to execute any tests from within a child process that does the same thing first. In the end it's only the executing test code that needs the access, not the buildbot itself. If I get a chance I'll see if I can scrounge up what I did, but will take that off-line from this ticket since it's a broader question. |
|
|
| msg129581 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2011-02-26 17:58 |
| Committed in r88652 (3.3) and r88655 (3.2). Unfortunately, Paul's buildbot seems a bit stuck in a previous build... (I didn't commit to 2.7 since things look fine there) |
|
|
| msg129642 - (view) |
Author: Paul Moore (paul.moore) * |
Date: 2011-02-27 17:58 |
| Seems to be correctly skipping the test now - failures are because of other issues (a load more hg builds means that the buildslave is getting a bit tight on space...) This change looks fine. Thanks! |
|
|
| msg129644 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2011-02-27 18:22 |
| Ok, great ! The hg builders are temporary - or, rather, the SVN builders will get removed once the transition is over. |
|
|