• Matplotlib 3.10.0 for trixie?

    From Nilesh Patra@21:1/5 to All on Sun Feb 16 08:00:01 2025
    Hi all, Hi Alexandre,

    There's approximately 2 months of time still for soft freeze. I believe we
    have enough time for a matplotlib update (and transition to testing).

    Should we go for it? I will try to spend some hours tonight to see how much work this may be.

    Thanks,
    Nilesh

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nilesh Patra@21:1/5 to Alexandre Detiste on Sun Feb 23 14:00:01 2025
    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.

    Best,Thanks
    Nilesh

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From James Addison@21:1/5 to alexandre.detiste@gmail.com on Sun Feb 23 19:50:01 2025
    On Sat, 22 Feb 2025 at 23:49, Alexandre Detiste
    <alexandre.detiste@gmail.com> wrote:
    [ ... 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

    Thank you, Alexandre and Nilesh! I think my MR seems likely to be
    obsoleted by the matplotlib 3.10 packaging -- and also that's a cleaner/preferable option rather than carrying a backported patch.

    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.

    Regards,
    James

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From James Addison@21:1/5 to James Addison on Sun Feb 23 20:50:02 2025
    On Sun, 23 Feb 2025 at 18:24, James Addison <jay@jp-hosting.net> wrote:
    [ ... 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.

    Well, the reason for those unexpected findings was that I was
    rebuilding the wrong package; that should have been a rebuild of
    astroplan-doc instead of astropy-doc.

    So, the good news: with matplotlib 3.10.0+dfsg1-1~exp2 from
    experimental, and some small configuration tweaks[1], I've been able
    to rebuild astroplan-doc reproducibly using a naive build-twice
    approach. Additional rebuilds/variance may find other problems, but
    that was a nice result even so.

    [1] - https://salsa.debian.org/debian-astro-team/astroplan/-/merge_requests/2

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nilesh Patra@21:1/5 to Nilesh Patra on Thu Mar 6 18:00:01 2025
    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!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nilesh Patra@21:1/5 to Nilesh Patra on Tue Mar 11 14:40:01 2025
    Hi,

    On 06/03/25 10:07 pm, Nilesh Patra wrote:


    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!

    Jay was very kind to investigate here and supplied w a patch[1] and a PR [2].

    Unfortunately, I do not have the environment to repro this reliably, nor have my
    yubikey to actually upload this to experimental.

    @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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From James Addison@21:1/5 to Nilesh Patra on Thu Mar 13 00:00:01 2025
    On Tue, 11 Mar 2025 at 13:15, Nilesh Patra <nilesh@debian.org> wrote:
    [ ... 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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nilesh Patra@21:1/5 to James Addison on Thu Mar 13 00:20:01 2025
    Hi James,

    On 13 March 2025 4:05:04 am IST, James Addison <jay@jp-hosting.net> wrote: >On Tue, 11 Mar 2025 at 13:15, Nilesh Patra <nilesh@debian.org> wrote:
    [ ... 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.

    ACK. I hope this gets merged soonish. For now we do have another immediate fix.

    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.

    Thanks a lot. I was planning to update to 3.10.1 (only a patch release).
    There is no need for you to raise merge requests, since this is a team maintained package, feel free to directly push.

    And I'd be glad if you add yourself as an uploader for this package if you are interested, but no pressure!


    Best,
    Nilesh

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nilesh Patra@21:1/5 to All on Sun Mar 16 16:10:01 2025
    Quick update: Uploaded matplotlib 3.10.1 with Jay's patch and a fix
    to not set backend to Tkagg system-wide (in /etc/matplotlibrc).

    I will check the pseudo-excuses on britney in around week. Hopefully, this upload should solve majority of issues.

    Thanks,
    Nilesh

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nilesh Patra@21:1/5 to Alexandre Detiste on Mon Mar 17 04:20:01 2025
    On 17 March 2025 3:01:31 am IST, Alexandre Detiste <alexandre.detiste@gmail.com> wrote:
    Hey,

    It uses Wayland now ! (or I mean automagically)

    In all previous versions, the Tkagg backend was being forced in /etc/matplotlibrc.

    I removed that enforcing in this upload and let matplotlib do the work of selecting appropriate backend.


    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.

    Thanks!

    The list is already much smaller than for the previous version bump.



    Best,
    Nilesh

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nilesh Patra@21:1/5 to Stuart Prescott on Tue Mar 18 08:00:01 2025
    Hi Stuart,

    On 18/03/25 12:01, Stuart Prescott wrote:


    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.

    Only five autopkgtest failing and already two packages fixed !
    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.

    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.

    Thanks,
    Nilesh

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nilesh Patra@21:1/5 to Stuart Prescott on Tue Mar 18 10:10:01 2025
    On 18/03/25 12:19, Stuart Prescott wrote:
    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
    have tests that actually touch the failing code.

    Realistically, testing reverse-dependencies and reverse-build-dependencies (for which I asked Lucas in another mail) is the maximum we can do here, otherwise we can never make a release :)

    Do you have some suggestions to get this moving in a better way?

    With regards to sasview, is the mail publically archived somewhere? The matplotlib version uploaded is a minor release here, with few deprecation and removal
    of few APIs, replacements for which are readily available. If even after fixing those, if sasview does not work, I'd be quite surprised!

    cheers
    Stuart

    Best,
    Nilesh

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nilesh Patra@21:1/5 to Alexandre Detiste on Tue Mar 18 12:10:01 2025
    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?

    (Ofcourse the service is not free :-))



    Best,
    Nilesh

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nilesh Patra@21:1/5 to Alexandre Detiste on Tue Mar 18 22:00:02 2025
    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 :-/



    Best,
    Nilesh

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nilesh Patra@21:1/5 to Nilesh Patra on Sat Mar 22 20:30:01 2025
    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:
    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 :-/

    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From James Addison@21:1/5 to Nilesh Patra on Sun Mar 23 13:30:01 2025
    Hi,

    On Sat, 22 Mar 2025 at 19:08, Nilesh Patra <nilesh@debian.org> wrote:
    [ ... 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?

    My sense from inspecting the ci.debian.net results for mdanalysis is
    also that the timeout is unrelated to the matplotlib-3.10 update --
    the same timeout (at approximately 2 hours and 50 minutes) seems to
    occur regardless of whether the exp/mpl-3.10 package is pinned into
    the build -- and in fact, checking again now, the timeout failure
    seems to occur for both amd64 and arm64. I wonder if it is a
    particular test case that sometimes gets stuck.

    In theory, I'd like to say: let's do the upgrade if we can -- I think
    users would generally be happy to have a (much) fresher version
    available, and although there's an effort/energy cost to upgrading,
    that effort cost could also potentially increase if we delay the
    upgrade to a later date...

    ...however: I'm not a Debian maintainer/developer (nor deb-python team
    member), only an eager contributor. I do intend to become a Debian
    project member at some point (possibly after improving my email
    etiquette and finding a more suitable laptop), but until then I can't
    really promise to contribute much assistance, so my opinions on this
    should be taken with a grain of salt!

    Cheers,
    James

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nilesh Patra@21:1/5 to Lucas Nussbaum on Sun Mar 30 13:50:01 2025
    Hi Lucas,

    On 30/03/25 1:35 pm, Lucas Nussbaum wrote:
    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

    This is due to compilation failure of c++ source

    healpy_1.18.0-1_unstable.log

    FTBFS due to patches being improperly applied (local changes detected)

    pandas_2.2.3+dfsg-8_unstable.log

    Known failure, fix pushed to unstable

    python-csb43_0.10.1+dfsg-1_unstable.log

    FTBFS due to patches being improperly applied (local changes detected)

    python-maggma_0.70.0-3_unstable.log

    Failure due to missing dependencies (pyproject_hooks._impl.BackendUnavailable: Cannot import 'setuptools.build_meta')

    python-mne_1.9.0-1_unstable.log

    Same failure as in #1100273 (reported march 12)

    pytroll-schedule_0.7.2-2_unstable.log

    Skimming through the code, it does not look related to matplotlib but would be nice if someone
    can double-check.

    sphinx-copybutton_0.5.2-2_unstable.log

    Dependency issue [Extension error (pydata_sphinx_theme)]

    xarray-sentinel_0.9.5+ds-3_unstable.log

    I don't see any build/runtime dep on matplotlib and even grepping through the code, it is not used.

    (those are not necessarily caused by matplotlib changes)

    It seems all failures are unrelated to matplotlib.

    You can find the relevant logs at http://qa-logs.debian.net/2025/03/27/

    Thank you very very very much for helping with this! :)

    Best,

    Lucas

    Best,
    Nilesh

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lucas Nussbaum@21:1/5 to Nilesh Patra on Sun Mar 30 10:30:01 2025
    Hi,

    On 18/03/25 at 10:11 +0530, Nilesh Patra wrote:
    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?

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nilesh Patra@21:1/5 to All on Sat Apr 12 10:00:01 2025
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From James Addison@21:1/5 to Nilesh Patra on Sat Apr 12 15:10:01 2025
    Hi Nilesh, Alex,

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From James Addison@21:1/5 to alexandre.detiste@gmail.com on Sat Apr 12 23:00:01 2025
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From James Addison@21:1/5 to James Addison on Sat Apr 12 23:40:01 2025
    On Sat, 12 Apr 2025 at 20:37, James Addison <jay@jp-hosting.net> wrote:

    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

    ...and also note: much of the guidance on that page has been
    superseded by functionality in dpkg; it may still be useful as
    history/context, but the current workflows are documented in: https://manpages.debian.org/unstable/dpkg/dpkg-maintscript-helper.1.en.html

    (apologies if I'm duplicating things you both already know.. I'm
    trying to get a grasp for what options the current tooling provides
    for this)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nilesh Patra@21:1/5 to James Addison on Sun Apr 13 00:40:01 2025
    On 12 April 2025 6:18:20 pm IST, James Addison <jay@jp-hosting.net> wrote: >Hi Nilesh, Alex,

    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.

    I usually had to mention such files it in d/conffiles.

    I now tried to unpack control.tar.xz of python3-matplotlib-data and saw it there regardless.
    Seems dh is doing its magic so I suppose my concern quoted above is invalid.

    Regardless, it makes sense to still do a -3 upload.

    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.

    Right. But, pipewire is much more than a python library that is intended to be consumed by other python applications and/or end user as a part of their code.

    It makes sense to have binaries, command line utilities even gui apps to have a conffile in /etc. But it looks weird for a python library to have one especially when the practical benefits are not great.

    I really doubt if any sysadmin takes the time to edit /etc/matplotlibrc. But yes this should be targeting forky release instead.

    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.

    ACK.

    Regards,
    James


    Best,
    Nilesh

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)