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

["Ludovic Courtès" <ludo@gnu.org>]

Hi,

Jan Nieuwenhuizen <janneke@gnu.org> skribis:

> 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...

Sorry for catching up days later but… did disabling WAL mode fix this
discrepancy?  IOW, without WAL mode, is the file produced on GNU/Linux
bit-identical to that produced on GNU/Hurd?

> 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.

As you found out it’s created by (guix store database) in this case.

Thanks,
Ludo’.