Errors with (display) when building derivations from the REPL.
I’m trying to do some work on Guix with Emacs and Geiser, and while a lot of things work fairly well, I consistently run into problems when trying to build derivations from the Geiser REPL. From what I can tell by looking at where it’s breaking, it seems to me like the output of the build process is supposed to be captured for display by the client, but (for whatever reason) the output port its supposed to go to is closed. The failing line appears to be these (found in guix/store.scm:758): --8<---cut here---start->8--- (let ((s (read-maybe-utf8-string p))) (display s (current-build-output-port)) --8<---cut here---end--->8--- I don’t know if this is an actual bug, or if I’m expected to set up the output port myself before attempting to do a build from the REPL. If it is an actual bug, I’ll be happy to submit this to the issue tracker. If it’s not, can someone tell me what I’m supposed to be doing for this to work? Also, is there a reason that the build’s output port doesn’t just default to standard output so no setup would be necessary? Sample code: --8<---cut here---start->8--- (define-module (bjc repltest) #:use-module (guix derivations) #:use-module (guix gexp) #:use-module (guix monads) #:use-module (guix store)) (define (m) (with-store store (run-with-store store (mlet %store-monad ((drv (lower-object (computed-file "test" #~(mkdir #$output) (mbegin %store-monad (built-derivations (list drv))) --8<---cut here---end--->8--- Backtrace: --8<---cut here---start->8--- scheme@(bjc repltest)> (m) ice-9/boot-9.scm:1685:16: In procedure raise-exception: In procedure display: Wrong type argument in position 2: #string 7f38350291c0> Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. scheme@(bjc repltest) [1]> ,bt In ice-9/boot-9.scm: 1752:10 8 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _) In guix/store.scm: 658:37 7 (thunk) In guix/monads.scm: 560:2 6 (run-with-store # 7f382193fb90> _ #:guile-for-build _ #:system _ #:target _) In guix/store.scm: 2001:38 5 (_ #) 1421:15 4 (_ # _ _) 759:14 3 (process-stderr _ _) In unknown file: 2 (display "substitute: \r" # 7f38350291c0>) In ice-9/boot-9.scm: 1685:16 1 (raise-exception _ #:continuable? _) 1685:16 0 (raise-exception _ #:continuable? _) --8<---cut here---end--->8--- -bjc
Re: Viewing derivation output in the store
Josselin Poiret writes: > Just for completeness' sake, here's my take on it from yesterday while > we were talking about it with Brian: Thank you for that, it was very enlightening. > (define-module (test) > #:use-module (guix gexp) > #:use-module (guix monads) > #:use-module (guix derivations) > #:use-module (guix store)) > > (define test-gexp > #~(begin > (copy-file #$(plain-file "helloes.txt" "contents") #$output) > (format #t "Helloes~%"))) > > (with-store store > (run-with-store store > (mlet* %store-monad > ((drv (gexp->derivation "myderivation" test-gexp)) > (output -> (derivation->output-path drv))) > (mbegin %store-monad > (built-derivations (list drv)) > (return (format #t "~a~%" output)) I tried playing with this for a while and ran into an issue when actually executing it in a REPL: if the derivation hasn’t yet been built, then during execution of of the ‘built-derivations’, an error is thrown: ---[snip]--- ice-9/boot-9.scm:1685:16: In procedure raise-exception: In procedure display: Wrong type argument in position 2: # Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. scheme@(zgrub) [1]> ,bt In ice-9/boot-9.scm: 1752:10 9 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _) In /home/bjc/guix/guix/store.scm: 658:37 8 (thunk) 2129:24 7 (run-with-store # _ #:guile-for-build _ #:system _ #:target _) In current input: 6373:8 6 (_ _) In /home/bjc/guix/guix/store.scm: 2001:38 5 (_ #) 1421:15 4 (_ # _ _) 759:13 3 (process-stderr _ _) In unknown file: 2 (display "building path(s) `/gnu/store/5jdlbc8vf5d0hf4inzj9k7gq6r9k6xsy-grub.cfg'\n" #) In ice-9/boot-9.scm: 1685:16 1 (raise-exception _ #:continuable? _) 1685:16 0 (raise-exception _ #:continuable? _) ---[snip]--- I’m way too new to all this to say for sure, but it seems to me that the build log output is being sent to a string, which, at least in the REPL, is closed prematurely (if it’s ever even opened). If I wait a bit for the derivation to build, executing the above code works fine and produces output in the output path. Is this something that’s worthy of a bug report, or am I doing things I’m not supposed to be doing by building derivations in a REPL? > I tried to use the most monadic approach here to demonstrate its > usefulness, however, it seems to me that derivation->output-path is not > documented, along with built-derivations (which is just (store-lift > build-derivations)). Yes, thankfully the code was either easy to infer from the name (derivation->output-path) or easy to read (built-derivations). > Lesson learned: don't shadow gexp (hence `test-gexp`)! > > As an aside: is there anything preventing us from having do notation à > la Haskell? This could help bridge mlet and mbegin with >>=, which in > its current form is impractical. Here's what it could look like: Because of the above error, and general cluelessness, I tried removing the ‘mbegin’ and found that the error went away, but the derivation wasn’t built. My (wrong) assumption was that the ‘mbegin’ was redundant with the ‘mlet’ since I figured the body of the mlet was in the monad context. The documentation also describes mbegin as akin to mlet, although at least the argument list implies a difference with careful reading: mlet has ‘body’ while mbegin uses ‘mexp’. > (mdo %store-monad > (drv <- (gexp-derivation "myderivation" test-gexp)) > (output <- (return (derivation->output-path drv))) > (built-derivations (list drv)) > (return (format #t "~a~%" output))) > > We could even have some more sugar for (x <- (return y)), Haskell has > `let x = y`, but we could instead have something like `(x := y)`? This would definitely be more intelligible to me, at least, and I know precious little Haskell. One final note that’s worth covering: while I was digging through code I noticed that file-like objects have an embedded gexp derivation. In the documentation they are described as the declarative counterpart of ‘gexp->derivation’, but since there is no documented way of turning them directly into a derivation, I was at a loss for what to do with them until someone in IRC suggested using the #~(copy-file …) gexp above. It turns out that there are ‘gexp-compiler’ instructions for these things, which will turn them back into derivations. However, there doesn’t seem to be a way to call them directly, and the only way I could find to invoke them was by using ‘lower-object’ (again found by grep-find through the codebase). This makes an intuitive sense, but the naming implies I’m missing some larger architectural picture here where ‘raising’ and ‘lowering’ are more precisely defined. So the copy-file gexp can be substituted by ‘(lower-object test-gexp)’: ---[snip]--- (mlet* %store-monad ((drv (lower-object (plain-file … …) ---[snip]---
Viewing derivation output in the store
I apologize if this isn’t the right place to ask these questions. While this is on the level of beginner tutorial (or should be, IMHO), the devel list seemed the most relevant. I’m trying to figure out how I can create a file and view it in the store before installation. I’d like to make sure the target looks the way I want before putting it in its final location. I would like to do this entirely within a Geiser session, rather than having to call shell commands for ease of edit-test-debug cycles and tracing. This is also for pedagogical purposes; I’m trying to learn how Guix goes from abstract file-like-object to an actual file. I’m still new to basically everything here, and exercises like this help me learn. So, given the following: ---[snip]--- (use-modules (guix) (guix gexp) (guix monads) (gnu)) (define test-file (plain-file "foo.txt" "the contents of foo")) (define test-gexp #~(begin #$test-file)) (define test-drv (gexp->derivation "foo" test-gexp)) ---[snip]--- How do I go from the derivation in ’test-drv’ to the output in the store? Something like how, from the REPL, this works: ---[snip]--- scheme@(guile-user)> ,enter-store-monad store-monad@(guile-user) [1]> (text-file "foo" "hello") $34 = "/gnu/store/mnzh1q6ilbw0bg04dg0vc4f47laz57lg-foo" ---[snip]--- Now I can easily open the path to ’/gnu/store/…foo’ to verify the contents are correct. NB: While I’m using ’plain-file’ here and its conents are obvious, this is just to keep things simple. My actual target comes from ’computed-file’. -bjc
Re: Update to bug 54919 gone missing
Tobias Geerinckx-Rice writes: > We don't have easy access to lower-level logs. Do you? You look like you > might self-host. > > Armed with a log snippet from you with a clear 250 'accepted' I'd feel less > bothersome asking the gnu.org folks to investigate. You know, I hadn’t even thought to check my mail queue. I can’t remember the last time I had a delivery problem (or maybe I’ve been having them the whole time and just not noticed 😉). I have my mail server set to require TLS, but it looks as though debbugs.gnu.org doesn’t support it: ---[snip]--- Apr 16 08:26:10 mx0 postfix/smtp[68543]: 347053CCD: to=<54...@debbugs.gnu.org>, relay=debbugs.gnu.org[209.51.188.43]:25, delay=78497, delays=78497/0.06/0.27/0, dsn=4.7.4, status=deferred (TLS is required, but was not offered by host debbugs.gnu.org[209.51.188.43]) ---[snip]--- This wasn’t an issue for other reports, as I used the bug-g...@gnu.org address, and eggs.gnu.org offers STARTTLS after the EHLO. I’m not sure what to do here. I’m kind of loathe to remove the TLS mandate on my server, and it seems to me like the debbugs MX should offer it for all the standard reasons. > Thanks for reporting both! Thanks for prodding me to dig further on my end. I honestly thought the mail just disappeared. -bjc
Update to bug 54919 gone missing
I sent an email to 54...@debbugs.gnu.org to update it with more specific information almost two days ago and I haven’t seen any changes in https://issues.guix.gnu.org/54919 . I also never got a bounce or other return communication saying what has happened; it’s as if my email were silently sent to the bit bucket. Is there more to the procedure than sending an email to the address at the bottom of the ticket? For the record, since it’s apparently lost: I tracked the issue down to this line in my home.scm: ---[snip]--- (service home-shepherd-service-type (home-shepherd-configuration)) ---[snip]--- When I comment that out, everything runs correctly. It seems as though the addition of this empty configuration caused the ’herd’ process to try to communicate with the shepherd process, and even though it was able to connect, it never got a response to the version query. There were more details in the lost bug report, but the above is the gist of it. -bjc
Re: guix home: error: rmdir: No such file or directory
Ludovic Courtès writes: > This comes from here: > > https://issues.guix.gnu.org/52808#20 > > That is, symlink-manager no longer prepends “.” to file names given to > ‘home-files-service-type’. > > Does that correspond to what you observed? A work-around that someone on IRC discovered was running: ‘ln -s ~/.config ~/config’ before running ‘guix home reconfigure …’ and this seems to work. Afterwards the ~/config symlink can be destroyed and subsequent reconfigures work as expected. That said, in my own configs I have only ever used ‘home-zsh-service-type’ and ‘home-xdg-configuration-files-service-type’ for managing my dotfiles. I don’t have explicit dot or dotless files anywhere. I still ran into the issue and had to use the “fix” above. -bjc
Re: guix home: error: rmdir: No such file or directory
Feng Shu writes: >> Cleaning up symlinks from previous home at >> /gnu/store/m70cycn4wkhqmk85pkh8jxspbnw35sw8-home. >> >> guix home: error: rmdir: No such file or directory > > yestoday have no this problem, today I guix pull and move > home-files-service-type (add "."), this issue is found. I’m having the same issue, and I’ve seen at least one other person on IRC having it as well. We all pulled guix today. I would have liked to start looking into it, but I have no idea where to even begin. I tried turning ‘verbose’ to 100 (I don’t know what valid values are, and can’t find documentation for the flag, so I assume higher is more logging), and the output was the same. I can’t even tell what it was trying to rmdir. I can appreciate that things like this happen in a rolling release, particularly on a feature this new and in heavy development, but I find it frustrating that I wasn’t even able to get a toe hold into figuring out specifically where things were failing, so I could either fix it myself, or provide details to the mailing list. I am *very* new to Guix, so I’m hoping that I’m just ignorant of how to start debugging a problem like this. I would deeply appreciate any guidance on the matter, as it would allow me to feel more comfortable, and hopefully more useful, in this environment. -bjc
Re: GNU Shepherd 0.9.0 released
Liliana Marie Prikler writes: > Am Mittwoch, dem 06.04.2022 um 23:25 +0200 schrieb Ludovic Courtès: >> ** Log file of unprivileged ‘shepherd’ is now under $XDG_DATA_DIR > Should that not be $XDG_STATE_DIR? I believe it should be $XDG_STATE_HOME, in fact. See: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html ---[snip]--- $XDG_STATE_HOME defines the base directory relative to which user-specific state files should be stored. If $XDG_STATE_HOME is either not set or empty, a default equal to $HOME/.local/state should be used. ---[snip]--- -bjc
