Message292075
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. |
|
Date |
User |
Action |
Args |
2017-04-21 19:39:31 | db3l | set | recipients:
+ db3l, ronaldoussoren, vstinner, ned.deily, palaviv |
2017-04-21 19:39:31 | db3l | set | messageid: <1492803571.45.0.106089565167.issue30126@psf.upfronthosting.co.za> |
2017-04-21 19:39:31 | db3l | link | issue30126 messages |
2017-04-21 19:39:31 | db3l | create | |
|