> /etc/matplotlibrc.
We have another example:
pip reads /etc/pip.conf and it's really useful to document there
what the company proxy is named.
So reverting the old patched /etc/matplotlibrc to upstream
pristine config was a first step in right direction;
I agree it should be removed later.
I
On 12 April 2025 6:18:20 pm IST, James Addison wrote:
>Hi Nilesh, Alex,
>
>Responding to the first point only, at the moment:
>
>On Sat, 12 Apr 2025 at 07:39, Nilesh Patra wrote:
>> [ ... snip ... ]
>> 1. matplotlib has historically shipped /etc/matploblibrc to force tkagg and
>> patched the cod
On Sat, 12 Apr 2025 at 20:37, James Addison wrote:
>
> On Sat, 12 Apr 2025 at 18:18, Alexandre Detiste
> 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 th
On Sat, 12 Apr 2025 at 18:18, Alexandre Detiste
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 /
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.
I ve started updating debian/README.Debian
Greetings
Le sam. 12 avr. 2025, 14:48, James Addison a écrit :
Hi Nilesh, Alex,
Responding to the first point only, at the moment:
On Sat, 12 Apr 2025 at 07:39, Nilesh Patra 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].
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/matplotlib
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
Thank you !
Le dim. 30 mars 2025 à 13:32, Nilesh Patra a écrit :
> > python-maggma_0.70.0-3_unstable.log
>
> Failure due to missing dependencies
> (pyproject_hooks._impl.BackendUnavailable: Cannot import
> 'setuptools.build_meta')
+ python3-setuptools easy to fix, only wondering why it didn't
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 ma
Hi,
On 18/03/25 at 10:11 +0530, Nilesh Patra wrote:
> On 18 March 2025 5:43:41 am IST, Alexandre Detiste
> wrote:
> >Le lun. 17 mars 2025 à 03:56, Nilesh Patra a écrit :
> >> I will check the pseudo-excuses on britney in around week. Hopefully, this
> >> upload should solve majority of issues.
Hi,
On Sat, 22 Mar 2025 at 19:08, Nilesh Patra wrote:
> [ ... snip ... ]
> On 19/03/25 2:11 am, Nilesh Patra wrote:
> > On 18 March 2025 5:43:41 am IST, Alexandre Detiste
> > wrote:
> > [ ... snip ... ]
> > I cleaned up 2 more. Now there is only one mdanalysis remaining which hangs
> > on arm6
On 19/03/25 2:11 am, Nilesh Patra wrote:
> On 18 March 2025 5:43:41 am IST, Alexandre Detiste
> wrote:
>> Le lun. 17 mars 2025 à 03:56, Nilesh Patra a écrit :
>>> I will check the pseudo-excuses on britney in around week. Hopefully, this
>>> upload should solve majority of issues.
>>
>> Only
On 18 March 2025 5:43:41 am IST, Alexandre Detiste
wrote:
>Le lun. 17 mars 2025 à 03:56, Nilesh Patra 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
wrote:
>Le lun. 17 mars 2025 à 03:56, Nilesh Patra 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/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
n
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 a écrit :
I will check the pseudo-excuses on britney in around week. Hopefully, this
upload should solve majority of issues.
Only five autopkgtest
Hi Nilesh
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
On 18/03/2025 11:13, Alexandre Detiste wrote:
Le lun. 17 mars 2025 à 03:56, Nilesh Patra 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-excuse
Le lun. 17 mars 2025 à 03:56, Nilesh Patra 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
On 17 March 2025 3:01:31 am IST, Alexandre Detiste
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
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 t
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
Hi James,
On 13 March 2025 4:05:04 am IST, James Addison wrote:
>On Tue, 11 Mar 2025 at 13:15, Nilesh Patra 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/matp
On Tue, 11 Mar 2025 at 13:15, Nilesh Patra 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://githu
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
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 transit
On Sun, 23 Feb 2025 at 18:24, James Addison 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 sou
On Sat, 22 Feb 2025 at 23:49, Alexandre Detiste
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 li
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 fi
Hi Alexandre
But 3.8 does not even build most of the days
Trying rerun the Salsa CI does not help because log is too long and truncated.
The full log from salsaci is available in the artifacts section of the
project on salsa:
https://salsa.debian.org/python-team/packages/matplotlib/-/ar
On Mon, Jul 22, 2024 at 11:40:23AM +0200, Alexandre Detiste wrote:
> Hi Nilesh,
>
> I joined Astro team and took care of matplotlib rdeps there.
>
> I'm struggling with basemap... I don't understand how
> this multi-package with it's 3 setup.py works.
> It's the very last rdpeps that will block m
On Wed, Mar 20, 2024 at 10:32:04AM +0900, ciel wrote:
> Alexandre-san,
>
> Sorry, it seems like I cannot contribute this because (at least) I'm
> pretty not sure if I can transplant this line properly:
>
> ```
> ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))
> echo "backend : TkAgg" > ma
Alexandre-san,
Sorry, it seems like I cannot contribute this because (at least) I'm
pretty not sure if I can transplant this line properly:
```
ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))
echo "backend : TkAgg" > matplotlibrc
```
Ciel.
2024年3月19日(火) 19:02 Alexandre Detiste :
>
> If
> Now, I am tempted to create a package matplotlib3 instead of forcing
please dont. the right course of action is:
- fork src:matplotlib2 from src:matplotlib to only provide the python2 package
- update src:matplotlib to upstream 3.x to provide only py3k modules
(and since there was also a discus
Quoting Steffen Möller :
Now, I am tempted to create a package matplotlib3 instead of forcing
everyone to update from this long term release (see
https://matplotlib.org/).
Any opinions from your sides?
I wonder, whether it's easier to wait for buster and then create an
orange backport? I'm
On Tue, 16 Oct 2018 at 22:11, wrote:
> On Tue, 2018-10-16 at 11:45 +0300, Arto Jantunen wrote:
> > ghisv...@gmail.com writes:
> > > Don't get me wrong, I am all in favour for a modern stack,
> > > including
> > > Python 3.
> > >
> > > However, upgrading NumPy et al. to their Python 3 only version
ghisv...@gmail.com writes:
> On Tue, 2018-10-16 at 11:45 +0300, Arto Jantunen wrote:
>> ghisv...@gmail.com writes:
>> > Don't get me wrong, I am all in favour for a modern stack,
>> > including
>> > Python 3.
>> >
>> > However, upgrading NumPy et al. to their Python 3 only versions,
>> > introduc
On Tue, 2018-10-16 at 11:45 +0300, Arto Jantunen wrote:
> ghisv...@gmail.com writes:
> > Don't get me wrong, I am all in favour for a modern stack,
> > including
> > Python 3.
> >
> > However, upgrading NumPy et al. to their Python 3 only versions,
> > introducing new legacy packages for Python 2,
On Tue, 2018-10-16 at 10:42 +0200, Steffen Möller wrote:
> > > Let me ask you this: where is the rush to package this machine
> > > learning
> > > library? Could it wait after the Buster release cycle, where we
> > > might
> > > be in a more comfortable position to upgrade matplotlib?
> > The short
ghisv...@gmail.com writes:
> Don't get me wrong, I am all in favour for a modern stack, including
> Python 3.
>
> However, upgrading NumPy et al. to their Python 3 only versions,
> introducing new legacy packages for Python 2, and patching the large
> collection of packages relying on the Python 2
Let me ask you this: where is the rush to package this machine learning
library? Could it wait after the Buster release cycle, where we might
be in a more comfortable position to upgrade matplotlib?
The short answer is yes. The almost as short one is "Conda has it
already, use that". The sligh
On Tue, 2018-10-16 at 10:16 +0200, Steffen Möller wrote:
> Hi Ghis,
>
> On 16.10.18 08:30, ghisv...@gmail.com wrote:
> > On Mon, 2018-10-15 at 22:44 +0200, Steffen Möller wrote:
> > > Hello,
> > >
> > > I am keeping me busy packaging the Orange machine learning
> > > library
> > > that
> > > seem
Hi Ghis,
On 16.10.18 08:30, ghisv...@gmail.com wrote:
On Mon, 2018-10-15 at 22:44 +0200, Steffen Möller wrote:
Hello,
I am keeping me busy packaging the Orange machine learning library
that
seems nice (https://orange.biolab.si/#Orange-Features). Now, the
test
routines demand a matplotlib.pyplo
On Tue, 2018-10-16 at 09:38 +0200, Ole Streicher wrote:
> ghisv...@gmail.com writes:
> > Indeed. Note that NumPy has already published plans to become
> > Python 3
> > only in the near future, so the deprecation of Python 2 in the
> > scientific stack will happen eventually.
> >
> > I just don't t
ghisv...@gmail.com writes:
> Indeed. Note that NumPy has already published plans to become Python 3
> only in the near future, so the deprecation of Python 2 in the
> scientific stack will happen eventually.
>
> I just don't think it should be rushed into the Buster release cycle.
If we really wan
On Tue, 2018-10-16 at 09:00 +0200, Andreas Tille wrote:
> On Tue, Oct 16, 2018 at 07:55:40AM +0100, ghisv...@gmail.com wrote:
> > > > I suppose the main module is still named "matplotlib" not
> > > > "matplotlib3" in version 3 onwards? So using python3-
> > > > matplotlib3
> > > > would
> > > > be
On Tue, Oct 16, 2018 at 07:55:40AM +0100, ghisv...@gmail.com wrote:
> > > I suppose the main module is still named "matplotlib" not
> > > "matplotlib3" in version 3 onwards? So using python3-matplotlib3
> > > would
> > > be a breach of policy.
> >
> > Probably.
>
> Described in Section 2.2 of th
On Tue, 2018-10-16 at 08:46 +0200, Andreas Tille wrote:
> On Tue, Oct 16, 2018 at 07:30:55AM +0100, ghisv...@gmail.com wrote:
> > > Any opinions from your sides?
> >
> > How is that going to work without creating package conflicts?
> >
> > I suppose the main module is still named "matplotlib" no
On Tue, Oct 16, 2018 at 07:30:55AM +0100, ghisv...@gmail.com wrote:
> > Any opinions from your sides?
>
> How is that going to work without creating package conflicts?
>
> I suppose the main module is still named "matplotlib" not
> "matplotlib3" in version 3 onwards? So using python3-matplotlib3
On Mon, 2018-10-15 at 22:44 +0200, Steffen Möller wrote:
> Hello,
>
> I am keeping me busy packaging the Orange machine learning library
> that
> seems nice (https://orange.biolab.si/#Orange-Features). Now, the
> test
> routines demand a matplotlib.pyplot module that is not in version 2
> that
51 matches
Mail list logo
