======================================================================
FAIL: test_compound (tkinter.test.test_ttk.test_widgets.ButtonTest)
----------------------------------------------------------------------
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

=====================================================================
FAIL: test_type (tkinter.test.test_tkinter.test_widgets.MenuTest)
----------------------------------------------------------------------
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?
Whose tcl/tk?  Distributed with system or locally compiled?

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:

======================================================================
FAIL: test_winfo_rgb (tkinter.test.test_tkinter.test_misc.MiscTest)
----------------------------------------------------------------------
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:
19016
19018

- (19016, 15399, 35985)
?      ^    ^^^      ^

+ (19018, 15420, 35980)
?      ^    ^^^      ^


======================================================================
FAIL: test_configure_type (tkinter.test.test_tkinter.test_widgets.MenuTest)
----------------------------------------------------------------------
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 `test_winfo_rgb`, it is not the case that the expected behaviour is no longer that #4a3c8c is equivalent to #4a4a3c3c8c8c since this is documented on the man page (https://www.tcl.tk/man/tcl/TkLib/GetColor.html#M8). I need to do more research into exactly what versions / platforms are effected.

I also believe the problem with `test_configure_type` is on the Tk end, since `[menu .m] configure -type {}` succeeds despite not being documented on the man page (https://www.tcl.tk/man/tcl8.4/TkCmd/menu.html#M13) nor in the "bad type" message:
% [menu .m] configure -type a 
bad type "a": must be normal, tearoff, or menubar

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 
  self._getints(self.tk.call('winfo', 'rgb', self._w, color))
either ._getints is buggy on this particular system (seems very unlikely), or root.tk.call is doing something flakey on this particular system (ditto), or the result is entirely the responsibility of tcl/tk and the test is too severe, testing tk, not our _tkinter/tkinter.

The preceding assert, which passed, is
  self.assertEqual(rgb('#F0F'), (0xFFFF, 0x0000, 0xFFFF))
Since the should that the call basically works, is the more detailed test needed for testing tkinter?

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.

> I need to do more research into exactly what versions / platforms are affected.

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.

> If this one is commented out, do the rest pass?

No. The test for #dede14143939 also fails:
- (57050, 5122, 14630)
+ (57054, 5140, 14649)

---

I've opened #45496 for this test failure so we can focus on the `AssertionError`s originally reported in this issue.

Closing as a duplicate of bpo-45436; fixes to the tests were committed with that issue number.