GNOME Bugzilla – Bug 658464
insanityweb: sane defaults/fall back gracefully if database does not exist/is not writable
Last modified: 2011-10-29 15:13:05 UTC
The current default location for the sqlite backend in settings.py is os.path.abspath(os.path.dirname(__file__))/../testrun.db In the default setup, this is /usr/[local/]share/insanity/testrun.db, which is unlikely to be writable. Would it make sense to fall back to $HOME/.local/share/insanity/testrun.db if this is the case? (possibly with some loud debugging for the perpetually confused) Also, if the database is empty, we should probably try to fix it at startup, rather than causing "Caught DatabaseError while rendering: no such table: testrun" on page load.
Senko: can you take a look at http://cgit.collabora.com/git/user/alsuren/gst-qa-system.git/log/?h=insanityweb-658464 and tell me whether it looks good? Thanks in advance.
In other news, manage.py daemon locks up when I try to ^C it. If you can work out why my changes cause this to happen, I owe you a beer. If not, I'll take another look tomorrow. ^CStopping the server... and I get the following backtrace with: gdb python `pgrep -f manage.py` ... (gdb) thread apply all bt
+ Trace 228368
Re-worked http://cgit.collabora.com/git/user/alsuren/gst-qa-system.git/log/?h=insanityweb-658464 to make Runner into a proper singleton (rather than one that is initialised on import). There shouldn't be any more locking issues because we only initialise the storage once.
Patches (up to 9f347e2e69fb1b169bd532cd1397fc5df898998) look great. ++ Thanks for fixing those!
Pushed to master by tpm after secondary approval by bilboed (note that 79f347e2e69fb1b169bd532cd1397fc5df898998 is the commit id. Not 9f347e2e69fb1b169bd532cd1397fc5df898998. I assume that this was just a typo) Thanks guys.