1759 2011-11-07 16:36:08 +0000 OperationalError: database is locked 2011-11-21 02:34:49 +0000 1 1 7 Build System, Metadata & Runtime BitBake bitbake 1.0 x86 Multiple RESOLVED FIXED High critical 1.0 PointRelease 1 elizabeth.flanagan josh elizabeth.flanagan josh poky.bs.watcher poky.watcher richard.purdie sgw --- --- --- oldest_to_newest 17148 0 elizabeth.flanagan 2011-11-07 16:36:08 +0000 Narrowed down and able to consistently repeat on OpenSuse 11.4/Python 2.7/sqlite3 2.6.0: bitbake poky-image-minimal poky-image-sato Pseudo is not present but is required, building this first before the main build NOTE: Error expanding variable WORKDIR | ETA: --:--:-- ERROR: Error parsing /srv/home/eflanagan/poky/meta/recipes-graphics/xorg-lib/libx11_git.bb: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception OperationalError: database is locked ERROR: Command execution failed: Exited with 1 eflanagan@autobuilder01:~/poky/build> env|grep PYTHON PYTHONSTARTUP=/etc/pythonstart ---------------- Interesting issues: 1. Only occurs during first run. Subsequent runs do not have this issue 2. Does not occur during a strace of bitbake ..... 3. Only occurring on the autobuilders Obviously an issue with sqlite3 and bitbake here. The best thought I have for why it doesn't occur during a strace is that we're seeing a timing issue here. 17154 1 josh 2011-11-08 08:43:24 +0000 Richard's intuition is that this error is caused by a floating SRCREV. Following this lead today. 17156 2 josh 2011-11-08 12:04:16 +0000 Frustratingly I can't reproduce this on a stock OpenSUSE 11.4 install (with updates), I don't see any relevant floating SRCREV's yet either. 17159 3 josh 2011-11-08 12:56:50 +0000 Workaround pushed to my bernard branch: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=josh/bernard&id=85c18bd1f093011f711e3c43ff93d48e6a9c9c7e 17189 4 elizabeth.flanagan 2011-11-13 22:21:03 +0000 Fixed in bernard. 17193 5 elizabeth.flanagan 2011-11-14 11:15:47 +0000 Reopening as 85c18bd1f093011f hasn't been pulled into bernard 17224 6 josh 2011-11-15 16:19:44 +0000 Update subject to reflect that this isn't OpenSuse specific. 17227 7 elizabeth.flanagan 2011-11-15 23:13:39 +0000 Were you able to replicate it outside of Opensuse? 17278 8 richard.purdie 2011-11-21 02:34:49 +0000 I'm going to mark this as resolved since the pressing issue of failures has been identified and fixed for Barnard. There is a separate bug open for investigating why such large timeouts are required (http://bugzilla.pokylinux.org/show_bug.cgi?id=1761).