I think having only the one failure (and one from a test that is quite
new) is pretty good.
I'm not sure why that test is failing -- is it possible it's testing
with an earlier checkout using tests from a newer checkout. This would
happen, for example, if running the tests from the matplotlib
I use up-to-date Debian testing (wheezy) with the amd64 architecture
and Debian's python3.2. I install matplotlib from the tarball
matplotlib-matplotlib-v1.1.0-684-ge87374e.tar.gz
Before the current install, I had also on my system Debian's
python-matplotlib and python-matplotlib-data package
On 05/15/2012 10:15 AM, Edward C. Jones wrote:
> Michael Droettboom said
>
> > Are you running the tests from the source directory? That often
> results in failures that look like this.
>
> Yes, I did that. Some Googling found the correct way to do it:
>
> python3.2
> >>> import matplotlib
>
Michael Droettboom said
> Are you running the tests from the source directory? That often
results in failures that look like this.
Yes, I did that. Some Googling found the correct way to do it:
python3.2
>>> import matplotlib
>>> matplotlib.test()
..K./usr/lib/python3/dist-packages/
Are you running the tests from the source directory? That often results
in failures that look like this.
Mike
On 05/14/2012 06:11 PM, Edward C. Jones wrote:
> I use up-to-date Debian testing (wheezy) with an amd64 architecture. I
> am trying to use matplotlib with Python 3.2, I downloaded
> ma
I use up-to-date Debian testing (wheezy) with an amd64 architecture. I
am trying to use matplotlib with Python 3.2, I downloaded
matplotlib-matplotlib-v1.1.0-684-ge87374e.tar.gz
I expanded the tarball and did
python3.2 setup.py build
and, as root,
python3.2 setup.py install
When I tried to run
