New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test_ttk test_compound, test_tk test_type fail with Tk 8.6.11.1 #87305
Comments
====================================================================== Traceback (most recent call last):
File "/build/python/src/Python-3.9.1/Lib/tkinter/test/test_ttk/test_widgets.py", line 173, in test_compound
self.checkEnumParam(widget, 'compound',
File "/build/python/src/Python-3.9.1/Lib/tkinter/test/widget_tests.py", line 152, in checkEnumParam
self.checkInvalidParam(widget, name, '',
File "/build/python/src/Python-3.9.1/Lib/tkinter/test/widget_tests.py", line 75, in checkInvalidParam
widget[name] = value
AssertionError: TclError not raised ===================================================================== Traceback (most recent call last):
File "/build/python/src/Python-3.9.1/Lib/tkinter/test/test_tkinter/test_widgets.py", line 1245, in test_type
self.checkEnumParam(widget, 'type',
File "/build/python/src/Python-3.9.1/Lib/tkinter/test/widget_tests.py", line 152, in checkEnumParam
self.checkInvalidParam(widget, name, '',
File "/build/python/src/Python-3.9.1/Lib/tkinter/test/widget_tests.py", line 75, in checkInvalidParam
widget[name] = value
AssertionError: TclError not raised |
When system? It appears to be some *nix. Is this a buildbot? |
It's Arch Linux x86_64 with system tcl/tk. It's build in a clean chroot for packaging and always reproducible. |
See also bpo-45436: test_tk.test_configure_type() failed on x86 Gentoo Non-Debug with X 3.x. |
Felix, are these still the exact errors you're experiencing? Both in my normal Arch install and in a chroot environment I get the following errors instead: ====================================================================== Traceback (most recent call last):
File "/cpython/Lib/tkinter/test/test_tkinter/test_misc.py", line 213, in test_winfo_rgb
self.assertEqual(rgb('#4a3c8c'), (0x4a4a, 0x3c3c, 0x8c8c))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: Tuples differ: (19016, 15399, 35985) != (19018, 15420, 35980) First differing element 0:
+ (19018, 15420, 35980) ====================================================================== Traceback (most recent call last):
File "/cpython/Lib/tkinter/test/test_tkinter/test_widgets.py", line 1244, in test_configure_type
self.checkEnumParam(widget, 'type',
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/cpython/Lib/tkinter/test/widget_tests.py", line 151, in checkEnumParam
self.checkInvalidParam(widget, name, '',
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/cpython/Lib/tkinter/test/widget_tests.py", line 73, in checkInvalidParam
with self.assertRaises(tkinter.TclError) as cm:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: TclError not raised In case I'm doing something stupid, here are the commands I used to set-up the chroot environment: $ CHROOT=chroot
$ mkdir $CHROOT
$ mkarchroot $CHROOT/root base-devel tk git gnu-free-fonts
$ xhost + local:
$ sudo mount --bind $CHROOT/root $CHROOT/root
$ sudo arch-chroot $CHROOT/root
> git clone https://github.com/python/cpython.git
> cd cpython
> ./configure && make -j24
> ./python -m test -v -u gui test_tk I'll start looking into these errors, since I'm able to reproduce them. |
TL;DR I believe these are both Tk issues. I will take it up with them when I have time. Starting with I also believe the problem with |
In Paine's failing color test, the returned tuple is The returned tuple is (0x4a48, 0x3c27, 0x8c91) versus (0x4a4a, 0x3c3c, 0x8c91), which is to say, nearly correct. Since the tested call is The preceding assert, which passed, is I looked at the color man page. It says "When fewer than 16 bits are provided for each color, they represent the most significant bits of the color, while the lower unfilled bits will be repeatedly replicated from the available higher bits. For example, #3a7 is the same as #3333aaaa7777." This is 4 bits to 16. It does not give an example for 8 or 12 to 16 and this might allow some wiggle room. Other text indicates some fuzziness in exact colors. "Tk_AllocColorFromObj returns a pointer to an XColor structure; the structure indicates the exact intensities of the allocated color (which may differ slightly from those requested, depending on the limitations of the screen)" Perhaps this screen-specific behavior is happening here. Also, "They allow colors to be shared whenever possible, so that colormap space is preserved, and they pick closest available colors when colormap space is exhausted. " Could this happen here? test_winfo_rgb has multiple asserts. If this one is commented out, do the rest pass? |
See PR 6578. We already faced a similar problem when test_winfo_rgb was added. We finally found test colors which behave consistently on all tested platforms. But it turns out that not on all. |
There is something non-trivial about this test failure. I have now tested another computer with a very similar setup (Plasma on X11) with exactly the same monitor (both using HDMI) and it passed this test. The only notable difference is one computer is using Intel integrated graphics while the other is Nvidia.
No. The test for #dede14143939 also fails:
--- I've opened bpo-45496 for this test failure so we can focus on the |
Closing as a duplicate of bpo-45436; fixes to the tests were committed with that issue number. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: