<herman>my pip3 reported attribute error: module contextlib has no attribute AbstractContextManager. I checked /gnu/store/ (seems that's where everything resides) and found 5 python-3.9.9 with different prefix like "12juh2khrkglgugfusgfiluf-". in 1 of them, the contextlib.py file holds content, and AbstractContextManager is there, the others' empty.
<herman>does anyone know what mechnism is used to specify which python is used?
<herman>I guess there's something to do with the profile concept
<a12l>lechner: Sorry for late reply, but thanks for the link!
<PotentialUser-43>Hello. I'm trying to build llhttp 8.1.0 in a guix package. Nominally, this should just be "npm install && make" but the build phase fails with "npm ERR! network This is a problem related to network connectivity." Is there something I have to do to give network access to the package's build phase?
<apteryx>why are there manpages not found by M-x man, that are found by M-x woman? E.g.: M-x woman RET qsort RET
<tedium>I'm trying to build llhttp 8.1.0 in a guix package, and its makefile relies on npm which fails with "npm ERR! network request failed" because it can't find registry.npmjs.org. Is there a way to give network access to a package's build phase?
<nckx>Guix builds are not allowed to use the network.
<nckx>The only exceptions are ‘fixed-output’ derivations, that is, the exact result (hash) is known in advance and this is enforced by Guix. This is how source tarballs and repositories are downloaded.
<nckx>NPM is a hellscape of infinite dependencies that are all downloaded from the Internet. This jives very poorly with Guix.
<nckx>You'll notice a distinct lack of npm (as opposed to ‘the npm/node’) packages in Guix for that reason. Sorry.
<nckx>seninha: There's a hac^Whelper called (channel-with-substitutes-available CHANNEL SERVER) to work around this. Basically, the CI sees Guix updates as soon as other users do, so it's possible to pull to a commit that hasn't finished building yet. Or… the commit was built on CI and you didn't get it for other reasons, that's also possible, but harder to answer.
<nckx>tedium: You got quieted by the local bot after "dependencies". You can share buff hunks of text using a paste service like paste.debian.net.
<nckx>It could have been called ‘guix-json’ instead of ‘json’ but I think the assumption was that ‘json’ is such a meaningless generic term that it can't conflict with anything more specific, which is… also true. A packages.json importer would be called ‘npm’ or ‘node’.
<nckx>tedium: I won't say I didn't chuckle, but also sorry for the disappoint :)
<nckx>H-node has many flaws, in quantity and quality of submissions, but ☝ was going to be my answer too.
<janneke>nckx: the `drop all your programming languages, NPM is the future, hop onto our banwagon'-trap
<nckx>For example, a non-free Wi-Fi card is (AFAIK!) still listed there ‘because it worked with Guix’, but Guix removed the driver because we found non-free files in it. Later someone asked to add it back because ‘it's on H-node’ :) Whee.
<janneke>at the time, npm had about 4x more packages than, e.g., python, ~250.000 iirc
<Nathan-web>I'm getting an error updating my kernel. the build log shows: "guix perform-download: error: /gnu/store/xdhbsg10hkz5kyafvl8vkaqfk131w3cr-linux-libre-6.1.8-guix.tar.xz.drv is not a fixed-output derivation"
<Nathan-web>Google hasn't shown anything. Is this a problem with my setup, or a packaging issue?
<nckx>Hi Nathan-web. This is a problem with a third-party channel. I thought they had fixed it already, but maybe not. Make sure you've run ‘guix pull’, otherwise ask in their (IRC) channel.
<elevenkb>i'm getting a weird error when i try to run `guix system reconfigure` with `install-bootloader`.
<elevenkb>so i can't run the new system, but happily guix keeps the old system configs around.
<seninha>Last question: i have set (guix-configuration ... (guix (current-guix)) ...) and it seems that `guix system reconfigure` calls `guix pull` (or at least outputs the same messages), is that the case?
<seninha>i'm running guix on a vm and I copied the vm-image.tmpl template to use in it. But idk what that (guix (current-guix)) line does.
<seninha>it seems that (guix (current-guix)) makes i use the last, bleeding-edge commit of guix, is it?
<elevenkb>the error is: `guix system: warning: exception caught while executing 'eval' service on 'root'`
<nckx>seninha: Yes, well spotted, that will cause a ‘guix pull’ as part of the build (isolated, so it won't change anything outside of the build). It solves a particular problem: Guix contains a ‘guix’ package, but since this is a regular Guix package with a source hash etc., it must by definition be an older commit of Guix. This can sometimes cause trouble, or simply waste space, so ‘(current-guix)’ is a little hack to refer to the ‘surrounding Guix’ tha
<nckx>t is actually performing the build as a package. I hope that makes sense; it sounds esoteric written down :)
<seninha>elevenkb: it seems that it does not know where `remove` comes from, you probably should use the proper modules
<seninha>try to include (srfi srfi-1) in your use-modules
<nckx>seninha: So no, not ’last available commit’, just ‘the same commit you've just invoked from the CLI, rather than an older one nested inside of it’.
<seninha>elevenkb: like (use-modules (gnu) (guix) (srfi srfi-1) ...)
<elevenkb>nckx, nope it is something like 2-3 days old.
<nckx>Not really (I'm not a VM person and have never used that image). I know why it's used in the installer: so that ‘guix system init my-shiny-new-system’ doesn't install older packages than the ones actually on the image.
<nckx>If the idea is that people will use the VM image without pulling, that would be the same reasoning.
<elevenkb>nckx: the issue is that my system configuration isn't self contained. just ignore me for now until i find a minimally complex and maximally self-contained reproducing example for this error.
<nckx>(Hm, no, it makes the change to the installer for the exact reason I gave above, but does not explicitly mention the VM image. Still, I guess one expected use case is that people will use Guix in the VM without pulling for some reason.)
<elevenkb>Yah sorry, I overstated... my last sucessfully rebooted generation was produced on Jan 14.
<nckx>elevenkb: Does this happen if you ‘guix system vm’ your configuration, assuming that works?
<nckx>elevenkb: That's recent enough in my book. Recent enough that there should be no weird missed API incompatibilities in Shepherd or Guix 👍
<ae_chep>oh you just used the ellipsis character instead of 3 dots. I'm used to seeing it elsewhere but that was a first for me in IRC
<nckx>TyPoGrApHy Is mY PaSsIoN (but like, kind of actually).
<elevenkb>nckx: i'm running guix system vm right nw.
<nckx>Mock me for my capitalisation & punctuation, but stay away from my … :)
<nckx>elevenkb: I didn't expect the build alone alone to trigger it. The reason I suggested a VM instead of ‘guix system build’ was to see what happens when you launch it (it should print a .sh script).
<luishgh>hi guix, i was trying to add a native-search-path for emacs' new treesit module and i have a question. when i add something like (search-path-specification (variable "TREE_SITTER_GRAMMARS") (files '("lib/tree-sitter"))) to a package, in this case emacs-next, does it mean that automatically any files produced by packages included in the profile that have the path like "$output/lib/tree-sitter/foo" would be added to that environment
<luishgh>variable? Or does that package need to increment the variable itself?
<nckx>I am requesting a DuckDuckGo ‘bang’ (‘Please test your bang’—OK) search command for Guix.
<nckx>‘☑ This bang would be useful to more than around 500 people.’
<nckx>luishgh: It should be automatic, but I don't know what you mean by ‘increment’.
<nckx>What you describe is certainly what is supposed to happen.
<luishgh>nckx: sorry, i wasn't really specific. what i mean is that the $out/lib/tree-sitter from the other package will be added to the variable using the delimiter ":". so, in the example, TREE_SITTER_GRAMMARS would have a value like "/gnu/store/hash-foo/lib/tree-sitter/foo:"
<terrified-user>Before this, the last system reconfigure was simply to add docker-service-type and that's all.
<nckx>Hi terrified-user. Sorry this happened! Did you make any other changes before the last reboot (a previous ‘guix system reconfigure’, perhaps)? Anything that could have changed your storage layout?
<nckx>(I can't promise anything, but in your shoes I'd be annoyed but not worried about data. Still, I don't want to preach at this time, but consider setting up backups later if you really are worried now.)
<terrified-user>nckx: I have backups, but from three days ago, so I'm not sure if I could lose something important. And most important things are in public repositories.
<nckx>If you don't have such a rescue medium, you can try ‘search --file /boot/grub/x86_64-efi/normal.mod’.
<luishgh>nckx: that's exactly what i want. i've added this native-search-path to emacs-next on my guix checkout, but when i run `./pre-inst-env guix shell emacs-next tree-sitter-c --search-paths' (tree-sitter-c is a package from a patch series still not applied on guix: https://issues.guix.gnu.org/49946), only PATH, EMACSLOADPATH and INFOPATH appear :/.
<nckx>terrified-user: Did you miss my message about a rescue medium (USB, CD, …) earlier or is that really not an option? If the file isn't there, bootstrapping GRUB from rescue mode is hard to impossible.
<nckx>Right, but I'm not sure if there's a way to get GRUB to load a mod~ file when it expects mod.
<terrified-user>nckx: So I plulgged the USB and rebooted. I'm at grub rescue again.
<nckx>Well, you'll have to ask your firmware (sometimes called ‘BIOS’) to bring up a boot menu. It sounds like it's still booting from your internal drive?
<ArneBab>Is this the right way to update my system from a local checkout with changes? /path/to/guix/pre-inst-env guix pull -c 12 -M 24 -k --branch=core-updates --allow-downgrades --url=/path/to/guix --disable-authentication
<nckx>If you run ‘lsblk -f’, you'll see all your partitions. I hope it's obvious from that layout which one is your root partition (the one with all your files, you saw from the rescue shell earlier). Or maybe you know it. Something like /dev/sda1.