Timothy Sample <
address@hidden> ezt írta (időpont: 2018. aug. 12., V, 4:03):
Christopher Lemmer Webber <address@hidden> 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.