IRC channel logs
2025-05-18.log
back to list of logs
<meaty>Is the new rust packaging flow in yet? <meaty>Should I keep waiting for it before I update my typst patch <muaddibb>what setup do you use to edit your system configuration file in emacs? geiser? anything fancy? <muaddibb>I was trying to setup geiser to recognize guix guile modules, but it is so easy to just look at the source <ieure>muaddibb, I just use scheme-mode, every time I try to use Geiser it takes for everrrrrr to compile whatever file I'm editing. <ieure>Having hacked CL with lisp-mode/SWANK/SLIME and Clojure with clojure-mode/nREPL/CIDER, the scheme-mode/geiser/guile setup leaves much to be desired. <azval>how could I use guix shell to have libcurl available ? <azval>when I do -F -C it doesnt find libcurl, without the container it works, when I do `ldd` the path to the library targets my /gnu/store, how can I compile it for a fhs compliant distro ? <ruther>`it doesn't find libcurl` - what doesn't find it? <ruther>Guix doesn't really support building for FHS. Use guix pack to build for systems that do not have Guix installed <azval>I cant reproduce, now it seems to work, I maybe indeed forgot to add "curl" to the manifest.. <azval>I see, so guix shell would be more to dev guix packages or to work on project that use interpreter (replacing pyenv for example?) ? <ruther>no, you can use guix shell for whatever you want, not just those things. I just said that you probably cannot use Guix as your deployment mechanism to people who do rely on FHS <ruther>usually you use it as development environment. I don't know why it would matter if projects use interpreter or if you're developing guix packages <azval>I see, I was just expecting that with -F since it emulates fhs, when compiling it would also use the "right" path for the binary dyn libs <intermet>Hi there! I am trying to set up a system container to which I can ssh to. I added the openssh-service and setup a pair of veth (as in the cookbook for the postgres container) but I cant ssh into it (connection refused). <ruther>azval: you cannot rely on that. It depends on what the build system will do, if it follows symlink you're out of luck. <azval>ah yes that makese sense, I will take a look at guix pack, thanks ! <azval>I am not sure to see the difference between guix copy and guix arhive, they seem to both transfer store files <ruther>azval: guix copy copies between two (running) guix hosts /gnu/store. guix archive can put stuff to file and out of file <azval>isnt it redundant ? couldnt use guix archive for both cases (--export/--import) ? <pastor>Hello! Does anyone know if its possible to propagate home services from system configurations? I don't think it is but what do you think about it? <identity>pastor: what do you mean by 'propagate'? <pastor>The idea is to have a similar behavior as system packages. Where if you declar a package in your system configuration, it is available to every user of the system. So what I want to do is that when I instantiate a system `plasma-desktop-service-type' all users will have the `home-plasma-service-type' available to them. <pastor>Yesterday I was playing arround with the idea of having a shepherd controlled plasma session started from SDDM. And this works great! <pastor>With this we can finally have DE having access to all the required environment variables visible from shepherd <pastor>And you can do cool things as `herd restart plasma' without being kicked out of your user session. <identity>pastor: there is a similar thing to what you are asking, 'guix-home-service-type', see (info "(guix) Guix Services") <pastor>The only think I don't like is that right now. You have to configure the `plasma-desktop-service-type' in the system config. And ensure that the user has a `home-plasma-service-type' configured also <pastor>I know about that one but doing it like so requires reconfiguring the system everytime you want to do a home-reconfigure <pastor>Plus that will still require to configure both services. <identity>pastor: it actually does not anymore, you can run guix home reconfigure on your system-config.scm and it will extract the home environment from there <pastor>Really, since when we have such a nice feature? I really missed that one <pastor>identity: could you give me your opinion on how to do this in a better way: <pastor>This is the trick I'm using to be able to run a plasma controlled shepherd from SDDM. I'm not sure if we can do better. <pastor>As you can see doing it like so requires the user to have the `home-plasma-desktop-service' <identity>pastor: the link does not seem to load on my end <pastor>I will try a different pastebin if this on does not load for you <pastor>I know it's not a pretty solution but I cannot think of another way of allowing a display manager (SDDM, GDM...) to boot a shepherd controlled desktop environment such as Plasma or Gnome... <identity>pastor: me neither, that looks like a solution i would arrive at myself <pastor>identity: If you could change Shepherd or Guix itself can you think of a better way? I can propose it and try to implement it if there is interest <pastor>I can only think of Shepherd extending it's service list from a system configured load path <identity>(P.S. though perhaps i would avoid system in favor of spawn and system*) <pastor>Would you? The thing is that you need to block and never return, if you spawn it in a child process would you do a waitpid or something? <identity>pastor: yeah, and fail if it returns non-zero exit status or something like that <pastor>Alright, I will try doing it like that <decfed>pastor: looking at your paste I wanted to let you know there is a function in guix to generate .desktop files. Cannot remember the name or module rn though ;) <identity>decfed, pastor: make-desktop-entry-file in (guix build utils) <decfed>identity: thanks! pastor: that might clean up the code a bit. <pastor>Oh! Thanks for that. I will take a look <graywolf>Hello Guix! I am probably missing something obvious. How can I get locales working in guix shell -C? I have tried guix shell -C guile coreutils glibc-locales -- env LANG=C.utf8 guile -c '' but that does not work. <ruther>graywolf: try adding glibc package <graywolf>ruther: no luck (and for some reason I get guix shell: warning: ambiguous package specification `glibc@2.39') <graywolf>Interesting, we actually have 2 packages named glibc and both are at version 2.39 <ruther>graywolf: c.UTF8 doesn't exist, it is C.UTF-8 <ruther>as you can see under the folder in $GUIX_LOCPATH <graywolf>LANG=C.utf8 works just fine outside of the guix shell though <graywolf>It is what I have on my laptop, I just want to get the same working inside the guix shell -C <graywolf>Oooooh but in the -C C.UTF-8 does actually work <ruther>graywolf: if C.UTF8 works in your system without container, you must've installed that locale specifically, ie. by using the locale field in your operating-system <ruther>To get it in a container, you would have to build glibc locales, not use the default glibc-locales packae that has C.UTF-8 <graywolf>Yeah, I have (locale "C.utf8") in my OS, but when I check the target of $GUIX_LOCPATH, I see only C.UTF-8 directory under it. <graywolf>That is why I always assumed some normalization is happening... somewhere <ruther>graywolf: you need to be looking under /run/current-system/locale <graywolf>That is like additionals ones added to the set from /run/current-system/locale? <ruther>GUIX_LOCPATH adds to the default paths. Mainly used on foreign distros <graywolf>One more question, should I bug report the guix shell: warning: ambiguous package specification `glibc@2.39' or is that expected? <yelninei>graywolf: i think it is because of glibc and glibc/hurd <graywolf>So Guix picks the glibc on Linux, and glibc/hurd on Hurd? I am not sure why it warns about the ambiguity then <ruther>graywolf: no, on hurd I think the wrong one will be chosen. This is limitation of specifications, the only way around it would be to name the packages differently <lilyp>hmm, can we maybe use some guix command bits to improve UX? <lilyp>like, support target-version as in `guix import` <apteryx>it's 'guix refresh' that supports --target-version <apteryx>lilyp: that script is specifically designed to get each gnome core package version from the releng file, so I don't think --target-version would be too useful with it. <apteryx>but if you meant adding extra options such as --releng-file-uri or the likes to avoid environment variables, that would be doable (I thought about it but punted for now) <lilyp>I think target-version is still a good idea, because it allows us to refresh to latest patch on a more stable branch while fetching latest on an upcoming branch <lilyp>I currently can't get gtk et al for gnome 48 to build because a deep deep failure in some python stuff, for example <lilyp>(and glib is very often a problematic update that force-bumps gtk and gstreamer if you want stuff to build) <apteryx>lilyp: I'll let you some time to experiment with it, I'm just starting. I applied your gnome-team branch and refresh gstreamer, among a couple other things, and trying ot build gtk+ then gtk <apteryx>in other news, I have rust 1.74.0 bootstrapped from mrustc 0.11.2! <g_bor>Hello, this might not be strictly something realted to guix, but I am facing a kind of strange behavior and would like to understand what am I missing. <g_bor>I am trying to build a guile program, that leverages guile-gnutls, but something seems off. I get the following error: <g_bor>In procedure dlopen: file "/gnu/store/hacg6cx3fpywgw271q16hpx9nirv7aga-guile-gnutls-4.0.0/lib/guile/3.0/extensions/guile-gnutls-v-2.so", message "/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by /gnu/store/pbnjnl6wzxlbfipqkx6yynnczajark5m-gnutls-3.8.3/lib/libgnutls.so.30)" <g_bor>What I tired is to get libc from my store (it has 2.39) and add it using LD_LIBRARY_PATH, but this segfaults. <ruther>g_bor: that is library incompatibility. You shouldn't be using ld library path, why are you trying to use it anyway? <g_bor>I would not like to use it, what I would like to do is to fix the error above <ruther>is the guile you're using coming from guix, from the same guix as guile-gnutls? <g_bor>ok, looks liek the guile is the curlpit, it does not come from guix. Thanks for your help. <ruther>g_bor: yeah, when using 'plugin'/'extension'-like systems the plugins have to have the same library deps, especially glibc as the base program <g_bor>yes, I was aware of this, the problem was that it looks like something pulled in a system guile on a foreign distro, which worked fine until now and I did not realize that I have not installed it from guix :) <apteryx>ruther I just sent the patch for the reduced rust bootstrap <apteryx>lilyp: ^ if you find yourself wasting hours building rust on gnome-team, know that there's now a rust 1.74.0 bootstrap patch <lilyp>I think my problem is deeper than that tho, with the python packages that got hit by the unprivileged builder <ruther>lilyp: what's unprivileged builder and how does it affect python packages? <lilyp>you can run guix-daemon as non-root user and some packages fail to build with that <lilyp>(you see it as a UID 30000 error) <efraim>apteryx: we already have mrustc->rust-1.74 for x86_64 on the rust-team branch <lh>I am a total autotools neophyte. where does e.g. GUIX_CHECK_GUILE_SSH come from? I can’t find a definition in the repo <lh>I see it used in the configure.ac files, and I see it expanded (I think) to a test expression in the generated configure script <lh>but I can’t find where that test expression is defined <lh>oh it’s in m4/guix.m4 which is tracked despite m4/ being entirely gitignored 🤔 should I send a patch excepting that file? <identity>i seem to be unable to connect to dicod (dicod-home-service-type), neither through Emacs's dictionary.el, nor with the dico cli. any tips? <identity>huh, 2e401032 seems to accidentally introduce a guaranteed-to-fail phase to the emacs-helm package <lilyp>fingers crossed that it'll be fixed in 7f814149 <sham1>I can't wait for emacs-team to get merged. Need that Emacs 31 <sham1>It will also fix the check-phase of yasnippets and such