Description of problem: It is a dependency of new pyOpenSSL Some effort is recorded at http://luther.ceplovi.cz/git/python-cryptography-pkg.git
While python-crytography depends on python-cffi, the failures in your build log don't make it obvious to me that the problem is in cffi. I'm not necessarily saying it isn't there, but it seems like there are various places it might be. I'm using python-cffi in python-cairocffi, and haven't observed any issues, though that doesn't prove that there's not a bug in python-cffi. In the assertion that's failing: assert 2164263935L == 2147486719 the hexadecimal values are 0x81000bff and 0x80000bff. Clearly there's a discrepancy, but it's not something as simple as byte ordering or a missing byte. I'm not sure how I can help with debugging this. Perhaps the python-cryptography upstream developers might some ideas.
I will try to ask upstream. And this should probably be added to the pyOpenSSL before I make a package review.
Adding an upstream bug.
The test needs patching, this is no problem of python-cffi. In general, there might be some SSL_CTX_OPTIONS pre-set as default so you cannot expect the output options to be the same as the options that are parameter of the call.
Yes, this is definitely pyca/cryptography's bug. We're tracking it on the GitHub issue and will have the test fixed shortly. Thanks for the report!
*** This bug has been marked as a duplicate of bug 1114267 ***