bug#30680: [racket-users] Using Racket's raco on on Guix(SD)

[Christopher Lemmer Webber]

Good news: this seems fixed with this patch.  Some more comments inline.

Timothy Sample writes:

>>> Also, I checked all of this from Racket without grafts, and it never
>>> complained about compiling OpenSSL stuff.  Running “raco setup” gives
>>> some other errors, though.
>>
>> You're right... without grafts it doesn't have the openssl error.  The
>> other writing to the store issues still seem to persist, but it doesn't
>> block running "raco setup" (after a "raco pkg install", a step I had
>> omitted earlier).
>
> Okay.  I was confused about the “raco setup” example, but the other step
> makes more sense now.
>
> I will say that even on Debian, with an regular user, I have seen
> “permission denied” errors because Racket tries to update files in
> “/usr/share”.

Okay... on that note, "raco pkg install" now completely works IME
without permission errors, I should mention.  I'm still seeing a couple
of permission errors on "raco setup", but they don't look like they
matter unlike the ones that were appearing earlier.  And you're right,
I tried on Debian and got some errors too.

For the record, the ones I saw looked like this:

delete-file: cannot delete file
  path: /gnu/store/33rx7rh6q22h3r11x8prz37nl7ygfl22-racket-6.12/bin/raco
  system error: Read-only file system; errno=30
  context...:
   
/gnu/store/33rx7rh6q22h3r11x8prz37nl7ygfl22-racket-6.12/share/racket/collects/launcher/launcher.rkt:358:0:
 make-unix-launcher
   
/gnu/store/33rx7rh6q22h3r11x8prz37nl7ygfl22-racket-6.12/share/racket/collects/setup/setup-core.rkt:1451:13:
 for-loop
   
/gnu/store/33rx7rh6q22h3r11x8prz37nl7ygfl22-racket-6.12/share/racket/collects/setup/setup-core.rkt:1428:8:
 make-launcher
   
/gnu/store/33rx7rh6q22h3r11x8prz37nl7ygfl22-racket-6.12/share/racket/collects/setup/setup-core.rkt:1556:8:
 for-loop
   
/gnu/store/33rx7rh6q22h3r11x8prz37nl7ygfl22-racket-6.12/share/racket/collects/setup/setup-core.rkt:178:50
   
/gnu/store/33rx7rh6q22h3r11x8prz37nl7ygfl22-racket-6.12/share/racket/collects/setup/setup-core.rkt:1425:4:
 for-loop
   
/gnu/store/33rx7rh6q22h3r11x8prz37nl7ygfl22-racket-6.12/share/racket/collects/setup/setup-core.rkt:71:0:
 setup-core
   
/gnu/store/33rx7rh6q22h3r11x8prz37nl7ygfl22-racket-6.12/share/racket/collects/setup/main.rkt:
 [running body]
   
/gnu/store/33rx7rh6q22h3r11x8prz37nl7ygfl22-racket-6.12/share/racket/collects/raco/main.rkt:
 [running body]

But again, I don't think they matter.

>> ISTM that this is a separate bug.  In fact I'm afraid I've polluted this
>> bug with what I thought were all the same bug but turned out to be
>> several different bugs, of which a couple are fixed now thanks to your
>> help.
>>
>> PS: About the bounty, my thoughts are that some of these smaller issues
>> being resolved are already worth a smaller amount of compensation (and
>> thanks!), but there are *two different* larger issues of which probably
>> either is worth the full amount (though I can only afford to pay for
>> one)... one of them is the issue of the grafts breaking eg openssl
>> (which maybe we should file as a separate bug?), and the other is this
>> original bug (30680) about the attempts to compile to the store (which
>> does not seem as big of a blocker as it did previously, but is still
>> very annoying).  Does that seem fair?  (Feel free to contact me
>> off-list.)
>
> Actually I think there is only one bug, which is the grafts thing.  This
> bug was originally about compiling OpenSSL files to the store.  Grafting
> doesn’t break OpenSSL it just makes Racket try to recompile its OpenSSL
> FFI wrappers.
>
> I have a patch, too.  I sent it to guix-patches, but I must have made a
> mistake because it ended up in bug-guix attached to this bug report.
> The patch can be found at .  Also, the
> attachment didn’t get sent to the list, but did make it to the bug page.
> Hm  Sorry for the goof!

It seems good to me.  I'm going to push it.  Thanks for your work on
this!

I'll email you off-list about paying the bounty :)

bug#30680: [PATCH] Patch Racket to fix bug #30680

[Timothy Sample]

Christopher Lemmer Webber  writes:

> Timothy Sample writes:
>
>> Hi Guix,
>>
>> (Patch is attached below.)
>>
>> This patch fixes .  It does so by
>> patching Racket to treat store files specially.  I have verified that it
>> both fixes the bug above and still recompiles non-store files.
>>
>> As far as I can tell, Racket only uses these checksums as part of its
>> “setup” library.  When deciding whether to use a bytecode file during
>> evaluation, it does not verify the checksum.  That’s why only the
>> “setup” code is patched.
>>
>> As a side note, both GDB and Go have similar problems:
>>
>> • 
>> • 
>>
>> If there ever is a more general solution, this patch will no longer be
>> necessary.
>>
>> (Also, Racket takes a bit of time to build, so reviewers beware!)
>>
>>
>> -- Tim
>
> Oh wait... it seems like the patch is not actually attached?  I assume
> that must be an error!
>
> Actually if I look at the raw view of the email I see:
>
> --=-=-=
> Content-Type: message/external-body;
>  
> name="/home/samplet/code/guix-wip-racket/0001-gnu-racket-Ignore-bytecode-checksums-in-the-store.patch";
>  access-type=local-file
>
> Content-Type: text/x-patch
> Content-ID: <87pnynbfy0@ngyro.com>
> Content-Transfer-Encoding: binary
>
>
>
> --=-=-=
>
> So it looks like it should be attached, but I don't see the file
> contents?
>
> Perhaps this is an error on my end!  But I'm very eager to test this
> patch!

Oops!  My fault.  The patch is attached here.  *crosses fingers*

>From 69383706548fadf550c84b3f0d07fc55d1c67858 Mon Sep 17 00:00:00 2001
From: Timothy Sample 
Date: Sun, 12 Aug 2018 11:12:38 -0400
Subject: [PATCH] gnu: racket: Ignore bytecode checksums in the store.

Fixes .

* gnu/packages/patches/racket-store-checksum-override.patch: New file.
* gnu/packages/scheme.scm (racket)[sources]: Add it.
---
 .../racket-store-checksum-override.patch  | 42 +++
 gnu/packages/scheme.scm   |  3 +-
 2 files changed, 44 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/racket-store-checksum-override.patch

diff --git a/gnu/packages/patches/racket-store-checksum-override.patch b/gnu/packages/patches/racket-store-checksum-override.patch
new file mode 100644
index 0..b22facca0
--- /dev/null
+++ b/gnu/packages/patches/racket-store-checksum-override.patch
@@ -0,0 +1,42 @@
+Racket uses checksums to test if it needs to recompile its source
+files to bytecode.  If Racket is updated by grafting, the source and
+bytecode files get updated, but the checksum stays the same.  Since
+the checksum no longer matches the source file, Racket tries to
+regenerate the bytecode and write it to the store, causing errors
+because the store is immutable.  This patch makes Racket ignore
+checksums for files in the store.
+
+See  for details.
+
+diff -ruN racket-6.12/collects/compiler/cm.rkt racket-6.12-patched/collects/compiler/cm.rkt
+--- racket-6.12/collects/compiler/cm.rkt	1969-12-31 19:00:00.0 -0500
 racket-6.12-patched/collects/compiler/cm.rkt	2018-08-12 06:36:46.061142149 -0400
+@@ -7,6 +7,7 @@
+  racket/list
+  racket/path
+  racket/promise
++ racket/string
+  openssl/sha1
+  racket/place
+  setup/collects
+@@ -627,6 +628,10 @@
+   #f
+   (list src-hash recorded-hash)))
+ 
++(define (store-reference? path)
++  (let ([store-prefix (or (getenv "NIX_STORE") "/gnu/store")])
++(string-prefix? (path->string path) store-prefix)))
++
+ (define (rkt->ss p)
+   (if (path-has-extension? p #".rkt")
+   (path-replace-extension p #".ss")
+@@ -679,7 +684,8 @@
+   (trace-printf "newer src... ~a > ~a" path-time path-zo-time)
+   ;; If `sha1-only?', then `maybe-compile-zo' returns a #f or thunk:
+   (maybe-compile-zo sha1-only? deps path->mode roots path orig-path read-src-syntax up-to-date collection-cache new-seen)]
+- [(different-source-sha1-and-dep-recorded path deps)
++ [(and (not (store-reference? path))
++   (different-source-sha1-and-dep-recorded path deps))
+   => (lambda (difference)
+(trace-printf "different src hash... ~a" difference)
+;; If `sha1-only?', then `maybe-compile-zo' returns a #f or thunk:
diff --git a/gnu/packages/scheme.scm b/gnu/packages/scheme.scm
index 4178a45a8..b30245cce 100644
--- a/gnu/packages/scheme.scm
+++ b/gnu/packages/scheme.scm
@@ -421,7 +421,8 @@ implementation techniques and as an expository tool.")
  (patches (search-patches
;; See: https://github.com/racket/racket/issues/1962
;; This can be removed in whatever Racket release comes after 6.12
-   "racket-fix-xform-issue.patch"
+   

bug#30680: [racket-users] Using Racket's raco on on Guix(SD)

[Timothy Sample]

Christopher Lemmer Webber  writes:

> Timothy Sample writes:
>
>> Christopher Lemmer Webber  writes:
>>
>>> Likewise, Gregor and Raart do not install:
>>>
>>> [...]
>>
>> This is a timezone issue.  The “tzinfo” package cannot find the
>> “zoneinfo” directory in GuixSD.  If you install the “tzdata” Racket
>> package, things seem to settle down.  (It would be better to tell
>> “tzinfo” to use the system database, but that’s harder to do.)
>
> Oh that's true.  I guess this was multiple issues.  Anyway, horray, that
> one seems ok now!

I’m glad to hear it!

>>> ... install raart, lots of "cannot open output file" error messages ...
>>> [...]
>>
>> I got better results with “raart” when “gcc-toolchain” was available
>> (i.e., “guix environment --ad-hoc gcc-toolchain”).  I guess it has to
>> compile a bit of native code, so it needs a compiler.  It still brakes
>> due to a syntax error, but I get the same error on Debian, so I guess
>> that’s something.  :)
>
> Yep... that seems to have fixed the install of that issue.

Cool!

>> Also, I checked all of this from Racket without grafts, and it never
>> complained about compiling OpenSSL stuff.  Running “raco setup” gives
>> some other errors, though.
>
> You're right... without grafts it doesn't have the openssl error.  The
> other writing to the store issues still seem to persist, but it doesn't
> block running "raco setup" (after a "raco pkg install", a step I had
> omitted earlier).

Okay.  I was confused about the “raco setup” example, but the other step
makes more sense now.

I will say that even on Debian, with an regular user, I have seen
“permission denied” errors because Racket tries to update files in
“/usr/share”.

> ISTM that this is a separate bug.  In fact I'm afraid I've polluted this
> bug with what I thought were all the same bug but turned out to be
> several different bugs, of which a couple are fixed now thanks to your
> help.
>
> PS: About the bounty, my thoughts are that some of these smaller issues
> being resolved are already worth a smaller amount of compensation (and
> thanks!), but there are *two different* larger issues of which probably
> either is worth the full amount (though I can only afford to pay for
> one)... one of them is the issue of the grafts breaking eg openssl
> (which maybe we should file as a separate bug?), and the other is this
> original bug (30680) about the attempts to compile to the store (which
> does not seem as big of a blocker as it did previously, but is still
> very annoying).  Does that seem fair?  (Feel free to contact me
> off-list.)

Actually I think there is only one bug, which is the grafts thing.  This
bug was originally about compiling OpenSSL files to the store.  Grafting
doesn’t break OpenSSL it just makes Racket try to recompile its OpenSSL
FFI wrappers.

I have a patch, too.  I sent it to guix-patches, but I must have made a
mistake because it ended up in bug-guix attached to this bug report.
The patch can be found at .  Also, the
attachment didn’t get sent to the list, but did make it to the bug page.
Hm  Sorry for the goof!

bug#30680: [PATCH] Patch Racket to fix bug #30680

[Christopher Lemmer Webber]

Timothy Sample writes:

> Hi Guix,
>
> (Patch is attached below.)
>
> This patch fixes .  It does so by
> patching Racket to treat store files specially.  I have verified that it
> both fixes the bug above and still recompiles non-store files.
>
> As far as I can tell, Racket only uses these checksums as part of its
> “setup” library.  When deciding whether to use a bytecode file during
> evaluation, it does not verify the checksum.  That’s why only the
> “setup” code is patched.
>
> As a side note, both GDB and Go have similar problems:
>
> • 
> • 
>
> If there ever is a more general solution, this patch will no longer be
> necessary.
>
> (Also, Racket takes a bit of time to build, so reviewers beware!)
>
>
> -- Tim

Oh wait... it seems like the patch is not actually attached?  I assume
that must be an error!

Actually if I look at the raw view of the email I see:

--=-=-=
Content-Type: message/external-body;
 
name="/home/samplet/code/guix-wip-racket/0001-gnu-racket-Ignore-bytecode-checksums-in-the-store.patch";
 access-type=local-file

Content-Type: text/x-patch
Content-ID: <87pnynbfy0@ngyro.com>
Content-Transfer-Encoding: binary



--=-=-=

So it looks like it should be attached, but I don't see the file
contents?

Perhaps this is an error on my end!  But I'm very eager to test this
patch!

bug#30680: [racket-users] Using Racket's raco on on Guix(SD)

[Christopher Lemmer Webber]

Timothy Sample writes:

> Christopher Lemmer Webber  writes:
>
>> Likewise, Gregor and Raart do not install:
>>
>> $ mv ~/.racket ~/.racket-borked
>> $ raco pkg install gregor   # lots of errors during install
>> $ racket
>> racket@> (require gregor)
>> explode-path: contract violation
>>   expected: (or/c path-for-some-system? path-string?)
>>   given: #f
>>   context...:
>>
>> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/path.rkt:116:0:
>>  do-explode-path
>>
>> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/path.rkt:126:0:
>>  find-relative-path7
>>/home/cwebber/.racket/6.12/pkgs/tzinfo/tzinfo/private/zoneinfo.rkt:117:2: 
>> for-loop
>>/home/cwebber/.racket/6.12/pkgs/tzinfo/tzinfo/private/zoneinfo.rkt:107:0: 
>> read-tzids
>>/home/cwebber/.racket/6.12/pkgs/tzinfo/tzinfo/private/zoneinfo.rkt:70:0: 
>> make-zoneinfo-source
>>
>> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/contract/private/arrow-val-first.rkt:388:18
>>/home/cwebber/.racket/6.12/pkgs/tzinfo/tzinfo/main.rkt:63:0: system-tzid
>>
>> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/contract/private/arrow-val-first.rkt:388:18
>>/home/cwebber/.racket/6.12/pkgs/gregor-lib/gregor/private/moment.rkt: 
>> [running body]
>>/home/cwebber/.racket/6.12/pkgs/gregor-lib/gregor/private/generics.rkt: 
>> [traversing imports]
>>/home/cwebber/.racket/6.12/pkgs/gregor-lib/gregor/private/clock.rkt: 
>> [traversing imports]
>>/home/cwebber/.racket/6.12/pkgs/gregor-lib/gregor/main.rkt: [traversing 
>> imports]
>>
>> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/private/misc.rkt:88:7
>
> This is a timezone issue.  The “tzinfo” package cannot find the
> “zoneinfo” directory in GuixSD.  If you install the “tzdata” Racket
> package, things seem to settle down.  (It would be better to tell
> “tzinfo” to use the system database, but that’s harder to do.)

Oh that's true.  I guess this was multiple issues.  Anyway, horray, that
one seems ok now!

>> ... install raart, lots of "cannot open output file" error messages ...
>> racket@> (require raart)
>> get-module-code: no such file: 
>> #
>>   context...:
>>
>> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/syntax/modcode.rkt:120:0:
>>  get-module-path54
>>
>> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/syntax/modcode.rkt:225:0:
>>  get-module-code82
>>
>> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/private/more-scheme.rkt:261:28
>>standard-module-name-resolver
>>
>> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/private/more-scheme.rkt:261:28
>>standard-module-name-resolver
>>
>> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/private/more-scheme.rkt:261:28
>>standard-module-name-resolver
>>
>> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/require-transform.rkt:266:2:
>>  expand-import
>>parse-reprov-spec1
>>
>> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/syntax/wrap-modbeg.rkt:46:4
>>
>> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/private/more-scheme.rkt:261:28
>>standard-module-name-resolver
>>
>> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/private/misc.rkt:88:7
>
> I got better results with “raart” when “gcc-toolchain” was available
> (i.e., “guix environment --ad-hoc gcc-toolchain”).  I guess it has to
> compile a bit of native code, so it needs a compiler.  It still brakes
> due to a syntax error, but I get the same error on Debian, so I guess
> that’s something.  :)

Yep... that seems to have fixed the install of that issue.

> Also, I checked all of this from Racket without grafts, and it never
> complained about compiling OpenSSL stuff.  Running “raco setup” gives
> some other errors, though.

You're right... without grafts it doesn't have the openssl error.  The
other writing to the store issues still seem to persist, but it doesn't
block running "raco setup" (after a "raco pkg install", a step I had
omitted earlier).

ISTM that this is a separate bug.  In fact I'm afraid I've polluted this
bug with what I thought were all the same bug but turned out to be
several different bugs, of which a couple are fixed now thanks to your
help.

PS: About the bounty, my thoughts are that some of these smaller issues
being resolved are already worth a smaller amount of compensation (and
thanks!), but there are *two different* larger issues of which probably
either is worth the full amount (though I can only afford to pay for
one)... one of them is the issue of the grafts breaking eg openssl
(which 

bug#30680: [PATCH] Patch Racket to fix bug #30680

[Timothy Sample]

Hi Guix,

(Patch is attached below.)

This patch fixes .  It does so by
patching Racket to treat store files specially.  I have verified that it
both fixes the bug above and still recompiles non-store files.

As far as I can tell, Racket only uses these checksums as part of its
“setup” library.  When deciding whether to use a bytecode file during
evaluation, it does not verify the checksum.  That’s why only the
“setup” code is patched.

As a side note, both GDB and Go have similar problems:

• 
• 

If there ever is a more general solution, this patch will no longer be
necessary.

(Also, Racket takes a bit of time to build, so reviewers beware!)

<<< message/external-body; name="/home/samplet/code/guix-wip-racket/0001-gnu-racket-Ignore-bytecode-checksums-in-the-store.patch"; access-type=local-file: Unrecognized >>>

-- Tim

bug#30680: [racket-users] Using Racket's raco on on Guix(SD)

[Gábor Boskovits]

Timothy Sample  ezt írta (időpont: 2018. aug. 12., V,
4:03):

> Christopher Lemmer Webber  writes:
>
> > Likewise, Gregor and Raart do not install:
> >
> > $ mv ~/.racket ~/.racket-borked
> > $ raco pkg install gregor   # lots of errors during install
> > $ racket
> > racket@> (require gregor)
> > explode-path: contract violation
> >   expected: (or/c path-for-some-system? path-string?)
> >   given: #f
> >   context...:
> >
> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/path.rkt:116:0:
> do-explode-path
> >
> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/path.rkt:126:0:
> find-relative-path7
> >
> /home/cwebber/.racket/6.12/pkgs/tzinfo/tzinfo/private/zoneinfo.rkt:117:2:
> for-loop
> >
> /home/cwebber/.racket/6.12/pkgs/tzinfo/tzinfo/private/zoneinfo.rkt:107:0:
> read-tzids
> >
> /home/cwebber/.racket/6.12/pkgs/tzinfo/tzinfo/private/zoneinfo.rkt:70:0:
> make-zoneinfo-source
> >
> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/contract/private/arrow-val-first.rkt:388:18
> >/home/cwebber/.racket/6.12/pkgs/tzinfo/tzinfo/main.rkt:63:0:
> system-tzid
> >
> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/contract/private/arrow-val-first.rkt:388:18
> >/home/cwebber/.racket/6.12/pkgs/gregor-lib/gregor/private/moment.rkt:
> [running body]
> >
> /home/cwebber/.racket/6.12/pkgs/gregor-lib/gregor/private/generics.rkt:
> [traversing imports]
> >/home/cwebber/.racket/6.12/pkgs/gregor-lib/gregor/private/clock.rkt:
> [traversing imports]
> >/home/cwebber/.racket/6.12/pkgs/gregor-lib/gregor/main.rkt:
> [traversing imports]
> >
> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/private/misc.rkt:88:7
>
> This is a timezone issue.  The “tzinfo” package cannot find the
> “zoneinfo” directory in GuixSD.  If you install the “tzdata” Racket
> package, things seem to settle down.  (It would be better to tell
> “tzinfo” to use the system database, but that’s harder to do.)
>
> > ... install raart, lots of "cannot open output file" error messages ...
> > racket@> (require raart)
> > get-module-code: no such file:
> #
> >   context...:
> >
> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/syntax/modcode.rkt:120:0:
> get-module-path54
> >
> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/syntax/modcode.rkt:225:0:
> get-module-code82
> >
> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/private/more-scheme.rkt:261:28
> >standard-module-name-resolver
> >
> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/private/more-scheme.rkt:261:28
> >standard-module-name-resolver
> >
> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/private/more-scheme.rkt:261:28
> >standard-module-name-resolver
> >
> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/require-transform.rkt:266:2:
> expand-import
> >parse-reprov-spec1
> >
> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/syntax/wrap-modbeg.rkt:46:4
> >
> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/private/more-scheme.rkt:261:28
> >standard-module-name-resolver
> >
> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/private/misc.rkt:88:7
>
> I got better results with “raart” when “gcc-toolchain” was available
> (i.e., “guix environment --ad-hoc gcc-toolchain”).  I guess it has to
> compile a bit of native code, so it needs a compiler.  It still brakes
> due to a syntax error, but I get the same error on Debian, so I guess
> that’s something.  :)
>
> Also, I checked all of this from Racket without grafts, and it never
> complained about compiling OpenSSL stuff.  Running “raco setup” gives
> some other errors, though.
> In the

Actually this problem resembles me to another one, it's similar to why gdb
is not working when grafting is used. I believe that the correct solution
to these types of issues would be to recompute the hashes, and provide the
updated hashes to the packages relying on them, so that they know the
correct hash of the grafted file. In the gdb case this seems to be easier
to solve, as the problem occurs inside a single package.