Hide Forgot
Description of problem: trac-0.10.3.1-1.fc6.noarch.rpm is linked against python-sqlite2. Previous versions were linked against python-sqlite3. This makes old environments not work with the new version, since they sqlite2-based version cannot read the sqlite3 databases. Trac should be linked against the sqlite3 version. Version-Release number of selected component (if applicable): trac-0.10.3.1-1
Hmm... Here are the requires for python-sqlite: libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1.3) libc.so.6(GLIBC_2.3) libc.so.6(GLIBC_2.4) libpthread.so.0 libsqlite3.so.0 python(abi) = 2.4 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rtld(GNU_HASH) And here are the requires for python-sqlite2: libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1.3) libc.so.6(GLIBC_2.3) libc.so.6(GLIBC_2.4) libpthread.so.0 libsqlite3.so.0 python(abi) = 2.4 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rtld(GNU_HASH) sqlite >= 3.3.3 This looks to me like both versions of the sqlite python bindings link against sqlite version 3. AFAICS, there is no package named python-sqlite3 in FC6.
Created attachment 149823 [details] Apache log from trying to open existing trac environment These are the errors I got from apache when trying to access Trac URLs after upgrading to trac-0.10.3.1-1.fc6.noarch.rpm with python-sqlite2.
I realize now that the bug report title is misleading, since as you say, there is no python-sqlite3. So the old version (trac-0.10.3.1) was linked against python-sqlite, and the new 10.3.1-1 version is python-sqlite2 (but from what I now understand, both should support sqlite3 databases). The problem is still that the new version could not read my existing trac databases. I'm not sure why (the apache logs I attached earlier indicate that it might be trying to do an upgrade), and given this new information about python-sqlite2, it seems like there shouldn't be a problem. But downgrading made the problem illustrated by the apache logs go away, so there is certainly something wrong.
Trac isn't really "linked" against python-sqlite or python-sqlite2. The trac code is supposed to auto-detect which one is installed. If both are installed I believe that it prefers the python-sqlite2 version based upon what I read in the code. When you upgraded trac was python-sqlite2 installed as a dependency when it wasn't installed before?
Yes, exactly: python-sqlite2 was installed as a dependency for the update to trac-0.10.3.1-1
I got some info that this might be a known issue from the trac-users list: http://initd.org/tracker/pysqlite/ticket/146 A possible work-around is listed there, which involves tweaking apache's config. Looks like some sort of Apache cache is built. I'll try to poke around an see if I can't figure out how to clear it.
After carefully reading the bug report from comment #6, it seems that there is a bug in python-sqlite2-2.3.2; the issue I described with trac is appearently fixed by using python-sqlite-2.3.3. I'll file a bug report against python-sqlite instead.
*** Bug 231907 has been marked as a duplicate of this bug. ***
I'm the poster of https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231907. I just wanted to confirm that the workaround suggested there: rpm -e --nodeps python-sqlite2 has restored function on my system. If you are contemplating applying this patch, I do suggest that you run "rpm -e" (without the --nodeps) to make sure that the only dependency is trac. Trac will run fine after the removal. Matt: what was the bug # for python-sqlite? I'ld like to track that one.
The python-sqlite2 bug is bug # 231848.
Thank you.
The latest version in Extras no longer depends on python-sqlite2. Thanks for all your help.
*** Bug 232162 has been marked as a duplicate of this bug. ***