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.