There was a cyclic bootstrap relationship between this and ... Pandas (?)
in the Numpy transition that was handled swiftly in the Pandas side
but I thing we are a now far enough in Numpy transition the reopload
3.8 to unstable with the accumulated fixes and start working
on 3.10 for experimental.
[ ... snip ... ]
James : do you want to help ;-) You can merge your own MR if you feel confident.
https://salsa.debian.org/python-team/packages/matplotlib/-/merge_requests/6
[ ... snip ... ]
I've built matplotlib 3.10 from experimental (including the no-PFB
patch from the exp2 upload) successfully and have been able to use
that to rebuild the astropy-doc package; as a result I think I've
found additional sources of nondeterministic documentation output in
the astropy documentation. But I'm happy with that progress, and will
close the matplotlib merge request.
On 23/02/25 05:19, Alexandre Detiste wrote:
There was a cyclic bootstrap relationship between this and ... Pandas (?)
in the Numpy transition that was handled swiftly in the Pandas side
but I thing we are a now far enough in Numpy transition the reopload
3.8 to unstable with the accumulated fixes and start working
on 3.10 for experimental.
I tried to upload the accumulated fixes, did not notice the tests were enabled
and screwed up and had to do multiple uploads -- sorry for that.
I've pushed changes for 3.10.0 to debian/experimental branch on salsa and uploaded
to experimental as well.
On 23/02/25 6:03 pm, Nilesh Patra wrote:
On 23/02/25 05:19, Alexandre Detiste wrote:
There was a cyclic bootstrap relationship between this and ... Pandas (?) >>> in the Numpy transition that was handled swiftly in the Pandas side
but I thing we are a now far enough in Numpy transition the reopload
3.8 to unstable with the accumulated fixes and start working
on 3.10 for experimental.
I tried to upload the accumulated fixes, did not notice the tests were enabled
and screwed up and had to do multiple uploads -- sorry for that.
I've pushed changes for 3.10.0 to debian/experimental branch on salsa and uploaded
to experimental as well.
So a a bunch of things are failing with:
```
ImportError: Cannot load backend 'TkAgg' which requires the 'tk' interactive framework, as 'headless' is currently running
```
I am unsure what it wrong here, and have raised a issue on github. This does not look
like a packaging error to me but please review!
[ ... snip ... ]
@Alexandre or someone else, could you please help w validating the fix or upload a -3
to experimental?
[1] https://github.com/matplotlib/matplotlib/commit/f45707d9e6111a83d2c741530cbff2be2c8005ff
[2] https://github.com/matplotlib/matplotlib/issues/29713
[ ... snip ... ]
@Alexandre or someone else, could you please help w validating the fix or upload a -3
to experimental?
[1] https://github.com/matplotlib/matplotlib/commit/f45707d9e6111a83d2c741530cbff2be2c8005ff
[2] https://github.com/matplotlib/matplotlib/issues/29713
Although we're nearing the trixie release freezes, I think it'd be
better to wait until that commit is merged into matplotlib's mainline >branch(es) before adopting it in Debian - it is the correct commit
hyperlink for the fix, but only exists in a pull request so far.
If it helps, I can offer a merge request on Salsa to add it to the
patch series for 3.10 of src:matplotlib (debian/experimental, I
expect) after the fix is merged upstream. We should probably also
create a bug for the TkAgg import error problem, so that we can
reference it from DEP-3 patch metadata -- despite (hopefully!) not
needing to carry the patch for long.
Hey,
It uses Wayland now ! (or I mean automagically)
I reinstalled the version from testing & checked with xeyes.
New version in experimental feels smoother;
it also open a nice KDE dialog bog here, not something
that looks like tkinter.
That's something to fight for.
I'll check the CI results too.
The list is already much smaller than for the previous version bump.
On 18/03/2025 11:13, Alexandre Detiste wrote:
Le lun. 17 mars 2025 à 03:56, Nilesh Patra <nilesh@riseup.net> a écrit : >>> I will check the pseudo-excuses on britney in around week. Hopefully, this >>> upload should solve majority of issues.pseudo-excuses shows only 5 packages running tests and of them, all 5 packages are failing - I'd rephrase this as 100% of the packages that manually declared python3-matplotlib in Testsuite-Triggers had failing tests.
Only five autopkgtest failing and already two packages fixed !
have tests that actually touch the failing code.When I saw the list yesterday, it showed dozens and dozens of packages running tests. In my previous upload where there
was a bug, I saw around 20 or so packages failing.
There's only 5 there, likely because it is bad display or things that passed do not show up. On that entire page, you
will mostly find packages that are _failing_. It is also not correct (or even believable) that only 5 packages in the whole archive ever
depend on matplotlib for tests given this is a very popular plotting library.
So that statement is incorrect.
hmm, ok, I'm very happy to be incorrect on that. I did check the excuses pages of some other packages and they seemed to show lots of packages that were passing. That's great news.
I'm still quite confident that we're undertesting though - I saw on the developer list for src:sasview that it's not compatible with matplotlib 3.10 and yet no flags from any tests are coming up. Like many uses of matplotlib, it probably doesn't even
cheers
Stuart
Le lun. 17 mars 2025 à 03:56, Nilesh Patra <nilesh@riseup.net> a écrit :
I will check the pseudo-excuses on britney in around week. Hopefully, this >> upload should solve majority of issues.
Only five autopkgtest failing and already two packages fixed !
Can we ask $someone to rebuild everything from unstable that
depends on matplotlib against this new version ?
(to see what fails)
I might remember there was a free-service instance available
somewhere but wouldn't mind some hand-holding.
Le lun. 17 mars 2025 à 03:56, Nilesh Patra <nilesh@riseup.net> a écrit :
I will check the pseudo-excuses on britney in around week. Hopefully, this >> upload should solve majority of issues.
Only five autopkgtest failing and already two packages fixed !
On 18 March 2025 5:43:41 am IST, Alexandre Detiste <alexandre.detiste@gmail.com> wrote:
Le lun. 17 mars 2025 à 03:56, Nilesh Patra <nilesh@riseup.net> a écrit : >>> I will check the pseudo-excuses on britney in around week. Hopefully, this >>> upload should solve majority of issues.
Only five autopkgtest failing and already two packages fixed !
I cleaned up 2 more. Now there is only one mdanalysis remaining which hangs on arm64 but works fine on amd64.
On a brief look, it does not really look related to matplotlib.
It could be great to try it out with current matplotlib on arm64 in debci like environment. If it hangs, we can just file a bug report.
I don't have the spoons for this at the moment :-/
[ ... snip ... ]
On 19/03/25 2:11 am, Nilesh Patra wrote:
On 18 March 2025 5:43:41 am IST, Alexandre Detiste <alexandre.detiste@gmail.com> wrote:
[ ... snip ... ]
I cleaned up 2 more. Now there is only one mdanalysis remaining which hangs on arm64 but works fine on amd64.
On a brief look, it does not really look related to matplotlib.
It could be great to try it out with current matplotlib on arm64 in debci like environment. If it hangs, we can just file a bug report.
I don't have the spoons for this at the moment :-/
The timeout looks unrelated to matplotlib, I however still did not manage to find
time to actually test this. Haven't heard back regarding rebuilding reverse-build dependencies
as well.
If this looks not feasible, should we drop the idea of releasing 3.10.1 for trixie?
Sorry for not replying earlier. I see that you uploaded matplotlib 3.10
to unstable in the meantime. I did a rebuild of unstable two days ago,
and did not notice anything specific related to matplotlib.
The build failures involving matplotlib are:
graph-tool_2.91+ds-4_unstable.log
healpy_1.18.0-1_unstable.log
pandas_2.2.3+dfsg-8_unstable.log
python-csb43_0.10.1+dfsg-1_unstable.log
python-maggma_0.70.0-3_unstable.log
python-mne_1.9.0-1_unstable.log
pytroll-schedule_0.7.2-2_unstable.log
sphinx-copybutton_0.5.2-2_unstable.log
xarray-sentinel_0.9.5+ds-3_unstable.log
(those are not necessarily caused by matplotlib changes)
You can find the relevant logs at http://qa-logs.debian.net/2025/03/27/
Best,
Lucas
On 18 March 2025 5:43:41 am IST, Alexandre Detiste <alexandre.detiste@gmail.com> wrote:
Le lun. 17 mars 2025 à 03:56, Nilesh Patra <nilesh@riseup.net> a écrit : >> I will check the pseudo-excuses on britney in around week. Hopefully, this >> upload should solve majority of issues.
Only five autopkgtest failing and already two packages fixed !
Can we ask $someone to rebuild everything from unstable that
depends on matplotlib against this new version ?
(to see what fails)
Since there is no as such ABI for this, which other modules use, so it won't be a transition per se as far as I understand.
Otherwise it won't be possible to do right now since we are in toolchain freeze.
But it does make sense to test the reverse build depends at least at the this (pre-release) stage, to avoid FTBFS bugs as much as possible.
I might remember there was a free-service instance available
somewhere but wouldn't mind some hand-holding.
I do not have such resources to do massive rebuilds like these.
I am adding Lucas to the thread. Lucas, do you think you could help us here?
[ ... snip ... ]
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.
In a later step we could discard unmodified config files based on a list of md5sum of what shipped in stable release.
So only users of default settings would get the new default settings.
On Sat, 12 Apr 2025 at 18:18, Alexandre Detiste
<alexandre.detiste@gmail.com> wrote:
In a later step we could discard unmodified config files based on a list of md5sum of what shipped in stable release.
So only users of default settings would get the new default settings.
Ok; and it seems the relevant query term / name for this situation is "obsolete conffile".
There's a useful writeup about conffile handling in general -
including that style of md5-based removal - on the wiki at: https://wiki.debian.org/DpkgConffileHandling
Responding to the first point only, at the moment:
On Sat, 12 Apr 2025 at 07:39, Nilesh Patra <nilesh@debian.org> wrote:
[ ... snip ... ]
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.
Ah; what is the problem related to the maintscripts?
The /etc/matplotlibrc file is considered a config file by apt/dpkg (it
is not removed unless a purge is requested), so I was hoping that
shipping a default/unmodified matplotlibrc in an updated 3.10 upload
(as Alex suggests in his thread) would provide a useful additional >conflict-resolution step for anyone who has modified theirs.
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.
I don't have a strong opinion about this part, although when in
sysadmin mode, I do tend to go looking in /etc first to find config
files.
On the other hand, we wouldn't be the first package to read config
files from elsewhere on the filesystem - pipewire springs to mind as
another case where default config files are located under /usr/share,
for example.
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.
+1 to a NEWS entry. I'm not so sure about removing the conffile
entirely yet, though. I think it may be safer to treat it as a
feature deprecation, allowing time for feedback about any use cases
that seem to require it and/or for users to migrate to alternatives.
Regards,
James
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 493 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 08:09:39 |
| Calls: | 9,710 |
| Files: | 13,740 |
| Messages: | 6,181,286 |