Ludovic Courtès writes: Hi!
>> It seems there is a compatibility bug/problem/thing with the db.sqlite >> that we produce on GNU/Linux. While an unpatched sqlite3 on the Hurd >> can read it, and work with it, the unpatched sqlite has locking >> problems. I found a workaround, though: dumping and loading the >> database file. [..] >> So...about the compatibility problem. I tried to diff the db.sqlite-orig >> db.sqlite-init binary files: they look completely different. Not sure >> how to handle this workaround, maybe we can insert a two system* calls >> somewhere when building the disk image? > > Weird, weird! > > Could you compare ‘db.dump’ created on GNU/Hurd with ‘db.dump’ created > from the same ‘sqlite3 -init’ command on GNU/Linux? Yeah, they are identical. The initial dump can only be created atm on GNU/Linux; the dump can be loaded (obviously) anywhere like so >> $ sqlite3 -init db.dump db.sqlite-init .quit and the resulting initial db.sqlite is the same. Guess we can do that by hand for now... > (Perhaps loading the dump reorders entries or something.) Yes, "or something" certainly! :) I have no clue... If/when we decide to pinpoint this bug, what could be a first step? Who is creating the database right now, is that the C++ daemon or guile-sqlite3. IWBN to have that code create/save a smaller version and see when reading fails. > I think the binary format of the database is supposed to be > architecture-independent and filling it is supposed to be deterministic. Yes, that works. > Congrats for getting this far anyway! Yeah... \o/ Janneke -- Jan Nieuwenhuizen <jann...@gnu.org> | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com