Installation of Racket packages tries to write to the store

Done

Details

5 participants

Gábor Boskovits
Christopher Lemmer Webber
Konrad Hinsen
Nils Gillmann
Timothy Sample

Owner: unassigned

Submitted by: Konrad Hinsen

Severity: normal

Konrad Hinsen wrote on 2 Mar 2018 17:52

Recipients:(address . bug-guix@gnu.org)

Message-ID:m1fu5is9ly.fsf@fastmail.net

Hi everyone,

After installing Racket:

   guix package -i racket

I tried to install a Racket package:

   raco pkg install sxml

I'd expect this to install the package "sxml" into $HOME/.racket, as it
does when Racket is installed via Debian.

It actually does this, and the package is usable and looks complete
(when comparing with an installation on another machine). However, for
bigger packages some compilation results are missing from $HOME/.racket.

There is a long list of errors (full log below) due to Racket trying to
write to locations in the store. The paths suggest that these are
temporary files, and that the location they are written to is completely
bogus (it's the directory that holds the openssl module).

I traced this back as far as I could by looking at the Racket compiler
source code. Compilation generates a temporary file in the same
directory where the result is supposed to go. If no errors occur, the
temporary file is then renamed to become the output. The partial stack
traces point to locations in the code that do a recursive traversal of
a library in order to compile everything. Unfortunately, the part that
decides where the output goes is not referenced in the stack trace.

Konrad.




$ raco pkg install sxml
Resolving "sxml" via https://download.racket-lang.org/releases/6.11/catalog/
Resolving "sxml" via https://pkgs.racket-lang.org
Downloading repository github://github.com/jbclements/sxml/master
raco setup: version: 6.11
raco setup: platform: x86_64-linux [3m]
raco setup: installation name: 6.11
raco setup: variants: 3m
raco setup: main collects: /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects
raco setup: collects paths: 
raco setup:   /home/hinsen/.racket/6.11/collects
raco setup:   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects
raco setup: main pkgs: /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/pkgs
raco setup: pkgs paths: 
raco setup:   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/pkgs
raco setup:   /home/hinsen/.racket/6.11/pkgs
raco setup: links files: 
raco setup:   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/links.rktd
raco setup:   /home/hinsen/.racket/6.11/links.rktd
raco setup: main docs: /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/doc/racket
raco setup: --- updating info-domain tables ---
raco setup: updating: /home/hinsen/.racket/6.11/share/info-cache.rktd
raco setup: --- pre-installing collections ---
raco setup: --- installing foreign libraries ---
raco setup: --- installing shared files ---
raco setup: --- compiling collections ---
raco setup: --- parallel build using 4 jobs ---
raco setup: 3 making: <pkgs>/sxml/sxml (sxml)
open-output-file: cannot open output file
  path: /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/openssl/compiled/tmp15200075491520007549081
  system error: Permission denied; errno=13
  compilation context...:
   /home/hinsen/.racket/6.11/pkgs/sxml/sxml/ssax/access-remote.rkt
   /home/hinsen/.racket/6.11/pkgs/sxml/sxml/ssax/id.rkt
   /home/hinsen/.racket/6.11/pkgs/sxml/sxml/ssax/multi-parser.rkt
   /home/hinsen/.racket/6.11/pkgs/sxml/sxml/xpath-context_xlink.rkt
   /home/hinsen/.racket/6.11/pkgs/sxml/sxml/ddo-axes.rkt
  context...:
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/racket/private/more-scheme.rkt:261:28
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/racket/file.rkt:199:0: call-with-atomic-output-file20
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:363:0: compile-zo*
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:572:26
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:564:42
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:688:15
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:723:0: ormap-strict
   [repeats 1 more time]
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:688:15
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:688:15
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:723:0: ormap-strict
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:688:15
   ...
open-output-file: cannot open output file
  path: /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/openssl/compiled/tmp15200075491520007549156
  system error: Permission denied; errno=13
  compilation context...:
   /home/hinsen/.racket/6.11/pkgs/sxml/sxml/ssax/access-remote.rkt
   /home/hinsen/.racket/6.11/pkgs/sxml/sxml/ssax/id.rkt
   /home/hinsen/.racket/6.11/pkgs/sxml/sxml/ssax/multi-parser.rkt
  context...:
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/racket/private/more-scheme.rkt:261:28
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/racket/file.rkt:199:0: call-with-atomic-output-file20
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:363:0: compile-zo*
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:572:26
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:564:42
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:688:15
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:723:0: ormap-strict
   [repeats 1 more time]
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:688:15
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:688:15
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:723:0: ormap-strict
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:688:15
   ...
open-output-file: cannot open output file
  path: /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/openssl/compiled/tmp15200075491520007549266
  system error: Permission denied; errno=13
  compilation context...:
   /home/hinsen/.racket/6.11/pkgs/sxml/sxml/ssax/access-remote.rkt
   /home/hinsen/.racket/6.11/pkgs/sxml/sxml/ssax/id.rkt
  context...:
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/racket/private/more-scheme.rkt:261:28
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/racket/file.rkt:199:0: call-with-atomic-output-file20
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:363:0: compile-zo*
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:572:26
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:564:42
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:688:15
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:723:0: ormap-strict
   [repeats 1 more time]
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:688:15
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:688:15
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:723:0: ormap-strict
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:688:15
   ...
open-output-file: cannot open output file
  path: /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/openssl/compiled/tmp15200075491520007549365
  system error: Permission denied; errno=13
  compilation context...:
   /home/hinsen/.racket/6.11/pkgs/sxml/sxml/ssax/access-remote.rkt
   /home/hinsen/.racket/6.11/pkgs/sxml/sxml/ssax/id.rkt
   /home/hinsen/.racket/6.11/pkgs/sxml/sxml/ssax/multi-parser.rkt
  context...:
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/racket/private/more-scheme.rkt:261:28
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/racket/file.rkt:199:0: call-with-atomic-output-file20
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:363:0: compile-zo*
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:572:26
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:564:42
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:688:15
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:723:0: ormap-strict
   [repeats 1 more time]
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:688:15
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:688:15
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:723:0: ormap-strict
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:688:15
   ...
raco setup: 3 making: <pkgs>/sxml/sxml/scribblings
open-output-file: cannot open output file
  path: /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/racket/compiled/tmp15200075491520007549402
  system error: Permission denied; errno=13
  compilation context...:
   /home/hinsen/.racket/6.11/pkgs/sxml/sxml/scribblings/extract-provides.rkt
  context...:
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/racket/private/more-scheme.rkt:261:28
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/racket/file.rkt:199:0: call-with-atomic-output-file20
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:363:0: compile-zo*
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:572:26
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:564:42
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:688:15
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:723:0: ormap-strict
   [repeats 6 more times]
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:782:4: compilation-manager-load-handler
   standard-module-name-resolver
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:405:23
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/syntax/modcode.rkt:62:2: reader
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/syntax/modcode.rkt:279:5: compile-one
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:363:0: compile-zo*
   ...
raco setup: 3 making: <pkgs>/sxml/sxml/ssax (ssax)
open-output-file: cannot open output file
  path: /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/openssl/compiled/tmp15200075491520007549425
  system error: Permission denied; errno=13
  compilation context...:
   /home/hinsen/.racket/6.11/pkgs/sxml/sxml/scribblings/util.rkt
  context...:
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/racket/private/more-scheme.rkt:261:28
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/racket/file.rkt:199:0: call-with-atomic-output-file20
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:363:0: compile-zo*
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:572:26
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:564:42
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:688:15
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:688:15
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:688:15
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:688:15
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:688:15
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   ...
open-output-file: cannot open output file
  path: /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/openssl/compiled/tmp15200075491520007549455
  system error: Permission denied; errno=13
  compilation context...:
   /home/hinsen/.racket/6.11/pkgs/sxml/sxml/ssax/access-remote.rkt
  context...:
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/racket/private/more-scheme.rkt:261:28
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/racket/file.rkt:199:0: call-with-atomic-output-file20
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:363:0: compile-zo*
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:572:26
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:564:42
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:688:15
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:723:0: ormap-strict
   [repeats 1 more time]
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:688:15
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:688:15
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:723:0: ormap-strict
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:688:15
   ...
open-output-file: cannot open output file
  path: /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/openssl/compiled/tmp15200075491520007549468
  system error: Permission denied; errno=13
  context...:
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/racket/private/more-scheme.rkt:261:28
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/racket/file.rkt:199:0: call-with-atomic-output-file20
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:363:0: compile-zo*
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:572:26
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:564:42
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:688:15
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:723:0: ormap-strict
   [repeats 1 more time]
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:688:15
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:688:15
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:723:0: ormap-strict
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:688:15
   ...
open-output-file: cannot open output file
  path: /gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/openssl/compiled/tmp15200075491520007549519
  system error: Permission denied; errno=13
  compilati

This message was truncated. Download the full message here.

Christopher Lemmer Webber wrote on 11 Aug 2018 17:18

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

Recipients:(name . Konrad Hinsen)(address . konrad.hinsen@fastmail.net)

Message-ID:87wosxexu7.fsf@dustycloud.org

Konrad Hinsen writes:

Toggle quote (31 lines)> On 22/05/2018 15:42, Christopher Lemmer Webber wrote:
>
>> Unfortunately when I try to install packages with "raco pkg install"
>> I get errors like the following:
>
> I filed a bug report about this problem a while ago:
>
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30680
>
> Quote:
>
>   I traced this back as far as I could by looking at the Racket compiler
>   source code. Compilation generates a temporary file in the same
>   directory where the result is supposed to go. If no errors occur, the
>   temporary file is then renamed to become the output. The partial stack
>   traces point to locations in the code that do a recursive traversal of
>   a library in order to compile everything. Unfortunately, the part that
>   decides where the output goes is not referenced in the stack trace.
>
>> I seem to remember a couple of packages failing altogether, though in
>> the present moment I think the result is bad performance due to not
>> being properly compiled, but I'm not really sure.
>
> In my tests, all packages ended up working, but performance is indeed
> worse than with a Racket installation outside of Guix.
>
> It would be nice if someone with more knowledge of Racket internals
> could give a hint or two for debugging this issue!
>
> Konrad.

I'm posting a bug bounty on this issue: if someone can fix this I will
pay them $250 USD.  I don't have the time or knowledge enough of Racket
internals to do so myself.

Timothy Sample wrote on 11 Aug 2018 22:23

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

Recipients:(name . Christopher Lemmer Webber)(address . cwebber@dustycloud.org)

Message-ID:87h8k0d54i.fsf@ngyro.com

Christopher Lemmer Webber <cwebber@dustycloud.org> writes:

Toggle quote (14 lines)> Konrad Hinsen writes:
>
>> In my tests, all packages ended up working, but performance is indeed
>> worse than with a Racket installation outside of Guix.
>>
>> It would be nice if someone with more knowledge of Racket internals
>> could give a hint or two for debugging this issue!
>>
>> Konrad.
>
> I'm posting a bug bounty on this issue: if someone can fix this I will
> pay them $250 USD.  I don't have the time or knowledge enough of Racket
> internals to do so myself.

I have discovered a few things, but I’m not sure how to fix the

underlying problem(s).

The reason Racket is trying to recompile the OpenSSL files is because of

a hash mismatch. This can be seen by enabling debugging output:

$ PLTSTDERR=debug raco setup openssl

Which says a lot of things, but most interestingly it says:

--------------------------------

...

compiler/cm: checking: /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt

compiler/cm: different src hash... (5d9ca57f3e267d956c7b5e62578467beb8ccc1d2 4d21ac412723fbf33f97669c2f73f0e9367f4510)

compiler/cm: maybe-compile-zo starting /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt

compiler/cm: start-compile: /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt

compiler/cm: compiling /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt

open-output-file: cannot open output file

path: /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/compiled/tmp15340167971534016797570

system error: Read-only file system; errno=30

context...:

...

--------------------------------

This hash mismatch is caused by grafting. When the package is built,

the path to OpenSSL gets hard-coded in a source file. The SHA-1 hash

for this file is stored in its “.dep” file. When the output is grafted,

the source file gets updated with a new OpenSSL path, but the hash does

not get updated. This makes Racket think that the cached bytecode file

is incorrect (even though it was likely grafted too), and it tries to

recompile it. It fails because it tries to write this new bytecode file

to the store.

I double checked this by trying with an ungrafted Racket, and got better

results. (There was still a warning about writing to the store, but it

seemed less significant.)

The only thing I can think of for a fix would be to patch Racket to be

more lenient with bytecode files in the store. That is, ignore hash

mismatches in store-files. I might give this a try later tonight if

nobody has any better ideas.

-- Tim

Christopher Lemmer Webber wrote on 11 Aug 2018 23:55

Recipients:(name . Timothy Sample)(address . samplet@ngyro.com)

Message-ID:87va8gfu0c.fsf@dustycloud.org

Timothy Sample writes:

Toggle quote (49 lines)> Christopher Lemmer Webber <cwebber@dustycloud.org> writes:
>
>> Konrad Hinsen writes:
>>
>>> In my tests, all packages ended up working, but performance is indeed
>>> worse than with a Racket installation outside of Guix.
>>>
>>> It would be nice if someone with more knowledge of Racket internals
>>> could give a hint or two for debugging this issue!
>>>
>>> Konrad.
>>
>> I'm posting a bug bounty on this issue: if someone can fix this I will
>> pay them $250 USD.  I don't have the time or knowledge enough of Racket
>> internals to do so myself.
>
> I have discovered a few things, but I’m not sure how to fix the
> underlying problem(s).
>
> The reason Racket is trying to recompile the OpenSSL files is because of
> a hash mismatch.  This can be seen by enabling debugging output:
>
>     $ PLTSTDERR=debug raco setup openssl
>
> Which says a lot of things, but most interestingly it says:
>
> --------------------------------
> ...
> compiler/cm: checking: /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt
> compiler/cm: different src hash... (5d9ca57f3e267d956c7b5e62578467beb8ccc1d2 4d21ac412723fbf33f97669c2f73f0e9367f4510)
> compiler/cm: maybe-compile-zo starting /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt
> compiler/cm:   start-compile: /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt
> compiler/cm:   compiling /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt
> open-output-file: cannot open output file
>   path: /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/compiled/tmp15340167971534016797570
>   system error: Read-only file system; errno=30
>   context...:
> ...
> --------------------------------
>
> This hash mismatch is caused by grafting.  When the package is built,
> the path to OpenSSL gets hard-coded in a source file.  The SHA-1 hash
> for this file is stored in its “.dep” file.  When the output is
> grafted, the source file gets updated with a new OpenSSL path, but the
> hash does not get updated.  This makes Racket think that the cached
> bytecode file is incorrect (even though it was likely grafted too),
> and it tries to recompile it.  It fails because it tries to write this
> new bytecode file to the store.

Interesting... I hadn't even considered grafting. (I still wonder why

it's even trying to open *any* file in the store for output though...)

Toggle quote (4 lines)

> I double checked this by trying with an ungrafted Racket, and got better

> results. (There was still a warning about writing to the store, but it

> seemed less significant.)

Cool!

Toggle quote (7 lines)

> The only thing I can think of for a fix would be to patch Racket to be

> more lenient with bytecode files in the store. That is, ignore hash

> mismatches in store-files. I might give this a try later tonight if

> nobody has any better ideas.

> -- Tim

BTW, some examples of packages where I've had trouble, in case it helps

with testing:

- Raart

- Gregor

- crypto (seemed to work last time, not sure why it wasn't working before)

Though at this point I also can't do just "raco setup" on a local

package either, but maybe resolving this issue will fix that.

Nils Gillmann wrote on 12 Aug 2018 00:05

Recipients:(name . Christopher Lemmer Webber)(address . cwebber@dustycloud.org)

Message-ID:20180811220538.ca2wyilh6gq62dm3@abyayala

Christopher Lemmer Webber transcribed 3.3K bytes:

Toggle quote (77 lines)> Timothy Sample writes:
> 
> > Christopher Lemmer Webber <cwebber@dustycloud.org> writes:
> >
> >> Konrad Hinsen writes:
> >>
> >>> In my tests, all packages ended up working, but performance is indeed
> >>> worse than with a Racket installation outside of Guix.
> >>>
> >>> It would be nice if someone with more knowledge of Racket internals
> >>> could give a hint or two for debugging this issue!
> >>>
> >>> Konrad.
> >>
> >> I'm posting a bug bounty on this issue: if someone can fix this I will
> >> pay them $250 USD.  I don't have the time or knowledge enough of Racket
> >> internals to do so myself.
> >
> > I have discovered a few things, but I’m not sure how to fix the
> > underlying problem(s).
> >
> > The reason Racket is trying to recompile the OpenSSL files is because of
> > a hash mismatch.  This can be seen by enabling debugging output:
> >
> >     $ PLTSTDERR=debug raco setup openssl
> >
> > Which says a lot of things, but most interestingly it says:
> >
> > --------------------------------
> > ...
> > compiler/cm: checking: /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt
> > compiler/cm: different src hash... (5d9ca57f3e267d956c7b5e62578467beb8ccc1d2 4d21ac412723fbf33f97669c2f73f0e9367f4510)
> > compiler/cm: maybe-compile-zo starting /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt
> > compiler/cm:   start-compile: /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt
> > compiler/cm:   compiling /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt
> > open-output-file: cannot open output file
> >   path: /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/compiled/tmp15340167971534016797570
> >   system error: Read-only file system; errno=30
> >   context...:
> > ...
> > --------------------------------
> >
> > This hash mismatch is caused by grafting.  When the package is built,
> > the path to OpenSSL gets hard-coded in a source file.  The SHA-1 hash
> > for this file is stored in its “.dep” file.  When the output is
> > grafted, the source file gets updated with a new OpenSSL path, but the
> > hash does not get updated.  This makes Racket think that the cached
> > bytecode file is incorrect (even though it was likely grafted too),
> > and it tries to recompile it.  It fails because it tries to write this
> > new bytecode file to the store.
> 
> Interesting... I hadn't even considered grafting.  (I still wonder why
> it's even trying to open *any* file in the store for output though...)
> 
> > I double checked this by trying with an ungrafted Racket, and got better
> > results.  (There was still a warning about writing to the store, but it
> > seemed less significant.)
> 
> Cool!
> 
> > The only thing I can think of for a fix would be to patch Racket to be
> > more lenient with bytecode files in the store.  That is, ignore hash
> > mismatches in store-files.  I might give this a try later tonight if
> > nobody has any better ideas.
> >
> > -- Tim
> 
> BTW, some examples of packages where I've had trouble, in case it helps
> with testing:
> 
>  - Raart
>  - Gregor
>  - crypto (seemed to work last time, not sure why it wasn't working before)
> 
> Though at this point I also can't do just "raco setup" on a local
> package either, but maybe resolving this issue will fix that.
> 

From what I've learned in the last couple of hours, the last problem could

be due to leftovers in your raco / dotRacket folder from an older installation.

Christopher Lemmer Webber wrote on 12 Aug 2018 01:28

Recipients:(name . Nils Gillmann)(address . ng0@n0.is)

Message-ID:87tvo0fpox.fsf@dustycloud.org

Nils Gillmann writes:

Toggle quote (15 lines)> Christopher Lemmer Webber transcribed 3.3K bytes:

>> BTW, some examples of packages where I've had trouble, in case it helps
>> with testing:
>> 
>>  - Raart
>>  - Gregor
>>  - crypto (seemed to work last time, not sure why it wasn't working before)
>> 
>> Though at this point I also can't do just "raco setup" on a local
>> package either, but maybe resolving this issue will fix that.
>> 
> From what I've learned in the last couple of hours, the last problem could
> be due to leftovers in your raco / dotRacket folder from an older installation.

Would be nice if it were so simple, but:

Having removed ~/.racket, try:

$ git clone https://github.com/cwebber/racket-linkeddata.git
$ cd racket-linkeddata/linkeddata

cwebber@jasmine:~/devel/racket-linkeddata/linkeddata$ raco setup
open-output-file: cannot open output file
  path: /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/compiled/tmp15340298121534029812614
  system error: Read-only file system; errno=30
  context...:
   /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/private/more-scheme.rkt:261:28
   /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/file.rkt:199:0: call-with-atomic-output-file20
   /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/compiler/cm.rkt:363:0: compile-zo*
   /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/compiler/cm.rkt:572:26
   /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/compiler/cm.rkt:564:42
   /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/compiler/cm.rkt:688:15
   /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/compiler/cm.rkt:688:15
   /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/compiler/cm.rkt:688:15
   /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/compiler/cm.rkt:635:0: compile-root
   /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/compiler/cm.rkt:782:4: compilation-manager-load-handler
   standard-module-name-resolver
   /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/setup/main.rkt: [running body]
   /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/raco/main.rkt: [running body]
cwebber@jasmine:~/devel/racket-linkeddata/linkeddata$ 


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

... install raart, lots of "cannot open output file" error messages ...
racket@> (require raart)
get-module-code: no such file: #<path:/home/cwebber/.racket/6.12/pkgs/ansi/ansi/private/tty-raw-extension.rkt>
  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

Timothy Sample wrote on 12 Aug 2018 04:03

Recipients:(name . Christopher Lemmer Webber)(address . cwebber@dustycloud.org)

Message-ID:871sb4cpeu.fsf@ngyro.com

Christopher Lemmer Webber <cwebber@dustycloud.org> writes:

Toggle quote (24 lines)> 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.)

Toggle quote (19 lines)> ... install raart, lots of "cannot open output file" error messages ...
> racket@> (require raart)
> get-module-code: no such file: #<path:/home/cwebber/.racket/6.12/pkgs/ansi/ansi/private/tty-raw-extension.rkt>
>   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.

Gábor Boskovits wrote on 12 Aug 2018 11:32

Recipients:(address . samplet@ngyro.com)

Message-ID:CAE4v=pgqSDKTPZFZcXpfn=ZSTd=EgtYRBZmAL2ionjnYZ9nvgg@mail.gmail.com

Timothy Sample <samplet@ngyro.com> ezt írta (id?pont: 2018. aug. 12., V,

4:03):

Toggle quote (93 lines)> Christopher Lemmer Webber <cwebber@dustycloud.org> 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:
> #<path:/home/cwebber/.racket/6.12/pkgs/ansi/ansi/private/tty-raw-extension.rkt>
> >   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.

Attachment: file

Christopher Lemmer Webber wrote on 12 Aug 2018 17:31

Recipients:(name . Timothy Sample)(address . samplet@ngyro.com)

Message-ID:87r2j3fvor.fsf@dustycloud.org

Timothy Sample writes:

Toggle quote (31 lines)> Christopher Lemmer Webber <cwebber@dustycloud.org> 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!

Toggle quote (25 lines)>> ... install raart, lots of "cannot open output file" error messages ...
>> racket@> (require raart)
>> get-module-code: no such file: #<path:/home/cwebber/.racket/6.12/pkgs/ansi/ansi/private/tty-raw-extension.rkt>
>>   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.

Toggle quote (4 lines)

> 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 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.)

Timothy Sample wrote on 12 Aug 2018 20:25

[PATCH] Patch Racket to fix bug #30680

Recipients:(address . guix-patches@gnu.org)

Message-ID:87r2j3bfy0.fsf@ngyro.com

Hi Guix,

(Patch is attached below.)

This patch fixes https://debbugs.gnu.org/30680. 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:

• https://debbugs.gnu.org/19973

• https://debbugs.gnu.org/25752

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!)

Content-Type: text/x-patch

Content-ID: <87pnynbfy0.fsf@ngyro.com>

Content-Transfer-Encoding: binary

-- Tim

Christopher Lemmer Webber wrote on 12 Aug 2018 22:35

Recipients:(name . Timothy Sample)(address . samplet@ngyro.com)(address . guix-patches@gnu.org)

Message-ID:87lg9bfhm8.fsf@dustycloud.org

Timothy Sample writes:

Toggle quote (26 lines)> Hi Guix,
>
> (Patch is attached below.)
>
> This patch fixes <https://debbugs.gnu.org/30680>.  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:
>
>     • <https://debbugs.gnu.org/19973>
>     • <https://debbugs.gnu.org/25752>
>
> 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.fsf@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!

Timothy Sample wrote on 12 Aug 2018 22:44

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

Recipients:(name . Christopher Lemmer Webber)(address . cwebber@dustycloud.org)

Message-ID:87d0unb9hk.fsf@ngyro.com

Christopher Lemmer Webber <cwebber@dustycloud.org> writes:

Toggle quote (16 lines)> Timothy Sample writes:
>
>> Christopher Lemmer Webber <cwebber@dustycloud.org> 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!

Toggle quote (11 lines)>>> ... 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!

Toggle quote (9 lines)

>> 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”.

Toggle quote (16 lines)> 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 https://debbugs.gnu.org/30680.  Also, the
attachment didn’t get sent to the list, but did make it to the bug page.
Hm....  Sorry for the goof!

Timothy Sample wrote on 12 Aug 2018 22:51

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

Recipients:(name . Christopher Lemmer Webber)(address . cwebber@dustycloud.org)(address . guix-patches@gnu.org)

Message-ID:874lfzb966.fsf@ngyro.com

Christopher Lemmer Webber <cwebber@dustycloud.org> writes:

Toggle quote (52 lines)> Timothy Sample writes:
>
>> Hi Guix,
>>
>> (Patch is attached below.)
>>
>> This patch fixes <https://debbugs.gnu.org/30680>.  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:
>>
>>     • <https://debbugs.gnu.org/19973>
>>     • <https://debbugs.gnu.org/25752>
>>
>> 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.fsf@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

Fixes https://debbugs.gnu.org/30680.

* 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

Toggle diff (64 lines)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 000000000..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 <https://debbugs.gnu.org/30680> 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.000000000 -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"))))
+                       "racket-fix-xform-issue.patch"
+                       "racket-store-checksum-override.patch"))))
     (build-system gnu-build-system)
     (arguments
      '(#:phases
-- 
2.18.0

Christopher Lemmer Webber wrote on 13 Aug 2018 02:21

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

Recipients:(name . Timothy Sample)(address . samplet@ngyro.com)

Message-ID:87in4ff75y.fsf@dustycloud.org

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

Timothy Sample writes:

Toggle quote (16 lines)>>> 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.

Toggle quote (27 lines)>> 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 <https://debbugs.gnu.org/30680>.  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 :)

Closed

Konrad Hinsen wrote on 13 Aug 2018 15:56

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

Recipients:(address . guix-patches@gnu.org)

Message-ID:m1a7pqbcaj.fsf@fastmail.net

Timothy Sample <samplet@ngyro.com> writes:

Toggle quote (2 lines)

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

I have ported the patch to Racket 7.0, the modified version is attached.

It gets rid of all the store-related error messages I got when

installing packages with raco, so as far as I am concerned the bug

is indeed fixed.

BTW, the patch (to Guix) for updating Racket to 7.0 is at

https://debbugs.gnu.org/32355

(but does not yet include this patch to Racket).

Thanks a lot for resolving this issue!

Konrad.

From da6defb46b69dfb55e5188ed851f5c1443f748ba Mon Sep 17 00:00:00 2001

(Port to Racket 7.0 of Timothy Sample's patch for Racket 6.12)

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 https://debbugs.gnu.org/30680 for details.

---

collects/compiler/private/cm-minimal.rkt | 8 +++++++-

1 file changed, 7 insertions(+), 1 deletion(-)

Toggle diff (35 lines)diff --git a/collects/compiler/private/cm-minimal.rkt b/collects/compiler/private/cm-minimal.rkt
index a5a5407..15af6b8 100644
--- a/collects/compiler/private/cm-minimal.rkt
+++ b/collects/compiler/private/cm-minimal.rkt
@@ -7,6 +7,7 @@
          racket/list
          racket/path
          racket/promise
+         racket/string
          openssl/sha1
          setup/collects
          compiler/compilation-path
@@ -543,6 +544,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")
@@ -595,7 +600,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:
-- 
2.18.0

Your comment

This issue is archived.

To comment on this conversation send an email to 30680@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it

mumi current 30680

Then, you may apply the latest patchset in this issue (with sign off)

mumi am -- -s

Or, compose a reply to this issue

mumi compose

Or, send patches to this issue

mumi send-email *.patch

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date