IRC channel logs
2026-11-11.log
back to list of logs
<Icy-Thought>sham1: Actually, I was not aware of tree-sitter-nix... we could always do something add treesit-grammars.with-all-grammars to packages <Icy-Thought>as in `epkgs: with epkgs; [ treesit-grammars.with-all-grammars ];` <sham1>Yeah, but of course in terms of Scheme <sham1>I just have the nix grammar installed because I also do Nix things on my Guix install. They mix like oil and water, separate but still moving together <lispmacs[work]>ieure: okay, thanks. that seems like a good example, although looking at emacs.scm, it seems like what I want is a slight variout of emacs-next, which is defined like so: (define-public emacs-next (emacs->emacs-next emacs)) <lispmacs[work]>emacs->emacs-next seems to be helper function that takes the name, commit, etc <ieure>lispmacs[work], `emacs->emacs-next' is a transformation procedure which accepts one package (`emacs') and outputs another package, which is bound to `emacs-next'. <ieure>They're all packages, this is just programmatically creating one from another. Which is also the thing you want to do. <Icy-Thought>sham1: that is very interesting! May I ask what you use the nix bit for? <sham1>Icy-Thought: mostly it's just for stuff that I need professionally, because mostly due to the age differential and how many more people use it (relatively), there are more things in nixpkgs than guix + assorted 3rd party channels <Icy-Thought>IMO guix needs more maintainers, because things land a lot quicker in nix compared to guix <sham1>Yeah, that's usually the problem with stuff run by volunteers. You actually need said volunteers <bavier>in my experience, guix is often a bit more thorough with testing and QA than nix; anecdote. <bavier>that can slow things down a bit. <sham1>I'm also personally glad about the added rigour even at the expense of being slower to get things <sham1>Also, the docs are just better <Icy-Thought>I guess we need more unixporn posts or something to get more people on board lol <podiki>the test shown works for eg gcc-15 but not gcc-16 (which does something different for libstdc++?) <podiki>because i run into build failures from std when using gcc-16 that match the old bugs these were supposed to work around <haugh>I'm building icecat and guixbuild has a `find' process which appears to be hanging. What do? Normally I just INT; is this likely to cause problems esp in the long run? <sneek>Welcome back haugh, you have 1 message! <sneek>haugh, lilyp says: I'd look at proxy-formals.scm:5:5 <haugh>sneek later tell lilyp thanks for your help with my operating-system definition <haugh>Oh it happens reliably, that's fun <haugh>`makeicecat' child `find' process is consuming one core. If I just peg the icecat version to the currently installed version, will guix skip the build? <haugh>It's the sed script embedded in this find command, the one that e.g. renames everything from Mozilla to GNU <aeillol>Is there anything in %desktop-services or %base-packages that installs GNOME extensions? I don't even use GNOME, how did I end up with it? <aeillol>(by the way, I removed gdm from my system) <stephen>aeillol: guix gc --referrers /gnu/store/*gnome-thing-in-store* I don't know of a better way yet, but saw someone mention this in here a while back for figuring out why a thing landed in your build.