Re: matplotlib
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" > matplotlibrc > ``` This doesn't need to be translated, but can be used as is. -- WBR, wRAR signature.asc Description: PGP signature
Re: matplotlib
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 you have the time/will, > > I would suggest to overhaul build to from 7 to new debhelper 13 > with the automagic "%: dh $@" rule. > > Almost all other Python projects have already been converted. > > wc -l */debian/rules > 29 lincity-ng/debian/rules > 25 lmfit-py/debian/rules > 21 logbook/debian/rules > 28 logilab-constraint/debian/rules > 35 love/debian/rules > 21 ltris/debian/rules > 15 lua-lpeg/debian/rules > 13 magic-wormhole/debian/rules >206 matplotlib/debian/rules > 14 mdp/debian/rules > 18 microsoft-authentication-library-for-python/debian/rules > 56 minetest/debian/rules > 13 mir-eval/debian/rules > 12 mrrescue/debian/rules > 18 mu-cade/debian/rules
matplotlib
If you have the time/will, I would suggest to overhaul build to from 7 to new debhelper 13 with the automagic "%: dh $@" rule. Almost all other Python projects have already been converted. wc -l */debian/rules 29 lincity-ng/debian/rules 25 lmfit-py/debian/rules 21 logbook/debian/rules 28 logilab-constraint/debian/rules 35 love/debian/rules 21 ltris/debian/rules 15 lua-lpeg/debian/rules 13 magic-wormhole/debian/rules 206 matplotlib/debian/rules 14 mdp/debian/rules 18 microsoft-authentication-library-for-python/debian/rules 56 minetest/debian/rules 13 mir-eval/debian/rules 12 mrrescue/debian/rules 18 mu-cade/debian/rules
Bug#1004960: ITP: cmyt -- Matplotlib colormaps from the yt project
Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org, debian-as...@lists.debian.org, debian-scie...@lists.debian.org * Package name: cmyt Version : 1.0.4 Upstream Author : Clement Robert * URL : https://github.com/yt-project/cmyt * License : BSD-3-Clause Programming Lang: Python Description : Matplotlib colormaps from the yt project cmyt integrates with matplotlib in a similar fashion to cmocean or cmasher It is a new build dependency of the "yt" package. I will maintain it within the Debian Python team. Salsa dir is https://salsa.debian.org/python-team/packages/cmyt Best regards Ole
Bug#998234: ITP: mpl-animators: An interative animation framework for matplotlib
Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org, debian-as...@lists.debian.org * Package name: mpl-animators Version : 1.0.0 Upstream Author : Sunpy Developers * URL : https://github.com/sunpy/mpl-animators * License : BSD-3-Clause Programming Lang: Python Description : An interative animation framework for matplotlib The mpl_animators package provides a set of classes which allow the easy construction of interactive matplotlib widget based animations. “Out of the box” classes are provided for making line or image plots from numpy arrays, with sliders to control the animation automatically added for all dimensions not on the axes of the plot. It is a new build dependency of the sunpy and ndcube packages. I will maintain it within the Debian Astro team in Salsa: https://salsa.debian.org/debian-astro-team/mpl-animators Best regards Ole
Bug#959968: RFS: mplcursors/0.3-1 [ITP] -- Interactive data selection cursors for Matplotlib
Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: debian-python@lists.debian.org Dear mentors, I am looking for a sponsor for my package "mplcursors" * Package name: mplcursors Version : 0.3-1 Upstream Author : Antony Lee * URL : https://github.com/anntzer/mplcursors * License : MIT * Vcs : https://salsa.debian.org/sudip/mplcursors Section : python It builds those binary packages: python3-mplcursors - Interactive data selection cursors for Matplotlib To access further information about this package, please visit the following URL: https://mentors.debian.net/package/mplcursors Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/m/mplcursors/mplcursors_0.3-1.dsc Changes since the last upload: * Initial release (Closes: #959870) Note: This is my first attempt at python package and so I have added debian-python@l.d.o in X-Debbugs-CC with the hope that someone from the python team will check this and point out my mistakes (if any). -- Regards Sudip
Re: Matplotlib 3.0 - update ok?
> 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 discussion about numpy) - make src:python-numpy provide only python2 package - fork src:numpy from src:python-numpy to provide only python3 modules. since i'm the maintainer of both matplotlib and numpy, i'll take care of these "transitions" -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
Re: Matplotlib 3.0 - update ok?
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 sure, immediately after release, we (= Python teams) will start to drop Python 2 support anyway. In the mean time new versions of matplotlib and friends, as well as orange, might be suitable for experimental, so that your packaging work doesn't need to wait. Orange looks very interesting and is a welcome addition to Debian, btw.!
Re: Matplotlib 3.0 - update ok?
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 versions, > > > introducing new legacy packages for Python 2, and patching the > > > large > > > collection of packages relying on the Python 2 versions of these > > > sounds > > > like a lot of work for the time we have got left in the Buster > > > release > > > cycle. > > > > In my understanding there is no need to patch any of the reverse > > dependencies. Currently there are binary packages called python-numpy > > and python3-numpy, built from a source package called python-numpy. > > In > > my understanding the proposed change is to keep having the exact same > > binary packages, just built from two different source packages > > (python-numpy and python-numpy-legacy or whatever). > > Oh, I see what you mean. > > So you'd have: > > - src:python-numpy-legacy providing python-numpy (<2.0) only > - src:python-numpy providing python3-numpy (>=2.0) only > This sort of thing has already happened for astroid, src:astroid builds python3-astroid 2.0.4-2 and src:astroid2 builds python-astroid 1.6.5-2 (and something similar for pylint). Cheers, mwh
Re: Matplotlib 3.0 - update ok?
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, >> > introducing new legacy packages for Python 2, and patching the >> > large >> > collection of packages relying on the Python 2 versions of these >> > sounds >> > like a lot of work for the time we have got left in the Buster >> > release >> > cycle. >> >> In my understanding there is no need to patch any of the reverse >> dependencies. Currently there are binary packages called python-numpy >> and python3-numpy, built from a source package called python-numpy. >> In >> my understanding the proposed change is to keep having the exact same >> binary packages, just built from two different source packages >> (python-numpy and python-numpy-legacy or whatever). > > Oh, I see what you mean. > > So you'd have: > > - src:python-numpy-legacy providing python-numpy (<2.0) only > - src:python-numpy providing python3-numpy (>=2.0) only > > Assuming version 2 is when the split happens. > > Am I correct? Yeah, this would be my understanding of the plan. Things could get more complex if the same split needs to happen at many levels of the stack (a library that uses numpy is only compatible with numpy <2.0, followed by another one on the next level down). -- Arto Jantunen
Re: Matplotlib 3.0 - update ok?
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, and patching the > > large > > collection of packages relying on the Python 2 versions of these > > sounds > > like a lot of work for the time we have got left in the Buster > > release > > cycle. > > In my understanding there is no need to patch any of the reverse > dependencies. Currently there are binary packages called python-numpy > and python3-numpy, built from a source package called python-numpy. > In > my understanding the proposed change is to keep having the exact same > binary packages, just built from two different source packages > (python-numpy and python-numpy-legacy or whatever). Oh, I see what you mean. So you'd have: - src:python-numpy-legacy providing python-numpy (<2.0) only - src:python-numpy providing python3-numpy (>=2.0) only Assuming version 2 is when the split happens. Am I correct? Ghis
Re: Matplotlib 3.0 - update ok?
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 answer is yes. The almost as short one is "Conda has it > > already, use that". The slightly longer answer is that I don't > > think > > that this is the right thing for Debian to do. We are then shipping > > an > > old version of matplotlib, i.e. oldstable, with a new release of > > our > > distribution. I do also think that that long-term support version 2 > > of > > matplotlib should remain in our distribution. So we would need to > > find > > a way to support two versions for the same distribution. > > Kind of answering myself - I do not see a rush, either. I was just > positively surprised about Orange and would like many users to share > that experience with Buster - not two years later. Looking at their release history [1], the upstream release cadence is once a month. Assuming the freeze takes about three months to complete (quite optimisticly), will upstream be interested in feedback and bug reports from 3 releases ago? Maybe. What about a year later? That would be 15 releases ago. I am not too sure about it. They'll just ask you to use Anaconda [2], which is the very first entry in their installation instructions. Don't you think? [1] https://pypi.org/project/Orange3/#history [2] https://orange.biolab.si/download/ Cheers, Ghis
Re: Matplotlib 3.0 - update ok?
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 versions of these sounds > like a lot of work for the time we have got left in the Buster release > cycle. In my understanding there is no need to patch any of the reverse dependencies. Currently there are binary packages called python-numpy and python3-numpy, built from a source package called python-numpy. In my understanding the proposed change is to keep having the exact same binary packages, just built from two different source packages (python-numpy and python-numpy-legacy or whatever). -- Arto Jantunen
Re: Matplotlib 3.0 - update ok?
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 slightly longer answer is that I don't think that this is the right thing for Debian to do. We are then shipping an old version of matplotlib, i.e. oldstable, with a new release of our distribution. I do also think that that long-term support version 2 of matplotlib should remain in our distribution. So we would need to find a way to support two versions for the same distribution. Kind of answering myself - I do not see a rush, either. I was just positively surprised about Orange and would like many users to share that experience with Buster - not two years later. How deep is the Python Policy wrt package naming set in stone? Wrt to the renaming that Andreas suggested - I would be prepared to work through renames of matlibtools to matlibtools2 in all those source trees that are incompatible with version 3. Cheers, Steffen
Re: Matplotlib 3.0 - update ok?
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 > > > seems nice (https://orange.biolab.si/#Orange-Features). Now, the > > > test > > > routines demand a matplotlib.pyplot module that is not in version > > > 2 > > > that > > > we feature. Version 3 is the current stable release. > > Ack. Thank you for explaining the context. > > > > > 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? > > 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 > > would > > be a breach of policy. > Yes. We would need to freely interpret that policy in analogy to > Debian > libraries e.g. for C/C++ or Java. I am not quite sure which interpretation you are refering to in this case. Back to the Debian Python policy, the wording in section 2.2 uses "should" instead of "must", so there is room for discussion in exceptional circumstances I guess. > > 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. There you go. > The almost as short one is "Conda has it already, use that". Even better. Or use a virtual environment. Which the majority of developers do (one or the other). > The slightly longer answer is that I don't think > that this is the right thing for Debian to do. We are then shipping > an > old version of matplotlib, i.e. oldstable, with a new release of our > distribution. "Old" indeed, but still actively maintained upstream. > I do also think that that long-term support version 2 of > matplotlib should remain in our distribution. So we would need to > find a > way to support two versions for the same distribution. I'll ask the same question again: besides your ITP for Orange, is there anything *already* in the archive in desparate need for an upgrade of matplotlib to its new major release? If not, figuring out a way to support both versions can be postponed to the next release cycle, imo. I don't see where the rush would be. There is already enough on our plates as far as RC bugs are concerned. I have already spoken quite a bit, so I'll let others in the team give their opinions. Cheers, Ghis
Re: Matplotlib 3.0 - update ok?
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.pyplot module that is not in version 2 that we feature. Version 3 is the current stable release. Ack. Thank you for explaining the context. 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? 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 would be a breach of policy. Yes. We would need to freely interpret that policy in analogy to Debian libraries e.g. for C/C++ or Java. 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 slightly longer answer is that I don't think that this is the right thing for Debian to do. We are then shipping an old version of matplotlib, i.e. oldstable, with a new release of our distribution. I do also think that that long-term support version 2 of matplotlib should remain in our distribution. So we would need to find a way to support two versions for the same distribution. Cheers, Steffen
Re: Matplotlib 3.0 - update ok?
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 think it should be rushed into the Buster release > > cycle. > > If we really want to then have a Python-2-numpy, why can't there be a > separate Python-2 legacy numpy source package? I do the same for > astropy. Who is "we"? I never said that personally. > Holding back normal updates especially for science packages just > because > we don't want to use a modern numpy/scipy/matplotlib stack is not > really > friendly to our users, which (in science) rely on at least "somehow" > modern software. And astropy that is more than a 1.5 years old > already > at the release of Buster would not be accepted by the users, and > patching it to use an older sw stack is also impractical. Afaik, matplotlib v2.x is under an LTS release scheme, so I don't think we are holding anything back. Same rationales for IPython, for which we maintain packages for the v5.x LTS releases instead of tracking v6.x. > > Even when we /still/ support Python 2, our focus and preference > should > be clearly Python 3. 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 versions of these sounds like a lot of work for the time we have got left in the Buster release cycle. Let me ask you this: besides Steffen's ITP, is there anything urgently calling for an upgrade of the scientific stack to something newer than the LTS versions? Where urgently implies fixing RC bugs impeding the Buster release. Maybe there are. If not, where is the rush really? Ghis
Re: Matplotlib 3.0 - update ok?
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 want to then have a Python-2-numpy, why can't there be a separate Python-2 legacy numpy source package? I do the same for astropy. Holding back normal updates especially for science packages just because we don't want to use a modern numpy/scipy/matplotlib stack is not really friendly to our users, which (in science) rely on at least "somehow" modern software. And astropy that is more than a 1.5 years old already at the release of Buster would not be accepted by the users, and patching it to use an older sw stack is also impractical. Even when we /still/ support Python 2, our focus and preference should be clearly Python 3. Best regards Ole
Re: Matplotlib 3.0 - update ok?
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 a breach of policy. > > > > > > Probably. > > > > Described in Section 2.2 of the Debian Python policy. > > Depending how heavy Steffen would volunteer to patch and also rename > the > module (which I would not consider a very sensible idea). Which means future packages depending on matplotlib v3+ would have to be manually patched to account for the renaming. Sounds impractical to me. > > > I'm not sure what might be the difference between: > > > > > >3.0.0 Stable version > > >2.2.3 LTS LTS version > > > > > > We have some months left until freeze so may be right now it is > > > not > > > to > > > late to package what upstream considers stable. > > > > > > Kind regards > > > > > > Andreas. > > > From the upstream homepage: "Matplotlib 3.0 is Python 3 only." > > > > Afaik, Python 2 is still considered relevant for the Buster release > > cycle. Hence why I am suggesting to wait for the next release cycle > > before upgrading key scientific packages, such as matplotlib, to > > Python > > 3 only. > > Right. This would surely kick several scientific packages. > > Kind regards > > Andreas. 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. Ghis
Re: Matplotlib 3.0 - update ok?
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 the Debian Python policy. Depending how heavy Steffen would volunteer to patch and also rename the module (which I would not consider a very sensible idea). > > I'm not sure what might be the difference between: > > > >3.0.0 Stable version > >2.2.3 LTS LTS version > > > > We have some months left until freeze so may be right now it is not > > to > > late to package what upstream considers stable. > > > > Kind regards > > > > Andreas. > > > >From the upstream homepage: "Matplotlib 3.0 is Python 3 only." > > Afaik, Python 2 is still considered relevant for the Buster release > cycle. Hence why I am suggesting to wait for the next release cycle > before upgrading key scientific packages, such as matplotlib, to Python > 3 only. Right. This would surely kick several scientific packages. Kind regards Andreas. -- http://fam-tille.de
Re: Matplotlib 3.0 - update ok?
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" not > > "matplotlib3" in version 3 onwards? So using python3-matplotlib3 > > would > > be a breach of policy. > > Probably. Described in Section 2.2 of the Debian Python policy. > > 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? > > I'm not sure what might be the difference between: > >3.0.0 Stable version >2.2.3 LTS LTS version > > We have some months left until freeze so may be right now it is not > to > late to package what upstream considers stable. > > Kind regards > > Andreas. >From the upstream homepage: "Matplotlib 3.0 is Python 3 only." Afaik, Python 2 is still considered relevant for the Buster release cycle. Hence why I am suggesting to wait for the next release cycle before upgrading key scientific packages, such as matplotlib, to Python 3 only. Cheers, Ghis
Re: Matplotlib 3.0 - update ok?
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 would > be a breach of policy. Probably. > 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? I'm not sure what might be the difference between: 3.0.0 Stable version 2.2.3 LTS LTS version We have some months left until freeze so may be right now it is not to late to package what upstream considers stable. Kind regards Andreas. -- http://fam-tille.de
Re: Matplotlib 3.0 - update ok?
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 > we feature. Version 3 is the current stable release. Ack. Thank you for explaining the context. > 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? 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 would be a breach of policy. 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? Cheers, Ghis
Matplotlib 3.0 - update ok?
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 we feature. Version 3 is the current stable release. 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? Cheers, Steffen
Re: Bug#902516: python-matplotlib-venn: FTBFS in buster/sid (failing tests)
On Thursday, 5 July 2018 08:09:50 AEST Andreas Tille wrote: > Control: tags -1 help > > Hi, > > I can confirm this problem in a pbuilder environment. Unfortunately I > have no idea about the cause of the issue nor how to fix it. Any hint > from the Debian Python team? Looks a lot like at least some of the tests are failing with: https://wiki.debian.org/ContinuousIntegration/TriagingTips/numpy-1.14-doctests cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
[Help] Re: Bug#902516: python-matplotlib-venn: FTBFS in buster/sid (failing tests)
Control: tags -1 help
Hi,
I can confirm this problem in a pbuilder environment. Unfortunately I
have no idea about the cause of the issue nor how to fix it. Any hint
from the Debian Python team?
Kind regards
Andreas.
On Wed, Jun 27, 2018 at 12:50:32PM +, Santiago Vila wrote:
> Package: src:python-matplotlib-venn
> Version: 0.11.5-4
> Severity: serious
> Tags: ftbfs
>
> Dear maintainer:
>
> I tried to build this package in buster with "dpkg-buildpackage -A"
> but it failed:
>
>
> [...]
> debian/rules build-indep
> dh build-indep --with python2,python3 --buildsystem=pybuild
>dh_update_autotools_config -i -O--buildsystem=pybuild
>dh_autoreconf -i -O--buildsystem=pybuild
>dh_auto_configure -i -O--buildsystem=pybuild
> pybuild --configure --test-pytest -i python{version} -p 2.7
> I: pybuild base:217: python2.7 setup.py config
> running config
> pybuild --configure --test-pytest -i python{version} -p 3.6
> I: pybuild base:217: python3.6 setup.py config
> running config
>dh_auto_build -i -O--buildsystem=pybuild
> pybuild --build --test-pytest -i python{version} -p 2.7
>
> [... snipped ...]
>
> File "/usr/lib/python2.7/dist-packages/_pytest/main.py", line 719, in
> _perform_collect
> self.items.extend(self.genitems(node))
> File "/usr/lib/python2.7/dist-packages/_pytest/main.py", line 860, in
> genitems
> rep = collect_one_node(node)
> File "/usr/lib/python2.7/dist-packages/_pytest/runner.py", line 502, in
> collect_one_node
> rep = ihook.pytest_make_collect_report(collector=collector)
> File "/usr/lib/python2.7/dist-packages/pluggy/__init__.py", line 617, in
> __call__
> return self._hookexec(self, self._nonwrappers + self._wrappers, kwargs)
> File "/usr/lib/python2.7/dist-packages/pluggy/__init__.py", line 222, in
> _hookexec
> return self._inner_hookexec(hook, methods, kwargs)
> File "/usr/lib/python2.7/dist-packages/pluggy/__init__.py", line 216, in
>
> firstresult=hook.spec_opts.get('firstresult'),
> File "/usr/lib/python2.7/dist-packages/pluggy/callers.py", line 180, in
> _multicall
> res = hook_impl.function(*args)
> File "/usr/lib/python2.7/dist-packages/_pytest/runner.py", line 369, in
> pytest_make_collect_report
> 'collect')
> File "/usr/lib/python2.7/dist-packages/_pytest/runner.py", line 189, in
> __init__
> self.result = func()
> File "/usr/lib/python2.7/dist-packages/_pytest/runner.py", line 368, in
>
> lambda: list(collector.collect()),
> File "/usr/lib/python2.7/dist-packages/_pytest/doctest.py", line 217, in
> collect
> module = self.fspath.pyimport()
> File "/usr/lib/python2.7/dist-packages/py/_path/local.py", line 668, in
> pyimport
> __import__(modname)
> File
> "/<>/.pybuild/cpython2_2.7_matplotlib-venn/build/matplotlib_venn/__init__.py",
> line 55, in
> from matplotlib_venn._venn2 import venn2, venn2_circles
> File
> "/<>/.pybuild/cpython2_2.7_matplotlib-venn/build/matplotlib_venn/_venn2.py",
> line 22, in
> from matplotlib.pyplot import gca
> File "/usr/lib/python2.7/dist-packages/matplotlib/pyplot.py", line 71, in
>
> from matplotlib.backends import pylab_setup
> File "/usr/lib/python2.7/dist-packages/matplotlib/backends/__init__.py",
> line 16, in
> line for line in traceback.format_stack()
>
>
> '''
>
> -- Docs: http://doc.pytest.org/en/latest/warnings.html
> === 15 failed, 34 passed, 3 warnings in 0.60 seconds
> ===
> E: pybuild pybuild:336: test: plugin distutils failed with: exit code=1: cd
> /<>/.pybuild/cpython2_2.7_matplotlib-venn/build; python2.7 -m
> pytest
> dh_auto_test: pybuild --test --test-pytest -i python{version} -p 2.7 returned
> exit code 13
> debian/rules:10: recipe for target 'override_dh_auto_test' failed
> make[1]: *** [override_dh_auto_test] Error 25
> make[1]: Leaving directory '/<>'
> debian/rules:7: recipe for target 'build-indep' failed
> make: *** [build-indep] Error 2
> dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit
> status 2
>
>
> The above is how the build ends in my autobuilder and it's not
> necessarily the relevant part.
>
> The failure is not, however, related to using dpkg-buildpackag
Re: Suspected change in test dependencies - where is "discover" (Was: [Help] Re: Bug#884040: python-matplotlib-venn FTBFS: test failure)
On Fri, Dec 15, 2017 at 05:22:09PM +0200, Juhani Numminen wrote:
>
> In debian/rules, are the arguments to dh_auto_test still needed? The error
> went
> away when I removed said arguments, like so:
>
> override_dh_auto_test:
> xvfb-run --auto-servernum --server-args="-screen 0 1024x768x24" \
> -dh_auto_test -- --test --system=custom --test-args='cp -a README.rst
> {home_dir}/build && cd {home_dir}/build && {interpreter} $(CURDIR)/setup.py
> test && rm README.rst'
> +dh_auto_test
Thanks a lot, that's it. Very helpful!
Andreas.
--
http://fam-tille.de
Re: Suspected change in test dependencies - where is "discover" (Was: [Help] Re: Bug#884040: python-matplotlib-venn FTBFS: test failure)
Andreas Tille kirjoitti 12.12.2017 klo 17:10:
> Hi again,
>
> On Mon, Dec 11, 2017 at 09:27:57AM +0100, Andreas Tille wrote:
>>
>> On Sun, Dec 10, 2017 at 09:05:07PM +0200, Adrian Bunk wrote:
>>> === warnings summary
>>> ===
>>> None
>>> [pytest] section in setup.cfg files is deprecated, use [tool:pytest]
>>> instead.
>>
>> I've fixed this in Git[1]
>>
>>> -- Docs: http://doc.pytest.org/en/latest/warnings.html
>>> == 1 warnings in 0.00 seconds
>>> ==
>>> ERROR: file not found: discover
>>
>
> I tried to build on local host (not in a pbuilder chroot) and than this
> issue does not occure. Seems I need to add a new Build-Depends for
> whatever reason. Any hint which one? I parsed the package pool for
> anything Python related containing a file "discover" / "discover.py" but
> besides many hits there was no real helpful one.
Hello,
In debian/rules, are the arguments to dh_auto_test still needed? The error went
away when I removed said arguments, like so:
override_dh_auto_test:
xvfb-run --auto-servernum --server-args="-screen 0 1024x768x24" \
-dh_auto_test -- --test --system=custom --test-args='cp -a README.rst
{home_dir}/build && cd {home_dir}/build && {interpreter} $(CURDIR)/setup.py
test && rm README.rst'
+dh_auto_test
Regards,
Juhani
Suspected change in test dependencies - where is "discover" (Was: [Help] Re: Bug#884040: python-matplotlib-venn FTBFS: test failure)
Hi again, On Mon, Dec 11, 2017 at 09:27:57AM +0100, Andreas Tille wrote: > > On Sun, Dec 10, 2017 at 09:05:07PM +0200, Adrian Bunk wrote: > > === warnings summary > > === > > None > > [pytest] section in setup.cfg files is deprecated, use [tool:pytest] > > instead. > > I've fixed this in Git[1] > > > -- Docs: http://doc.pytest.org/en/latest/warnings.html > > == 1 warnings in 0.00 seconds > > == > > ERROR: file not found: discover > I tried to build on local host (not in a pbuilder chroot) and than this issue does not occure. Seems I need to add a new Build-Depends for whatever reason. Any hint which one? I parsed the package pool for anything Python related containing a file "discover" / "discover.py" but besides many hits there was no real helpful one. Kind regards Andreas. -- http://fam-tille.de
[Help] Re: Bug#884040: python-matplotlib-venn FTBFS: test failure
control: tags -1 help
Hi,
On Sun, Dec 10, 2017 at 09:05:07PM +0200, Adrian Bunk wrote:
> === warnings summary
> ===
> None
> [pytest] section in setup.cfg files is deprecated, use [tool:pytest]
> instead.
I've fixed this in Git[1]
> -- Docs: http://doc.pytest.org/en/latest/warnings.html
> == 1 warnings in 0.00 seconds
> ==
> ERROR: file not found: discover
But this seems to be the real issue.
> E: pybuild pybuild:283: test: plugin custom failed with: exit code=4: cp -a
> README.rst
> /build/1st/python-matplotlib-venn-0.11.5/.pybuild/pythonX.Y_2.7/build && cd
> /build/1st/python-matplotlib-venn-0.11.5/.pybuild/pythonX.Y_2.7/build &&
> python2.7 /build/1st/python-matplotlib-venn-0.11.5/setup.py test && rm
> README.rst
> dh_auto_test: pybuild --test --test-pytest -i python{version} -p 2.7 --test
> --system=custom "--test-args=cp -a README.rst {home_dir}/build && cd
> {home_dir}/build && {interpreter}
> /build/1st/python-matplotlib-venn-0.11.5/setup.py test && rm README.rst"
> returned exit code 13
Any hint how to fix this?
Kind regards
Andreas.
[1]
https://anonscm.debian.org/cgit/debian-med/python-matplotlib-venn.git/tree/debian/patches/fix_build_time_test.patch
--
http://fam-tille.de
Re: Bug#813782: python-matplotlib-venn: FTBFS: [failed test] Intersection with the arc along the same circle (which means infinitely many points usually) is reported as no intersection at all.
I can't reproduce the bug (apparently it's architecture- or machine-specific), but it is
indeed due to rounding errors. I modified the test to address this problem and hopefully
it fixes it.
The updated code is in in github as well as pypi.
Best regards,
Konstantin.
On 13.02.2016 8:01, Andreas Tille wrote:
Hi,
as you can read below, one test of the test suite fails. As far as I
can see it is possibly a rounding issue rather than a failure. I wonder
how the test could be tweaked to pass successfully if you share my
opinion or what else could be done to pass the test suite successfully.
Kind regards
Andreas.
On Fri, Feb 05, 2016 at 09:37:32AM +0100, Chris Lamb wrote:
Source: python-matplotlib-venn
Version: 0.11-2
Severity: serious
Dear Maintainer,
python-matplotlib-venn fails to build from source in unstable/amd64:
[..]
running test
running egg_info
creating matplotlib_venn.egg-info
writing requirements to matplotlib_venn.egg-info/requires.txt
writing matplotlib_venn.egg-info/PKG-INFO
writing top-level names to matplotlib_venn.egg-info/top_level.txt
writing dependency_links to matplotlib_venn.egg-info/dependency_links.txt
writing manifest file 'matplotlib_venn.egg-info/SOURCES.txt'
warning: manifest_maker: standard file 'setup.py' not found
reading manifest file 'matplotlib_venn.egg-info/SOURCES.txt'
writing manifest file 'matplotlib_venn.egg-info/SOURCES.txt'
running build_ext
= test session starts
==
platform linux2 -- Python 2.7.11, pytest-2.8.5, py-1.4.31, pluggy-0.3.1 --
/usr/bin/python2.7
cachedir: ../../../.cache
rootdir:
/home/lamby/temp/cdt.20160205085405.L1EHTA93Fx/python-matplotlib-venn-0.11,
inifile: setup.cfg
collecting ... collected 49 items
matplotlib_venn/_arc.py::matplotlib_venn._arc.Arc.__init__ PASSED
matplotlib_venn/_arc.py::matplotlib_venn._arc.Arc.angle_as_point PASSED
...
matplotlib_venn/_venn3.py::matplotlib_venn._venn3.venn3 PASSED
matplotlib_venn/_venn3.py::matplotlib_venn._venn3.venn3_circles PASSED
=== FAILURES
===
___ [doctest] matplotlib_venn._arc.Arc.intersect_arc
___
339 Intersection with the arc along the same circle (which means
infinitely many points usually) is reported as no intersection at all.
340
341 >>> a = Arc((0, 0), 1, -90, 90, True)
342 >>> a.intersect_arc(Arc((1, 0), 1, 90, 270, True))
343 [array([ 0.5 , -0.866...]), array([ 0.5 , 0.866...])]
344 >>> a.intersect_arc(Arc((1, 0), 1, 90, 180, True))
345 [array([ 0.5 , 0.866...])]
346 >>> a.intersect_arc(Arc((1, 0), 1, 121, 239, True))
347 []
348 >>> a.intersect_arc(Arc((1, 0), 1, 120, 240, True))
Expected:
[array([ 0.5 , -0.866...]), array([ 0.5 , 0.866...])]
Got:
[array([ 0.5 , 0.8660254])]
/home/lamby/temp/cdt.20160205085405.L1EHTA93Fx/python-matplotlib-venn-0.11/.pybuild/pythonX.Y_2.7/build/matplotlib_venn/_arc.py:348:
DocTestFailure
= 1 failed, 48 passed in 0.51 seconds
==
E: pybuild pybuild:274: test: plugin custom failed with: exit code=1: cp -a README.rst
/home/lamby/temp/cdt.20160205085405.L1EHTA93Fx/python-matplotlib-venn-0.11/.pybuild/pythonX.Y_2.7/build
&& cd
/home/lamby/temp/cdt.20160205085405.L1EHTA93Fx/python-matplotlib-venn-0.11/.pybuild/pythonX.Y_2.7/build
&& python2.7
/home/lamby/temp/cdt.20160205085405.L1EHTA93Fx/python-matplotlib-venn-0.11/setup.py test && rm
README.rst
dh_auto_test: pybuild --test --test-pytest -i python{version} -p 2.7 --test --system=custom
--test-args=cp -a README.rst {home_dir}/build && cd {home_dir}/build && {interpreter}
/home/lamby/temp/cdt.20160205085405.L1EHTA93Fx/python-matplotlib-venn-0.11/setup.py test && rm
README.rst --dir . returned exit code 13
Re: Bug#813782: python-matplotlib-venn: FTBFS: [failed test] Intersection with the arc along the same circle (which means infinitely many points usually) is reported as no intersection at all.
Hi,
as you can read below, one test of the test suite fails. As far as I
can see it is possibly a rounding issue rather than a failure. I wonder
how the test could be tweaked to pass successfully if you share my
opinion or what else could be done to pass the test suite successfully.
Kind regards
Andreas.
On Fri, Feb 05, 2016 at 09:37:32AM +0100, Chris Lamb wrote:
> Source: python-matplotlib-venn
> Version: 0.11-2
> Severity: serious
>
> Dear Maintainer,
>
> python-matplotlib-venn fails to build from source in unstable/amd64:
>
> [..]
>
> running test
> running egg_info
> creating matplotlib_venn.egg-info
> writing requirements to matplotlib_venn.egg-info/requires.txt
> writing matplotlib_venn.egg-info/PKG-INFO
> writing top-level names to matplotlib_venn.egg-info/top_level.txt
> writing dependency_links to matplotlib_venn.egg-info/dependency_links.txt
> writing manifest file 'matplotlib_venn.egg-info/SOURCES.txt'
> warning: manifest_maker: standard file 'setup.py' not found
>
> reading manifest file 'matplotlib_venn.egg-info/SOURCES.txt'
> writing manifest file 'matplotlib_venn.egg-info/SOURCES.txt'
> running build_ext
> = test session starts
> ==
> platform linux2 -- Python 2.7.11, pytest-2.8.5, py-1.4.31, pluggy-0.3.1 --
> /usr/bin/python2.7
> cachedir: ../../../.cache
> rootdir:
> /home/lamby/temp/cdt.20160205085405.L1EHTA93Fx/python-matplotlib-venn-0.11,
> inifile: setup.cfg
> collecting ... collected 49 items
>
> matplotlib_venn/_arc.py::matplotlib_venn._arc.Arc.__init__ PASSED
> matplotlib_venn/_arc.py::matplotlib_venn._arc.Arc.angle_as_point PASSED
> ...
> matplotlib_venn/_venn3.py::matplotlib_venn._venn3.venn3 PASSED
> matplotlib_venn/_venn3.py::matplotlib_venn._venn3.venn3_circles PASSED
>
> === FAILURES
> ===
> ___ [doctest] matplotlib_venn._arc.Arc.intersect_arc
> ___
> 339 Intersection with the arc along the same circle (which means
> infinitely many points usually) is reported as no intersection at all.
> 340
> 341 >>> a = Arc((0, 0), 1, -90, 90, True)
> 342 >>> a.intersect_arc(Arc((1, 0), 1, 90, 270, True))
> 343 [array([ 0.5 , -0.866...]), array([ 0.5 , 0.866...])]
> 344 >>> a.intersect_arc(Arc((1, 0), 1, 90, 180, True))
> 345 [array([ 0.5 , 0.866...])]
> 346 >>> a.intersect_arc(Arc((1, 0), 1, 121, 239, True))
> 347 []
> 348 >>> a.intersect_arc(Arc((1, 0), 1, 120, 240, True))
> Expected:
> [array([ 0.5 , -0.866...]), array([ 0.5 , 0.866...])]
> Got:
> [array([ 0.5 , 0.8660254])]
>
>
> /home/lamby/temp/cdt.20160205085405.L1EHTA93Fx/python-matplotlib-venn-0.11/.pybuild/pythonX.Y_2.7/build/matplotlib_venn/_arc.py:348:
> DocTestFailure
> ===== 1 failed, 48 passed in 0.51 seconds
> ==
> E: pybuild pybuild:274: test: plugin custom failed with: exit code=1: cp -a
> README.rst
> /home/lamby/temp/cdt.20160205085405.L1EHTA93Fx/python-matplotlib-venn-0.11/.pybuild/pythonX.Y_2.7/build
> && cd
> /home/lamby/temp/cdt.20160205085405.L1EHTA93Fx/python-matplotlib-venn-0.11/.pybuild/pythonX.Y_2.7/build
> && python2.7
> /home/lamby/temp/cdt.20160205085405.L1EHTA93Fx/python-matplotlib-venn-0.11/setup.py
> test && rm README.rst
> dh_auto_test: pybuild --test --test-pytest -i python{version} -p 2.7 --test
> --system=custom --test-args=cp -a README.rst {home_dir}/build && cd
> {home_dir}/build && {interpreter}
> /home/lamby/temp/cdt.20160205085405.L1EHTA93Fx/python-matplotlib-venn-0.11/setup.py
> test && rm README.rst --dir . returned exit code 13
--
http://fam-tille.de
Help needed: Bug#802354: python-matplotlib-venn: FTBFS: AttributeError: can't set attribute
Hi Python team,
I have no idea why this package now fails to build but was building
before.
Any hint would be welcome
Andreas.
- Forwarded message from "Chris West (Faux)"
<solo-debianb...@goeswhere.com> -
Date: Mon, 19 Oct 2015 19:05:55 +0100
From: "Chris West (Faux)" <solo-debianb...@goeswhere.com>
To: Debian Bug Tracking System <sub...@bugs.debian.org>
Subject: Bug#802354: python-matplotlib-venn: FTBFS: AttributeError: can't set
attribute
X-Debian-PR-Message: report 802354
X-Debian-PR-Package: src:python-matplotlib-venn
X-Debian-PR-Keywords: sid stretch
X-Debian-PR-Source: python-matplotlib-venn
Source: python-matplotlib-venn
Version: 0.11-1
Severity: serious
Justification: fails to build from source
Tags: sid stretch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org
Dear Maintainer,
The package fails to build:
== 49 passed in 1.17 seconds ===
pybuild --test --test-pytest -i python{version} -p 3.4 --test
--system=custom "--test-args=cp -a README.rst {home_dir}/build && cd
{home_dir}/build && {interpreter} /python-matplotlib-venn-0.11/setup.py test &&
rm README.rst" --dir .
I: pybuild base:170: cp -a README.rst
/python-matplotlib-venn-0.11/.pybuild/pythonX.Y_3.4/build && cd
/python-matplotlib-venn-0.11/.pybuild/pythonX.Y_3.4/build && python3.4
/python-matplotlib-venn-0.11/setup.py test && rm README.rst
running test
Traceback (most recent call last):
File "/python-matplotlib-venn-0.11/setup.py", line 56, in
entry_points=''
File "/usr/lib/python3.4/distutils/core.py", line 148, in setup
dist.run_commands()
File "/usr/lib/python3.4/distutils/dist.py", line 955, in run_commands
self.run_command(cmd)
File "/usr/lib/python3.4/distutils/dist.py", line 973, in run_command
cmd_obj.ensure_finalized()
File "/usr/lib/python3.4/distutils/cmd.py", line 107, in ensure_finalized
self.finalize_options()
File "/python-matplotlib-venn-0.11/setup.py", line 21, in finalize_options
self.test_args = []
AttributeError: can't set attribute
E: pybuild pybuild:262: test: plugin custom failed with: exit code=1: cp -a
README.rst /python-matplotlib-venn-0.11/.pybuild/pythonX.Y_3.4/build && cd
/python-matplotlib-venn-0.11/.pybuild/pythonX.Y_3.4/build && python3.4
/python-matplotlib-venn-0.11/setup.py test && rm README.rst
dh_auto_test: pybuild --test --test-pytest -i python{version} -p 3.4 --test
--system=custom --test-args=cp -a README.rst {home_dir}/build && cd
{home_dir}/build && {interpreter} /python-matplotlib-venn-0.11/setup.py test &&
rm README.rst --dir . returned exit code 13
debian/rules:10: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 25
Full build log:
https://reproducible.debian.net/rb-pkg/unstable/amd64/python-matplotlib-venn.html
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
___
Debian-med-packaging mailing list
debian-med-packag...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
- End forwarded message -
--
http://fam-tille.de
Need help python module testing at package build time: python-matplotlib-venn
Hi,
I'd like to package python-matplotlib-venn since a Debian Med package
depends from this module. I injected the packaging to
svn://anonscm.debian.org/debian-med/trunk/packages/python-mathplotlib-venn/trunk/
Unfortunately I'm running into:
.pybuild/pythonX.Y_2.7/build/matplotlib_venn/_common.py .
.pybuild/pythonX.Y_2.7/build/matplotlib_venn/_math.py
.pybuild/pythonX.Y_2.7/build/matplotlib_venn/_region.py .
.pybuild/pythonX.Y_2.7/build/matplotlib_venn/_venn2.py ...
.pybuild/pythonX.Y_2.7/build/matplotlib_venn/_venn3.py
ERRORS
ERROR collecting .pybuild/pythonX.Y_3.4/build/matplotlib_venn/_arc.py _
/usr/lib/python2.7/dist-packages/py/_path/local.py:660: in pyimport
raise self.ImportMismatchError(modname, modfile, self)
E ImportMismatchError: ('matplotlib_venn._arc',
'/tmp/buildd/python-matplotlib-venn-0.11/.pybuild/pythonX.Y_2.7/build/matplotlib_venn/_arc.py',
local('/tmp/buildd/python-matplotlib-venn-0.11/.pybuild/pythonX.
Y_3.4/build/matplotlib_venn/_arc.py'))
___ ERROR collecting .pybuild/pythonX.Y_3.4/build/matplotlib_venn/_common.py ___
/usr/lib/python2.7/dist-packages/py/_path/local.py:660: in pyimport
raise self.ImportMismatchError(modname, modfile, self)
E ImportMismatchError: ('matplotlib_venn._common',
'/tmp/buildd/python-matplotlib-venn-0.11/.pybuild/pythonX.Y_2.7/build/matplotlib_venn/_common.py',
local('/tmp/buildd/python-matplotlib-venn-0.11/.pybuild/
pythonX.Y_3.4/build/matplotlib_venn/_common.py'))
ERROR collecting .pybuild/pythonX.Y_3.4/build/matplotlib_venn/_math.py
/usr/lib/python2.7/dist-packages/py/_path/local.py:660: in pyimport
raise self.ImportMismatchError(modname, modfile, self)
E ImportMismatchError: ('matplotlib_venn._math',
'/tmp/buildd/python-matplotlib-venn-0.11/.pybuild/pythonX.Y_2.7/build/matplotlib_venn/_math.py',
local('/tmp/buildd/python-matplotlib-venn-0.11/.pybuild/pythonX.Y_3.4/build/matplotlib_venn/_math.py'))
___ ERROR collecting .pybuild/pythonX.Y_3.4/build/matplotlib_venn/_region.py ___
/usr/lib/python2.7/dist-packages/py/_path/local.py:660: in pyimport
raise self.ImportMismatchError(modname, modfile, self)
E ImportMismatchError: ('matplotlib_venn._region',
'/tmp/buildd/python-matplotlib-venn-0.11/.pybuild/pythonX.Y_2.7/build/matplotlib_venn/_region.py',
local('/tmp/buildd/python-matplotlib-venn-0.11/.pybuild/
pythonX.Y_3.4/build/matplotlib_venn/_region.py'))
ERROR collecting .pybuild/pythonX.Y_3.4/build/matplotlib_venn/_util.py
/usr/lib/python2.7/dist-packages/py/_path/local.py:660: in pyimport
raise self.ImportMismatchError(modname, modfile, self)
E ImportMismatchError: ('matplotlib_venn._util',
'/tmp/buildd/python-matplotlib-venn-0.11/.pybuild/pythonX.Y_2.7/build/matplotlib_venn/_util.py',
local('/tmp/buildd/python-matplotlib-venn-0.11/.pybuild/pythonX.Y_3.4/build/matplotlib_venn/_util.py'))
___ ERROR collecting .pybuild/pythonX.Y_3.4/build/matplotlib_venn/_venn2.py
/usr/lib/python2.7/dist-packages/py/_path/local.py:660: in pyimport
raise self.ImportMismatchError(modname, modfile, self)
E ImportMismatchError: ('matplotlib_venn._venn2',
'/tmp/buildd/python-matplotlib-venn-0.11/.pybuild/pythonX.Y_2.7/build/matplotlib_venn/_venn2.py',
local('/tmp/buildd/python-matplotlib-venn-0.11/.pybuild/
pythonX.Y_3.4/build/matplotlib_venn/_venn2.py'))
___ ERROR collecting .pybuild/pythonX.Y_3.4/build/matplotlib_venn/_venn3.py
/usr/lib/python2.7/dist-packages/py/_path/local.py:660: in pyimport
raise self.ImportMismatchError(modname, modfile, self)
E ImportMismatchError: ('matplotlib_venn._venn3',
'/tmp/buildd/python-matplotlib-venn-0.11/.pybuild/pythonX.Y_2.7/build/matplotlib_venn/_venn3.py',
local('/tmp/buildd/python-matplotlib-venn-0.11/.pybuild/
pythonX.Y_3.4/build/matplotlib_venn/_venn3.py'))
___ ERROR collecting matplotlib_venn/_arc.py ___
/usr/lib/python2.7/dist-packages/py/_path/local.py:660: in pyimport
raise self.ImportMismatchError(modname, modfile, self)
E ImportMismatchError: ('matplotlib_venn._arc',
'/tmp/buildd/python-matplotlib-venn-0.11/.pybuild/pythonX.Y_2.7/build/matplotlib_venn/_arc.py',
local('/tmp/buildd/python-matplotlib-venn-0.11/matplotlib_venn/ _arc.py'))
_ ERROR collecting matplotlib_venn/_common.py __
/usr/lib/python2.7/dist-packages/py/_path/local.py:660: in pyimport
raise self.ImportMismatchError(modname, modfile, self)
E ImportMismatchError: ('matplotlib_venn._common',
'/tmp/buildd/python-matplotlib-venn-0.11/.pybuild/pythonX.Y_2.7/build/matplotlib_venn/_common.py',
local('/tmp/buildd/python-matplotlib-venn-0.11/
matplotlib_venn/_common.py'))
__ ERROR collecting matplotlib_venn/_math.py ___
/usr/lib/python2.7/dist-packages/py/_path/local.py:660: in pyimport
raise self.ImportMismatchError(modname
Re: Availability of Numpy, WX, Matplotlib and Scipy under Python3
Re: Availability of Numpy, WX, Matplotlib and Scipy under Python3 = Thanks to Thomas Kluyver and Dmitrijs Ledkovs. On Mon, 2012-09-03 at 21:27 +0100, Thomas Kluyver wrote: Python 3 versions of numpy and scipy are already in wheezy. wx and matplotlib haven't yet released Python 3 compatible versions, and Wheezy is frozen now, so they've missed that boat. If you need to use those packages for a substantial application in the near future, sticking with Python 2 for now is your safest bet. If you use Python 2.6 or 2.7 with modern idioms, it should be relatively easy to port code later when all the libraries are ready. Given the issue with (especially) WX, I think I will stick with Python 2.7 for the time being. On Tue, 2012-09-04 at 01:07 +0100, Dmitrijs Ledkovs wrote: You may want to request a backport from folks who do those, and maybe (dependencies permitting) they can make a python3 backport of scipy / numpy for current stable release squeeze. I'll consider that if and when I find any differences between Python 2.7 and 3.* that become pressing issues for me. Otherwise, I suspect that any request for a backport from me will only distract from more useful work for a wider range of users. -- It is a pity that (particulaly) wxPython has missed the Wheezy revision window. When I looked at the various GUIs available in Python, I thought that wxPython was the one with the best combination of advanced facilities and ease of use. Thanks again for the quick and useful responses. Best regards -- Nigel Sedgwick, Cambridge Algorithmica Ltd URL: http://www.camalg.co.uk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1346745609.2391.11.ca...@napier3.camalg.co.uk
Re: Availability of Numpy, WX, Matplotlib and Scipy under Python3
On Sep 04, 2012, at 09:00 AM, Nigel Sedgwick wrote: Given the issue with (especially) WX, I think I will stick with Python 2.7 for the time being. The only suggestion I'd make is that you write your Python 2 code so that it's easier to port to Python 3 when all your dependencies are available. I'm not sure how many good guides there are out there on writing Python 3-friendly Python 2 code, but you might have a look at http://wiki.ubuntu.com/Python/3 for some hints. I suppose the top recommendations I'd give are: * Target nothing older than Python 2.6 (2.7 is even better) * As much as possible, write common idiom code (possibly using the 'six' library if necessary). * from __future__ import absolute_import, print_function, unicode_literals * Get your bytes vs. strings story straight right from the start. * Use b'' for bytes. * Avoid idioms you know are gone in Python 3, like backticks, dict.iter*() methods, xrange(), etc. Or essentially: write your code as if it were a single code base, dual-compatible code base. Eventually, it will be even if you end up dropping Python 2 support at some point. ;) Cheers, -Barry -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120905094639.04d3f...@resist.wooz.org
Availability of Numpy, WX, Matplotlib and Scipy under Python3
Dear All Availability of Numpy, WX, Matplotlib and Scipy under Python3 = I am a user of Debian Squeeze (6.0.5) on an AMD64 computer. I would like to switch a mainstream development of mine from Python2.6 (or 2.7) to Python3.1 (or 3.2) as soon as practical. The application makes heavy use of numpy and wx and will soon make heavy use of scipy, matplotlib and various other python libraries that are widely used. Currently, as far as I can see, there is no support for these libraries under python3, as installed using Debian Synaptic from the Debian site(s). The technical problem is one of the location of these python libraries in the Linux directory tree, and the versions of numpy and scipy not being sufficiently recent for use with python3.0 or higher. I could install these libraries from the current source downloads. However, that is a load of effort and (worse) there is a risk that I will do not do it properly and get in a mess. Is there any current expectation of when these libraries, especially python3-numpy, python3-wx and python3-matplotlib are likely to become available under Debian Squeeze? As an alternative, on the assumption that they will be available under Debian Wheezy, what is the likely timescale for that release to move from testing to stable? Information on the above would help me decide what to do: (i) carry on with Python2 for a bit longer; (ii) go for a source code install of these libraries for python3 under Debian; (iii) acquire a (new) non-critical computer and install a test version of Debian Wheezy on it, with most/all python libraries being python3 compatible; even (iv) use an MS Windows version of python3 and the libraries and try running it under Wine. Thanks in advance for any useful information. Best regards -- Nigel Sedgwick, Cambridge Algorithmica Ltd URL: http://www.camalg.co.uk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1346680657.27451.26.ca...@napier3.camalg.co.uk
Re: Availability of Numpy, WX, Matplotlib and Scipy under Python3
Hi Nigel, On 3 September 2012 14:57, Nigel Sedgwick n...@camalg.co.uk wrote: The application makes heavy use of numpy and wx and will soon make heavy use of scipy, matplotlib and various other python libraries that are widely used. Python 3 versions of numpy and scipy are already in wheezy. wx and matplotlib haven't yet released Python 3 compatible versions, and Wheezy is frozen now, so they've missed that boat. If you need to use those packages for a substantial application in the near future, sticking with Python 2 for now is your safest bet. If you use Python 2.6 or 2.7 with modern idioms, it should be relatively easy to port code later when all the libraries are ready. As far as I understand Debian, none of those python3- packages will be added to Squeeze. The idea of a stable release is that the only updates it gets are bugfixes and security. Looking further ahead: matplotlib is aiming to release a Python 3 version in October. wxPython has a development version working on Python 3, but I don't see any indication of how soon a release is planned. Other GUI toolkits (Qt, GTK) already support Python 3, if they are an option for you. Best wishes, Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caovn4qipxjjqxswn1dwc3rcnzhc15icn8e5dyxwa18yurzo...@mail.gmail.com
Re: Availability of Numpy, WX, Matplotlib and Scipy under Python3
On 3 September 2012 21:27, Thomas Kluyver tho...@kluyver.me.uk wrote: Hi Nigel, On 3 September 2012 14:57, Nigel Sedgwick n...@camalg.co.uk wrote: The application makes heavy use of numpy and wx and will soon make heavy use of scipy, matplotlib and various other python libraries that are widely used. Python 3 versions of numpy and scipy are already in wheezy. wx and matplotlib haven't yet released Python 3 compatible versions, and Wheezy is frozen now, so they've missed that boat. If you need to use those packages for a substantial application in the near future, sticking with Python 2 for now is your safest bet. If you use Python 2.6 or 2.7 with modern idioms, it should be relatively easy to port code later when all the libraries are ready. As far as I understand Debian, none of those python3- packages will be added to Squeeze. The idea of a stable release is that the only updates it gets are bugfixes and security. One more thing there is debian-backports =) http://backports-master.debian.org/ You may want to request a backport from folks who do those, and maybe (dependencies permitting) they can make a python3 backport of scipy / numpy for current stable release squeeze. Looking further ahead: matplotlib is aiming to release a Python 3 version in October. wxPython has a development version working on Python 3, but I don't see any indication of how soon a release is planned. Other GUI toolkits (Qt, GTK) already support Python 3, if they are an option for you. Best wishes, Thomas Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluj7xcppo3bgujw-7+sazvjvet_kjtqdovfh-3-7ruk...@mail.gmail.com
Typo in python-matplotlib
Hi, in the package python-matplotlib I've just hit a typo in
/usr/share/pyshared/matplotlib/axes3d.py:
raise NotImplmentedError('axes3d is not supported in matplotlib-0.98.
You may want to try the 0.91.x maintenance branch')
should read NotImplementedError instead of NotImplmentedError.
To reproduce just try:
from matplotlib import axes3d
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/lib/python2.5/site-packages/matplotlib/axes3d.py, line
1, in module
raise NotImplmentedError('axes3d is not supported in
matplotlib-0.98. You may want to try the 0.91.x maintenance branch')
NameError: name 'NotImplmentedError' is not defined
not such a big deal, the import should fail with NotImplementedError
instead of NameError. How is the policy for reporting such bugs
upstream? Should I simply go and report, or is there an official
spokesman of the DPMT?
thanks,
tiziano
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Typo in python-matplotlib
Hello Tiziano,
On Mon, Sep 8, 2008 at 12:07, Tiziano Zito [EMAIL PROTECTED] wrote:
Hi, in the package python-matplotlib I've just hit a typo in
/usr/share/pyshared/matplotlib/axes3d.py:
raise NotImplmentedError('axes3d is not supported in matplotlib-0.98.
You may want to try the 0.91.x maintenance branch')
should read NotImplementedError instead of NotImplmentedError.
To reproduce just try:
from matplotlib import axes3d
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/lib/python2.5/site-packages/matplotlib/axes3d.py, line
1, in module
raise NotImplmentedError('axes3d is not supported in
matplotlib-0.98. You may want to try the 0.91.x maintenance branch')
NameError: name 'NotImplmentedError' is not defined
Thanks for the notice.
not such a big deal, the import should fail with NotImplementedError
instead of NameError. How is the policy for reporting such bugs
upstream? Should I simply go and report, or is there an official
spokesman of the DPMT?
Well, at your choice: you can report the bug on Debian BTS and let me
forward it or directly open the bug upstream (there are chances that
someone already reported it, either on their mailing list or BTS).
Kindly,
Sandro
--
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: matplotlib 0.90.1-3
On Sat, Feb 23, 2008 at 5:08 PM, Ondrej Certik [EMAIL PROTECTED] wrote: On Sat, Feb 23, 2008 at 4:31 PM, Eike Nicklas [EMAIL PROTECTED] wrote: Hi Ondrej et al., Yes, I read that bug. There are more problems with matplotlib - it is not lintian clean, it still uses Numerics and numarray besides numpy (I don't know if this is a feature or a bug), I think upstream deprecated Numerics and numarray and the latest version only uses numpy. Changelog excerpts: 2007-06-01 Deprecate Numeric and numarray for use as numerix. 2007-06-02 Released 0.90.1 at revision 3352 2007-06-07 Disable build of numarray and Numeric extensions for internal MPL use and the numerix layer. 2007-07-19 replaced the Python code in numerix/ by a minimal wrapper around numpy that explicitly mentions all symbols that need to be addressed for further numpification [...] and only numpy is mentioned in the current README. Anyway, as a matplotlib user, I am happy that you want to fix the current issues, but sadly I currently don't have the time to help with that. It shouldn't be a big problem and I'll do it, as I also use and need it. We are actually only waiting for an approval from the matplotlib maintainers. Anyway, this seems it will take quite some time before it gets resolved, so I compiled the fixed packages for i386 and amd64 and put them here to my repository: http://debian.certik.cz/ Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: matplotlib 0.90.1-3
Hi, currently, matplotlib doesn't install with numpy in sid, when numpy switched to gfortran and it conflicts with matplotlib. It seems just a recompile of matplotlib fixes the problem. I imported matplotlib to DPMT svn: svn://svn.debian.org/svn/python-modules/packages/matplotlib/ and committed the necessary change. Unfortunatley, the maintainer and uploaders of matplotlib didn't yet reply to my email and bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467099 and a simple NMU will not fix the problem, as numpy conflicts with python-matplotlib ( 0.90.1-3). So what should I do to get this fixed soon? Should I upload (I can do that as a DM) a new revision of numpy not conflicting with python-matplotlib? Or can you upload the new matplotlib as I prepared in the svn? The best solution is the one I offered to the maintainers of matplotlib in the bug above - to maintain matplotlib in DPMT. But unless they approve it, I don't think we can do that. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: matplotlib 0.90.1-3
Hi, On Sat, 23 Feb 2008 13:07:24 +0100 Ondrej Certik wrote: currently, matplotlib doesn't install with numpy in sid, when numpy switched to gfortran and it conflicts with matplotlib. That might also (partly) fix a bug I reassigned to matplotlib: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466818 It was initially reported against pondus, which does not explicitely use python-numpy, but only python-matplotlib (which it correctly depends on) Eike pgppYeU57Siv3.pgp Description: PGP signature
Re: RFS: matplotlib 0.90.1-3
On Sat, Feb 23, 2008 at 4:31 PM, Eike Nicklas [EMAIL PROTECTED] wrote: Hi Ondrej et al., Yes, I read that bug. There are more problems with matplotlib - it is not lintian clean, it still uses Numerics and numarray besides numpy (I don't know if this is a feature or a bug), I think upstream deprecated Numerics and numarray and the latest version only uses numpy. Changelog excerpts: 2007-06-01 Deprecate Numeric and numarray for use as numerix. 2007-06-02 Released 0.90.1 at revision 3352 2007-06-07 Disable build of numarray and Numeric extensions for internal MPL use and the numerix layer. 2007-07-19 replaced the Python code in numerix/ by a minimal wrapper around numpy that explicitly mentions all symbols that need to be addressed for further numpification [...] and only numpy is mentioned in the current README. Anyway, as a matplotlib user, I am happy that you want to fix the current issues, but sadly I currently don't have the time to help with that. It shouldn't be a big problem and I'll do it, as I also use and need it. We are actually only waiting for an approval from the matplotlib maintainers. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
python-matplotlib 0.62.4 ipython 0.6.3 debian packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I've packaged a new version of python-matplotlib and ipython, you can find my packages at this address: deb http://anakonda.altervista.org/debian packages/ deb-src http://anakonda.altervista.org/debian sources/ # apt-get install python-matplotlib python-matplotlib-doc ipython P.S. python-matplotlib-doc isn't complete because pydoc exits with a segfault when I build documentation, I'm investigating on this... - -- /Vittorio Palmisano/ Home Page: http://redclay.altervista.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBNHZjpT6bvDtyXOIRAmdSAKCeCdL+LKWEoZe86XqGXaKpyGQUzwCfSWz6 fZPWvFkHuv40FVbpXdUUveo= =mUTV -END PGP SIGNATURE- -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Oliviero.it presenta in esclusiva il pantaloncino INNUELLE, il primo elettro-trattamento indossabile, per raggiungere i principali obiettivi di ogni seria azione contro la cellulite! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2661d=31-8
