pyOpenSSL SPKG

[kini]

pyOpenSSL 0.13 doesn't build on systems with sufficiently old OpenSSL versions. A patch exists for this but has not been included upstream. So, we have to make an SPKG.

(This SPKG continues the history of an old pyOpenSSL SPKG I found somewhere.)

Install ​this spkg.

[kini]

Setting this ticket to depend on #13121 because the current sagenb SPKG will overwrite this pyOpenSSL with its own internally included pyOpenSSL 0.12, making it difficult to test this SPKG.

[kini]

Actually maybe we should make this an optional SPKG. It looks like we barely use OpenSSL at all - we can probably just wrap the import and handle it gracefully when pyOpenSSL isn't installed. See also William's comments a while ago ​here.

[kini]

See #13385.

[jhpalmieri]

Keshav: the naming convention for spkgs seems to be to use lowercase almost exclusively. So I would suggest calling this "pyopenssl".

[kini]

OK.

[kini]

Actually I take back my suggestion about waiting for #13121 to go in before testing this - #13121 depends on this, because if #13121 goes in without this ticket going in, people won't have an SPKG-based way to install pyOpenSSL into their Sage.

[jhpalmieri]

If we're making this an optional spkg, then we don't need to patch deps.

[kini]

Yes, the attached patch was mentioned in the description before I decided this should be an optional SPKG. Now it is not mentioned in the description.

Actually now I see there's a way to delete my attachment, so I'm doing so.

[jhpalmieri]

Should the patch command have the form patch ... || die ...?

Otherwise, this seems to build properly. People who have issues with old versions of OpenSSL should test it, though.

[kini]

I figured applying the patch is not going to fail on someone else's system if it worked on my system. I suppose it can't hurt to add a || die though.

Updated SPKG is at the same URL.

[jhpalmieri]

As I said earlier, this builds properly for me. The patch makes sense, too.

I think we have two options with this ticket: (1) Accept the spkg as is, so we can get the new notebook (etc.) merged; then if there are remaining issues with conflicting versions of OpenSSL, we can work on fixing them. (2) Try to get people who have already had issues with old versions of OpenSSL to see if this spkg fixes them.

Since this is an optional spkg, and since I don't know who to ask about option (2), I'm inclined to go with option (1). Keshav, what do you think?

[kini]

Jeroen is the one to ask, as I believe this problem first came up when Jeroen was testing on a buildbot which had an old OpenSSL (OS X 10.4 I think).

But personally I'd go for (1) as I want to see #13121 and its web of dependencies get merged ASAP :)

[jdemeyer]

If it's an optional package: go for it! I don't really care about OpenSSL on this OS X 10.4 machine.

Be sure to test the combination of the OpenSSL spkg with the PyOpenSSL spkg though.

[novoselt]

OK report: I have started with a fresh 5.3.rc0 and got a crash on Debian Wheezy. Then I followed instructions on #13121 and got a message to read README, which after #13385 tells to install pyopenssl. Installing it from this ticket made everything work.

[jhpalmieri]

It certainly builds on top of the Sage OpenSSL package, for example on skynet/iras. Then I can load the pyOpenSSL example files and use them, although they're not very well documented, so I can't use them very much. They work without giving any errors about missing imports or bad libraries or anything like that. So I say it's ready.

[schilly]

i just put this optional spkg on the server+mirrors.