This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Tkinter tests failed on Windows buildbots
Type: behavior Stage: resolved
Components: Tests, Tkinter, Windows Versions: Python 3.4
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: larry, loewis, paul.moore, python-dev, r.david.murray, serhiy.storchaka, steve.dower, tim.golden, zach.ware
Priority: low Keywords: patch

Created on 2015-12-12 17:01 by serhiy.storchaka, last changed 2022-04-11 14:58 by admin. This issue is now closed.

File name Uploaded Description Edit
pep101_custom_buildbots.diff zach.ware, 2015-12-22 19:58
Messages (11)
msg256287 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2015-12-12 17:01
Tkinter related tests are failed on 4 of 6 Windows 3.4 buildbots.

ERROR: setUpModule (test.test_tcl)
Traceback (most recent call last):
  File "C:\\3.4.kloth-win64\build\lib\test\", line 685, in setUpModule
    tcl = Tcl()
  File "C:\\3.4.kloth-win64\build\lib\tkinter\", line 1955, in Tcl
    return Tk(screenName, baseName, className, useTk)
  File "C:\\3.4.kloth-win64\build\lib\tkinter\", line 1856, in __init__ = _tkinter.create(screenName, baseName, className, interactive, wantobjects, useTk, sync, use)
_tkinter.TclError: Can't find a usable init.tcl in the following directories: 
    C:/ C:/ C:/ C:/ C:/ C:/ C:/

This probably means that Tcl wasn't installed properly.


Is this a test suite defect, or there is an issue with using Tkinter on Windows? In latter case this is a release blocker.
msg256294 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2015-12-12 21:02
I was encountering this recently trying to set up a build machine for the release, and it seems to be a build issue.

Martin is building the release and apparently has it working.
msg256748 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2015-12-20 03:05
I'm assuming this is a configuration issue on the buildbots.
msg256803 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2015-12-21 17:04
Larry: considering that 3.4 is now officially out of bugfix mode, how long do you want to keep the 3.4 buildbots around?  From a selfish buildmaster configurator perspective, axing the 3.4 bots simplifies a few things :)
msg256826 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2015-12-22 05:56
I hear your plea.  But isn't it almost as easy to just leave it alone?  3.4 won't get many checkins from now on, so it won't actually kick off many tasks.  But it would mean the "check the buildbots" step of making a release would be super easy, rather than the huge pain of requesting a manual build on the buildbots.
msg256844 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2015-12-22 17:04
Well, it clutters up the buildbot web interface with builders that aren't being used.  Our historical pattern has been to deactivate the builders after a release goes into security-fix-only mode.

Zach, would it be practical to just comment them out and then reactivate them when Larry does a release, or would that eliminate the benefit from your point of view?
msg256845 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2015-12-22 17:25
Would pretty much eliminate the benefit; there are currently a few special cases for 3.4 (particularly for the ICC builders, and the XP bot), which could go away.

For the record, the secret undocumented method for running a build on all custom builders is to fill out the third-to-last set of entry boxes (the one that includes a "Repo path" box) on and click the associated 'Force Build' button.  It's really not that hard to request such a build, but I will grant that it's rather inconvenient.

On the other hand, it wouldn't be too hard to just add the branch back without the special cases around release time for a little while, but there may be some expected failures.
msg256846 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2015-12-22 17:33
How about just keeping the stable set configs, minus any from that set that have special cases?  Although if it is just one form submission, maybe we just need to document that in the release manager's guide?
msg256857 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2015-12-22 19:58
I think only keeping some builders would be more complex than any other option.  Here's a patch against pep101 to document the custom builder trick.
msg259945 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2016-02-09 16:43
New changeset 5430f4fd4ca7 by Zachary Ware in branch 'default':
Issue #25848: Add section on running a build on all custom builders
msg259946 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2016-02-09 16:44
I added the note to the devguide instead of pep101, and will be removing the 3.4 builders shortly.
Date User Action Args
2022-04-11 14:58:24adminsetgithub: 70035
2016-02-09 16:44:08zach.waresetstatus: open -> closed
resolution: out of date
messages: + msg259946

stage: resolved
2016-02-09 16:43:34python-devsetnosy: + python-dev
messages: + msg259945
2015-12-22 19:58:04zach.waresetfiles: + pep101_custom_buildbots.diff
keywords: + patch
messages: + msg256857
2015-12-22 17:33:18r.david.murraysetmessages: + msg256846
2015-12-22 17:25:20zach.waresetmessages: + msg256845
2015-12-22 17:04:09r.david.murraysetnosy: + r.david.murray
messages: + msg256844
2015-12-22 05:56:18larrysetmessages: + msg256826
2015-12-21 17:04:27zach.waresetmessages: + msg256803
2015-12-20 03:05:05larrysetpriority: release blocker -> low

messages: + msg256748
2015-12-12 21:02:56steve.dowersetnosy: + loewis
messages: + msg256294
2015-12-12 17:01:12serhiy.storchakacreate