IRC channel logs
2025-08-04.log
back to list of logs
<Kolev>Opening an issue with Guixotic. I'm not confiedent in myself to fix this problem. <Gooberpatrol66>i thought someone submitted a patch for a smartd service to guix but now i can't find it <vhns>Does `guix gc` clear old entries from Grub in a Guix System? <ieure>vhns, No, `guix system delete-generations' does. <apteryx>ieure: are we already deleting unbundled sources from the mozilla browsers? the source is ridiculously large ^^': librewolf-141.0-1.source.tar.gz 891.8MiB <apteryx>it could be done in the computed origin or a snippet, if not done already <ieure>apteryx, No, good suggestion. <ieure>apteryx, Not sure how much good it'll actually do, you still need the full Firefox source tarball to make the LW source. <ieure>But I suppose it is less disk overall. <apteryx>yes, that's the main reason, and also ensuring nothing bundled gets picked up by mistake <ieure>Yeah, I like it. Will see what I can do for the next release. <ieure>I'd really like to 100% unbundle LW, but it has a bajillion vendored Rust libraries. Maybe the new thing can help with that, I haven't tried it yet. <apteryx>feel free to add me as reviewer if you get to it <apteryx>yeah, the new rust tooling can probably can be used to provide the rust crate inputs instead of using the vendored ones <nomike_>I was working on a new package for pythonscad which was finally merged earlier today. As PythonSCAD doesn't have an official release yet (but we're working on that), I've set the version number of the package to "0.0.0-0". <nomike_>The problem is however, that during development of the package definition i once used "2025.07.25-0" as a version number which I've installed in my guix-home. <nomike_>And now Guix won't upgrade to the new version as it believes the old version to be a downgrade. <nomike_>I've ran `guix remove pythonscad && guix install pythonscad` to take care of this. But that doesn't have an effect on "guix-home". I tried removing the package from guix-home, reconfiguring and adding it again, but it still has the old version. <nomike_>I figured out that the issue is with PythonSCAD itself and/or the Guix package and thus the program itself reports the wrong version. I will submit a patch to the package/ <drewverl`>Would it be a cool addition to guix pact option to create debian pacakges, if they could include a systemD unit config file, and logic around upgrading the package? For context, I need to install something on Ubuntu and i was realizing the "natural" way to do that would be as a dot deb, but it's going to be unpackaged into a system process and so needs a system unit config, which guix doesn't seem to help with. I'm guessing this is just <drewverl`>because no one bothered to add these options more then some theoretical abstraction boundary being crossed. <identity>drewverl`: it is pack, not pact :) it can output deb archives, though you will have to do the systemd services yourself with a build phase or something <identity>it is not present on account of Guix using Shepherd, and nobody got the itch to make systemd services for packages; i think we have a way to create .desktop files, which are similar in structure to systemd units iirc, so you might be able to hack something up yourself <identity>it would probably be too much work for a one-off <apteryx>is there a tool to diff two .drv locally? <SquircleSpace>hey folks! I recently sent my first email to guix-devel. It looks like it hasn't been sent out broadly yet. I'm guessing its in a moderation queue since I'm a new sender. Unfortunately, I sent the email from the wrong email address. I'd rather not have that email address posted publicly and would ideally want that email to get killed so I <SquircleSpace>can resend it from my preferred public email address. Is anyone here able to help? The email subject is "RFC systemd-boot bootloader" <sneek>Welcome back SquircleSpace, you have 1 message! <sneek>SquircleSpace, ruther says: yes, emacs is already updated on emacs-team branch. So the reason is that there are branches before it in queue that are waiting to be built by QA <efraim>SquircleSpace: I've cleared the moderation queue, it should show up soon™ <bdju>Does ungoogled-chromium need to be built again after every guix pull or will there be pulls where it can use the same build from before? I've been skipping upgrading it lately, but I also keep pulling a lot. I eventually want to let the upgrade finish, but I don't think I can reasonably build it on my PC, so was hoping for a substitute. <bdju>The fast pace of fixing and upgrading packages lately has been nice, so it's a small price to pay if I can't get a substitute right now, was just curious. <untrusem>you can check with `guix weather ungoogled-chromium` command if subtitutes are available or not <identity>bdju: packages only need to be rebuilt if something they depend on has changed <bdju>I remembered guix weather existed but I didn't remember it could check a specific package. Neat. I had just tried my upgrade command with --dry-run at the end and it said it'd need to be upgraded but didn't say it would need to be built. <bdju>Maybe a lot of dependencies for ungoogled-chromium have been changing lately, or the build server has been too busy to get to it then. <apteryx>does modify-inputs change the ordering of the inputs list? <apteryx>it uses map on the original inputs list <csantosb>apteryx: regarding diffs or .drv, I use ediff under emacs <apteryx>that's what I did, after formatting with the guix-scheme-mode <apteryx>still not as good as what QA shows :-) <csantosb>TIL there is also guix-build-log-minor-mode ... this is endless <csantosb>Impressive "364e883298 * gnu: Remove #:test-target argument."; I wonder what is the rationale here <identity>csantosb: some of them disable tests, some use a phase from a different build system, and some have #:test-target "test", which i assume is the default <apteryx>hm, modify-inputs do not affect implicit inputs <csantosb>identity: But, it removes the #:test-target, why ? <identity>csantosb: because the packages that were modified in that commit do not need #:test-target <human_equivalent>Hm. A few weeks ago a system reconfigure repeatedly made my computer instantly power off. Now I'm getting the same thing when building wine64. <human_equivalent>--cores=1 and --max-jobs=1 seems to work... maybe I have a bad power supply. <Kabouik>I am trying to run `guix package -u` on a low power device (a keyboard slider phone running Droidian) and clang crashes midwway after the configure phase, with no error. I just get a "terminated by signal SIGKILL (Force quit)". It still had some 1GB of free RAM when this happened. Is there a way I can get more info on what's wrong? <Kabouik>I guess the OOM killer was invoked even if there was still some RAM <eev>do you have earlyoom service? <Kabouik>I'll try with with a higher level verbosity (it'll take some time before it crashes again) <Kabouik>I don't think so eev, or it's not named that way <efraim>I don't think you'll be able to build clang with only 1GB of RAM. Do you have any swap? what architecture is that device? <efraim>oh, I didn't read that part fully <Kabouik>And in fact I have been using Guix package manger on it for years, I just have a big Guix upgrade to do <efraim>if it was still during configure <efraim>if it was still during 'configure then I don't see --cores=1 making a big difference <Kabouik>11% through right now and still 2GB availabl;e <Rutherther>have you considered building on another device and just deploying / substituting? <Kabouik>Oh the RAM usage is proportional to the number of cores? I could definitely try with fewer cores then; currently I'm using 4 (out of 8) <Kabouik>Nope Rutherther but that would be a nice last resort solution indeed <efraim>not directly proportional but fairly close <Kabouik>That's good to know, I can try playing with that variable then if this try fails too <jlicht>I'm getting some build (or rather, test) failures for emacs-pgtk <gabber>ci.g.g.o seems unavailable all morning (504) <lynnn>afternoon. i have a pretty easy question, im trying to do the initial guix pull on an aarch64 machine. im getting gnutls and libgcrypt as 404s when trying to bootstrap. are these just failing so they have no builds? <lynnn>also i tried to guix build libgcrypt --no-substitutes --no-grafts but it still downloads so im guessing it is just absolutely necessary to build anything else (which makes sense) <lynnn>oh the build doesn't fail the hash is mismatched. that is very odd <yelninei>i forgot how painful it is to bootstrap cmake with only one core <efraim>I'm still on guile-final on powerpc-linux <efraim>still need to get my childhurds setup <yelninei>guile takes forever as well . I am now on the third attempt after an additional testfailure and discovering that the cmake-bootstrap workaround is no longer necessary <yelninei>i also had to disable the tests in re2c, i dont remember building this before but the tests just hang forever <Kabouik>I don't understand the build errors in https://0x0.st/8hsl.txt; are they related to my own setup/machine or is it something wrong with Guix at the moment? The errors mentions invalid token, so I'm thinking the issue may not be local. <ieure>Kabouik, Not sure, the root cause is the definition of the KEYWORD cpp macro, everything else is failures because of that not being defined. "/tmp/guix-build-clang-17.0.6.drv-0/source/clang/include/clang/Basic/TokenKinds.def:23:26: error: pasting "kw_" and "[" does not give a valid preprocessing token" <ieure>Building with too new/old a version of clang? <Kabouik>Yup that is the first error I thought was significant. It's a guix package -u after a fresh guix pull. <ieure>Okay, well, it's probably broken in Guix / not your fault. The aarch builds are in pretty bad state, there are a ton of failures. <ieure>Would file an issue about it. <Kabouik>Damn, it was working well the last time I was using this device, but I stopped for some months due to dead battery, and just changed it and was hoping to daily drive the device again. <ieure>Seems like a regression, Clang 17 is a couple years old. <ieure>Kabouik, If you're motivated, bisecting the history to figure out where the build broke would be helpful. <Kabouik>I'd have to check exactly how to proceed before I do (I was doing my guix upgrade as a side task while working) <ada36>hey everyone, is there a way to configure a herd service to run after the network becomes available? Something like systemd's netework-online.target <Kabouik>ieure: actually I see that `guix pulll` is not pulling channels from `~/.config/guix/channels.scm` by default like it does on my computer. It's still using savannah. I have a more recent channels.scm file, I'll try to pull with -c flag. <identity>ada36: put 'networking in the requirement field? <untrusem>why does greetd show two entries of everything, here is the pic <teddd>is there a way to define propagated inputs at build time ? <identity>teddd: what exactly do you mean by “build time”? <teddd>during the build of a package. Let's say I have a file packages.scm that gets generated during a build phase and say it evaluates to a list of packages. How can I add it to the package's propagated inputs ? <identity>pretty sure you can not do that, inputs need to be known before the actual build takes place <teddd>yes that's also what I would expect <efraim>Kabouik: I assume you're trying to build icecat? <ieure>teddd, I agree with identity, you can't change the definition of a package during its build. And propagated-inputs are part of the package definition. <ieure>teddd, What are you trying to do that you want this mechanism? <ieure>*that makes you want this mechanism <teddd>ieure, I actually want to define a build process for literate emacs configs. So I want to tangle elisp code blocks along with scheme code blocks. All the scheme code blocks are used to define the guix package dependencies. The way around to the propagated inputs is to just have a function to load the scheme file with the dependencies in a guix manifest. It actually works pretty well for me, I've been using it for a few days. I will <ieure>teddd, So you have a package with your Emacs configuration and propagated-inputs with all the Guix `emacs-whatever' packages it needs to work? <teddd>ieure, Roughly yes. I have a package with all the lisp code that makes my emacs config and one scheme file that evaluates to a list of `emacs-blah` guix packages. This package does not have the right propagated inputs, its only input is a config.org file. To get the dependencies I have to build the package and load that scheme file. <Kabouik>No, I don't have icecat installed efraim and the build occurs during an upgrade. I'm still guix puling <ieure>teddd, Gotcha. Yeah, the way you're doing it won't work. You can write a function that creates a package dynamically and defines it with the correct propagated-inputs. <ieure>teddd, I've also seen a couple attempts to configure Emacs through Guix. Like you'd have your whole Emacs config in Scheme and use Guix Home to serialize it to ~/.emacs.d/init.el and include packages in the profile. <efraim>perhaps you can swap clang-18 in for clang-17? <teddd>ieure, yeah I figured. The way to go is probably to do it in two steps. One to generate the guix dependencies and a second that takes the results of the first and inputs. <teddd>ieure, yes that's exactly what I am trying to do. rde already has a nice tool for thing where you can embbed elisp in scheme. But I prefer to have a literate file <teddd>`elisp-configuration-package` in (rde home services emacs) could be interesting for you <ieure>teddd, Make an Org literate config for Guix Home which includes all that? <teddd>ieure, yes, that's what I now have <ieure>teddd, Unfortunately, I have to use macOS for work, and since Guix doesn't run there, I don't want to make my Emacs configuration require it. <untrusem>I am in middile of converting my guix config to org <ieure>It's kind of a monstrosity at the moment, Guix Home stuff mostly, but a Makefile-and-straight.el thing bolted on for non-Guix systems. Hoo boy do I appreciate Guix's Emacs packaging after making that mess work. <teddd>ieure, yeah gotcha. I also have a some collegues who would use guix if it was available on mac <ieure>I'd rather dump macOS entirely, but that decision isn't up to me. <teddd>untrusem, what is your approach ? <ieure>macOS is horrible these days. Buggy and jammed full of advertising and useless frippery. <teddd>untrusem, I also thought about it. But I'm actually pretty satisfied with using guile modules for now <teddd>ieure, yeah I try my best to avoid it ^^ <teddd>ieure, note that I still have some packages managed by straight though. So my config is still flexible <untrusem>I have based my config on hako, so I have one big org file that makes use of org's noweb syntax <teddd>untrusem: I see. noweb can be great at times. That's also what I use for my Emacs config. <teddd>untrusem: thanks for sharing <untrusem>I mean I first test my system config in a vm just to be sure, but niri would show a blank screen because the command `guix system vm` provides doesn't have 3d accelration enabled by default <untrusem>and here I was blaming myself and my guix fu for days <untrusem>I am creating a guix gotcha files for these type of things so that I don't fell for it again <ieure>untrusem, I had to boot one of my Guix boxes back into Debian because the nVidia stuff broke for some reason and it would boot to a black screen. Tough to debug. <ieure>Spent several days poking at it off and on, then decided a working system was better than a broken one and booted up the Debian install I kept around for just such an eventuality. <ieure>untrusem, I know EXWM, I've been daily driving it since like... 2017. The hypothetical Wayland version would have to be called EWWM. <yelninei>not a fan of the new cmake test phase being something between extremely slow or completely broken on hurd <untrusem>I tried exwm, but I need eyeCandy so niri it is <Kabouik>hako's configurations are very inspiring, thanks for sharing! I'm interested in org-ifying my emacs and Guix configs too at some point. <Kabouik>I'm not sure how to replace clang during `guix package -u` efraim but I'm still hoping the update channels.scm will help. <untrusem>Kabouik: my emacs is already in org, now my guix too <untrusem>I just want one file that I can take up and configure my systen <ieure>I also want that, but no secrets management makes it difficult. <untrusem>ohh yeah, you wouldn't need something for sops <Kabouik>But currently exploring Notmuch/aerc/gnus for my emils (I'v been using nmail for years and really likee it but am considering a more Emacsy way now), which is a quest big enough for now because I manage to set up reading but smtp is still causing me headaches. <ieure>Kabouik, I used to use vm way back in the day. Have been using mu4e for a good bit, but I don't love it. Tried Gnus, but the setup was a lot. Notmuch seems interesting. <ieure>Kabouik, Main thing is that I don't much like either offlineimap or isync and you gotta have some tool to maintain the local Maildir. <Kabouik>That's what concerns me. I mean I do have a work-in-progress setup that seems to work (with a mcron service in config.scm to fetch new mails every two minutes), but I like having the exact same email wokflow in all my devices, and downloading all my emails locally on my Droidian phone is not very appealing when I'm already struggling to make room for a guix package upgrade. <Kabouik>nmail allows online and local emails which is more convenient for that use case. <Kabouik>But the speed of notmuch is attractive. <Kabouik>Re: Gnus setup: yeah, I find a lot of outdated information, and while I have the default notmuch configuration working, I think I still need gnus for sending emails, and that I haven't managed to get working yet. Other than that, if I had something working in Emacs, then the configuration would become a non issue because init.el is something that I would likely make machine-agnostic. <ieure>Kabouik, Seems unlikley that notmuch would require you to use Gnus to send email. mu4e lets you pick an arbitrary function to send, I use smtpmail for that. <ieure>Kabouik, It does need a different auth setup than receiving email, but that's just how email works. <Kabouik>Oh, I think I tried using smtpmail too and I mistakenly assumed it was a Gnus command. I think it refused to pick the ~/.authinfo.gpg that I set up. In any case I just wanted to try, see if this was worth the effort, but am not fully committed to it because I need multi-account support (need a notmuch fork for that) and depending on local email copies is not great for all my machines. <Kabouik>So I'm in a position where excitment/curiosity are getting balanced by the rabbit hole that it is starting to be for just the test it initially was. <ieure>Kabouik, mu4e actually has excellent multi-account support via its contexts. Each context is a complete configuration (identity, email, Maildir location, sending, receiving, literally everything) and you can pretty easily switch between them with ; <Kabouik>I see that aerc has pretty good account separation too. But notmuch seemed to be the fastest of all, and easily toggling between threaded and unthreaded view was interesting too. I think it supports showing inline images too (which has been a limitation I accepted for years by using a terminal client, but I can see how convenient it would be sometimes instead of extracting email parts). <ieure>Kabouik, I have my smtpmail setup in ~/.authinfo.gpg, it works fine. But I feel your pain, authinfo can be a real hassle to debug. If it doesn't like the format of your entry, it just doesn't see it, and that's a weird signal to debug. <Kabouik>I actually did not try mu4e. I considered it, then read a few user feedback, half stating they preferred one, half the other; so I just picked notmuch because I read "speed". <Kabouik>mu4e seems to support inline attachments too. <ieure>mu4e performance is fine, the slow bit is talking to the IMAP/SMTP servers. After you fetch, you do need to update the local index, but that happens in mu(1), which is a C program, so not subject to Emacs performance issues. <ieure>I'm not sure if it shows the images inline, but you can open attachments (including images and PDFs) inside Emacs. <Kabouik>Can mu4e work without a local mbsync/isync database, i.e., just from remote imap server? <ieure>Kabouik, mu4e is the Emacs interface for mu, which is a mail indexer, which only works with a local Maildir. <ieure>Kabouik, Does Notmuch talk directly to the IMAP server? <Kabouik>Re: .authinfo: Yeah, using .authinfo is new to me, and there's also the other issue of my mcron job in Guix's config.scm: my mbsync's config files in the cron job also need to read a .gpg file to connect to imap and download, but I don't know how unlocking that gpg file can work in a cron job, and storing the pass in a plain text file instead is not an option. <Kabouik>No, I don't think Notmuch can talk to IMAP directly either. That's probably one reason for its speed. But I did like that nmail could do both (including for search); though not as powerful as notmuch. aerc I think can probably do both too, but is more vim than emacs paradigm. <ieure>Kabouik, Authinfo has grown a bunch of different storage backends, so it can use .authinfo.gpg or pull stuff out of password-store (that is, pass(1), the standard UNIX password manager). <ieure>But, yeah. I don't have an auto mail checking thing because of the situation with secrets. <Kabouik>I know aerc is appreciated by devs with an heavily patch-oriented workflow, I remember unmatched-paren here was using it. <Kabouik>I might give m4ue a try too. In any case, now that my mbsync setup is made (except for the secrets thing), I think trying the default configurations for all of these will be easier. <Kabouik>I do use pass/pass-tomb too so using that instead of .authinfo would be fine by me. <a6Y37l>I just ran guix-install.sh as root earlier today. Unfortunately guix pull first complains about a file being read-only and then can't get to a socket. What steps did I miss?