Hi, Yese there will be a 3.10.1+dfsg1-3.
1. I think we should keep for now a pristine /etc/matplotlibrc and tell somehow it's depreciation. And then remove it in Forky. Or maybe convince upstream to look for /etc/matplotlibrc if it's there. (disclaimer: I do use these optional /etc/matplotlibrc , /etc/git... to provision system defaults, maybe other do so) 2. Yes, MPL should be fixed here. The idea to ask people to remove gedit to work around problem looks weird ;-) Greetings Le sam. 12 avr. 2025 à 09:39, Nilesh Patra <nil...@debian.org> a écrit : > > Hi Alex, James, all, > > Seems matplotlib migrated to testing now. I was thinking if it makes sense to > do > an incremental 3.10.1+dfsg1-3 release. > > There are 2 things that bother me that could be fixed in this release: > > 1. matplotlib has historically shipped /etc/matploblibrc to force tkagg and > patched the code > to use this if there are no user defined rc files see [1]. However, this was > not > handled properly via maintscripts so that'd mean over-writing user-modified > /etc/matplotlibrc. > > The backend detection logic is now better and I feel we should get rid of the > "yield '/etc/matplotlibrc'" in > [1] and also stop shipping the conffile both and add in a rm_conffile to > remove previously > installed /etc/matplotlibrc. > > Probably also a d/NEWS to inform the sysadmin that this no longer works. It > does not make > sense to me for a python lib to have a conffile. > > 2. matplotlib fails when there is empty gi directory. This is reported in > #1101565 and James > has kindly provided a patch (thank you!). > > [1] > https://salsa.debian.org/python-team/packages/matplotlib/-/blob/master/debian/patches/20_matplotlibrc_path_search_fix.patch?ref_type=heads > > Please let me know what you think? > > Best, > Nilesh
