Upgrade 0.10.2 -> 0.10.4 fails in fedora 7

[shap@…]

We're restoring after upgrading from FC6 to FC7. Attempts to start trac give a backtrace in the log. Looks like DatabaseManager? cannot connect for some reason. I tried running trac-admin /xxx upgrade by hand. It exited without any complaint. The trac.ini for this site has

database=sqlit:db/trac.db

Oddly, I have been able to dump most of the site using trac-admin. Unfortunately, trac-admin doesn't appear to have any way to dump tickets (now THAT is a bug), so simply creating a new site and reloading our state doesn't look like an option. Is there some way to dump the tickets short of re-installing trac on an FC6 system (which we will do, if we must)?

In any case, I'm hoping there is a simple fix for this short of a re-install from source. We rely on RPM for updates, so we do not consider reinstalling from source to be a viable option.

I have marked this "critical" because anything that takes out a functioning site should be considered critical. If that view isn't consistent with the severity scheme used by EdgeWall?, feel free to adjust.

Here is the traceback from the http error log:

[Mon Aug 06 08:44:38 2007] [error] [client 192.168.1.40]   File "/usr/lib/python2.5/site-packages/trac/web/main.py", line 391, in dispatch_request\n    env = _open_environment(env_path, run_once=run_once)
[Mon Aug 06 08:44:38 2007] [error] [client 192.168.1.40]   File "/usr/lib/python2.5/site-packages/trac/web/main.py", line 58, in _open_environment\n    env_cache[env_path] = open_environment(env_path)
[Mon Aug 06 08:44:38 2007] [error] [client 192.168.1.40]   File "/usr/lib/python2.5/site-packages/trac/env.py", line 463, in open_environment\n    if env.needs_upgrade():
[Mon Aug 06 08:44:38 2007] [error] [client 192.168.1.40]   File "/usr/lib/python2.5/site-packages/trac/env.py", line 341, in needs_upgrade\n    db = self.get_db_cnx()
[Mon Aug 06 08:44:38 2007] [error] [client 192.168.1.40]   File "/usr/lib/python2.5/site-packages/trac/env.py", line 203, in get_db_cnx\n    return DatabaseManager(self).get_connection()
[Mon Aug 06 08:44:38 2007] [error] [client 192.168.1.40]   File "/usr/lib/python2.5/site-packages/trac/db/api.py", line 76, in get_connection\n    return self._cnx_pool.get_cnx(self.timeout or None)
[Mon Aug 06 08:44:38 2007] [error] [client 192.168.1.40]   File "/usr/lib/python2.5/site-packages/trac/db/pool.py", line 101, in get_cnx\n    cnx = self._connector.get_connection(**self._kwargs)
[Mon Aug 06 08:44:38 2007] [error] [client 192.168.1.40]   File "/usr/lib/python2.5/site-packages/trac/db/sqlite_backend.py", line 113, in get_connection\n    return SQLiteConnection(path, params)
[Mon Aug 06 08:44:38 2007] [error] [client 192.168.1.40]   File "/usr/lib/python2.5/site-packages/trac/db/sqlite_backend.py", line 160, in __init__\n    timeout=timeout)
[Mon Aug 06 08:44:38 2007] [error] [client 192.168.1.40] SystemError: NULL result without error in PyObject_Call

[shap@…]

In case it is helpful, I also checked the SELinux audit logs and so forth. To my surprise, this doesn't look like an SELinux issue -- which is a refreshing change. :-)

[shap@…]

Someone on IRC suggested that this might by a python->sqlite binding problem. That seems plausible, but if that is the case I would have expected that trac-admin /path wiki dump would have failed...

jonas: I know that debugging this stuff remotely is a pain in the butt. If you like, email me offline and I'll send a phone number. Happy to run checks on my end if that will help you diagnose, but that sort of thing seems to go faster by phone.

[thatch]

Apparently an issue with FC7's package dependencies. Installing python-sqlite2 and restarting Apache made it work again. Closing as invalid since it's a platform issue, not a Trac one.

[shap@…]

For those who may want to add their voice, the Fedora bug report is here:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246306

[thatch]

And an additional cross-reference, I found this in our ML from earlier: http://lists.edgewall.com/archive/trac/2006-May/008028.html

[anonymous]

Note, however, that the 2006-May bug had pysqlite installed. The issue in my case was a missing Fedora dependency; python-sqlite package was missing in our install.