Description of problem: python is failing to build from source on F17 and rawhide. Needed to add an Obsoletes for python-sqlite2 and that's how I discovered this. Version-Release number of selected component (if applicable): python-2.7.2-19.fc18 How reproducible: Everytime Steps to Reproduce: 1. fedpkg clone python 2. cd python 3. fedpkg build Actual results: Build fails Expected results: Build succeeds Additional info: F17: http://koji.fedoraproject.org/koji/taskinfo?taskID=3800336 F18: http://koji.fedoraproject.org/koji/taskinfo?taskID=3800334 Same problems with the tests: 347 tests OK. 1 test failed: test_ssl 39 tests skipped: test_aepack test_al test_applesingle test_bsddb185 test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_dl test_gdb test_gl test_imgfile test_ioctl test_kqueue test_linuxaudiodev test_macos test_macostools test_msilib test_ossaudiodev test_pep277 test_scriptpackages test_smtpnet test_socketserver test_startfile test_sunaudiodev test_timeout test_tk test_ttk_guionly test_unicode_file test_urllib2net test_urllibnet test_winreg test_winsound test_zipfile64 4 skips unexpected on linux2: test_gdb test_ioctl test_tk test_ttk_guionly [1219652 refs] make: *** [test] Error 1
Both F17 and F18 builds failed due to this test case failing within test_ssl: ====================================================================== FAIL: test_openssl_version (test.test_ssl.BasicSocketTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/builddir/build/BUILD/Python-2.7.2/Lib/test/test_ssl.py", line 151, in test_openssl_version (s, t)) AssertionError: ('OpenSSL 1.0.1-fips-beta2 19 Jan 2012', (1, 0, 0, 0, 3)) ----------------------------------------------------------------------
Both the f17 and f18 builds were against openssl-1.0.1-0.1.beta2.fc17 The last successful build of python was python-2.7.2-18.fc17: http://koji.fedoraproject.org/koji/buildinfo?buildID=281149 which was against openssl-1.0.0e-3.fc17 The failing assertion is (edited for conciseness): s = ssl.OPENSSL_VERSION t = ssl.OPENSSL_VERSION_INFO major, minor, fix, patch, status = t # Version string as returned by OpenSSL, the format might change self.assertTrue(s.startswith("OpenSSL {:d}.{:d}.{:d}".format(major, minor, fix)), (s, t)) It looks like: ssl.OPENSSL_VERSION == 'OpenSSL 1.0.1-fips-beta2 19 Jan 2012' ssl.OPENSSL_VERSION_INFO == (1, 0, 0, 0, 3) and the assertion is complaining because the string version starts with 'OpenSSL 1.0.1', whereas the tuple version is somehow 1.0.0 This probably affects the "python3" src.rpm also: the test case in Python-3.2.2 appears to share the same code.
Looking in Python-2.7.2/Modules/_ssl.c: ssl.OPENSSL_VERSION comes from: SSLeay_version(SSLEAY_VERSION) via this code: 1748 r = PyString_FromString(SSLeay_version(SSLEAY_VERSION)); 1749 if (r == NULL || PyModule_AddObject(m, "OPENSSL_VERSION", r)) 1750 return; ssl.OPENSSL_VERSION_INFO comes from: SSLeay() via this code: 1726 /* OpenSSL version */ 1727 /* SSLeay() gives us the version of the library linked against, 1728 which could be different from the headers version. 1729 */ 1730 libver = SSLeay(); 1731 r = PyLong_FromUnsignedLong(libver); 1732 if (r == NULL) 1733 return; 1734 if (PyModule_AddObject(m, "OPENSSL_VERSION_NUMBER", r)) 1735 return; 1736 status = libver & 0xF; 1737 libver >>= 4; 1738 patch = libver & 0xFF; 1739 libver >>= 8; 1740 fix = libver & 0xFF; 1741 libver >>= 8; 1742 minor = libver & 0xFF; 1743 libver >>= 8; 1744 major = libver & 0xFF; 1745 r = Py_BuildValue("IIIII", major, minor, fix, patch, status); 1746 if (r == NULL || PyModule_AddObject(m, "OPENSSL_VERSION_INFO", r)) 1747 return;
CCing tmraz (openssl owner) tmraz: any thoughts? are SSLeay() and SSLeay_version(SSLEAY_VERSION) out-of-sync somehow?
In /usr/src/debug/openssl-1.0.1-beta2/crypto/cversion.c: 65 const char *SSLeay_version(int t) 66 { 67 if (t == SSLEAY_VERSION) 68 return OPENSSL_VERSION_TEXT; and: 113 unsigned long SSLeay(void) 114 { 115 return(SSLEAY_VERSION_NUMBER); 116 } /usr/include/openssl/opensslv.h has: 28 #define OPENSSL_VERSION_NUMBER 0x10000003L 29 #ifdef OPENSSL_FIPS 30 #define OPENSSL_VERSION_TEXT "OpenSSL 1.0.1-fips-beta2 19 Jan 2012" 31 #else 32 #define OPENSSL_VERSION_TEXT "OpenSSL 1.0.1-beta2 19 Jan 2012" 33 #endif Reassigning to openssl
This is with openssl-1.0.1-0.1.beta2.fc17.x86_64
Also Ruby are FTBFS. I cannot build updated Ruby. The following tests are failing: https://github.com/ruby/ruby/blob/trunk/test/openssl/test_x509cert.rb https://github.com/ruby/ruby/blob/trunk/test/drb/test_drbssl.rb
(In reply to comment #7) > Also Ruby are FTBFS. I cannot build updated Ruby. The following tests are > failing: > > https://github.com/ruby/ruby/blob/trunk/test/openssl/test_x509cert.rb > https://github.com/ruby/ruby/blob/trunk/test/drb/test_drbssl.rb For reference, which of these tests are failing, and how?
(In reply to comment #8) > (In reply to comment #7) > > Also Ruby are FTBFS. I cannot build updated Ruby. The following tests are > > failing: > > > > https://github.com/ruby/ruby/blob/trunk/test/openssl/test_x509cert.rb > > https://github.com/ruby/ruby/blob/trunk/test/drb/test_drbssl.rb > > For reference, which of these tests are failing, and how? Actually the failures are bit different than what you described here. I opened separate issue for Ruby: https://bugzilla.redhat.com/show_bug.cgi?id=797217
Thanks. Retitling this issue to restrict it to the thing that breaks the Python test (incoherent versioning).
Can you please drop this test from the python testsuite? Unfortunately the numeric version number has to be kept the same as was in the 1.0.0 version because it is part of the ABI. I've never seen any other application that would compare the numeric version number with the string.
I'll try to provide symbol versioning for the SSLeay() function so it returns the old version to apps compiled against 1.0.0 and a new version against apps built with 1.0.1.
Please try the build against the current rawhide - it should now return coherent version for newly built apps.
Works: http://koji.fedoraproject.org/koji/taskinfo?taskID=3843404 test_ssl test_sslwrap_simple (test.test_ssl.BasicTests) ... ok test_DER_to_PEM (test.test_ssl.BasicSocketTests) ... ok test_ciphers (test.test_ssl.BasicSocketTests) ... ok test_constants (test.test_ssl.BasicSocketTests) ... ok test_openssl_version (test.test_ssl.BasicSocketTests) ... ok test_parse_cert (test.test_ssl.BasicSocketTests) ... {'notAfter': 'Feb 16 16:54:50 2013 GMT', 'subject': ((('countryName', u'US'),), (('stateOrProvinceName', u'Delaware'),), (('localityName', u'Wilmington'),), (('organizationName', u'Python Software Foundation'),), (('organizationalUnitName', u'SSL'),), (('commonName', u'somemachine.python.org'),))} ok Could you do an update for f17 too please?
F17 is reverted to 1.0.0g due to other regressions. See: https://admin.fedoraproject.org/updates/FEDORA-2012-2665/openssl-1.0.0g-4.fc17
This fake OPENSSL_VERSION downgrade also bites Squid-3 on F16 which uses OPENSSL_VERSION to adjust to slight differences in a couple of openssl-1.0.x versions.
Unfortunately as I said there is no way to avoid that fake downgrade for released distros. On Fedora rawhide this is solved by using symbol versioning.