Bug 1813075

pythran fails to build after ipython updated to 7.12

____________________ TestIpythonMagic.test_loadext_and_run _____________________
[gw1] linux -- Python 3.8.2 /usr/bin/python3
self = <pythran.tests.test_ipython.TestIpythonMagic testMethod=test_loadext_and_run>
    def test_loadext_and_run(self):
>       subprocess.check_call(['ipython', 'ipython_script.ipy'])
pythran/tests/test_ipython.py:7: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
popenargs = (['ipython', 'ipython_script.ipy'],), kwargs = {}, retcode = 2
cmd = ['ipython', 'ipython_script.ipy']
    def check_call(*popenargs, **kwargs):
        """Run command with arguments.  Wait for command to complete.  If
        the exit code was zero then return, otherwise raise
        CalledProcessError.  The CalledProcessError object will have the
        return code in the returncode attribute.
    
        The arguments are the same as for the call function.  Example:
    
        check_call(["ls", "-l"])
        """
        retcode = call(*popenargs, **kwargs)
        if retcode:
            cmd = kwargs.get("args")
            if cmd is None:
                cmd = popenargs[0]
>           raise CalledProcessError(retcode, cmd)
E           subprocess.CalledProcessError: Command '['ipython', 'ipython_script.ipy']' returned non-zero exit status 2.
/usr/lib64/python3.8/subprocess.py:364: CalledProcessError
----------------------------- Captured stderr call -----------------------------
[TerminalIPythonApp] WARNING | File 'ipython_script.ipy' doesn't exist
______________ TestIpythonMagic.test_loadext_and_run_timeit_twice ______________
[gw2] linux -- Python 3.8.2 /usr/bin/python3
self = <pythran.tests.test_ipython.TestIpythonMagic testMethod=test_loadext_and_run_timeit_twice>
    def test_loadext_and_run_timeit_twice(self):
>       subprocess.check_call(['ipython', 'ipython_script_timeit.ipy'])
pythran/tests/test_ipython.py:10: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
popenargs = (['ipython', 'ipython_script_timeit.ipy'],), kwargs = {}
retcode = 2, cmd = ['ipython', 'ipython_script_timeit.ipy']
    def check_call(*popenargs, **kwargs):
        """Run command with arguments.  Wait for command to complete.  If
        the exit code was zero then return, otherwise raise
        CalledProcessError.  The CalledProcessError object will have the
        return code in the returncode attribute.
    
        The arguments are the same as for the call function.  Example:
    
        check_call(["ls", "-l"])
        """
        retcode = call(*popenargs, **kwargs)
        if retcode:
            cmd = kwargs.get("args")
            if cmd is None:
                cmd = popenargs[0]
>           raise CalledProcessError(retcode, cmd)
E           subprocess.CalledProcessError: Command '['ipython', 'ipython_script_timeit.ipy']' returned non-zero exit status 2.
/usr/lib64/python3.8/subprocess.py:364: CalledProcessError
----------------------------- Captured stderr call -----------------------------
[TerminalIPythonApp] WARNING | File 'ipython_script_timeit.ipy' doesn't exist


See koschei:
https://koschei.fedoraproject.org/package/pythran?collection=f33
https://koschei.fedoraproject.org/package/pythran?collection=f32

The blocks the Python 3.9 rebuild.

For the build logs with Python 3.9, see:
https://copr-be.cloud.fedoraproject.org/results/@python/python3.9/fedora-rawhide-x86_64/01300678-pythran/

For all our attempts to build pythran with Python 3.9, see:
https://copr.fedorainfracloud.org/coprs/g/python/python3.9/package/pythran/

Testing and mass rebuild of packages is happening in copr. You can follow these instructions to test locally in mock if your package builds with Python 3.9:
https://copr.fedorainfracloud.org/coprs/g/python/python3.9/

Let us know here if you have any questions.

Python 3.9 will be included in Fedora 33. To make that update smoother, we're building Fedora packages with early pre-releases of Python 3.9.
A build failure prevents us from testing all dependent packages (transitive [Build]Requires), so if this package is required a lot, it's important for us to get it fixed soon.
We'd appreciate help from the people who know this package best, but if you don't want to work on this now, let us know so we can try to work around it on our side.