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.