Hi! Jan Nieuwenhuizen <jann...@gnu.org> 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’.
