IRC channel logs
2025-05-19.log
back to list of logs
<apteryx>efraim: oh! nice. my git grep --all foo failed <apteryx>does it not work on non-x86-64 arch? <ieure>Does anyone have a Guix Home setup that native-compiles Emacs packages? I wrote a package transformer for this and mapped it over every package in my home-environment, but something's not right, it complains of conflicting emacs-s entries. <ieure>And I'm calling it like (define base-home-environment (home-environment ...) (+emacs-native-comp base-home-environment) <ieure>The "second entry ... propagated from emacs-lemon@2.1.0" is the untransformed emacs-s, so I guess something is failing to apply `with-full-emacs' to that package's propagated-inputs. <ieure>Correction, I'm defining my initial home-environment like: (define base-home-environment (home-environment ...)) and transforming it with: (+emacs-native-comp base-home-environment) <ieure>(It's a bit more complicated than that, but that's effectively what's happening) <apteryx>lilyp: I've rebased the gnome-team branch on master <apteryx>hako: had you tried to build rust-bootstrap-1.74 on non-x86-64 systems? <apteryx>efraim: if you have time, could you report the rust-bootstrap-1.74 failures you saw on aarch64 and powerpc64le? <apteryx>I was under the impression that it's supposed to work, though I think Mutabah doesn't own non-x86-64 hardware I think so wouldn't know if it doesn't work. <apteryx>hako: sorry for the ping, I think the rust bootstrap 1.74 author was someone else. <lilyp>I don't think there was anything committed to it yet <trevdev>Is there some trick to getting geiser & repl driven development to work *well* for developing something like your home configuration, or really, anything that imports modules and uses GEXPs at all? It's slow, kicks my core temp up and I can't even get debug output. I just want to know why my export module isn't working and there's not traceback that I can see. <ieure>trevdev, Have had much the same experience as you. Guile takes a long time to compile any modules that the thing I'm hacking uses. I can never tell if it's locked up (which seems to happen a good amount) or compiling or what. In extreme cases, I've had it take 10+ minutes to compile when I C-c C-k. <ieure>trevdev, I don't have solutions, just letting you know that you're not imagining it. <trevdev>ieure: I've read there's a way to launch guix repl - is the plumbing maybe better there? <ieure>trevdev, No. The Guix REPL is the Guile REPL with some stuff loaded into it. <ieure>This isn't going to make Guile compile stuff any faster. <trevdev>Ah ok. I'll just try to be patient. I managed to resolve the tiny bug I made, that had 0 tracebacks. <ieure>Been there. I visit more often than I'd like. <apteryx>lilyp: there's a single hicolor-icon-theme version bump commit I had pushed there <m4xxed>Good Morning! Is anyone else getting the "no proper 'ls` command found" error when trying to ssh onto a guix system on another machine via emacs' tramp? Is there a fix? It seems to be an emacs-30 issue ... <identity>the dicod daemon seems to not work properly as a service (dicod-home-service-type) for me, it works fine when i invoke it manually (dicod -f --config=/gnu/store/...-dicod.conf), is there perhaps a problem related to --inetd? <csantosb>Ups ... all yhetil.org archives are down, I'm afraid <JLambda>Is anyone else having issues with `guix pull` and/or `guix system reconfigure`? I'm getting `Git error: unexpected http status code: 502` regularly, although `guix pull` finally worked after a few re-attempts. <JLambda>identity: Good to know, thanks! I'll try to use the mirror. <rynn>Yep, I stopped doing pulls around this time of day because it's pretty much always having issues at this time. <cdegroot_>I can't speak for others, but my routine is "hey, it's Monday morning (EST), let me update my systems before my first meeting" ;-) <JLambda>rynn: pretty inconvenient if you need to install/update something at that moment, hehe. Hopefully the migration to codeberg goes well and solves this. Fingers crossed! <hiecaq>ieure: about the package transformer, I think `package-input-rewriting` should do the trick. <ruther`>hiecaq: package input rewriting is for changing inputs, not arguments. And it uses package mapping under the hood <hiecaq>Hmm, I thought replacing emacs-minimal with emacs should enable native compiling, won't it? <ruther`>ah right if you use it to change a build dep, sure <ruther`>still dont see how it can solve the issue though. replacing emacs argument or changibg all build inputs is basically the same as long as the packages dont have emacs in inputs explicitely. it clearly worked once for the package <hiecaq>I'm not 100% sure with the technical difference, maybe mapping over the home-environment's packages list makes a different. I'm using a service to maintain a list of all my explicitly-used Emacs packages and mapping over that and it works. https://codeberg.org/hiecaq/guix-config#headline-65 <ruther`>hiecaq: I see no reason why mapping over one list of packages or another would make package mapping behave differently. As long as they contain all emacs packages in profile, everything is fine <cricri>hi! A beginner question about gexp here.. I am about to register a udev rule for my operating-system definition. In the rule, I want to specify the path to the 'ip' executable that the iproute2 package will receive in the gnu store. However, the build fails with an error: Throw to key `match-error'. May someone give me a hint? <cricri>In my operating-system definition I am specifying the service with: 155 (udev-rules-service 'eth0-spoof %eth0-spoof-udev-rules) <cricri>(udev-rules-service 'eth0-spoof %eth0-spoof-udev-rules) <ruther>cricri: I don't think there is any issue with the parts of your config you've sent <cow_2001>it is the newer guile-lib version 0.2.8.1 <RavenJoad>Could someone take a quick peek at 77448 for me? I submitted it a while ago and have not heard anything about it. <ekaitz>RavenJoad: looks good to me, but I didn't test <ekaitz>RavenJoad: why add it in a separate file? <RavenJoad>Separate file because its a separate family of languages. It's a logic language, but it is not prolog. <ekaitz>RavenJoad: and some comments that shouldn't be there <ekaitz>you could sent a v2 of the patches <RavenJoad>That was the plan. The only feedback I had gotten so far was about using #$(this-package-input ...) instead of (assoc-ref inputs ...). I wanted to see if anyone else had anything before I went further. <ekaitz>RavenJoad: the native-search-paths comment you should remove <ekaitz>run guix lint on top of it just in case, and guix style <RavenJoad>Definitely. I wasn't sure if I needed to touch that, since souffle adds headers & libraries that can be used later for GCC. Meaning you can compile C++ against souffle's implementation of datalog. <ekaitz>RavenJoad: then or remove or uncomment <ekaitz>i don't know what is better, probably uncomment <ekaitz>you can try to make a `guix shell souffle` and try to use one of the libs <RavenJoad>I actually have a full script to automatically run the examples from Souffle's website in all the usual modes (interpret directly, transpile->compile C++->run binary) and test against using a SQLite database for the logic facts. <RavenJoad>That was something I wanted to do eventually, have "usage tests" for a package that also help determine when it is broken. <RavenJoad>Doing 'guix shell souffle' worked on that script. (Well 'guix shell souffle sqlite', since the test relies on testing against SQLite too.) <RavenJoad>But I have not tried to use souffle itself as a library. <ruther>simendsjo: because the team approach moves slowly, there are branches queued before emacs-team branch <simendsjo>ruther: Ah, I see, thanks. I looked at that branch and noticed the last commit was two months ago. <ruther>the patch you sent has already been merged, to emacs-team branch <meaty>Is the new rust importer fully merged into the rust-team branch yet? Or is it still being worked on/documented <ruther>latest commit in emacs-team hasn't been made 2 months ago, it was 3 weeks ago <ruther>meaty: the importer is inr rust-team branch, yes <wizard>this one's probably a lil niche but is anyone else having issues with pipewire midi? <wizard>it looks like there might have been a regression in 1.4.0 that was fixed in 1.4.2 <vagrantc>anyone able to pull from master? (exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (rust-cargo-test-macro-0.4)) (value #f)) <vagrantc>57ea6d3d593f483f50fd410478f9b645bbd72b45 <vagrantc>build of /gnu/store/7zwrz3kh00l9di8xs0r5b5r0a957zn7c-guix-package-cache.drv failed <vagrantc>hint: This usually indicates a bug in one of the channels you are pulling from, or some incompatibility among them. You <vagrantc>can check the build log and report the issue to the channel developers. <sham1>Got the same error trying to pin my channels <sham1>Oh well, guess I'll wait 'till tomorrow to update my stuff <identity>in my checkout there is indeed no rust-cargo-test-macro-0.4 in crates-io.scm (only -0.3) <sham1>vagrantc: should probably send a bug report to debbugs <sham1>Unless it's already reported, ofc <ieure>Based on all the rust-* commits from 1h ago, guessing the rust-team branch merged and caused some brokenness. <civodul>is it ‘rust-team’ or just some out-of-the-blue patch series? <vagrantc>all signed by dannym ... who does not appear to be listed in etc/teams.scm <abbe>git blame ... | fgrep test-macro-0.4