[IPython-dev] [ANN] IPython 0.13.2 bugfix release candidate

[Thomas Spura]

On Fri, Mar 22, 2013 at 7:12 PM, MinRK <benjaminrk at gmail.com> wrote:
>
>
> On Fri, Mar 22, 2013 at 7:20 AM, Thomas Spura <tomspur at fedoraproject.org>
> wrote:
>>
>> On Wed, Mar 20, 2013 at 9:12 PM, MinRK <benjaminrk at gmail.com> wrote:
>> > I have cut the first release-candidate for the 0.13.2 bugfix release.
>>
>> [snip]
>>
>> > - running tests with iptest / iptest3
>> >
>> > Reports of success are great, but reports of failures are even more
>> > useful.
>>
>> When running the tests in mock, I get the following failure (also
>> already with 0.13.1):
>> ERROR: %pylab works on engines
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>>   File
>> "/builddir/build/BUILDROOT/ipython-0.13.2.rc1-1.fc18.x86_64/usr/lib/python3.3/site-packages/IPython/testing/decorators.py",
>> line 229, in skipper_func
>>     return f(*args, **kwargs)
>>   File
>> "/builddir/build/BUILDROOT/ipython-0.13.2.rc1-1.fc18.x86_64/usr/lib/python3.3/site-packages/IPython/parallel/tests/test_magics.py",
>> line 329, in test_px_pylab
>>     ip.magic("px plot(rand(100))")
>>   File
>> "/builddir/build/BUILDROOT/ipython-0.13.2.rc1-1.fc18.x86_64/usr/lib/python3.3/site-packages/IPython/core/interactiveshell.py",
>> line 2137, in magic
>>     return self.run_line_magic(magic_name, magic_arg_s)
>>   File
>> "/builddir/build/BUILDROOT/ipython-0.13.2.rc1-1.fc18.x86_64/usr/lib/python3.3/site-packages/IPython/core/interactiveshell.py",
>> line 2063, in run_line_magic
>>     result = fn(*args)
>>   File
>> "/builddir/build/BUILDROOT/ipython-0.13.2.rc1-1.fc18.x86_64/usr/lib/python3.3/site-packages/IPython/parallel/client/magics.py",
>> line 234, in px
>>     return self.parallel_execute(line)
>>   File
>> "/builddir/build/BUILDROOT/ipython-0.13.2.rc1-1.fc18.x86_64/usr/lib/python3.3/site-packages/IPython/parallel/client/magics.py",
>> line 259, in parallel_execute
>>     result.get()
>>   File
>> "/builddir/build/BUILDROOT/ipython-0.13.2.rc1-1.fc18.x86_64/usr/lib/python3.3/site-packages/IPython/parallel/client/asyncresult.py",
>> line 125, in get
>>     raise self._exception
>>   File
>> "/builddir/build/BUILDROOT/ipython-0.13.2.rc1-1.fc18.x86_64/usr/lib/python3.3/site-packages/IPython/parallel/client/asyncresult.py",
>> line 150, in wait
>>     raise r
>> IPython.parallel.error.RemoteError: TypeError(can't use a string
>> pattern on a bytes-like object)
>> ======================================================================
>> ERROR: %pylab works on engines
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>>   File
>> "/builddir/build/BUILDROOT/ipython-0.13.2.rc1-1.fc18.x86_64/usr/lib/python3.3/site-packages/IPython/testing/decorators.py",
>> line 229, in skipper_func
>>     return f(*args, **kwargs)
>>   File
>> "/builddir/build/BUILDROOT/ipython-0.13.2.rc1-1.fc18.x86_64/usr/lib/python3.3/site-packages/IPython/parallel/tests/test_view.py",
>> line 615, in test_magic_pylab
>>     reply = ar.get(5)
>>   File
>> "/builddir/build/BUILDROOT/ipython-0.13.2.rc1-1.fc18.x86_64/usr/lib/python3.3/site-packages/IPython/parallel/client/asyncresult.py",
>> line 125, in get
>>     raise self._exception
>>   File
>> "/builddir/build/BUILDROOT/ipython-0.13.2.rc1-1.fc18.x86_64/usr/lib/python3.3/site-packages/IPython/parallel/client/asyncresult.py",
>> line 150, in wait
>>     raise r
>> IPython.parallel.error.RemoteError: TypeError(can't use a string
>> pattern on a bytes-like object)
>>
>>
>> When running iptest3 not inside of mock, anything is fine and I don't
>> know what the difference between those two runs is...
>>
>> Do you have a suggestion/hint, where I could search for the error
>> instead of simply overcome this by skipping those two tests?
>
>
> If you show the remote traceback (RemoteError.print_traceback()), that
> should find the error.

It's somewhere deep in matplotlib and fontconfig, so it has nothing to
do with the ipython side.
I'll track that issue further downstream...

Thanks,
    Tom