+++ This bug was initially created as a clone of Bug #263714 +++ This is a 'similar' bug (upgrading to svn 1.6.0 breaks trac) After subversion upgrade to 1.6.0, Trac-0.11.2 stopped to work due to a conflict in Subversion SQLite3 usage and Trac usage. Subversion calls sqlite3_config to initialize multithreaded mode, however Trac has already started using SQLite3 databases, so sqlite3_config fails. I have implemented a temporary hack-fix in my setup to ignore failure on sqlite3_config. Fix posted to Subversion as http://subversion.tigris.org/issues/show_bug.cgi?id=3387 A potential solution that may work is updating subversion to use sqlite3_open_v2 with threading options set so that it errors out if threading is actually disabled. Reproducible: Always Steps to Reproduce: trac-admin <path-to-trac-repo> resync Resyncing repository history... Traceback (most recent call last): File "/usr/bin/trac-admin", line 8, in <module> load_entry_point('Trac==0.11.2', 'console_scripts', 'trac-admin')() File "/usr/lib/python2.5/site-packages/trac/admin/console.py", line 1298, in run admin.run() File "/usr/lib/python2.5/site-packages/trac/admin/console.py", line 140, in run self.cmdloop() File "/usr/lib/python2.5/cmd.py", line 142, in cmdloop stop = self.onecmd(line) File "/usr/lib/python2.5/site-packages/trac/admin/console.py", line 123, in onecmd rv = cmd.Cmd.onecmd(self, line) or 0 File "/usr/lib/python2.5/cmd.py", line 219, in onecmd return func(arg) File "/usr/lib/python2.5/site-packages/trac/admin/console.py", line 665, in do_resync repos = env.get_repository().sync(self._resync_feedback) File "/usr/lib/python2.5/site-packages/trac/env.py", line 277, in get_repository return RepositoryManager(self).get_repository(authname) File "/usr/lib/python2.5/site-packages/trac/versioncontrol/api.py", line 157, in get_repository repos = self._connector.get_repository(rtype, rdir, authname) File "/usr/lib/python2.5/site-packages/trac/versioncontrol/svn_fs.py", line 280, in get_repository 'branches': self.branches}) File "/usr/lib/python2.5/site-packages/trac/versioncontrol/svn_fs.py", line 401, in __init__ self.repos = repos.svn_repos_open(self.path, self.pool()) File "/usr/lib/python2.5/site-packages/libsvn/repos.py", line 55, in svn_repos_open return apply(_repos.svn_repos_open, args) svn.core.SubversionException: ('Could not configure SQLite', 200030)
This has already been fixed, emerge --sync and try again please, thx. *** This bug has been marked as a duplicate of bug 263714 ***
(In reply to comment #1) > This has already been fixed, emerge --sync and try again please, thx. > > *** This bug has been marked as a duplicate of bug 263714 *** > Sorry, not a dupe. I jumped the gun, assigning to maintainer for review. Thanks for reporting.
Could this be somehow related to the fact that subversion-1.6.0-r1 pulled in sqlite-3.6.12 without the threadsafe USE option? I was just coming here to file a bug on that.
(In reply to comment #3) > Could this be somehow related to the fact that subversion-1.6.0-r1 pulled in > sqlite-3.6.12 without the threadsafe USE option? I was just coming here to file > a bug on that. Nope, threadsafe USE flag is independent of this initialization. The initialization is performed to set at runtime what type of threadsafety to use... though I suspect that if threadsafe is not set on sqlite3 that there might be failures with setting the threadsafe options in Subversion..
(In reply to comment #0) > Fix posted to Subversion as > http://subversion.tigris.org/issues/show_bug.cgi?id=3387 Please describe this problem more precisely on dev@subversion.tigris.org mailing list. http://subversion.tigris.org/mailing-lists.html
Created attachment 188029 [details, diff] subversion-1.6.1-fix-sqlite-configuration.patch Please test this patch.
Created attachment 188030 [details, diff] Patch for subversion-1.6.1.ebuild
(In reply to comment #6) > Created an attachment (id=188029) [edit] > subversion-1.6.1-fix-sqlite-configuration.patch > > Please test this patch. This patch does resolve the problem... though it leaves open the potential problem of SQLite3 not being setup for multithreaded operation... However, given the current exposed SQLite3 API, there isn't much in terms of alternate options.
https://svn.collab.net/viewvc/svn?view=revision&revision=37185
Fixed.