IRC channel logs
2025-12-11.log
back to list of logs
<vhns>Sorry for all of these not-exactly-contextualized questions, but, when building an install image, is there a way to not have it pull the repositories you defined for it? As in, whenever I build my install image, it pulls the latest updates from the Guix repositories. <ieure>vhns, I don't believe so. Also noting this conflicts with your goal of not using the network -- if you pull, the stuff in the installer's store will stop being the correct version to copy to your target disk. <graywolf>Hi all, I am trying to wrap my head around the new rust packaging, and I am bit at loss... How do I inherit from cargo package and bump a version? Previously, it was possible to make it work, with some modify-inputs work, but I cannot figure out it for the new approach. Nothing from rust-crates.scm is public, so I cannot even reuse the crates from there. <graywolf>Would anyone have an example how to approach this, possibly from their channel? <ieure>master broken for anyone else? Trying to update a package, but `make' dies, complaining about contributing.de.texi. <ieure>I'm on ec959892550, which is the latest commit to master. <vhns>guix pulling rn, let's see <vhns>I'll try doing configure and whatnot <vhns>(my computer is slow, so it'll take a while) <vhns>ieure: no issue on my side <vhns>paste to come, one second... <vhns>not sure if I should've `make clean` <vhns>I'll give it a whirl, I guess <vhns>same result after `make clean` <vhns>as in, it worked fine, no error <ieure>Hmm, I also ran `make clean', didn't help at all. <ieure>Thank you for giving it a shot! <sibl>which one actually upgrade system packages (ex: kernel) `guix upgrade` or `guix reconfigure` ? <bdunahu>it sounds like you want `guix system reconfigure`? But that won't do anything unless you download the newest package definitions with `guix pull`. <sibl>so guix pull + guix upgrade will not upgrade the kernel, like everything else except the kernel ? not sure to understand the boundaries of the upgrade between those two <sibl>(I understand that guix pull "upgrade guix" and its packages definition) <bdunahu>`guix upgrade' only updates packages you've installed with `guix install' <sibl>I see, and I guess packages installed using guix home are in the same bag as the ones installed using `guix install` right ? <bdunahu>No, there's `guix home reconfigure` for that <sibl>okay interesting, thank you ! <sibl>this one is gonna be a bit more tricky to explain but I put all my config files under `guix-config` and within multiple directories `home` and `systems`, both directories are independant, they dont use each other's file/code <sibl>but anytime I do a guix system or guix home reconfigure I get warnings like: `error: home-packages: unbound variable` <bdunahu>Where does home-packages come from? Is that a variable you defined? <sibl>as you can see, its totally independant of the /systems directory, but when I do a guix system reconfigure -L ~/guix-config, it shows warning about that variable not being defined (it doesnt tell in which files which doesnt help me much) <bdunahu>yes, the error messages aren't great. Likely the file that has the variable home-packages doesn't compile <sibl>but I did a `grep -r -E 'home-packages|home packages' guix-config` so it shows every files which contains that variable name, and I checked those files so many times <sibl>and even with the warnings, the reconfigure happens well (both for home and system) so I am really wondering whats going on <bdunahu>which file is defining that variable though? <sibl>`guix-config/home/packages.scm` <bdunahu>you could try compiling it yourself using `guile -L /path/to/guix-config` and then `,use (home packages)` <sibl>actually those are "hint" not warning (not sure if that helps), when I did what you just said, it showed a warning and some hint for unbound variable (failed to load (gnu packages abiword))), which isnt part of my config <sibl>I think I fixed a part of it, which now gives me this error: no code for module (gcrypt hash) <bdunahu>can you share a paste of the output for the compilation? <sibl>but I dont know where it pulls this from <Rutherther>when using guile, from nowhere, you should rather use guix repl when checking files that depend on guix <sibl>oh when I do `guix repl` then `,use (home packages)` now I get no warnings or hint <sibl>let me try to reconfigure again with that <sibl>well still those hints xD <Rutherther>it's better to do guix repl file, not guix repl and inside of it ,use <sibl>`guix repl -L ~/guix-config ~/guix-config/home/lexipad-home.scm`, like this ? <sibl>I get no warnings with this, doesnt output anything tho <sibl>for both my home config and my system config <Rutherther>then it seems to me it's different file that complains <sibl>but when I reconfigure I do `guix home -L ~/guix-config reconfigure ~/guix-config/home/lexipad-home.scm` which seems very close to the guix repl command, what is there that could complain that wouldnt complain while doing the repl ? <sibl>and for my system: `sudo guix system -L ~/guix-config/ reconfigure ~/guix-config/systems/lexipad.scm` <bdunahu>Is it still `home-packages` that is unbound? <sibl>so the funny thing is when I do guix home reconfigure, its both `home-packages` (twice hint) and `lexipad-packages` <sibl>but when I do sudo guix system reconfigure, only twice home-packages <bdunahu>I wonder if this could result from using `specifications->packages', rather than importing the package modules manually and using the symbols directly <bdunahu>you'd likely get better error messages if you did not use specification->package <Rutherther>I think there's a good chance there would be no errors if specification->package wasn't involved. It needs to go through all the modules <Rutherther>just try running guix repl on every scm file in your ~/.guix-config and I think you will find the file that's producing those errors <sibl>I just did `find ~/guix-config/ -type f -name '*.scm' | xargs guix repl -L ~/guix-config/` and got no output <sibl>$? is 0 so I guess all good <sibl>could it be because of my dotfiles directory ? <sibl>there shouldnt be any .scm file in it but idk <bdunahu>Since `system reconfigure' is still pointing to `home packages`, I think you should remove the use of specification->packages <sibl>I should remove all the `specification->packages` and `specification->package` from my config ? and instead import them like (guix package ...) ? <bdunahu>(gnu package ...), but yes. You could also try emptying out the specification->package expression so it temporarily looks up nothing, and see if that fixes it <bdunahu>I don't know, bisect until you find the problematic package? <sibl>I just tried, as long as there is a package in the specifications->packages list, I get the warning <sibl>and I also have `specifications->packages` in my lexipad-packages.scm and this one is ok for some reason <bdunahu>You could probably manually evaluate this stuff in the REPL to find the reason, but since debugging is so difficult it seems like you should avoid using it in your config <sibl>I will ask gemini to remake that file with use-module instead and see if that makes the hint go away <sibl>okay, no more warnings ! finally xD <csantosb>Am I the only one experiencing issues with Github ? <identity>most people experience issues with github at some point in their lives. i can open some repositories just fine, though <Rutherther>I have experienced something like that just yesterday, caused by unreachable DNS servers. There were 3 configured from DHCP and 2 of them weren't reachable <csantosb>It's weird: since yesterday, after I ssh to a remote server, I have problems to fetch sources, it just hangs forever. <simendsjo>I use a package which uses libglvnd, but then OpenGL doesn't work. Replacing it with mesa works on my system, but will break for those using proprietary nvidia drivers...? Is it possible to somehow tell libglvnd to use mesa as a backend? <qbit>anyone getting an invalid hash for libgcrypt? <qbit>sha256 hash mismatch for /gnu/store/03qf4fz9fbyn26jnn2w61ps0c4k23py7-libgcrypt-1.8.8.tar.bz2: expected hash: 1xasrh9zxhgj2n5n8dvpzbwn1mzpmlzy270xhbq2gl8xk2xy4pc9 actual hash: 08pmr25gghkfnnsa4m5vxi3h1piprfynlp55q798c15gfp11332m <cmack>qbit: no, but my libgrypt is at 1.11.0 <qbit>i am tryign to get things working on a debian box, so far i tried the official installer, but that runs into issues doing anything (it seems to go into a "fetch loop") <qbit>so i installed via apt, that is more functional - i was able to install tmux.. but doing a pull fails with the hash issue <qbit>i am also pulling from a pinned channel (though, i get the same error when I run without the pinned scm file) <qbit>46e1b73b449c526b987aa2872cdbeec91403b49e is the pinned commit - which seems recent enough <BoGuE1979>How can I add an additional CA certificate to $SSL_CERT_DIR and/or $SSL_CERT_FILE? <gabber>is it possible to use search-input-file or search-input-directory with wildcards, e.g. (search-input-file inputs "libfoo.so.*") <csantosb>And "a ‘separator’ value of ‘#f’ specifies a “single-component search path”—in other words, a search path that cannot contain more than one element" <BoGuE1979>Thank you I finally managed to add my ca-cert using a package similar to "le-certs". <BoGuE1979>my previous attempts adding an etc-service-type broke everything ssl related... <basicnpc>1. I can get sbcl@2.5.8 from the official channel. If I want to get any older version (say sbcl@2.4.7), what should I do? <basicnpc>2. native-search-paths in the package definition will change the final env variable. I wonder what if I bring two packages in to a guix shell that intend to modify the same env to different values? <csantosb>And "6.16.8 Load Paths" in Guile doc, seems it is not <basicnpc>csantosb: I see. So I also have to search in that specific revision? <csantosb>Look in guix history: "d2d1dcd1dd3 * gnu: sbcl: Update to 2.5.2" <csantosb>Then, `guix time-machine --commit=d2d1dcd1dd3 -- install sbcl`, will install 2.5.2 <basicnpc>But why? Doesn't guix guarantee 'build once, work always'? <csantosb>TLDR, you'll need the pre-build artifact available in a substitute server; otherwise, you'll need to build it locally, provided the sources are still around <basicnpc>Finally for today I like to nudge on the last question.. <basicnpc>2. native-search-paths in the package definition will change the final env variable. I wonder what if I bring two packages in to a guix shell that intend to modify the same env to different values? <Rutherther>basicnpc: currently it behaves the same as if you had multiple profiles that tried to set it and you loaded all of them. Ie. for search paths with a non-#f separator, they are concatenated. For search paths with #f separator, the latter is used. This then depends on the order of the packages in the profile <basicnpc>Does that mean `guix shell A B` and `guix shell B A` may be different? <Rutherther>yes unfortunately. It should definitely be solved <basicnpc>Rutherther I doubt if there's any solution to this though... to have each package working in their own chrooted space? <basicnpc>csantosb: WOW THAT's a brilliant read. I really enjoyed it. <cmack>I'm getting errors in different packages (rav1e, dnsmasq, abseil-cpp) when trying to cross-compile a pinebook-pro image from an x86-64 machine. I know there is a push for 1.5 right now... is this expected or should I file bugs? <Rutherther>basicnpc: the solution is to tell the user to not put such packages in the same profile as they are incompatible <basicnpc>Rutherther Ah I see, at least to throw them some warnings. <Rutherther>this can happen with python2, python3 for example <basicnpc>naive and incomplete idea: Can't we wrap each package in their own subshell having their own set of env vars? <gabber>cmack: i don't think cross-compiling works for these images ATM <gabber>i had to "--system=aarch64-linux" for my pinebook builds <Rutherther>basicnpc: each package... no, because that's the idea, to have more packages in one profile with a search path. For example "python python-numpy@1 python-pandas", that way you get numpy and pandas packages. If you separated each package to a separate subshell, you no longer get python with numpy and pandas <gabber>cmack: feel free to file bug reports for the inability to cross-compile, though! <basicnpc>csantosb: Aw I love that article. It makes me want to read more about VMs (how they are made, nuances.. etc). Any suggestions? <csantosb>basicnpc: yeah, the author of the text is not too bad 😁 <csantosb>At the Nix side of life there is someone doing a PhD on functional package management ... <cmack>Rutherther: oh I see the fix touches quite a few things. Thanks for your work on it. <basicnpc>Has anyone heard of cases who use guix (or nix.. less preferrably but ok) as a professional (i.e. paid) system admin? <gabber>basicnpc: i think some of us are doing this. i can't imagine myself crafting new systems for clients that are *NOT* guix (imagine the headache) <basicnpc>gabber: Are you a system admin using guix? <basicnpc>csantosb: So has guix started to track successful and unsuccessful pairs of (package, environment)? <basicnpc>by environment I mean: VM and time and etc.. <meatoid>to what standard to packages have to "run" in `guix shell --pure`? I'm taking a second look at PCSX2 and it seems that when run in --pure it can't open an audio stream, but otherwise it runs fine <meatoid>(also, it wants the includes from ffmpeg at build time, but doesn't have ffmpeg in its closure, which is interesting to me) <gabber>basicnpc: i administer some systems, although i currently do not earn money with that occupation <basicnpc>gabber: What stops you from getting a paid position, given that guix is so easy (once you set it up) to use? <gabber>basicnpc: people giving me money <gabber>i am currently looking into going down that path, but making people (and their shops) take the Guix train needs some selling. people like to do how they are used to, even if it means jumping some hoops (on a regular basis) <basicnpc>Yeah, but you don't advertise that. Why not first getting a position, and slowly change their underlying system? You can start from a smaller place where not many other sysadmins are presented. <basicnpc>My previous department was run by one single IT guy. Though he had to do monitor/ printer setup and maintain the dept mail server.. <meatoid>I also wonder about the usability of guix for institutional environments... maybe "guix deploy" means all the pieces are there for proper remote management of a fleet? that, and a more restricted "guix shell" (--container by default) would mean faculty can try out software without having to ask IT <basicnpc>That's exactly why I ask. Guix users are purer in mind I think, but that may prevent them by pursuing successfully in some real settings as things ALWAYS get dirty there. <basicnpc>but the hope is .. if we have one successful case, they can share all the setups, and that would be really enlightening for the community <gabber>in my experience it is very hard to make people learn (and adapt) new (and better) ways. no matter how "suboptimal" ansible is, people get used to it and then they imagine it being cheaper to keep using it than for the small-ish teams to learn new stuff. the same goes for other distros, FlatPacks, docker images, etc <meatoid>the corpo i work for is *heavily* embedded in m$ <meatoid>we use **ing sharepoint for our internal websites <basicnpc>Is it challenging to integrate Guix into an institute's systems using Ansible? <meatoid>I would guess one would slowly pare back the ansible until all it does is deploy guix and run guix reconfigure <gabber>basicnpc: i don't think so. it's more that `guix deploy` is—even though it is rather a work-in-progress by product—so much more advanced than ansible, that it seems breathtaking. people rather try to get along with not-so-well-crafted Python ansible roles than trying to work scheme <cdegroot>"worse is better". We use Nix at work, but we were double lucky: a) we're a startup, b) we hired a heavyweight Nix contributor to specifically help out with infra. If leadership is behind it, change is easier :-). Anyway, I don't think anyone will want to go back by now. We have a single - somewhat large - flake.nix that describes both our dev env and our production systems and it's all wonderfully consistent and very simple to reason <cdegroot>But getting over the hump is hard, whatever "advanced" technology you're trying to introduce :) <basicnpc>cdegroot: Good for you, and thanks for sharing! <cdegroot>My best advice for if things are more established is to find similar minds, and do demos. Slowly build support. Find out what the biggest issue with Ansible is and show how Guix addresses it. <basicnpc>Yes, it's difficult to communicate. For someone who does not know, it's also not their responsibility to 'automatically' get why guix is good. That's what true campaigners have to pay efforts into. <cdegroot>But especially in a work environment, "good enough" is often good enough, alas. I leaned heavily on the fact that we're building software for critical care and being able to know exactly what's running where and being able to replicate it was a big important item. <cdegroot>And you need to think in years, not weeks or months, to build support, unless you find a killer use case. <gabber>i heald a half-they presentation with hands-on and whatnot. it was a tiny shop (6 people), all were there. i figure they were somewhat slower kind to adapt to improvement <luca>I come from a devcontainer/docker shop where the dev and prod environments are very different. Dev needs a lot more tooling installe for example. Is it not the same concept in nix/guix? Or do people add their own in the environment (like `guix shell -f guix.scm neovim emacs ripgrep etc`) <basicnpc>`guix time-machine --commit=d2d1dcd1dd3`, after >1hour of building, fails. <basicnpc>Rerunning it => getting the same failing message. <basicnpc>csantosb: Something just hit me. The solution that the article provided to solve the hardware problem is by offloading building to VMs. However, modern hardware (e.g. CPUs) are almost impossible to replicate. So how was that fully possible? <gabber>basicnpc: what's the exact error message? and is this the complete command you're trying? <cdegroot>luca: Our dev env setup is 1. Install direnv + nix, 2. checkout monorepo, 3. cd into monorepo. 4 drink coffee or tea. All that is needed outside of that is to bring your IDE. And that monorepo has Terraform, Python, Julia, and Elixir code in it. Plus all sorts of native libraries that dependencies pull in. It's a game changer. <basicnpc>Yes that's the full command. Lemme figure out how to post the log to a pastebin.. <gabber>basicnpc: are you on a headless machine? <basicnpc>I'm on another physical thinkpad. But my setup there is thin, so I am still trying. <cdegroot>gabber: the most important thing when trying to introduce new tech: what problem does it solve? If it doesn't solve a real problem, it's probably not worth introducing. "The devil you know...", etc. It's hugely situationally dependent. <basicnpc>sprunge is down.. ix.io is also taking a break -_- <gabber>solves the problem of "if i deploy FOO to system X, is it really the only thing deployed there", which ansible is not able to do <gabber>basicnpc: not sure what these are, i usually pipe output to `nc termbin.com 9999` <cdegroot>Yup. But is that important enough to your org to warrant a migration? <basicnpc>That's the content of my /var/log/guix/hhhhhhh-nonguix.drv.gz <gabber>cdegroot: i'm not there anymore. my rough estimate was that by using upgradeable, reproducible systems we would be able to save quite a bunch of work-hours. i guess they didn't feel the same <gabber>basicnpc: i see. you should craft a channels.scm file with a nonguix commit hash that works with the guix commit in question <cdegroot>I once worked at a company where I showed that extending the stack we were already switching to more aggressively would reduce our hosting footprint by 90%, and nobody was interested. Companies are weird sometimes :) <gabber>it does not feel rigth IMHO but `guix time-machine --commit` pulls all channels, and just pins the guix channel to the commit given <ieure>Hmmm, so I need to update cbindgen from 0.28 to 0.29, but I don't really understand how the new packaging model is supposed to work. Came up with this patch, but it doesn't build. Any ideas? https://paste.debian.net/1413522/ <ieure>I cloned cbindgen 0.29 and ran `guix import --insert=gnu/packages/rust-crates.scm crate --lockfile=/tmp/cbindgen/Cargo.lock cbindgen@0.29' to get this. <ieure>Then duplicated rust-cbindgen-0.28 and tweaked it for 0.29. <ieure>Building it complains about a missing dependency, "clap." <basicnpc>gabber.. hmm.. perhaps that commit does not exist? I copied and pasted from another folk here. <gabber>basicnpc: no. if the commit does not exist, you get: "guix time-machine: error: Git error: object not found - no match for prefix (abcdefabcdef)" <basicnpc>That's weird then. I don't know what to do.. <gabber>try `guix describe --format=channels > channels.scm`, delete everything but the main guix channel and change the hash in there <basicnpc>That hash also looks pretty, weird, as a randomly generated one. It has too many d's. <gabber>then you `guix time-machine -C channels.scm` and it will work (i assume) <gabber>you can try your first command with `-q`, so it won't load the other channels <Rutherther>ieure: that's strange, so the error is in build phase? Can you send the whole error and some context around it? <basicnpc>gabber trying your '-C channels.scm' now. :-) <gabber>basicnpc: this is basically `guix time-machine --commit=d2d1dcd1dd3 -q` with extra steps <ieure>Rutherther, Yes, build fails. <ieure>*won't let me paste the output, tells me "do not spam" <weary-traveler>basicnpc: why do you think that perfect replication is necessary? <basicnpc>weary-traveler: For reproducible research for example. <weary-traveler>basicnpc: i don't follow the connection. if the build for the reproducible research happened in a vm, all that's needed is the ability to run that vm in future <basicnpc>The research shouldn't be assumed to only happen in the VM. <weary-traveler>i'm not assuming that. i'm simply assuming that a vm-based build process exists that is able to reproduce the results that were possibly observed outside of the vm. if the research is specifically on architectural specifics that the vm isn't able to emulate, that would be outside of scope. but that's by definition. <weary-traveler>iow, if vm is acceptable build target, the approach of using vms for build helps reproducibility. that says nothing about when vm is not acceptable build target <basicnpc>This solution would break if some package really depends on some details of the hardware that a VM cannot capture? But those case are rare.. so we shouldn't care. <weary-traveler>i'm not saying don't care about other cases. they're simply outside the scope of this one <basicnpc>Yeah, I think it's brilliant. Just trying to think of edge cases that it may not be able to take care of.. <weary-traveler>having an oncologist doesn't mean other ailments aren't useful to focus on. just not the oncologist's job <weary-traveler>basicnpc: if there are such cases that are of interest to you, start hacking :) <yelninei>how does the supported-systems field work with cross packages? <nmeum>let's say I want to create an /srv/files.example.org directory for my nginx before it is started. what's the best way to do that? do I write my own *seperate* activation-service-type and have nginx-service-type depend on that? or do I somehow modify the *existing* nginx-service-type and add my activation-service-type to it? <gabber>what's the easiest way to read stdout from an (invoke ) call into a variable? <cdegroot>nmeum: I'd pop that in a separate service and do the dependency thing. <yelninei>gabber: (ice-9 popen) and open-input-pipe <cdegroot>(I still need to port my static site stuff from Nix, but there I build the site in Nix and that's an input dependency, I think, for the Nginx config in the store so the whole thing gets setup before Nginx starts) <nmeum>configuration: so how do I modify its shepherd-requirements? <gabber>i tried (with-output-to-string (lambda _ (invoke "foo"))) but this didn't work... <cdegroot>nmeum: I'd need to read the source, sorry. If it can't do that, time for a PR I guess :-) (I really should port my Nix config to Guix but... not allowing myself any time for the fun stuff until my book is out) <ieure>Rutherther, I fixed rust-cbindgen, issue is that the importer dumps it into `define-cargo-inputs' in rust-crates.scm, but it uses the name "cbindgen" instead of "cbindgen-0.29". Manually edited the code and it's building. But either the importer is buggy or I'm using it wrong, seems like this shouldn't be happening. <ieure>Also not sure why I have to give the cargo.lock file to the importer instead of it using the one in the crate I'm importing. Maybe they don't end up in the crates? <Rutherther>you seem to be passing in "cbindgen@0.29", which I am surprised even works. I did not notice that before <Rutherther>the name you want to end up in the rust-crates, so "cbindgen-0.29" in your case <ieure>Oh, well, maybe that's my problem. <ieure>Rutherther, Yeah, that seems to work. I couldn't find any examples of how to use this, and the blog post just says `guix import crate ... PACKAGE' with no explanation of what PACKAGE should be. <meatoid>should packages as a rule be able to run with 100% of their features in `guix shell --pure`? I'm revising the pcsx2 package and the sound doesn't work in --pure <ieure>meatoid, I think that's expected, some environment variable tells it where to connect to PulseAudio, which gets wiped with --pure. <meatoid>also in that patch series, shaderc-for-pcsx2 was added by accident. Since it's not very old and not used by anything, is it OK to delete it outright? or does it have to go through the deprecation process, in which case I'll put the removal in a seperate PR. libpng-for-pcsx2 also should've been libpng-next... <ieure>meatoid, If shaderc-for-pcsx2 is used by pcsx2 only, or by nothing at all, you can remove it without deprecating. <simendsjo>I started digging into how to get libglvnd to use mesa as a backend, and it seems like mesa should build libEGL_mesa.so and libGLX_mesa.so so we can use it as a backend for libglvnd? Should -Dglvnd=true be added to the mesa package? <ham5urg>My goal is to compile the firmware tool of Intel to flash Arc GPUs. <gabber>ham5urg: there seems to be some kind of error in the local channel you specify <ham5urg>gabber, is there a verbose way for "guix pull"? <gabber>ham5urg: i don't think so. just read the log (`zless /var/log/guix/drvs/pq/lakwwfi45zp36msx2ypsizzlgv5nw0-local-channel.drv.gz` in your case) to get enlightened <gabber>in my experience this more often than not is some module misnaming or syntax error <gabber>see, either you misnamed your module or your (use-modules) or #:use-module is faulty <ham5urg>I can't see where, have been a too long day. I not yet install anything, just doing a guix pull. "~/local-channel# ls -> intel-gpu" and "~/local-channel/intel-gpu# ls -> metee.scm" <gabber>ham5urg: then maybe taking a break and getting some fresh air could help? this often does the trick for me (: <Rutherther>ham5urg: so why are you trying to load (metee) when it's in a subfolder, so likely (intel-gpu metee)? <Rutherther>ah and you actually are using channel directory "intel-gpu", so then it is indeed just (metee) and your define-module is wrong, it shouldn't be "(intel-gpu metee)", but just "(metee)" <ham5urg>Rutherther, I try to avoid using sub-repositories, it's my first step with Guix, trying try to keep the .scm small. <ham5urg>How are big .scm files debugged? Are there other ways as zcat /var/log/guix/drvs... ? <ham5urg>a simple "(define-module (metee))" only metee.scm fails with "(exception misc-error (value #f) (value "no code for module ~S") (value ((metee))) (value #f))" <ieure>ham5urg, Pasting your pasted code into a bare Guile repl works fine for me. <ieure>Though it has some minor errors, you're missing the (guix gexp) module, and asl2.0 is unbound because you commented out (guix licenses).