matplotlib-devel Mailing List for matplotlib

> On 7 Feb 2015, at 10:18 pm, Thomas Caswell <tca...@gm...> wrote:
> 
> raise ValueError(msg % style)
> ValueError: 'https://gist.github.com/adrn/6590261/raw' not found in the style library and input is not a valid URL or path. See `style.available` for list of available styles.
> 
> Is your computer connected to the internet? Can you get to that url in any other way? This works on my machine and on the travis (both linux and osx https://travis-ci.org/MacPython/scipy-stack-osx-testing). Unfortunately the code currently snarfs all exceptions so this makes it hard to sort out what exactly is going wrong.
> 
Yes, the "not found in the style library and input is not a valid URL or path" message is not exactly
clear about that. Both with lynx and wget I am getting a warning about an invalid ssl certificate for
that URL, so I need to explicitly override it or use ‘wget —no-check-certificate’. Curl seems to have
some issues of its own, does not download the raw file anyway, though silently unless given ‘-v':
> curl -v -O https://gist.github.com/adrn/6590261/raw 
* Hostname was NOT found in DNS cache
 % Total % Received % Xferd Average Speed Time Time Time Current
 Dload Upload Total Spent Left Speed
 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 192.30.252.143...
 0 0 0 0 0 0 0 0 --:--:-- 0:00:02 --:--:-- 0* Connected to gist.github.com (192.30.252.143) port 443 (#0)
 0 0 0 0 0 0 0 0 --:--:-- 0:00:03 --:--:-- 0* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
* Server certificate: *.github.com
* Server certificate: DigiCert SHA2 High Assurance Server CA
* Server certificate: DigiCert High Assurance EV Root CA
> GET /adrn/6590261/raw HTTP/1.1
> User-Agent: curl/7.37.1
> Host: gist.github.com
> Accept: */*
> 
< HTTP/1.1 301 Moved Permanently
< Content-length: 0
< Location: https://gist.githubusercontent.com/adrn/6590261/raw
< Connection: close
< 
 0 0 0 0 0 0 0 0 --:--:-- 0:00:03 --:--:-- 0
* Closing connection 0
> wget https://gist.github.com/adrn/6590261/raw 
--2015年02月09日 01:38:16-- https://gist.github.com/adrn/6590261/raw
Resolving gist.github.com (gist.github.com)... 192.30.252.143
Connecting to gist.github.com (gist.github.com)|192.30.252.143|:443... connected.
ERROR: cannot verify gist.github.com's certificate, issued by ‘/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA’:
 Unable to locally verify the issuer's authority.
To connect to gist.github.com insecurely, use `--no-check-certificate’.
I don’t know if this is only due to something peculiar with my proxy or cache settings, but the mpl error
comes down to python2.7’s urllib rejecting this certificate
>>> from urllib2 import urlopen
>>> fp = urlopen('https://gist.github.com/adrn/6590261/raw')
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "/sw/lib/python2.7/urllib2.py", line 154, in urlopen
 return opener.open(url, data, timeout)
 File "/sw/lib/python2.7/urllib2.py", line 431, in open
 response = self._open(req, data)
 File "/sw/lib/python2.7/urllib2.py", line 449, in _open
 '_open', req)
 File "/sw/lib/python2.7/urllib2.py", line 409, in _call_chain
 result = func(*args)
 File "/sw/lib/python2.7/urllib2.py", line 1240, in https_open
 context=self._context)
 File "/sw/lib/python2.7/urllib2.py", line 1197, in do_open
 raise URLError(err)
urllib2.URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)>
(even when using ‘http://...' in the URL), while python3.4 urllib apparently has no problems with it:
>>> from urllib.request import urlopen
>>> fp = urlopen('https://gist.github.com/adrn/6590261/raw')
>>> fp
<http.client.HTTPResponse object at 0x10c782a90>
>>> fp.read()
b'axes.facecolor : adeade’
MacOS X’s own /usr/bin/python (2.7.6) works as well, and Safari displays that URL as encrypted with a trusted
certificate from DigiCert SHA2 High Assurance Server CA.
An obvious suspect would be the latter two using Mac OS X’s system ssl, which is OpenSSL 0.9.8za, while
lynx, wget and fink python all use fink’s OpenSSL 1.0.2; on a Linux machine with OpenSSL 1.0.1e wget and
python2.7 can resolve the URL as well (though curl doesn’t download anything there either).
But Fink’s python3.4 is using the same OpenSSL 1.0.2 as it’s python2.7, and accepts the certificate as well!
Anyway this is obviously not a matplotlib problem.
> On 10.10 there are a number of additional errors (I’ve checked the save_animation
> errors are not due to permission problems):
> 
> ERROR: matplotlib.tests.test_animation.test_save_animation_smoketest('ffmpeg', 'mp4')
> ----------------------------------------------------------------------
...
> To be clear, this fails on some versions of osx and not others? Can you track this back any further to sort out what is going on? I don't have a mac to do any testing on.
> 
OK, I could track this down to a broken ffmpeg on the 10.10 machine, which I did not bother to check earlier,
because I had used ffmpeg on that same machine only 2 weeks ago. But another library update in between
broke a compatibility version; after rebuilding ffmpeg those tests are passing now.
> 
> ======================================================================
> ERROR: Failure: AttributeError ('module' object has no attribute 'test_backend_qt4')
> FAILED (KNOWNFAIL=372, SKIP=1, errors=7)
> 
> The bunch of these look like something is very broken about the installation. AttributeErrors like that tend to mean that something in the imports of those test modules errors (and nose eats those errors).
> 
Unfortunately yes, the actual error was a failing ‘import mock’, so the mock package just needs to be added to
the test dependencies for the python2.7 flavour. With it installed, those 4 above pass as well, so I seem to be left
with only the openssl problem.
Thanks for the assistance!
					Derek

Sorry about the bad tarball, I forgot to clean my git directory before
generating it. Another point in favor of using the gh tarball, I can't
screw it up.
This is the first I have seen that CVE.
That PR is not included in 1.4.3 because it completely over-hauls how the
Agg rendering works (and generated a whole bunch of other bugs along the
way).
Mike: Is there a way to fix up the security issues reported on just the
1.4.x branch with out pulling that whole patch back?
Tom
On Sun Feb 08 2015 at 7:47:00 PM Benjamin Root <ben...@ou...> wrote:
> Please ignore my test failure report. I was accidentally running an older
> install of matplotlib from the same branch.
>
> Ben Root
>
> On Sat, Feb 7, 2015 at 9:08 PM, Benjamin Root <ben...@ou...> wrote:
>
>> I am getting some test failures here and on master in the collections
>> module.
>>
>> ======================================================================
>> FAIL: __main__.test_regularpolycollection_rotate.test
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>> File "/home/ben/miniconda/lib/python2.7/site-packages/nose/case.py",
>> line 197, in runTest
>> self.test(*self.arg)
>> File
>> "/home/ben/.local/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py",
>> line 51, in failer
>> result = f(*args, **kwargs)
>> File
>> "/home/ben/.local/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py",
>> line 196, in do_test
>> '(RMS %(rms).3f)'%err)
>> ImageComparisonFailure: images not close:
>> /home/ben/Programs/matplotlib/result_images/test_collections/regularpolycollection_rotate.png
>> vs.
>> /home/ben/Programs/matplotlib/result_images/test_collections/regularpolycollection_rotate-expected.png
>> (RMS 54.618)
>>
>> ======================================================================
>> FAIL: __main__.test_regularpolycollection_scale.test
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>> File "/home/ben/miniconda/lib/python2.7/site-packages/nose/case.py",
>> line 197, in runTest
>> self.test(*self.arg)
>> File
>> "/home/ben/.local/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py",
>> line 51, in failer
>> result = f(*args, **kwargs)
>> File
>> "/home/ben/.local/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py",
>> line 196, in do_test
>> '(RMS %(rms).3f)'%err)
>> ImageComparisonFailure: images not close:
>> /home/ben/Programs/matplotlib/result_images/test_collections/regularpolycollection_scale.png
>> vs.
>> /home/ben/Programs/matplotlib/result_images/test_collections/regularpolycollection_scale-expected.png
>> (RMS 120.828)
>>
>> ----------------------------------------------------------------------
>> Ran 54 tests in 15.149s
>>
>> FAILED (failures=2)
>>
>>
>>
>> The squares in the first test are larger than they should be. I have some
>> other errors, but they seem to other be floating point errors, or issues
>> with fonts.
>>
>> Ben Root
>>
>>
>> On Sat, Feb 7, 2015 at 4:46 PM, Thomas Caswell <tca...@gm...>
>> wrote:
>>
>>> Sandro,
>>>
>>> Well, creating the tarball on GH is a lot easier for us as it happens
>>> automatically! I don't want to unilaterally change policy so I will create
>>> the files on SF.
>>>
>>> If you want to tracking GH for debian instead of SF I don't think that
>>> would be a bad idea, but I don't know how much of a hassle that would be
>>> for you.
>>>
>>> Tom
>>>
>>> On Sat Feb 07 2015 at 4:14:36 PM Sandro Tosi <mo...@de...> wrote:
>>>
>>>> On Sat, Feb 7, 2015 at 9:05 PM, Thomas Caswell <tca...@gm...>
>>>> wrote:
>>>> > Sandro,
>>>> >
>>>> > Can you use the tarball from github
>>>> > (https://github.com/matplotlib/matplotlib/archive/v1.4.3rc1.tar.gz ?)
>>>>
>>>> Sure I can, but since all the previous release (even RC) were done one
>>>> SF, we have our tools to monitor and download new releases pointing to
>>>> SF: do you plan to switch to GH for releasing tarballs too?
>>>>
>>>> Cheers,
>>>> --
>>>> Sandro Tosi (aka morph, morpheus, matrixhasu)
>>>> My website: http://matrixhasu.altervista.org/
>>>> Me at Debian: http://wiki.debian.org/SandroTosi
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Dive into the World of Parallel Programming. The Go Parallel Website,
>>> sponsored by Intel and developed in partnership with Slashdot Media, is
>>> your
>>> hub for all things parallel software development, from weekly thought
>>> leadership blogs to news, videos, case studies, tutorials and more. Take
>>> a
>>> look and join the conversation now. http://goparallel.sourceforge.net/
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>>
>>
>

I think I figured it out... the linestyles are a list of tuples. When they
get coerced to a numpy array, and then coerced back to a list, you get a
list of lists instead of a list of tuples!
There must be some code deep down in the agg that is expecting a tuple, and
choking on a list.
Ben Root
On Sun, Feb 8, 2015 at 5:54 PM, Benjamin Root <ben...@ou...> wrote:
> I am experimenting with my idea for utilizing a _draworder attribute in
> Collection objects. Since not everything in a collection is guaranteed to
> be the same length or even be numpy arrays, I have to add some logic to
> coerce everything to numpy arrays and tile their data so that the length of
> their first axis match up.
>
> I also have logic to convert all objects back to their original types
> prior to continuing, just in case that makes any difference.
>
> However, using AGG seems to fail here:
>
> Traceback (most recent call last):
> File "/home/ben/miniconda/lib/python2.7/site-packages/nose/case.py",
> line 197, in runTest
> self.test(*self.arg)
> File
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py",
> line 51, in failer
> result = f(*args, **kwargs)
> File
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py",
> line 183, in do_test
> figure.savefig(actual_fname, **self._savefig_kwarg)
> File
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/figure.py",
> line 1490, in savefig
> self.canvas.print_figure(*args, **kwargs)
> File
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/backend_bases.py",
> line 2211, in print_figure
> **kwargs)
> File
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/backends/backend_agg.py",
> line 525, in print_png
> FigureCanvasAgg.draw(self)
> File
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/backends/backend_agg.py",
> line 472, in draw
> self.figure.draw(self.renderer)
> File
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/artist.py",
> line 60, in draw_wrapper
> draw(artist, renderer, *args, **kwargs)
> File
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/figure.py",
> line 1094, in draw
> func(*args)
> File
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/mpl_toolkits/mplot3d/axes3d.py",
> line 273, in draw
> ax.draw(renderer)
> File
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/mpl_toolkits/mplot3d/axis3d.py",
> line 370, in draw
> self.gridlines.draw(renderer, project=True)
> File
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/mpl_toolkits/mplot3d/art3d.py",
> line 203, in draw
> LineCollection.draw(self, renderer)
> File
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/artist.py",
> line 60, in draw_wrapper
> draw(artist, renderer, *args, **kwargs)
> File
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/collections.py",
> line 345, in draw
> self._offset_position)
> File
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/backends/backend_agg.py",
> line 127, in draw_path_collection
> return self._renderer.draw_path_collection(*kl, **kw)
> SystemError: new style getargs format but argument is not a tuple
>
> The PDF and SVG backends aren't experiencing this problem. I have taken
> out the parts of my code that "broadcasted" the arrays, and the error still
> happens. I then took out the code that coerced everything to numpy arrays
> in the first place, and the error disappeared (taking that out effectively
> let everything pass through unaffected). Keep in mind that my code coerced
> everything back to their original types prior to calling the renderer, so
> it was merely the action of converting stuff into an array that did this.
>
> The best I can figure is that there is something wrong with the C++ code
> for our agg wrapper? Googling the exception message brings up various
> discussions of mistakes in the argument handling of C/C++ code. I haven't a
> clue, though, why this would be an issue.
>
> Thoughts?
> Ben Root
>
>

Please ignore my test failure report. I was accidentally running an older
install of matplotlib from the same branch.
Ben Root
On Sat, Feb 7, 2015 at 9:08 PM, Benjamin Root <ben...@ou...> wrote:
> I am getting some test failures here and on master in the collections
> module.
>
> ======================================================================
> FAIL: __main__.test_regularpolycollection_rotate.test
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/home/ben/miniconda/lib/python2.7/site-packages/nose/case.py",
> line 197, in runTest
> self.test(*self.arg)
> File
> "/home/ben/.local/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py",
> line 51, in failer
> result = f(*args, **kwargs)
> File
> "/home/ben/.local/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py",
> line 196, in do_test
> '(RMS %(rms).3f)'%err)
> ImageComparisonFailure: images not close:
> /home/ben/Programs/matplotlib/result_images/test_collections/regularpolycollection_rotate.png
> vs.
> /home/ben/Programs/matplotlib/result_images/test_collections/regularpolycollection_rotate-expected.png
> (RMS 54.618)
>
> ======================================================================
> FAIL: __main__.test_regularpolycollection_scale.test
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/home/ben/miniconda/lib/python2.7/site-packages/nose/case.py",
> line 197, in runTest
> self.test(*self.arg)
> File
> "/home/ben/.local/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py",
> line 51, in failer
> result = f(*args, **kwargs)
> File
> "/home/ben/.local/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py",
> line 196, in do_test
> '(RMS %(rms).3f)'%err)
> ImageComparisonFailure: images not close:
> /home/ben/Programs/matplotlib/result_images/test_collections/regularpolycollection_scale.png
> vs.
> /home/ben/Programs/matplotlib/result_images/test_collections/regularpolycollection_scale-expected.png
> (RMS 120.828)
>
> ----------------------------------------------------------------------
> Ran 54 tests in 15.149s
>
> FAILED (failures=2)
>
>
>
> The squares in the first test are larger than they should be. I have some
> other errors, but they seem to other be floating point errors, or issues
> with fonts.
>
> Ben Root
>
>
> On Sat, Feb 7, 2015 at 4:46 PM, Thomas Caswell <tca...@gm...> wrote:
>
>> Sandro,
>>
>> Well, creating the tarball on GH is a lot easier for us as it happens
>> automatically! I don't want to unilaterally change policy so I will create
>> the files on SF.
>>
>> If you want to tracking GH for debian instead of SF I don't think that
>> would be a bad idea, but I don't know how much of a hassle that would be
>> for you.
>>
>> Tom
>>
>> On Sat Feb 07 2015 at 4:14:36 PM Sandro Tosi <mo...@de...> wrote:
>>
>>> On Sat, Feb 7, 2015 at 9:05 PM, Thomas Caswell <tca...@gm...>
>>> wrote:
>>> > Sandro,
>>> >
>>> > Can you use the tarball from github
>>> > (https://github.com/matplotlib/matplotlib/archive/v1.4.3rc1.tar.gz ?)
>>>
>>> Sure I can, but since all the previous release (even RC) were done one
>>> SF, we have our tools to monitor and download new releases pointing to
>>> SF: do you plan to switch to GH for releasing tarballs too?
>>>
>>> Cheers,
>>> --
>>> Sandro Tosi (aka morph, morpheus, matrixhasu)
>>> My website: http://matrixhasu.altervista.org/
>>> Me at Debian: http://wiki.debian.org/SandroTosi
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming. The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is
>> your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>

Hi,
On Sat, Feb 7, 2015 at 9:46 PM, Thomas Caswell <tca...@gm...> wrote:
> Sandro,
>
> Well, creating the tarball on GH is a lot easier for us as it happens
> automatically! I don't want to unilaterally change policy so I will create
> the files on SF.
the release tarball contains __pycache__ directories and other binary
files, like lib/matplotlib/backends/_backend_agg.cpython-34m.so
(likely it was generated from a "live" directory, where some tests
have been run).
I just gave a brief look at updating the package and I noticed just
some failures in the tests related to test_axes_grid1 (but it might be
due to an un-clean env, I will re-run in a chroot to be sure), also
any reason not to include
https://github.com/matplotlib/matplotlib/commit/ba4016014cb4fb4927e36ce8ea429fed47dcb787#diff-51
? that would fix CVE-2013-1424
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi