Timothy Sample <samp...@ngyro.com> ezt írta (időpont: 2018. aug. 12., V,
4:03):

> Christopher Lemmer Webber <cweb...@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.

Reply via email to