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

From: Ludovic Courtès <[email-masked]>
Date: Fri, 03 Jul 2020 15:51:29 +0200

Hi!

Jan Nieuwenhuizen <[email-masked]> skribis:

> Thanks -- it seems that buys us a pretty cheap fix after all, $-wise ;)

Heheh.  :-)

> It turns out that Debian's patch (and thus this patch series) is
> probably OK: It fixes the locking problem on the Hurd, while exposing
> another bug, apparently: "unable to open database file".
>
> 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.
>
> Look...
>
> $ scp childhurd2:/var/guix/db/db.sqlite db.sqlite-orig
> db.sqlite                                                                       100%  144KB   5.8MB/s   00:00    
> 11:30:37 janneke@dundal:~/tmp [env]
> $ sqlite3 db.sqlite-orig .dump > db.dump
> 11:30:45 janneke@dundal:~/tmp [env]
> $ sqlite3 -init db.dump db.sqlite-init .quit
> -- Loading resources from db.dump
> 11:30:49 janneke@dundal:~/tmp [env]
> $ cmp db.sqlite-orig db.sqlite-init 
> db.sqlite-orig db.sqlite-init differ: byte 19, line 1
> [1]11:31:11 janneke@dundal:~/tmp [env]
> $ scp db.sqlite-init childhurd2:/var/guix/db/db.sqlite
> db.sqlite-init                                                                  100%  144KB   7.3MB/s   00:00    
> 11:31:21 janneke@dundal:~/tmp [env]
> $ guix offload test
> guix offload: testing 1 build machines defined in '/etc/guix/machines.scm'...
> guix offload: Guix is usable on 'localhost' (test returned "/gnu/store/883yjkl46dxw9mzykykmbs0yzwyxm17z-test")
> guix offload: 'localhost' is running GNU Guile 3.0.4
> sending 1 store item (0 MiB) to 'localhost'...
> exporting path `/gnu/store/y6b7bjqsazmm6jsyj5y80dqqajysw64p-export-test'
> guix offload: 'localhost' successfully imported '/gnu/store/y6b7bjqsazmm6jsyj5y80dqqajysw64p-export-test'
> retrieving 1 store item from 'localhost'...
> guix offload: successfully imported '/gnu/store/gxz6hzyc1cy3m1w9l7f2dk6rcspvymxf-import-test' from 'localhost'
> 11:31:29 janneke@dundal:~/tmp [env]
>
> 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?  (Perhaps loading
the dump reorders entries or something.)

I think the binary format of the database is supposed to be
architecture-independent and filling it is supposed to be deterministic.

Congrats for getting this far anyway!

Ludo’.