<gabber>i configured a home-openssh-service. `guix home container config.scm` and trying one of the ssh rules i get "Bad owner or permissions on /home/gabriel/.ssh/config". owner is pid 65534, group (name?) is overflow. is that a bug?
<civodul>gabber: hi! i noticed that within the container, but it's fine otherwise
<civodul>that's because /gnu/store in the container is owned by the "overflow" user
<gabber>hi! so it is not possible to check whether the home-openssh service works in the container?
<z20>Hello. I've been having some difficulty getting Guix System running on both a Librebooted Thinkpad X200 and a stock BIOS T410. In both cases, I was unable to get as far as the GDM login screen, and had an error saying "ACPI (...) BCTG: evaluate failed". After removing references to power services in config.scm, this error no longer shows up, but I still have no graphical login screen. Does anyone know what the origin of this error
<z20>was able to install Guix with the autoinstaller, somehow.
<gabber>is the binary `more` not part of a basic container toolset? `dd` is, `cat` and `echo` are. if so: which package brings `more` along? it's one of the harder tools to search for..
<nckx>z20: You're certainly not the only X200 Guix user… I think raghavgururajan had an X200 with Guix on it at one point? I'm positive there are several, I just don't know who. The last warning or error printed to the console more often than not has nothing to do with graphics problems.
<nckx>Or the poor PC speaker would have been responsible for most of them.
<muradm>sneek: later tell unmatched-paren: i provided gtkgreet package and configuration yesterday isn't it? i didn't follow your last discussion, could you make wlgreet working for you? do you need gtkgreet paste bins again?
<sneek>unmatched-paren, muradm says: i provided gtkgreet package and configuration yesterday isn't it? i didn't follow your last discussion, could you make wlgreet working for you? do you need gtkgreet paste bins again?
<jpoiret>bonz060: you can look up where a specific package is propagated manually in the manifest file present at the root of any profile
<jpoiret>there's no CLI for that right now I think
<jpoiret>the manifest file internal to profiles contains a description of all the installed packages as well as the ones propagated in a tree
<jpoiret>are you getting the issue while building a package?
<bonz060>jpoiret: I've actually found how to do that using guix graph. Here's how that command looks like: "guix graph -L /home/bonface/projects/guix-bioinformatics --path genenetwork2 python-dataclasses"
<jpoiret>right, but you need to know which package pulls it in then :p
<jpoiret>there's no guix graph --path PROFILE-PATH PACKAGE
<taeaad>If I run install.packages() in an interactive session, it says that my Guix path to the library is not readable. Conversely, I don't know how to specify that I am looking for an R package with "guix install" on the CLI.
<maximed>I could give some explanation but it's easiest to give with concrete examples.
<maximed>I have an example ‘in the wild’ -- it's python instead of R, but it's exactly the same system
<taeaad>I mean, I have two options here. 1) Forget about it and use a personal library with the internal command install.packages or 2) Make a Guix package for the libraries that are not available under "guix install r-*".
<maximed>taeaad: For (2), you first need "guix import cran", as you wrote.
<taeaad>maximed: That works for me and I can echo it out to a file.
<maximed>theaad: Could you upload the file at paste.debian.net (makes the explanations easier)?
<dcunit3d>i hope to start building more packages soon. i have a channel set up on my filesystem
<dcunit3d>what if the package doesn't doesn't include a runnable bin?
<acrow>dcunit3d: yes, that's why 'guix build <your-package>' is probably what you want. To avoid a build you might try something like, 'ls -d /gnu/store/*<pkg_name>*'.
<berkowski>I'm certainly no expert, but that store path will look like the /usr root of a normal system, so it'll contain the usual bin (e.g. /usr/bin), lib, etc
<acrow>Though there will likely be choices if you don't do gc often.
<dcunit3d>ah thanks. i've run into this a few times.
<berkowski>Is there a way to set shell environment variables in a "guix shell" manifest.scm? I'd like set the equivalent of setting "CC=$(which gcc)" after running `guix shell gcc-toolchain`. The manifest file will install gcc-toolchain for me, but I'd like it to also set a few environment variables
<dcunit3d>there may be some way to do it with direnv, but that's not a great solution
<dcunit3d>i was looking deeper into manifests the other day and i thought i saw something like that, but now don't see it in the docs
<berkowski>Yeah, I came across an old blog post speaking to that. But I'd like to keep it in the manifest file as it really only affects those using guix to set up the development environment. I don't need to do anything special if I use system packages
<lechner>Hi, are traductions the same as upgrades? (on mailing list)
<berkowski>fwiw this is due to having to use user-installed rust through rustup because guix doesn't provide alternate toolchains (thumbv6m for me)
<dcunit3d>the manifest record is defined in guix/guix/profiles.scm:204
<dcunit3d>then the environment is purified/defined when the profile loaded in load-profile at line 2032
<nckx>lechner: Translations? Of? Which mailing list?
<dcunit3d>berkowski: you may be able to use a manifest's properties, but i am unsure. one other way that may allow you to set variables is to abuse a manifest's search-paths functionality
<lechner>nckx: <email@example.com> on devel, but it's not on the web yet
<berkowski>dcunit3d: yeah, looking through the parts you listed. My lisp is... weak... but it looks like I should be looking at the `manifest-entry-properties`?
<dcunit3d>yeh, it's really tough to parse some scheme. the records are fairly straightforward, but the lambdas/macros and gexps throw me for a loop
<dcunit3d>the `guix edit` command helps me navigate the codebase, but i use emacs with lispy, so i can run through it pretty quick.
<dcunit3d>i haven't had enough time to learn scheme yet though, so i'm afraid i can't help you much more than that. there may be a way to get the manifest to evaluate and create an environment with a path.
<dcunit3d>if nothing else, you can craft a package containing a script to place in the guix shell's path somewhere and run that.
<berkowski>I'll try to hunt down a package defintion for something that exports environment variables. I know git does
<maximed>I had some disagreements on how it was presented and the implementation (it does more specifically search paths, which are already handled by packages), but having a method to set arbitrary environment variables in manifests sounds good to me.
<berkowski>maximed, dcunit3d: Think I've got something workable here, and if I can do it then the bar of entry is pretty low :) I'll throw it up a gist once I comment it some
<berkowski>just in case this gets dragged up by someone else searching
<maximed>"guix weather" runs as your current user, the substitution happens by the daemon. The user has a cache, I don't know if the daemon has a cache but if it has a cache it is an independent cache.
<maximed>Possibly the two caches have a different view on the world.
<maximed>Should resolve itself automatically by waiting a little.
<maximed>(where little=some quantity I don't know the value of)
<nckx>You can delete /var/guix/substitute/cache/* if you want.
<nckx>raingloom: What does ‘guix build -d calibre’ say?
<podiki[m]>nckx: did we ever actually sort out any of that gallium driver naming business? I see we don't have "crocus,zink,d3d12"
<nckx>raingloom: What does ‘guix build -d calibre --no-grafts’ say? — to be safe.
<raingloom>/gnu/store/n3s5bizkqa8ydx0kw6kniy88m24sjrz6-calibre-5.36.0.drv is what it tries to build
<raingloom>then it tries to connect to the offload machine, which... why.
<unmatched-paren>maximed: i just found another reason to be excited for antioxidant :)
<raingloom>with --no-grafts it just prints this: /gnu/store/h9vfp3ml67k220mivgcj0fb2n5lwby7d-calibre-5.36.0.drv
<podiki[m]>d3d12 was enabled in Arch for WSL hardware support (does guix work in WSL?)
<ss2>Here in https://issues.guix.gnu.org/54561#25 Ludo meant that I'm supposed to add certain files to local.mk and POTFILES.in. Should they be part of the same commit of when the actual service file is added to the tree?
<podiki[m]>"The Zink driver is a Gallium driver that emits Vulkan API calls instead of targeting a specific GPU architecture. This can be used to get full desktop OpenGL support on devices that only support Vulkan." (from mesa's docs)
<podiki[m]>in short, to run opengl stuff using vulkan, since opengl support is getting spotty it seems
<nckx>podiki[m]: I think we should ideally aim for -Dgallium-drivers=auto, if that's at all realistic.
<unmatched-paren>interesting! i didn't know there were devices that only supported vulkan
<nckx>Which should be ‘all’, for the architecture.
<podiki[m]>what about on other archetectures, should it just be auto for everything and hope mesa/meson is smart enough? the comments in our mesa package imply svga on aarch64 needed work at some point
<podiki[m]>well auto did not enable d3d12 so must be a missing dependency, will investigate
<vagrantc>oh yeah, i need to push FORCE_SOURCE_DATE to core-updates ...
<vagrantc>now i just need to use my amazing native english skills to update the description betterer
<nckx>I'm going to be optimistic and say that I'll submit the actual content soon enough that it doesn't need a ‘coming soon’ announcement. Also a way to motivate myself to actually do so now that I've promised to.
<ardon>Hi Guix, playing with postgres again. I want to set its locale to C.UTF-8 but from my understanding Guix isn't set up with it by default, so I get errors. How can I add the C.UTF-8 locale to my system configuration?
<ardon>nckx: Thanks for the heads up! Will wait for it then
<vagrantc>that could definitely be a while. stick with my empire's handy en_US.UTF-8 locale for the near future...
<nckx>With any other package I might have suggested building a custom postgres linked to the new release, but that would asplode your machine in this case so I won't. Sorry for the disappointing answer.
<nckx>It's probably just me, but the use case of other packages running texlive to build documentation is both (1) perfectly logical and (2) wasn't obvious to me at first.
<vagrantc>ok ... thanks for spelling out your thoughts, that might actually help me write something worth pushing :)
<nckx>I will gladly serve as lowest common denominator for comment testing.
<podiki[m]>on the mesa "auto" front: I can eliminate a few configuration cases we have, but we have architectures that don't support "auto" and also where the "auto" list is less drivers (not sure what that means, maybe a change in v22?)