Subject: bug#61852: ‘scheme48-prescheme’ is not reproducible

From: Andrew Whatson <[email-masked]>
Date: Tue, 28 Feb 2023 15:55:23 +1000

Ludovic Courtès wrote:
> Hi again Andrew,
> 
> It turns out that the package is not reproducible:
> 
> --8<---------------cut here---------------start------------->8---
> $ ./pre-inst-env  guix challenge scheme48-prescheme
> /gnu/store/qkby7f4nr3lxlm16zmswmka5hgfs6spw-scheme48-prescheme-1.9.2 contents differ:
>    no local build for '/gnu/store/qkby7f4nr3lxlm16zmswmka5hgfs6spw-scheme48-prescheme-1.9.2'
>    https://ci.guix.gnu.org/nar/lzip/qkby7f4nr3lxlm16zmswmka5hgfs6spw-scheme48-prescheme-1.9.2: 0fahr4s5qz980zz96xmrwf8r87w56kicxr8s80fvis98q7v5czll
>    https://bordeaux.guix.gnu.org/nar/lzip/qkby7f4nr3lxlm16zmswmka5hgfs6spw-scheme48-prescheme-1.9.2: 0jphmcmijk68phwq93qbzszy5pdmnasa3qdcp2nc5wqc25a7kpxk
>    differing file:
>      /lib/scheme48-1.9.2/prescheme.image
> 
> 1 store items were analyzed:
>    - 0 (0.0%) were identical
>    - 1 (100.0%) differed
>    - 0 (0.0%) were inconclusive
> $ git log |head -1
> commit cf9e0508b26196dc985302776d860a0359652c59
> --8<---------------cut here---------------end--------------->8---
> 
> Any idea what might be wrong?

Hmm, interesting!

This is an image produced by Scheme 48 dumping its VM state into a file 
which can be loaded later to save parsing/expansion time.  This is the 
same technique used by Scheme 48 to produce its own initial image.  It 
looks like the "scheme48" package has the same problem:

```
$ guix challenge scheme48
/gnu/store/9c47l5cn60zrr9sm0hn55zibf8zmv33l-scheme48-1.9.2 contents differ:
   local hash: 0pyygj4nf8fw2xpciy81d01r2b2339bxhgpfdn2zq2wqvsn2ycra
 
https://ci.guix.gnu.org/nar/lzip/9c47l5cn60zrr9sm0hn55zibf8zmv33l-scheme48-1.9.2: 
0pyygj4nf8fw2xpciy81d01r2b2339bxhgpfdn2zq2wqvsn2ycra
 
https://bordeaux.guix.gnu.org/nar/lzip/9c47l5cn60zrr9sm0hn55zibf8zmv33l-scheme48-1.9.2: 
12wxxqxmpdqgg2fzbcbm68h1jqynz9gqhxzalyspqq7hh2fgr46k
   differing file:
     /lib/scheme48-1.9.2/scheme48.image

1 store items were analyzed:
   - 0 (0.0%) were identical
   - 1 (100.0%) differed
   - 0 (0.0%) were inconclusive
```

Comparing hex dumps of the files, there are significant differences, and 
a quick dive through the image dumping code leads into VM and garbage 
collector details which are over my head.

I guess patching Scheme 48 to build deterministic images is out-of-scope 
and maybe an issue for upstream.

> Thanks,
> Ludo’.

Cheers!
Andrew