It looks like that test is explicitly setting tkagg as the backend but we are not detecting that there is a usable x11 or wayland session.

The fix is to either to not force a GUI backend or provide a graphical environment in the container.

It looks like that test is explicitly setting tkagg as the backend but we are not detecting that there is a usable x11 or wayland session.

No, that's not the case. I cloned the repo in question, and tried to (case insensitive) grep for TkAgg and found no results. Another example is:

https://ci.debian.net/packages/b/bmtk/unstable/amd64/58413274/

and the corresponding repo https://github.com/AllenInstitute/bmtk

Given that the same version worked fine with matplotlib 3.8.3 in the same environment, I suppose this would be a regression w the new version.

I'm not certain yet, but I think there is a case-sensitivity mismatch at the following location that has a change-in-behaviour between v3.8.3 and v3.10.0:

When testing those versions comparatively in Debian containers, I find the backend_fallback value unchanged (True for both), and the default-or-none backend value to be TkAgg for both -- but the set is either:

{'GTK3Agg', 'TkCairo', 'GTK4Cairo', 'TkAgg', 'Qt5Agg', 'QtCairo', 'Qt5Cairo', 'MacOSX', 'WXCairo', 'QtAgg', 'GTK4Agg', 'GTK3Cairo', 'WX', 'WXAgg'}

or

{'gtk3cairo', 'tkcairo', 'notebook', 'qtagg', 'wx', 'gtk4cairo', 'qt5agg', 'qt5cairo', 'wxagg', 'gtk4agg', 'gtk3agg', 'macosx', 'qtcairo', 'wxcairo', 'tkagg'}

(hence a different comparison result -- and hence a different rcParams["backend"] value; either the default sentinel or not; which then causes a difference in backend selection/switch during the tests)

I'm not certain yet, but I think there is a case-sensitivity mismatch at the following location that has a change-in-behaviour between v3.8.3 and v3.10.0:

I've opened #29721 with a minimal repro that I've used to confirm this, and also a fix that I've tested locally. Unit test coverage is not yet provided.

An alternative approach would be to rename some of the internal backend identifiers in registry.py (e.g. the keys in _BUILTIN_BACKEND_TO_GUI_FRAMEWORK).

Ping @ianthomas23

It looks like that test is explicitly setting tkagg as the backend but we are not detecting that there is a usable x11 or wayland session.

No, that's not the case. I cloned the repo in question, and tried to (case insensitive) grep for TkAgg and found no results. Another example is:

@nileshpatra aha; I think I might have uncovered the place where the TkAgg backend is selected; it's in a config file, so code searching the source package contents wouldn't find it. The relevant line that sets the config entry is, I believe: https://salsa.debian.org/python-team/packages/matplotlib/-/blob/da997760e5fc43739b5f49ebba633d1de2b40e77/debian/rules#L62

It looks like that test is explicitly setting tkagg as the backend but we are not detecting that there is a usable x11 or wayland session.

No, that's not the case. I cloned the repo in question, and tried to (case insensitive) grep for TkAgg and found no results. Another example is:

@nileshpatra aha; I think I might have uncovered the place where the TkAgg backend is selected; it's in a config file, so code searching the source package contents wouldn't find it. The relevant line that sets the config entry is, I believe: https://salsa.debian.org/python-team/packages/matplotlib/-/blob/da997760e5fc43739b5f49ebba633d1de2b40e77/debian/rules#L62

Hi @jayaddison thanks for your work on this. However, even version 3.8.3 had the same line, cf: https://sources.debian.org/src/matplotlib/3.8.3-7/debian/rules/#L58

Even all versions before that also had the same line, see https://sources.debian.org/src/matplotlib/3.6.3-1/debian/rules/#L156

But I did not see autopkgtest failing then 😅

@jayaddison This is the log with bmtk version 1.1.1+ds-4 with matplotlib 3.8.3-7 https://ci.debian.net/packages/b/bmtk/unstable/amd64/58714318/

and this is with 3.10.0 https://ci.debian.net/packages/b/bmtk/unstable/amd64/58555849/

The test_plot_traces tests fail with new version and the same thing was working w an older version.

This is the diff b/w older matplotlibrc and newer one, if this helps. I wonder if there's a change in the handling of backend in newer version?

--- /tmp/old/etc/matplotlibrc	2025-02-23 11:17:22.000000000 +0000
+++ etc/matplotlibrc	2025-02-23 13:42:55.000000000 +0000
@@ -148,8 +148,14 @@
 ## for more information on patch properties.
 #patch.linewidth:       1.0    # edge width in points.
 #patch.facecolor:       C0
-#patch.edgecolor:       black  # if forced, or patch is not filled
-#patch.force_edgecolor: False  # True to always use edgecolor
+#patch.edgecolor:       black  # By default, Patches and Collections do not draw edges.
+                               # This value is only used if facecolor is "none"
+                               # (an Artist without facecolor and edgecolor would be
+                               # invisible)  or if patch.force_edgecolor is True.
+#patch.force_edgecolor: False  # By default, Patches and Collections do not draw edges.
+                               # Set this to True to draw edges with patch.edgedcolor
+                               # as the default edgecolor.
+                               # This is mainly relevant for styles.
 #patch.antialiased:     True   # render patches in antialiased (no jaggies)
 
 
@@ -425,13 +431,19 @@
 #axes.autolimit_mode: data  # If "data", use axes.xmargin and axes.ymargin as is.
                             # If "round_numbers", after application of margins, axis
                             # limits are further expanded to the nearest "round" number.
-#polaraxes.grid: True  # display grid on polar axes
-#axes3d.grid:    True  # display grid on 3D axes
+#polaraxes.grid:    True   # display grid on polar axes
+#axes3d.grid:       True   # display grid on 3D axes
+#axes3d.automargin: False  # automatically add margin when manually setting 3D axis limits
 
 #axes3d.xaxis.panecolor:    (0.95, 0.95, 0.95, 0.5)  # background pane on 3D axes
 #axes3d.yaxis.panecolor:    (0.90, 0.90, 0.90, 0.5)  # background pane on 3D axes
 #axes3d.zaxis.panecolor:    (0.925, 0.925, 0.925, 0.5)  # background pane on 3D axes
 
+#axes3d.mouserotationstyle: arcball  # {azel, trackball, sphere, arcball}
+                            # See also https://matplotlib.org/stable/api/toolkits/mplot3d/view_angles.html#rotation-with-mouse
+#axes3d.trackballsize: 0.667  # trackball diameter, in units of the Axes bbox
+#axes3d.trackballborder: 0.2  # trackball border width, in units of the Axes bbox (only for 'sphere' and 'arcball' style)
+
 ## ***************************************************************************
 ## * AXIS                                                                    *
 ## ***************************************************************************
@@ -601,7 +613,8 @@
 ## * IMAGES                                                                  *
 ## ***************************************************************************
 #image.aspect:          equal        # {equal, auto} or a number
-#image.interpolation:   antialiased  # see help(imshow) for options
+#image.interpolation:   auto         # see help(imshow) for options
+#image.interpolation_stage: auto     # see help(imshow) for options
 #image.cmap:            viridis      # A colormap name (plasma, magma, etc.)
 #image.lut:             256          # the size of the colormap lookup table
 #image.origin:          upper        # {lower, upper}
@@ -668,14 +681,14 @@
 #path.snap: True  # When True, rectilinear axis-aligned paths will be snapped
                   # to the nearest pixel when certain criteria are met.
                   # When False, paths will never be snapped.
-#path.sketch: None  # May be None, or a 3-tuple of the form:
-                    # (scale, length, randomness).
-                    #     - *scale* is the amplitude of the wiggle
-                    #         perpendicular to the line (in pixels).
-                    #     - *length* is the length of the wiggle along the
-                    #         line (in pixels).
-                    #     - *randomness* is the factor by which the length is
-                    #         randomly scaled.
+#path.sketch: None  # May be None, or a tuple of the form:
+                    #  path.sketch: (scale, length, randomness)
+                    # - *scale* is the amplitude of the wiggle
+                    #    perpendicular to the line (in pixels).
+                    # - *length* is the length of the wiggle along the
+                    #    line (in pixels).
+                    # - *randomness* is the factor by which the length is
+                    #    randomly scaled.
 #path.effects:
 
 
@@ -733,6 +746,8 @@
                          #     None: Assume fonts are installed on the
                          #           machine where the SVG will be viewed.
 #svg.hashsalt: None      # If not None, use this string as hash salt instead of uuid4
+#svg.id: None            # If not None, use this string as the value for the `id`
+                         # attribute in the top <svg> tag
 
 ### pgf parameter
 ## See https://matplotlib.org/stable/tutorials/text/pgf.html for more information.

I think there are three things that should be done here:

1. debian should drop setting the backend, the auto-backend selection logic is much better now and they should stop forcing tkagg
2. we have a bug in the "the user asked for a GUI backend but we can not give them a GUI but we will be forgiving" logic that looks like @jayaddison has proposed a fix for. Previously this test was relying on one configuration that told us to ignore another configuration which is less than ideal.
3. in the failing tests you can use the MPLBACKEND=agg ENV to override the matplotlibrc and force to a backend that does not require x11

While this has exposed a bug, I think it has been been latent for a while because most packagers have stopped forcing the default backend.

The fastest way out of this problem is 3. If the "we" in the OP is debian then you should definitely do 1. We will also fix the bug, but I do not think it is the sort of bug that would drive an emergency release as there are multiple ways (that are technically better!) to avoid the problem.

I think there are three things that should be done here:

1. debian should drop setting the backend, the auto-backend selection logic is much better now and they should stop forcing tkagg

I tend to agree -- I am actually confused as to why this was ever needed.

I took this package over from the previous maintainer recently and this was left unchanged until now.
When I actually tried to look at the original point at which this was introduced, I see this:

From matplotlib version 0.98.3-6 the default backend in Debian is 'TkAgg', the
simplest backend available in most context.

If you want to change it, you have two ways: system wide, changing the file

  /etc/matplotlibrc

or on a user basis, changing the file

  $HOME/.config/matplotlib/matplotlibrc

All I can guess is that things used to work differently in this very old version. There's also an associated patch with this: https://sources.debian.org/src/matplotlib/3.8.3-7/debian/patches/20_matplotlibrc_path_search_fix.patch/

And it likely makes sense to keep it for now, due to distro-specific location of those paths.

2. we have a bug in the "the user asked for a GUI backend but we can not give them a GUI but we will be forgiving" logic that looks like @jayaddison has proposed a fix for. Previously this test was relying on one configuration that told us to ignore another configuration which is less than ideal.
3. in the failing tests you can use the MPLBACKEND=agg ENV to override the matplotlibrc and force to a backend that does not require x11

While this has exposed a bug, I think it has been been latent for a while because most packagers have stopped forcing the default backend.

I see.

The fastest way out of this problem is 3. If the "we" in the OP is debian then you should definitely do 1. We will also fix the bug, but I do not think it is the sort of bug that would drive an emergency release as there are multiple ways (that are technically better!) to avoid the problem.

I can always incorporate a patch in debian and make a release, no need for you (upstream) to cut a release immediately :)

I think you can drop just the sed -i ... line and things will work.

Yes, I understood that -- I'll give that a try on Sunday afternoon. Meanwhile it'd also be good to get 2. fixed, it could be nice to cherry-pick that as a patch. Thanks again!

This issue has closed because of PR #29721 fixing the Matplotlib bug. Feel free to reopen if there is more to discuss.