IRC channel logs
2025-07-23.log
back to list of logs
<Kolev>Still waiting on emacs-elfeed to install. <clarkf>Kolev, elfeed shouldn't be that intensive. Are you sure you're not still experiencing disk failure? In my experience, slow disk io absolutely kills guix performance <Kolev>Also, this is happening on two different machines. <Kolev>clarkf, well now it's happening only on the computer I replaced the disk in. Now I'm not quite sure. Maybe I do need to get a proper big hard drive. <jmes>Can I "pack" a guix system container so I can just copy it to another GNU/Linux machine and run it without foreign guix? <Kolev>I don't believe you can install stuff in the container. The container stays the way it was defined. <vhns>Is there a way to append to a package arguments? That is, such that I can inherit and add more arguments to it. <vhns>Instead of having to copy-paste the existing ones <jmes>Kolev: that would be great if so, I'm okay with such a container being completely declared ahead of time. Do you know the mechanism I use to create one? <vagrantc>vhns: i think it is slightly more complicated that just adding stuff, but you can inherrit individual phases and whatnot and add and delete stuff from it <Rutherther>vhns, of course, it is just a list. See the substitute-keyword-arguments and ensure-keyword-arguments helpers <Kolev>jmes, did you read about "guix pack" in the manual? <jmes>Yeah but I can't connect the dots for using it alongside Guix System Containers <Kolev>guix pack -f docker -S /bin=bin guile guile-readline <jmes>I guess I need to pack what I need to generate the run script on the remote machine <Rutherther>jmes, have you thought about making a system docker image rather than packing guix system container, as that is much better supported use case? <Kolev>Rutherther, what's the difference? <jmes>Yes, I was just curious if I could get away without it. But I will definitely experiment with the docker stuff too. <Rutherther>Kolev, guix system container produces a script to run a container, guix system image produces an image you import to docker/podman and run with docker/podman <Kolev>Rutherther, sounds like "guix system image" is better. <jmes>Yes probably best for my case, thank you both :) <Rutherther>Note that Guix system container shares the gnu store with host, so it might be harder to get it properly working in a guix pack, making a nested namespace. And user namespaces is a requirement for guix system container for sure <Rutherther>I might try this at one point though, seems like an interesting thing to try, to make a package from container-script and put it to guix pack <jmes>I thought -RR would eliminate the user namespace requirement <jmes>Would love to know if you try it and succeed (or fail)! <Rutherther>That eliminates the requirement of guix pack, but not of guix system container <Rutherther>And I am doubtful guix system container script would have any chance of working if you used any of the other backends for pack than user namespaces <vhns>Rutherther, vagrantc: Ended up using the example from the cookbook that is in .guix/modules/guile-package.scm which is (package-with-configure-flags). I wonder why this isn't defined as a public variable/utility. <vhns>err, from (guix-cookbook) Package Variants <vhns>which is what I needed, to modify a packages configure flags <bdju>Anyone been thinking of updating the Gajim or Kaidan packages? I was just thinking I wanted to check in on each client's progress, but we have pretty old versions of each. <apteryx>is someone else having issues with the indentation of scheme in emacs 30 having changed? seems to be party caused by my config, as 'emacs -q' behaves closer to emacs 29, but I'm at a loss. <apteryx>I'm now seeing larger hanging indents using 2 spaces instead of 1 for example <apteryx>interesting, it seems like my current emacs is in a weird state, as starting a second instance with 'emacs' (without -q) does behave the same as 'emacs -q' for indenting scheme. <apteryx>if I want to expose a native shepherd service as a service-type in Guix, is there a shorthand to do that, or must I define a <shepherd-service> record, then wrap it in a <service-type> record manually? <vhns>When using (greetd-service-type) with (greetd-wlgreet-sway-session) is it meant to start sway when you login? In my case I still end up on a regular shell <vhns>Oh well, changing (command) to "sway" under (greetd-wlgreet-sway-session) did the trick <WilhelmVonWeiner>I can't reconfigure a system I have installed on an old laptop because it doesn't have network. I can set up wpa_supplicant with `wpa_passphrase` and `wpa_supplicant -i wlp1s0 -B -c wpa.conf`. I can't ping anything, is there an obvious reason why? <gr1n>I've just installed guix and I'm seeing that neovim is on version 0.9.5 on the channel but 0.11.3 in their git, I suppose that emacs is more common in guix due to being more useful for guile <gr1n>how common are outdated packages? <identity>gr1n: iirc the neovim update is held up by the rust-team packages because of tree-sitter and stuff <gr1n>I see, rust seems difficult to do declaratively <identity>the problem is less declarativeness and more sprawling dependency trees and how to deal with them, though the rust team have figured out a better approach (see the recent blog post) <gr1n>I had horrible download times using the official iso that still pointed to savannah, changing to the codeberg channel solved it, is that known? <identity>gr1n: savannah is struggling because of scrapers at the moment <gr1n>ouch, good thing I didn't keep trying <gr1n> I saw some commits about creating an impermanence setup but I can't find any examples in the documentation <decfed>I would also be interested in that impermanence thing <gr1n>if no one finds some documentation or guide I'll read how it was supposed to work reading the commits and write one <Deltafire>made a 2 line change to a file, now guix has spent all day compiling stuff <old>with recent kernel, I get a segfault of the init process and failed to load micro-code for my cpu <old>I do manage to boot completely tho <old>anybody with similar issue? <old>microcode: No sha256 digest for patch ID: 0xa20102e found <old>microcode: CPU1: update failed for patch_level=0x0a20102e <old>init[1]: segfault at 3fff00 ip 00000000004d4953 sp 00007ffdbb8ffc50 error 4 in guile[d4953,401000+201000] likely on CPU 5 (core 5, socket 0) <identity>iirc i got a segfault at boot too today, let me check <andreas-e>I suppose this is not with the linux-libre kernel from guix? <identity>“[…] sp 00007ffee0999720 […] likely on CPU 3 (core 3, socket 0)” for me <old>andreas-e: if the segfault is a consequence of the failed microcode update nope I suppose <identity>nothing about microcode apart from “Current revision” <old>identity: you have linux-libre or linux from nonguix? <old>I have the non-libre variant. So there's something about Guile that crashes the init process during boot <Deltafire>i just rebooted and got this: segfault at 3fff00 ip 00000000004d4953 sp 00007ffd2c466870 error 4 in guile[d4953,401000+201000] likely on CPU 2 (core 2, socket 0) <old>gcc 14 is kind of old? identity: did you mean 15? <identity>old: well gcc-14 recently became the default (up from gcc-11) <old>I don't see any major breaking change in gcc-14 for C <andreas-e>Tons of! Lots of compiler warnings became errors. <apteryx>it does a bunch of extra checks, so packages building with -Werror fail <old>that's not a breaking change <identity>it did cause a bunch of breakage, though! <old>in the sens of packaging sure <Kabouik>I remember that someone wanted to look into how to avoid being prompted for the LUKS passphrase twice when booting Guix. Maybe unmatched-paren (but not sure, and sadly I don't see them around anymore, same with nckx). Was there any progress made on that front? <old>not in the sens of running the software after compilation <old>For example, a breaking change would be like in gcc-15 where union do not initialize to 0 fully anymore but only the size of the first member <old>if somehow you rely on the full union to be 0, then you will likely get a segfault <nameiwillforget>I'm trying to import my Emacs config into my new Guix system and I thought I'd use Guix to install the packages that I'd normally install from MELPA with use-package. But I'm not sure what the right way for this is. I found `guix import` but it generates a package declaration with a fixed version and I don't want to litter my Guix config with dozens of these package declarations. So I thought I'd define in my config a variable <nameiwillforget>`melpa-packages` containing all package names I have from MELPA, then use `mapcar` to apply `guix import` to each package name. But when I do that I get a message that `import` does not fulfill any known form. So what's the right way to install my Emacs packages using Guix or should I just do it the old-fashioned `use-package` way? <identity>nameiwillforget: the (gnu packages emacs-xyz) module has a lot of emacs packages, are some packages you use missing from it? <nameiwillforget>At least some that I'm using don't appear when I look for them on packages.guix.gnu.org. <csantosb>nameiwillforget: Instead of packages.... try `guix search emacs-whatever` <nameiwillforget>Yeah, for instance if I do `guix search emacs-smart-mark` I get nothing. <csantosb>Also useful, `guix search emacs- | recsel -p name,synopsis` <identity>some are just not packaged, you could package them and contribute <nameiwillforget>I could start to, once I've gotten Emacs set up ^^. So for those I should just use `use-package`? <identity>also search takes multiple words so you could “guix search emacs package name” instead <csantosb>Try a: `guix import elpa -a melpa smart-mark > /tmp/smart-mark.scm` <csantosb>nameiwillforget: do you have many missing packages ? depending if this is only a few or a lot, you might proceed differently <identity>nameiwillforget: putting those in your config (or a separate file that you then ‘use-modules’) may be a better option <csantosb>Use-package considers dependencies already installed by Guix ? <nameiwillforget>csantosb: That works. That's why I thought I'd just make it so that declarations for these packages are created using `mapcar` and `guix import` each time I reconfigure my home system. But `guix import` doesn't seem to work in `config.scm`, even in the system-wide one. <identity>csantosb: ‘:ensure t’ should try to load the package first and otherwise try to ‘package.el’ it, ‘package.el’ should handle dependencies correctly i would guess <identity>nameiwillforget: i would be surprised if it did, how are you invoking it anyways? <nameiwillforget>I'd then bind the generated list to a variable, then install all package declarations in the variable. <identity>‘guix’ is not a function, you would want something like (guix-command "import" <>) and even then it would not to what you want and would be a headache to make it do what you do want (and definitely take up more space than the package definitions would) <nameiwillforget>Oh, ok. So I guess the simplest way would be to just use `use-package` for now and look at adding missing packages to the repositories in the long run, right? <gihc>Hi all, I would like to experiment with Guile Hoot on my phone. The the documentation for Hoot says that the easiest way to get started is to use guix shell. The guix qcow2 image uses xfce, but I would like a headless/no graphics. Can I download such and image anywhere <gihc>I am using termux on my phone which has qemu-system-x86_64 <andreas-e>I do not think so. But you can always create one! <pegaso>or just adjust the vm maybe? never used the qcow2 image but I guess you can remove xfce-desktop-service-type from /etc/config.scm and then run guix system reconfigure /etc/config.scm. be careful with the parens in the way? <pegaso>refer to "using the system configuration" in the manual, should give you some ideas <pegaso>"using the configuration system", i mean <podiki>andreas-e: so llvm-for-rocm has different errors for different gcc version (gcc-14 was the only one with that include error); i decided to try to update the whole rocm set and actually it wasn't bad so i'll post that for review today <andreas-e>podiki: Sounds good! I like it when a problem is solved by updating, since that automatically makes us make progress. <podiki>i was worried because rocm is a complicated set, but at least i got them to build and i think it runs for opencl (darktable-cltest for now) <nikolar>as far as i can tell, you just need a basic server to server a few files <yelninei>janneke: i tried to change it from profile/hurd to system/hurd/hurd but then I was missing netdde <yelninei>additionally the librump test also fails to link when building natively with lots of undefined references, but only reenabled when cross compiling <podiki>(source (package-source ...)) is failing for me with "source expression failed to match any pattern" what am i missing? the package is in a different module but i tried referring to it like that as well and still the same <janneke>yelninei: it used to be system/profile/hurd, right? <janneke>before commit f2cefd700d6fb6ee26a9289b8194524062d2778f <podiki>actually error is unbound-variable for the package in package-source; hrm <yelninei>janneke: system/profile/hurd and profile/hurd is the same thing. I misread your change yesterday <yelninei>Imo it should be system/hurd/hurd to use the operating-system field that already exists for this and not rely on the profile but we miss netdde which is problematic <podiki>the package is also hidden but even an @@ still doesn't work <ieure>podiki, Hidden packages are orthogonal to whether a symbol is exported from a module. <podiki>right okay, it is a define-public package though <podiki>is this maybe when things are resolved and thunked? <ieure>podiki, Do you have a paste of your package definition? <podiki>the source is llvm-for-rocm, trying to not duplicate the same source origin in (gnu packages rocm) packages <ieure>podiki, Possible you haven't imported whatever module defines `package-source'? <ieure>Seems unlikely, I think it's (gnu package) or something, same as the `package' record type. <podiki>certainly have, as that package (llvm-for-rocm) is used in inputs in that same rocm module <ieure>podiki, Not sure. I find it helpful in these situations to screw around in the REPL until I figure out what's wrong; eval bits of the package definition to see what isn't working. <podiki>i don't think i know how i would approach this in the repl :) the variable llvm-for-rocm is fine in inputs, but not in (source (package-source llvm-for-rocm)) <podiki>i even tried a direct module-ref (resolve-interface <ieure>podiki, The error you're getting is saying that some macro you're using is malformed. Guessing something else about the package definition is wrong and Guile having useless error reporting is misleading you. <podiki>the packages build otherwise, just trying to change the source line <ieure>Pretty much impossible to say without seeing the package definition you're having the problem with. Feel free to PM it if it's unsuitable for the channel. <podiki>this is for guix, just trying to clean up slightly before i submit it <podiki>(one source change to try package-source llvm-for-rocm) <ieure>podiki, I'm able to load a Guix REPL and ,m (gnu packages rocm), then paste your patched rocm-device-libs package definition into it and get a working package. So I think this supports my theory that something else with your package definition is wrong. <podiki>this is with the line change to (package-source llvm-for-rocm)? <ieure>Evaluating (package-source llvm-for-rocm) also works fine. <ieure>podiki, So I think this supports what I was saying, that there's some other issue and the Guile error reporting is unclear. <podiki>my thought it is something about when things are resolved in the package definition, which might not be the same as in the repl <podiki>as i get the error only in that one line change, fine with a regular source origin <ieure>Shouldn't be a problem unless you have some kind of module cycle. <podiki>there's not, the same package is used as an input <ieure>Would recommend backing out your changes and reapplying them one hunk at a time until you find the issue. <podiki>everything builds and works, just trying to deduplicate the same source origins <ieure>If you back everything out and add just the (source (package-source ...)) change, does that break? <ieure>Hmmm, okay. I don't know then. It sounds like a module cycle. <podiki>something something when things are resolved, thunked, .... <podiki>guess i'lljust use a (define ... (origin ...)) as i started to <Zelphir>Hi! I am running into a locales issue with Guix and I am not sure what I am doing wrong. I am running Guix on foreign distro (Debian 12) and I installed "glibc-locales" in guix root profile (`su -` and then `guix install glibc-locales`) and in the normal user profile (just `guix install glibc-locales` as normal user). Both packages install just fine. But then Guix tells me I should export GUIX_LOCPATH. Which I did: `export GUIX_LOCPATH="${HOME}/.guix-profi <Zelphir>le/lib/locale"` in `.profile`. However, now guix-installed Guile is broken. It now has trouble with the lambda unicode character, instead of writing "lambda" and also has problems with the degree character "°" that I tend to use for loop variables. Also I get an error: "guile: warning: failed to install locale" and "warning: failed to install locale: Invalid argument". I already found https://lists.gnu.org/archive/html/bug-guix/2020-05/msg00668.html, but <Zelphir> even though I installed the locales in the root profile and user profile, I still have this issue. <hwpplayer1>hello, do you please show the package manager source code link ? <Zelphir>Does anyone know what the recommended way is to make guix locales work on foreign distro, so that neither Guix nor Guile has an issue and bugs me about installing locales? I had Guile working fine on this distro before, but recently gave in to the nagging of Guix to install the locales and export GUIX_LOCPATH, and now Guile seems broken. <Zelphir>Also I noticed, that the progress bars when doing `guix pull` are broken, and show trapezoids with question mark inside, instead of "bars". <podiki>however, there was just a big merge in guix updating core components, so maybe you were unlucky with your timing just before/after and need to do a guix pull, upgrade, and relogin/restart <ieure>Zelphir, That glyph means you don't have a font on your system able to display that character. <Zelphir>Hm, but how did the font disappear? I know this worked properly before. <ieure>hwpplayer1, That is the source, yes. <Zelphir>I'll try the things mentioned on that website podiki mentioned. <ieure>hwpplayer1, It's not really that simple. What are you trying to do? <ieure>hwpplayer1, Changes are contributed as pull requests on Codeberg. <Zelphir>Does installing the `glibc-locales` package also generate the locales, or do I need to run any extra command? <Zelphir>Seems Guile is now so broken, that I cannot even do that import: <Zelphir>scheme@(guile-user)> (use-modules (gnu packages base)) <Zelphir>In procedure string=: Wrong type argument in position 2 (expecting string): #f <AidenIsik>Hi, I've been a bit stupid and forgot to put changelogs for my commits in a PR. I've tried to use committer.scm.in, however it does not seem to work properly. Does it need processed by autotools or something? <podiki>there are some snippet helpers (yasnippet, tempel) if that's what you are looking for <podiki>there is no autotools processing for that <Zelphir>My terminal emulator is configured to use "DejaVu Sans Mono Book". Which I was able to select in the preferences of the terminal emulator itself, from a list of available fonts. So the font exists, but only question mark thingies shown as progress bars. Not sure what I am supposed to do, because I don't think the idea is to have me guessing a font that has "progress bar parts". <ieure>Zelphir, If your font doesn't have a glyph, the system will fall back to one that does. <ieure>Zelphir, ex. most Western fonts don't have CJK glyphs, so font rendering will combine multiple fonts to show you the codepoints. <Zelphir>That seems to be broken on my system. Is that related to locales? <Zelphir>If the `glibc-locales` are not working or not found, could this make this glyph search break? <Zelphir>(I have to restart to reload .profile. Should be right back.) <Zelphir>Well, the funny (annoying) thing is, that even when I set `export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"` in my `.profile` guix still complains about `hint: Consider installing the `glibc-locales' package and defining `GUIX_LOCPATH', along these lines: ...`. <vagrantc>i get the feeling something wrongly resets various permissions periodically... <andreas-e>AidenIsik: committer.scm.in is processed by configure to create committer.scm. And this only handles simple situations; simple package updates work well. <andreas-e>vagrantc: We are several to have noticed this, the button has disappeared. Now we just close... <vagrantc>i guess i could force-push the commit that fixed it... <vagrantc>then it would presumably be marked as merged ... <vagrantc>but then it might show no commits differing <Zelphir>Ah wait, that is talking about Guix OS. Nvm. <Zelphir>I fixed it! Yay!! -- The issue were somehow wrong entries in '/etc/locale.gen', which were commented as "added by KDE" or something, OR, LC_ALL not being set inside '/etc/default/locale'. After fixing those 2 things, regenerating locales, and restarting, now guile works again, and Guix also stopped nagging about installing glibc-locales. So apparently it was an issue in my distribution's configuration. <Zelphir>To be clear: (1) I have installed "glibc-locales 2.41 out /gnu/store/vaq9j09i3qln1cj6d363r629y3a59krj-glibc-locales-2.41" in the root profile, and "glibc-locales 2.39 out /gnu/store/xf6mwxlp10pj4dv6diqb30z0spla8s5w-glibc-locales-2.39" in the user profile. Why those are different, I cannot say. It is what guix chose to install. Perhaps because of dependencies of other packages I have in the normal user profile, that depend on the older <Zelphir>version. Or because I need to run `guix package -u`. <Kabouik>andreas-e: I realized from a message of the chafa dev that our package is missing support for multiple image formats. Is that okay if I make a new PR even though you just merged one? Sorry for the extra work. :/ <andreas-e>Kabouik: Sure, make all the PRs you like! On my hand, I do not guarantee that I will not implement an exponential back-off strategy and commit more and more slowly :-P <andreas-e>All my messages to @gnu.org, among which guix-devel@gnu.org, are coming back now with the error: <andreas-e>connect to eggs.gnu.org[209.51.188.92]:25: No route to host <Kabouik>I was actually quite happy to see fast commits, I must admit I have had some packages getting covered in dust in the old days and that sometimes hurt my motivation to submit patches (that and I must say I was not comfortable with the git-send-email workflow, though I did see how it could be great once mastered) <andreas-e>For the time, it may be luck - although I do not want to dampen your enthusiasm! <ieure>andreas-e, eggs.gnu.org is the MTA for gnu.org, can you ping / traceroute it? <ieure>andreas-e, Guess is that it's GNU infra falling over yet again. <andreas-e>I notice that the issues and PR queues are growing again. <andreas-e>So mathematically, somme issues will end up in the hidden tail collecting dust. <andreas-e>I (and other people) have been quite fast over the past few days reacting to breakage from the Big Merge(TM). <andreas-e>ieure: I can ping, traceroute shows lots of *. <ieure>andreas-e, `nc -vzw1 eggs.gnu.org 25' will test connectivity to the SMTP port. Doesn't appear to be working to me. <Kabouik>I'm having headaches with the propagated-inputs conflicts when trying to upgrade my Guix packages, it seems to go as far down as things like `curl`.. <podiki>a reason we don't like propagated-inputs :( <podiki>did you add any to some package locally? or else maybe something is now propagated that you had in your profile explicitly, so you can get rid of it <Kabouik>No I don't think I added any, at least not in the last few months that's for sure. Can't exclude that there is something in a package from a private channel that was poorly maintained. One problem is the conflict error message is not exhaustive, it keeps throwing an error for two or three propagated inputs from some packages, then you remove them, and you discover that it goes down to other packages. <Kabouik>It would be nice to have an exhaustive list of conflicts from the first try, and ideally a way to list the guilty packages in a space-separated list so that they can easily be removed and reinstalled together. <Kabouik>I excluded jnettop from the upgrade and it seems to upgrade now, at least it has not crashedy et. <Kabouik>I see that andreas-e opened an issue about that package too. <andreas-e>We also use it on our infrastructure. But as for other packages, I am saying to myself that there must be more modern, maintained software for this kind of tasks?! <Kabouik>I can't help you there, I actually don't remember why I installed it, probably something that would have been done with a one-off guix shell jnettop at the time. :< I wonder if bandwhich can do the same things, it looks less advanced. <ieure>nomike, I generally prefer to have the folks engaged with the review do the merge. <nomike>Yes, but ngraves, who reviewed the PR wrote that they don't have commit rights and that we have to wait for a committer to come along. I asked Daym, a personal fried of mine, who spotted a typo, which I fixed yesterday. <nomike>I'm afraid waiting for someone with commit rights to stumble upon this PR and merge it will never happen. Or are people browsing PRs from time to time? <nomike>It's a bug currently in guix which breaks to packages and I fixed it. I want to submit a new package, which depends on the broken one, and as long as the PR isn't merged. I can't submit the other.