IRC channel logs
2023-11-19.log
back to list of logs
<tribals>Is there a way to get direct link to store item on substitute server? Like, throw it to someone and he can download it with browser? <ieure>If I have a package which inherits from another one, and I need to change the arguments to the build system, how does that work? Manual says any package fields I don't specify are inherited, but I'm not sure if it does some deep merge of the argument list. Didn't see a modify-inputs type function that would change those arguments. <tribals>Package arguments are just alists of #:keyword 'somevalue pairs, those are modifiable through alists-related procedures <ieure>tribals, Is the alist of the parent package brought into scope by either package or inherit? Or do I have to go pull those out of the original package definition somehow? <tribals>ieure: you can always pull it directly from inherited package, reffering it by variable name: (package-arguments inherited-package) <tribals>There was this-package or something like, but I didn't remember and failed to use it myself. <Kabouik>I can't figure out what the issue is with my package (https://0x0.st/HvDa.scm): it builds fine on my computer but fails on another device (aarch64, less RAM) witht this error (https://0x0.st/HvDm.txt). Yet the device is not OOM, and I know that manually building from sources on that device works, so the issue is with the package. <Kabouik>I also noticed that the device kind of becomes unresponsive around 96-97%, even though it still has RAM. This does not happen wheq en manually building from sources with cmake and make -s. <tribals>Try to do this: guix shell -D telegram-desktop; from that shell, try to build your package with make. It can spot differences in dependencies used to build locally and in guix <tribals>Or: guix shell -D telegram-desktop --pure <lh>has anyone incrementally migrated from nix home-manager to guix home before? <lh>I would like the two to coexist while I familiarize myself with guix, but unfortunately it writes to .profile and .config/fontconfig/fonts.conf by default <lh>I have an extensive home-manager config that manages both these files, and I would prefer it continue to do so while I start by adding simple things like CLI packages to my guix home config <lh>I can manually add what the guix home services write to .profile and fonts.conf to my home-manager config, and since what is written contains no store hashes, this should work fine. the part I’m missing is how to prevent guix home from clobbering these files <ieure>lh, I'm mostly guessing here, but I believe that anything Guix Home does is expressed as a service -- so I think you need to remove the services that clash with your home-manager setup. <ieure>And if you don't want Guix Home managing your startup files, I think you'll have to put some of the stuff it expects into your home-manager setup for them to coexist usefully. <lh>unfortunately these services are baked into guix home, you don’t explicitly enable them in your guix-home.scm <ieure>I don't have any guidance on actually doing this, since I'm mostly guessing, and I don't see an obvious analogue to the system config's %base-services in Guix Home. <ieure>lh, I'm reasonably certain that any file manipulations Guix Home does come from home services. Those are likely in the default set of services to run -- you should be able to remove them. <ieure>Can I tell you how to remove them? No. But I'm fairly certain they can be removed. <lh>yeah, I’m working on figuring out how they are added in guix/gnu/home.scm, it’s just a bit over my head at the moment so I figured I’d check here <lh>actually it looks like I just have to add an essential-services to my home configuration, so I should be able to copy from home-environment-default-essential-services and pare it down from there <Kolev>adanska, doing well. Got Guix System on all my computers now. 😀 <adanska>nice!!! watching Guix download and set up a new computer is always so fun <Kolev>adanska, it's so fast to recover from backup! Run `guix system reconfigure`, run `guix home reconfigure`, copy personal files over - done! <adanska>yeah! thats the one thing i really appreciate about guix. if something goes wrong or my laptop dies etc... i can get back on my feet really quickly <Kolev>Icedove shows the Thunderbird icon in the Activities Overview in GNOME. <lh>it looks like the git-annex package installs no man pages? guix 2ab5e44 <sner>lh: looks like git-annex has some has some handler phases for man page generation that are probably failing (either build-manpages isn't generating them, or its putting them somewhere that isn't $#source ++ "/man" where install-manpages expects them to be) <sner>(build-manpages ran in 0.6 seconds with no log output, install-manpages in 0.0 with the same) <lh>thanks sner. cc efraim who seems to be a maintainer, the git-annex package looks like it is missing its man pages <Kolev>I can't pass standard input to `guix system build`. <efraim>lh, sneer: I'm taking a look at it now, looks like the easiest option is to build from git <lh>efraim: 20230926 doesn’t improve the situation? no worries if you want to just wait for the next tag, looks like they happen at most every couple months <efraim>lh: I didn't check. Also by building from git we can get the shell completions <lh>wdym “build from git”? I thought you meant from HEAD but not sure now <lh>git-fetch instead of url-fetch? <lh>interesting that hackage seems to be preferred over upstream typically <lh>does that provide any benefits? <efraim>looks like debian builds from git by default <efraim>I think it mostly comes down to historically preferring a release tarball over raw sources, and they've often been cleaned up more than just a git tag <attila_lendvai>sources checked into the repo ought to be the cleanest, if you ask me <lh>it is traditional for upstreams to produce a release tarball that can be downloaded without a fancy client like git, but in this case the hackage tarball does not contain the full sources, so yeah <lh>forges like git{hub,lab} have endpoints that make tarballs from tags as well. those won’t have any tidying of the sources (removal of CI config, etc) though <lh>is the commit in a channel only respected with guix pull -C? <efraim>I haven't pushed it yet to guix, I'm bumping the version and trying to re-enable dbus integration <lh>I’m asking in general <lh>i.e. if you have a channel in ~/.config/guix/channels.scm with a commit specified, does guix pull still pull the default branch head? <lh>that seems to be happening to me <efraim>I think you still need to specify %default-channels (or whatever it is called) <lh>like prepend to that in channels.scm? won’t channels.scm take precedence regardless? <lh>yeah, but when I specify a guix channel with a commit in ~/.config/guix/channels.scm and then guix pull, I seem to get HEAD <Franciman>is there a way to go to the definition of things like slim-service-type inside guix? <Franciman>for packages you have guix edit package-name that shows you the definition. But what about guix core components? <lilyp>You can define both packages and services in your config.scm, but the more things you need to add, the longer it gets. <lilyp>Definitely consider upstreaming whatever you have :) <Franciman>uhm sorry i mean is there a way to browse the definition of things? <Franciman>like operating-system records, or discovering which services are defined <lilyp>Oh, you mean like "guix edit"; sorry, I misunderstood <lilyp>guix system has search/edit, which is likely what you're looking for <lh>I pin the guix channel in channels.scm, but every time I pull, it uses a different commit. I am able to override it using --commit=hash --allow-downgrades, but without those arguments it will update again. <lh>am I doing something wrong? I just want guix pull to use the commit I declaratively specify in channels.scm <lh>yeah guix pull is just ignoring the commit I pin guix to <isaneran>is there a way to install gcc cross compiler that I've missed? Or do I have to make a custom build of GCC (for example with custom build flags) <isaneran>I don't think what I want is guix build --target=..., since I'm looking to mess around with compiling programs to run with qemu-riscv64 <attila_lendvai>ACTION wishes more people understood shepherd's internals, and if he could fire away questions when civodul is not around <efraim>I'm not sure I can count cross-compiling as working if I can only target a few of the architectures <tribals>Could someone help me please with understanding of what guix-publish is capable for? For example, there is an URL handrler for `/nar/file/NAME/sha256/HASH` paths, which seems to what I'm searching for. But I can't figure out how to compose such an URL properly. In order to - what? In order to "just download file (fixed-point output) from store" <cbaines>that endpoint is designed for fixed output derivations, where they're looking for a file by name and hash <tribals>I have a small server running Guix SD (which is too small to build outputs), but it is accessible publicly. So, I built my own installation media, then copied (`guix copy`) it to my server, then my logic is as follows: a file is already in place (in store), the server runs 'guix publish`, it has domain name, so I can just throw my friend an URL of <tribals>such installation media and he will download it with browser and use to install Guix on his VM. Can I? <tribals>cbaines: "they're looking for a file". What does that mean? <Franciman>after a guix system reconfigure, shepherd gets stuck <Franciman>how can I understand where it gets stuck? It both prevents the guix system reconfigure to finish <Franciman>and it also hangs when i run "sudo herd help" lol <attila_lendvai>Franciman, i'm also staring at that problem right now. i installed my own shepherd latest + my patches, and i thought it's only for me, but apparently it also manifests on latest master? <attila_lendvai>i'm working on adding proper debug logging to shepherd to make these less hopeless to debug <attila_lendvai>but i'd need to consult with civodul not to go too much against his ideas. currently the log-output-port is sometimes printed for the user who calls some herd commands, which is not something i would expect <Franciman>would be extremely helpful. For now rebooting solved it <Kabouik>unmatched-paren: would you mind sharing your aerc config? I typically use nmail instead but would want to try aerc, and I'm struggling to find a keymap that would work with Emacs. <xelxebar>It's the K language, which is famously terse and that's reflected in the implementation. <xelxebar>To outsiders, it looks like obfuscation, which is why Ludo killed it, but it's definitely not. <xelxebar>The code really is "the preferred form of the work for making modifications". <xelxebar>I responded in the thread, but it's been a month, so I'd like to ping. <xelxebar>Oh! It's read backwards. Ha! Never realized. Cheers. <Franciman>parinfer-rust has an rc/ directory containing scripts for kakoune text editor <Franciman>if I run guix install parinfer-rust, it seems that these files are not direcyl accessible (i have to go to the store and find them, manually) is there a way to access them or should i just fix the package definition to also include those files? <attila_lendvai>Franciman, i have a hypothesis: shepherd gets stuck when an error happens in a service's start of stop GEXP. are you using unusual services on that machine? <attila_lendvai>i have all kinds of custom services that i wrote, some just inline stuff in my machine's config. stress testing shepherd's error handling <mirai>is the generation before the reconfigure perhaps too old? <attila_lendvai>mirai, when this happens the herd command becomes unresponsive (hangs). C-c breaks it, but i think shepherd stops responding on its socket <attila_lendvai>what hangs the reconfigure is that at the end the service restart script hangs like herd does <mirai>I recall seeing weird things when shepherd version last got bumped <attila_lendvai>that a good point, though! i doubt such incompatibilities are handled. <Kabouik>How can I make my package use a `make.sh` script provided with the sources of the program, instead of vanilla make? The reason is this `make.sh` script gracefully detects the number of cores and available RAM in a system to properly set `make -j<n>` the most optimal way. I would like the package to use that as well. This is the package: https://0x0.st/Hvnp.scm <Kabouik>Alternatively, I'd be interested in how to hardcode `make -j1` in the package definition, but this would be unnecessarily slow on machines with many cores and much RAM. <attila_lendvai>Kabouik, grep for parallel in gnu/packages. there's #:parallel-build? #f <attila_lendvai>Kabouik, otherwise you can grep for replace 'build to see examples of replacing the build phase with e.g. (invoke "make" "-j" ...) <lechner>attila_lendvai / thanks for that pointer! i always forget about that option <lechner>one of the many ways Guix tries to tame the zoo <Kabouik>lechner, attila_lendvai, thanks. I'll try that! (setenv ""MAKEFLAGS" …) looks simpler to add to my package definition, I'll start with that. <Kabouik>Using make.sh from the sources wouldn't be standard, right? I assume it contradicts the Guix paradigm to use an arbitrary build script, even if it comes from the tarball. <attila_lendvai>Kabouik, there's plenty of precedent for that, but it's additional complexity in the package <Kabouik>Good to know. Actually the benefit would be nice as it would significantly accelerate build time on machines with more RAM/cores, but let's try to make it work on low-memory machines first with -j1. If it works, then I can submit a patch, and I'll see later for a more complex way. <lh>here is my .config/guix/channels.scm. I have guix pinned to a commit. despite this, guix pull seems to always pull latest. my understanding from (guix)Invoking guix pull is that the pin here should take precedence over the presumably unpinned guix in %default-channels, no? <Franciman>how can I import libstdc++ in a guix shell container? <sner>lh: make sure your XDG_CONFIG_DIRECTORY is either set sanely or not at all (as long as it's not set wrong guix pull will find the directory) <lh>sner: you mean XDG_CONFIG_HOME? it is set to /home/me/.config, so I would say sane. also, this still happens with guix pull -C ~/.config/guix/channels.scm. I also noticed it only happens with guix, not emacs <lh>so it seems like somehow the default channel in the guix source code is taking precedence, but from reading the code I can’t find how that would be happening <sner>lh: that's definitely weird, i'll take a look at the pull script quick as well <lh>yeah I’ve been looking at guix/scripts/pull.scm and guix/channels.scm but the logic looks right. not familiar enough with guile/guix to know how to debug the guix command <ieure>Hi folks! I'm having a problem where `guix repl' can't use modules in any channel other than the official guix one. the repl complains that there's "no code for module" when I try to use it; but `guix install' will install them. My assumption is that I should be able to use modules from any channel I have configured. <ieure>`guix install toolshed' works fine in the shell; ,use (atomized packages floppy-disk) fails in the repl. <ieure>Do I have to do something special to make those modules available to the REPL? <ieure>Okay, looks like I have to do `,use (gnu packages base)' and then I can import stuff from channels. <ieure>Very surprising that `guix repl' doesn't set up %load-path for me! <ieure>Hmm. Still something wacky here, the Geiser REPL still can't load the module from my channel. <sner>lh: when you say it only happens with guix, not emacs, what do you mean? <lh>the guix commit is ignored, but the emacs one isn’t. at least, as far as I can tell, since I can see that the guix-emacs repo has new commits <ieure>Ugh okay none of this makes any sense to me. <lh>I have confirmed channel-list ignores it now <sner>lh: take a look at the definition of channel-with-substitutes-available in guix/ci.scm <sner>lh: "Return a channel inheriting from CHAN but which commit field is set to the latest commit with available substitutes for the Guix package definitions at URL." <lh>the manual mentioned that function so I just ran with it <lh>I guess if you are pinning a channel, that function doesn’t matter <lh>so I can just remove it <sner>i totally missed that line in your first pastebin, i wasn't aware that function existed until now; thanks for giving me the chance to educate myself <ieure>Okay. So when I `guix repl' and `,use (gnu packages base)', it adjusts %load-path to point to my channels. Great. But in the REPL started by emacs-guix, using that module *doesn't* change %load-path. <ulfvonbelow>ieure: (gnu packages) modifies %load-path and %load-compiled-path based on GUIX_PACKAGE_PATH and the channels <ieure>ulfvonbelow, Yeah, I got that. But how come it *doesn't* do that in the Geiser REPL? <ulfvonbelow>it's a bit unintuitive and should probably be documented at some point <sner>ieure: check the environment vars set for your emacs process <lh>I guess when I’m bumping my guix pin, I can add that function again to get the latest commit with substitutes, then remove it after a pull. bit clunky but it works. thanks sner! <ulfvonbelow>e.g. start in emacs, run guix pull with new channel, now have to restart geiser to use the newer guix instance? <lh>my next question is how can I have guix prefer emacs packages from the guix channel over the same ones the emacs channel when I don’t specify a version? <ieure>ulfvonbelow, Which environment variables should I be checking? <ieure>ulfvonbelow, I logged out and back in, I don't think I have a stale guix laying around. <sner>lh: if you're declaring a configuration/manifest in a file, just import the guix repo modules for the packages you want by name <ulfvonbelow>I'd say run ",m (guix describe)" in geiser and see what it has to say about things like (current-channel-entries) <Franciman>I'm trying to run a gui inside a guix shell container, i do the --preserve trick , but i get this error: <Franciman>Authorization required, but no authorization protocol specified <lh>sner: I see, thanks. yeah I’m doing this with guix home so that should work <ieure>ulfvonbelow, Looks like (current-channels) is the function. It shows only the Guix channel. `guix describe' in the shell shows all of them. <ulfvonbelow>ieure: I believe I see the root of the problem - current-profile in (guix describe) has this: (and (string-suffix? "/bin/guix" program) ...) <sner>lh: looks like you're good, but just for reference, if you wanted to do this from command-line, you would be out of luck. The specification->package function should probably be extended at some point to support specification of package location (repo) <ulfvonbelow>basically, it uses the filename of the program by which the current process was started to try to figure out "which" guix it's running from, which is also how it finds out what its channels are <ieure>ulfvonbelow, I see, and the emacs-guix repl starts Guile and loads the Guix modules, so it fails that test. <lh>sner: good to know, thanks. coming from nix I don’t intend to use guix imperatively at all, fortunately <sner>lh: also, for your own sanity, prefixing your imports of each channel (i.e. (use-modules ((gnu packages emacs-xyz) #:prefix guix:))) will make things a lot more readable <ulfvonbelow>and the process of looking up that information involves many invocations of mlambda which will cache the result until explicitly invalidated <lechner>Hi, is the --rebuild-cache option to 'guix shell' supposed to invalidate the entries in ~/.cache/guix/profiles? <ieure>ulfvonbelow, Have a suggestion for a fix here? Seems unlikely that I'm the first person to hit this, and also bizarre that "the perfect setup" would make something like this so difficult. <ulfvonbelow>personally I usually do packaging stuff from the command line (probably far from perfect), and hacking on guix itself from geiser <lh>sner: wouldn’t that be #:prefix emacs- or something? <ulfvonbelow>I think you can probably work around it by starting geiser, then loading only (guix describe) at first, then setting initial-program-arguments to a list with the first element being the full path to the guix command, then loading (gnu packages) <ulfvonbelow>I haven't seen whether others have run into this problem before, but I certainly hope they don't have to in the future <sner>lh: for the guix-emacs channel you're using, yes, it would be (use-modules ((emacs packages melpa) #:prefix emacs:)) <ieure>I'm going to ask on help-guix, I think. Got to be a better approach than manually fixing stuff up every time I launch the repl. It seems very hacky to me. <ulfvonbelow>perhaps instead of looking for where the guix command is, it should look for where some guile module is <ulfvonbelow>and use that to determine "the current guix profile" <sner>lh: this way, each emacs package you specify must be prefixed by either "guix:..." or "emacs:..." denoting which channel source you want the package from <ulfvonbelow>that way it would work both from 'guix ...' commands and from arbitrary guile code <lh>oh, I misunderstood the prefixing <ieure>lh, #:prefix is importing the whole package as an alias. <ieure>Like `import foo.bar.baz as baz' in Python, or `(require '[some.ns :as sns])' in Clojure. <ieure>vs. plain use-module imports public symbols from the package into yours. <lh>who wins if you import unprefixed modules with identical public symbols? last one listed? <ieure>I believe so, and it prints a warning that you're clobbering a symbol. <lilyp>well it actually depends; if it's marked as replacing, it replaces :) <lh>are Unknown # object: "#~" errors expected when trying to use modules in the repl? <sner>lh: you're missing a the syntax definition for gexps in the module you're trying to import <sner>lh: (use-modules (guix gexp)) <lilyp>plus you can customize it via :duplicates <lh>oh I guess it’s because the gcrypt module prevented the gexp module <sner>lh you're right, but guile-gcrypt should always be in the guile load path on guix. anything weird about shell env you're launching guile from? <lh>I don’t have any env vars mentioning guile <lh>command -v guile is /home/lh/.guix-home/profile/bin/guile which is guile 3.0.9 in /gnu/store <sner>the fact that GUILE_LOAD_PATH is unset is definitely weird <sner>how customized is your system's config.scm? Are you using %base-packages and %base-services or did you drop them for customization? <sner>lh this definitely complicates things lol <sner>in that case it makes far more sense, hold on <lh>the package and module generally seem to work, at least <sner>the guile load path won't be set by default unless you're loading a profile with guile installed explicitly <lilyp>you can use guix repl; that'll always have the guix stuff <sner>install guile by name in your guix-home, and it will propagate the env var to your user shell, which should also bind guix's default packages <lh>I already have guile in my home.scm <lh>I did have to remove the home service that clobbers the shell profile though lol, that’s probably it <sner>that is 100% the problem lmao <sner>guix repl would be your best bet then, if you don't want to get your hands too dirty with merging guix/nix home configs <lechner>Hi, does the '-l' option for 'guix environment' serve the same purpose as '-f' for 'guix shell'? <lh>the home service that sets .profile just adds `. ~/.guix-home/setup-environment` and `~/.guix-home/on-first-login`, and manually running those doesn’t add any guile env vars <sner>lechner: yes, but afaik guix environment is deprecated in favor of guix shell (so use the latter) <lechner>sner / thanks! something in the latter is not working right. i'm trying to debug <lh>in fact I had added those to my nix-managed .profile and am still getting this error. I can just use guix repl I guess but it seems like this should work <sner>lh in that case the question is: what is the content of ~/.guix-home/profile/etc/profile (and if the load-path setter is in there why isn't it being hit) <lh>is guix package --list-profiles not supposed to include ~/.guix-home? mine does not <lechner>lh / guix home and guix package may be incompatible <sner>lh can you pastebin your whole home config.scm <lh>actually I had commented out setup-environment, let me try restoring that and logging in again first <lh>I don’t think I had realized that packages would add to the profile’s etc/profile and didn’t like that it hardcoded xdg vars <sner>lh: gotcha, note that you can override those xdg values by extending home-xdg-base-directories-service-type <sner>you can also override pretty much any default behavior of guix-home by changing the essential-services record parameter in your home-config.scm (though this is a fast-track to breakage if you're not careful) <lh>yeah I had to do that yesterday to stop it from clobbering fontconfig lol. I’m not touching gui packages yet <lh>ok I source setup-environment in .profile now, but have the same issue. setup-environment sources etc/profile and the variables in there are getting set <lh>but etc/profile doesn’t set GUILE_LOAD_PATH <lh>if guix home is incompatible with guix package, I don’t know how to check --search-paths, because guix home doesn’t support that option <lh>so it seems to be a problem with the guile package <apteryx>when I set searx as my search engine in IceCat, I get a search results page that is instead a searx public instances listing, e.g.: <apteryx>GkIAvNRYF5Dhw9PULtEYdMAdO9nJ56JQVSro0EnSPVJLYEvg3oCFR9hL1Aedx9C1kgc1scE6U6QsLvEUKtCfy_pq417y4V2tczxAcM796__-dS8XCrvLaIY1iLyB72i1BRFKZE1pjrn76aYlJ1OlZ5H6z5RIWYNecM0eHlN11aAoc5YGClIgvE5HVbXO11YviVTef61uGBImXi-MDeQHaAVDUXhc_0EPI2FmsZN3GB8xPKJcqe8l53EfOdqTXN4rf0fQ1Ll9dJjerEy5ytc6c7QidsH_t_w7MSuTi9LYgTLgUtUe4LoyteJN3hKG3KMtk8SWlJsoTRYg16jfV2Y9ob8KoAHjEKjlxxeRCKA4GtrJa67-ntJKLZ5rqggyC2iQ_5DIKtI0GbteF3Jpf6f <apteryx>iayom0c2kAifF2eBuPjKXo7TqOfVJW6bxQ2ngY0R84DzgXXsxZjbgfR6F4P61Xc63gklHIdV7sP1qLS9O_zk7qchXIh7yle5w2VT2HvVxhL0p2AzoeYl6-f1Uv3AUW9tugPRl1ZAlxnVXWfdrsv2yry9nosCyB7-1bMJqFXkn4AWg9Y7Q==&q=test <lechner>Hi, does 'guix pull' update substitutes too often? <ulfvonbelow>would a list of searx instances serve as a sort of "meta-meta-search engine"? <sner>lh: to confirm, what is the exact package for guile you have included in your home config.scm (and if you could pastebin that file it'd help) <sner>lechner: wdym by "too often"? <sner>lh: "guix shell -C gcc-toolchain coreutils grep" doesn't include guile <lh>sner: I first test with gcc-toolchain, then exit and do a new one with guile <lh>to show that native-search-paths work for gcc-toolchain <sner>lh: my bad, you're right <lh>I suppose I should have used time-machine but it’s basically master <lh>maybe this is just something no one on guix system notices because it works fine on guix system, but not sure <apteryx>lechner: yeah, that would have been somewhat intuitive, but there's nothing suggesting that this can be done <apteryx>just instance links bringing you to their home page <apteryx>(where I can search, but that's the most ackward interface ever for a browser search add-on) :-) <apteryx>I'd expect to be able to configure the plugin or browser to use a particular instance <lh>sner: it seems as simple as the fact that guile-gcrypt is not part of guile, actually. maybe this solidifies the fact that I should be using guix repl <lh>well, that still doesn’t answer why the search path doesn’t show up I guess <sner>lh: your above point is generally correct <sner>the reason the search path isn't showing up is I was incorrect regarding the conditions under which guix propagates its own libs to the guile load path for a home-environment <lh>shouldn’t this be independent of home-environment given the container <lh>(given GUILE_LOAD_PATH was unset in the container) <sner>the guile load path var is only exported if the environment includes a package that requires it be set. The guix modules are _not_ auto-exported in the presence of the guile package <lh>ah yeah I just thought of that and tried it with guile-gcrypt haha <lh>so everything is working as intended <sner>the main reason for my confusion was that my personal home environment contains guile-gcrypt, without naming the package in my config <sner>turns out the reason for that is that the emacs-guix package exports guile-gcrypt as a propagated-input, and thus dumps it to my home env <lh>I installed emacs-guix but it seems to be unmaintained and broken, so I removed it <lh>hmm, I will try it again sometime then <lh>maybe no one has run into this because they have guile-gcrypt in their environment from emacs-guix or something else <sner>lh: yeah it looks like this is something of an oversight for users of guix under another OS. In the guix system case, guile-gcrypt is always available in the load path due to the guix-service-type system service installing guix in the global profile <sner>in your case, the guix executable is managed by nix, meaning that the guix package itself isn't present in any of the guix profiles for your user. as such, its dependencies aren't available either <lh>yeah, I’m realizing this live <sner>alternatively, you could just add the guix package itself to your home config, though that might result in some weirdness during updates <lh>or maybe I can try adding guix itself to my guix home <sner>we are riding the same wavelength in real-time lol <lh>yeah I really appreciate your help, my first weekend with guix would have been unmeasurably worse without this channel <sner>glad we got things resolved! i've been through the wringer with guix enough times to know your pain, happy to help <lh>can you think of what might happen if I use guix installed via guix home to guix pull and guix home reconfigure? for one it means there will be a version mismatch between the guix client and the guix daemon, I think. I will probably just add the guix deps to be safe <lh>wait, command -v guix already reports /home/lh/.config/guix/current/bin/guix. so it must be designed to update in place, and adding the same package to my home config should be fine, I’d guess <lh>I guess the guix client/daemon interface must be frozen in that case <sner>lh: the guix command binary is generally designed for update in place on all systems, so you should be ok. If you want to avoid adding the guix package directly, you can use package->development-manifest from the (guix profiles) module to only add the packages needed to build guix <sner>wait actually, not that function, if you want to add them to your home config.scm file you should use (package-development-inputs guix) expand the output list into the packages field <lh>that would include all the build deps, I think I want the propagated inputs? <lh>to just get the repl working anyway <lh>package-transitive-propagated-inputs is looking good <ulfvonbelow>a manifest will have its propagated inputs included automatically <lh>ulfvonbelow: in this case I am aiming to avoid adding guix itself to my guix home config <lh>in fact when I did try that route it seemed to want a different commit of guix than the one in my ~/.config/guix/channels.scm <ulfvonbelow>yeah, for any guix, (@ (gnu packages package-management) guix) is going to be an older commit than the one corresponding to that guix <ulfvonbelow>splice in (package-development-inputs guix) to your manifest, the manifest-handling code will take care of filling out all the propagated inputs <lh>this isn’t a manifest, it’s home-environment-packages, so just a list of packages with optional outputs iiuc <lh>(map cadr (package-transitive-propagated-inputs guix)) seems to work <ulfvonbelow>I would assume it gets transformed into a manifest in the process of 'guix home reconfigure' running; if it didn't include the propagated inputs, that would be rather broken <lh>my point is that (package-development-inputs guix) includes a bunch of packages I don’t need to make geiser work on a guix checkout <ulfvonbelow>in that case, yeah, package-transitive-propagated-inputs sounds about right <lh>no worries, thanks for confirming :D <lh>it does seem like there should be some kind of construct to install an interpreter with some packages without having to muck about with env vars you need to log out to reload. e.g. nix has python3.withPackages https://nixos.wiki/wiki/Python <ulfvonbelow>I imagine that's probably done by wrapping the executable so that it sets the environment variables automatically <lh>imo it makes more sense to have a wrapped guile than pollute my home env with a load path var <lh>well they are different use cases, I will just have to figure that out later <ulfvonbelow>in which case there's good tooling in the build stratum (see "wrap-program") for that, all that's left is for Someone™ to write a convenience procedure <al1r4d>currently i want to use guix on devuan and i used to be gnu guix os user <al1r4d>i have a question: does guix require compilation to install and update applications? <lh>no, it offers binary substitutes <al1r4d>can I just use a binary application so I don't have to compile it in guix? 