Ludovic Courtès writes: Hi!
> "Jan (janneke) Nieuwenhuizen" <jann...@gnu.org> skribis: > >> $ guix offload test >> guix offload: testing 1 build machines defined in '/etc/guix/machines.scm'... >> guix offload: Guix is usable on 'childhurd' (test returned >> "/gnu/store/883yjkl46dxw9mzykykmbs0yzwyxm17z-test") >> guix offload: 'childhurd' is running GNU Guile 3.0.4 >> guix offload: error: exception occurred on remote host 'localhost': >> (%exception #<inferior-object #<&store-protocol-error message: >> "setting synchronous mode: locking protocol" status: 1>>) > Does it help if you set ‘settings.fsyncMetadata = false’ in the daemon? > As a stop-gap, we could add a command-line option if that helps. Tried that, thanks. No, it does not help. (But that's good news, see below!) > The “synchronous = normal” mode translates to ‘fsync’ calls, right? If > you rpctrace sqlite3, do you see ‘file_sync’ calls failing? Tried that before, rpctrace hangs before I see something useful. > Does sqlite pass its tests on GNU/Hurd? That's the (or at least a) right question: YES! > My 2¢! Thanks -- it seems that buys us a pretty cheap fix after all, $-wise ;) 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... --8<---------------cut here---------------start------------->8--- $ 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] --8<---------------cut here---------------end--------------->8--- 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? Greetings, Janneke -- Jan Nieuwenhuizen <jann...@gnu.org> | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
