bug#42151: [PATCH 0/3] offload to Childhurd fails: setting synchronous mode: locking protocol

[Jan Nieuwenhuizen]

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 <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com