Bug 506552 – dev-python/cffi-0.8.2: IOError: [Errno 2] No such file or directory: '/usr/lib64/python2.7/site-packages/cryptography/hazmat/bindings/__pycache__/_cffi__x5eaa210axf0ae7e21.c

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Amadeusz Żołnowski (RETIRED) 2014-04-02 12:46:25 UTC]

I get following exception when running Gajim. It occurs with cffi-0.8.2, with 0.8.1 it's OK.

$ gajim
Traceback (most recent call last):
  File "gajim.py", line 72, in <module>
    import nbxmpp
  File "/usr/lib64/python2.7/site-packages/nbxmpp/__init__.py", line 14, in <module>
    import simplexml, protocol, auth_nb, transports_nb, roster_nb
  File "/usr/lib64/python2.7/site-packages/nbxmpp/auth_nb.py", line 37, in <module>
    import rndg
  File "/usr/lib64/python2.7/site-packages/nbxmpp/rndg.py", line 25, in <module>
    import OpenSSL.rand
  File "/usr/lib64/python2.7/site-packages/OpenSSL/__init__.py", line 8, in <module>
    from OpenSSL import rand, crypto, SSL
  File "/usr/lib64/python2.7/site-packages/OpenSSL/rand.py", line 11, in <module>
    from OpenSSL._util import (
  File "/usr/lib64/python2.7/site-packages/OpenSSL/_util.py", line 4, in <module>
    binding = Binding()
  File "/usr/lib64/python2.7/site-packages/cryptography/hazmat/bindings/openssl/binding.py", line 83, in __init__
    self._ensure_ffi_initialized()
  File "/usr/lib64/python2.7/site-packages/cryptography/hazmat/bindings/openssl/binding.py", line 99, in _ensure_ffi_initialized
    libraries)
  File "/usr/lib64/python2.7/site-packages/cryptography/hazmat/bindings/utils.py", line 72, in build_ffi
    ext_package="cryptography",
  File "/usr/lib64/python2.7/site-packages/cffi/api.py", line 341, in verify
    lib = self.verifier.load_library()
  File "/usr/lib64/python2.7/site-packages/cffi/verifier.py", line 73, in load_library
    self._write_source()
  File "/usr/lib64/python2.7/site-packages/cffi/verifier.py", line 125, in _write_source
    file = open(self.sourcefilename, 'w')
IOError: [Errno 2] No such file or directory: '/usr/lib64/python2.7/site-packages/cryptography/hazmat/bindings/__pycache__/_cffi__x5eaa210axf0ae7e21.c'

Reproducible: Always

[Comment 1 Amadeusz Żołnowski (RETIRED) 2014-04-02 12:50:40 UTC]

Created attachment 374090 [details]
emerge --info dev-python/cffi

[Comment 2 Dirkjan Ochtman (RETIRED) 2014-04-02 12:57:30 UTC]

I asked upstream about it.

[Comment 3 Justin Lecher (RETIRED) 2014-04-02 13:03:44 UTC]

you need to rebuild dev-python/cryptography.

[Comment 4 Mike Gilbert 2014-04-02 15:44:35 UTC]

*** Bug 506442 has been marked as a duplicate of this bug. ***

[Comment 5 Ian Delaney (RETIRED) 2014-04-07 14:10:02 UTC]

(In reply to Justin Lecher from comment #3)
> you need to rebuild dev-python/cryptography.

You implying this kicks it into a working state therefore this is NO bug?

[Comment 6 Justin Lecher (RETIRED) 2014-04-07 14:40:11 UTC]

(In reply to Ian Delaney from comment #5)
> (In reply to Justin Lecher from comment #3)
> > you need to rebuild dev-python/cryptography.
> 
> You implying this kicks it into a working state therefore this is NO bug?

it does, but we don't have any mechanism right now which trigger the rebuild automatically or semi-manually (revdep-rebuild). Can we do something here to force it?

[Comment 7 Mike Gilbert 2014-04-07 14:45:15 UTC]

(In reply to Justin Lecher from comment #6)
> it does, but we don't have any mechanism right now which trigger the rebuild
> automatically or semi-manually (revdep-rebuild). Can we do something here to
> force it?

Revbumping dev-python/cryptography would do the job.

I'm not clear on what causes the problem in the first place. When would one need to rebuild this?

[Comment 8 Dirkjan Ochtman (RETIRED) 2014-04-07 16:54:58 UTC]

Justin, what Mike (and I), I think, are wondering is why this cryptography would need rebuilding when cffi is bumped. Do you have an actual explanation or statement from upstream that this is the case, or do you just see empirically that it helps? Because it sure seems to me like an upstream (cffi) bug.

[Comment 9 Justin Lecher (RETIRED) 2014-04-07 17:20:52 UTC]

I simply tried. I as the most obvious choice because dev-python/cryptography was the next package upwards in the stacktrace.

[Comment 10 Ian Delaney (RETIRED) 2014-04-17 15:43:26 UTC]

from my memory of working cffi it makes and references such _cffi__VERY-LONG-NUMBER.c files in a __pycache__ as a matter of course.  I observed this from working lxml-cffi, a pypy capable lxml branch of cffi by a pypy dev, over some days and I am quite sure no-one else ever did.  Since it's > 6 months ago I can't recall the details but what we have is cffi seeking such files in a system installed cryptography.  It suggests to me that the cffi package is building is getting muddled looking for files where they should never be found in a system installed cryptography.  Why it does this with cryptography only I wouldn't know, but if I recall it's to do with the .pyc files.  You really need someone who properly understands cffi and its operating mechanisims.  It's clearly neither easy nor common knowledge, kind of pypy like.  I started to back then.  The re-emerging of cryptography I suspect does some form of re-initializing.

[Comment 11 Dirkjan Ochtman (RETIRED) 2014-05-08 09:53:41 UTC]

After further deliberation with upstream, it appears that we currently have to rebuild all cffi-dependent packages on a cffi update. Do we have some nice slotting-based way to make Portage handle that for us?

[Comment 12 Justin Lecher (RETIRED) 2014-05-08 11:51:08 UTC]

(In reply to Dirkjan Ochtman from comment #11)
> After further deliberation with upstream, it appears that we currently have
> to rebuild all cffi-dependent packages on a cffi update. Do we have some
> nice slotting-based way to make Portage handle that for us?

Subslots should do it, shouldn't them?

[Comment 13 Michał Górny 2014-05-08 12:43:50 UTC]

Yes, likely:

  SLOT="0/${PV}"

in dev-python/cffi, and:

  dev-python/cffi:=[${PYTHON_USEDEP}]

in deps.

[Comment 14 Michał Górny 2014-05-08 21:47:18 UTC]

And subslot added to cffi. Now it's just the matter of adding slot operators on rev-deps. And then, the matter of making people add them in the future...

[Comment 15 Michał Górny 2014-05-08 22:37:27 UTC]

So the subslot is there, and all rev-rdeps were updated and bumped. i think this concludes this as FIXED since everything should start working well starting with next @world update.

[Comment 16 Dirkjan Ochtman (RETIRED) 2014-05-09 06:01:05 UTC]

Thanks for doing that!