Stabilize dev-python/apsw-3.6.21.1.
This requires sqlite-3.6.21 to go stable first, right?? At least tests fail instantly with 3.6.20, so maybe the ebuild needs to be updated to have this dep? * Testing of dev-python/apsw-3.6.21.1 with Python 2.6... Python /usr/bin/python2.6 (2, 6, 4, 'final', 0) Testing with APSW file /var/tmp/portage/dev-python/apsw-3.6.21.1/work/apsw-3.6.21-r1/build-2.6/lib.linux-i686-2.6/apsw.so APSW version 3.6.21-r1 SQLite lib version 3.6.20 SQLite headers version 3006020 Using amalgamation False Unraiseable exception <type 'exceptions.OSError'>:[Errno 13] Permission denied File "tests.py", line 7515, in <module> setup() File "tests.py", line 7467, in setup val=multiprocessing.Value("i", 0) File "/usr/lib/python2.6/multiprocessing/__init__.py", line 248, in Value return Value(typecode_or_type, *args, **kwds) File "/usr/lib/python2.6/multiprocessing/sharedctypes.py", line 75, in Value lock = RLock() File "/usr/lib/python2.6/multiprocessing/__init__.py", line 178, in RLock return RLock() File "/usr/lib/python2.6/multiprocessing/synchronize.py", line 142, in __init__ SemLock.__init__(self, RECURSIVE_MUTEX, 1, 1) File "/usr/lib/python2.6/multiprocessing/synchronize.py", line 49, in __init__ sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) Otherwise tested with sqlite-3.6.21 everything is alright.
(In reply to comment #1) > This requires sqlite-3.6.21 to go stable first, right?? I can't reproduce any test failure with dev-db/sqlite-3.6.20-r1 and dev-python/apsw-3.6.21.1.
I can confirm outside my chroot. Inside I am not able to reproduce.
(In reply to comment #3) > I can confirm outside my chroot. Inside I am not able to reproduce. Other way round. In chroot USE="fts3 readline" for sqlite, outside USE=readline.
Ok, same here: Fails in chroot, good outside. And look at the error, it's a permissions error. So it seems like test.py is requesting something that is not allows inside the chroot.
(In reply to comment #5) > Ok, same here: Fails in chroot, good outside. And look at the error, it's a > permissions error. So it seems like test.py is requesting something that is > not allows inside the chroot. So this problem could be safely ignored.
x86 stable and closing.