David Bolen added the comment:
No recent changes to the buildbot (I think the last was in September to bump
the local python used to run the slave/build installer to 2.7).
The default system sqlite (/usr/lib) is 3.0.8.6, so extremely old, but 3.6.11
is in /usr/local/{lib,include} from early days of setting up the slave, so only
marginally less old. As long as the python build process finds that (which it
appears to) it should be consistent.
I configured and built a local 3.x branch version of python on the slave and
modified it to dump the version info during module initialization:
> ./python.exe
Python 3.7.0a0 (heads/master:d1ae24e, Apr 21 2017, 15:06:29)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
SQLITE_VERSION: 3.6.11
SQLITE_VERSION_NUMBER: 3006011
sqlite3_libversion: 3.6.11
so it appears to be in line. This local build still fails the test.
Maybe whatever feature is needed for this test is broken with 3.6.11.
One thing I did notice, though I suspect it's not an issue, but the 3.6.11 this
slave is using seems to fall into the gap in the original bpo-9303 _v2 support
patch where a _v2 prepare with a plain close (versions >= 3.3.9 and <3.7.14).
Both plain and _v2 close methods have the same signature, but I wonder if there
might be an issue mixing and matching?
I don't think anything else has a hard dependency on my /usr/local libraries on
the slave at this point (the dmg installer builds its own local copies), so I
could try updating that to a more current sqlite3 if we wanted to see if that
resolved the issue.
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue30126>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
