IRC channel logs
2025-07-18.log
back to list of logs
<Kolev>I'm having issues installing Emacs. Are the servers down? <Kolev>jnms, is there a Guix package for har? <jnms>Kolev: Not yet, I want to fix the dlang packages some time. On master d-tools fails tests which breaks dub, which you would do `dub run har` with, but that also fails due to libcurl missing. <Kolev>I'm not thrilled by the usage of D lang. <Kolev>Emacs still not installed. Stuck at substitute: <pinoaffe>hi guix! I'm wondering about guix internals atm: I've packaged harper (rust-based spellchecking tool) - when I run `guix build rust-harper-ls` it terminates almost instantly, outputting the store path, but when I run `guix package --install rust-harper-ls` it wants to build a *bunch* of things - why is that? <pinoaffe>(a bunch of seemingly unrelated things, from python to imagemagick and gtk+) <pinoaffe>I'd expect that if a package has already been built and is available locally, installing it would "just" be a matter of bookkeeping <Rutherther>pinoaffe: guix install is not just installing that package, it is building the whole profile with all your installed packages. As bare minimum it needs stuff to perform the build of the profile itself. But also it is possible it will redownload/rebuild some of the packages you have installed in the profile due to grafts. If there were no grafts, it would be reused from the store directly <pinoaffe>Rutherther: thanks! I suspected this was something related to grafts, but wants to rebuild those packages even when I run it with --no-grafts specified <Rutherther>pinoaffe: the thing is that you probably don't have the non-grafted packages in your store anymore, you probably used guix gc in the meantime <Rutherther>pinoaffe: the non-grafted variants of the packages are not gc rooted, only the grafted variants are as those are the ones referenced by your profile <pinoaffe>Rutherther: I don't think I've ever ran guix gc on this laptop - is it performed automatically? <Rutherther>so yes, right now you are in a state where you need to download them. If you used guix package with --no-grafts, gc rooted and then also used --no-grafts, you should not need to download anything <pinoaffe>i think my main takeaway is that I don't really know squat about how guix fundamentals are implemented in practice <zimoun>sneek, later tell civodul: Any chance that you give a look to PR #1108 about load-path (user experience) before your summer break? :-) <jlicht>andreas-e: I left a comment for you on codeberg, since you've been the one reacting to my core-packages-team stuff, but feel free to ignore it :-) <m4xxed>I have just noticed that emacs-lsp-mode in guix is outdated and there are some fixes missing that enable support for new LSP Spec 3.17 features, such as the new GlobPattern etc. Some LSP Servers (e.g. biome, oxlint) have already adapted to these new types and this will cause emacs to throw errors because it doesn't receive a string in every <m4xxed>situation, but sometimes a more complex pattern. Any tips on how we could update emacs-lsp-mode? I tried it locally but I have failing tests when I inherit from emacs-lsp-mode and just update the commit and hash... (not a scheme pro myself) <csantosb>sneek: later tell m4xxed, guix emacs-lsp-mode package is not outdated, latest upstream release is 9.0.0; problem is this is from 1 year ago <janneke>so, M-x fj-list-issues RET origin RET .. and then on the first issue: RET breaks for me (using latest master): <janneke>setq: Wrong number of arguments: (4 . 9), 10 <janneke>ACTION did finally find out how to un-bceak exwm-0.34: use exwm-wm-mode instead of exwm-enable <z572>andreas-e: It seems that the core-packages-team on qa is quite good. Maybe it's time to merge? <z572>x86_64-linux 93.3%, aarch64-linux 86.1% <csantosb>janneke: cannot reproduce; it works as usual for me <csantosb>My current branch is master, and remote is called "codeberg", in case it matters <janneke>csantosb: thanks for looking, so it's only broken for me :( <janneke>and you're using current master, right? <dcunit3d>i installed the guix service on nix as a system service, but I built it with /var set to /gnu/var so it would be contained to a single partition. <dcunit3d>for some reason, installing as root didn't give me a profile that exists at /root/.config/guix/current, but just a link to the correct place <dcunit3d>maybe i need to reboot or something for a proper activation <dcunit3d>when I run `guix describe`, it returns an empty git checkout, sooo... <dcunit3d>i'm new to nix, but i halfway know what i'm doing. idk whether it's user customization/error or what. the timestamps for the /root/.config/guix profile indicate that it's been updated. i'd rather avoid using that one. <dcunit3d>i tried asking on the #nixos channel also, but it's a split use-case lol <dcunit3d>guix describe shows "repository: #f, commit: #f" ... when i run guix pull, idk what it's pulling into the store. it took awhile, but eventually fails with <dcunit3d>"guix/ui.scm:890:18: error: graph-descendant?: unbound variable" <dcunit3d>, then at guix/ui.scm "unrecognized keyword #:refspecs ..." <dcunit3d>so i think something unexpected occured in the initial `guix pull` and aborted unexpectedly -- then doesn't have access to the same initial repository or something. <identity>guix pull crashing should not break the repository, though; still, try removing the repository directory and retrying guix pull <dcunit3d>i'm running from "/run/current-system/sw/bin/guix" now. `which guix` only shows that now. earlier, it was showing "/etc/profiles/per-user/dc/bin/guix" but my initial guix pull was for a user profile. <tazjin>dcunit3d: when you say you installed it, do you mean you enabled the nixos option for running guix, or something else? <dcunit3d>guix is initially set up as a binary built in /nix/store. i expected to run `guix pull` to get things running from guix store. /etc/profiles/per-user/me -> /etc/static/profiles/per-user/me -> /nix/store/...-user-environment <dcunit3d>i'll brb. gotta reboot, but i don't have an IRC bouncer. i'm hoping the reactivation will fix things. <dcunit3d>if not, i'll probably just delete the btrfs /@guix subvolume, reconfigure the system and ensure I bootstrap /gnu/store properly <dcunit3d>i wasn't using fresh shells when running some of those commands and had added users.users.dc.packages = [ pkgs.guix ]; so maybe i screwed up the store initialization. <janneke>for the archives: fj.el works fine for me now, i was using a stale git checkout of fj.el; /my bad <luca>Hi, is there a way in guix to have shepherd send it's logs to /dev/log (where they can be picked up by other logging services) <identity>luca: see (info "(shepherd) System Log Service") and (info "(guix) Base Services") <luca>So if I read this correctly I should tell shepherd (through message-destination) to log to /dev/log (and also maybe it's default would be nice) <csantosb>I'm not sure what the difference is exactly between the two alternatives: <csantosb>#~( .. #$(this-package-input "INPUT") / #$INPUT ..) <graywolf>From what Ludovic told me in a patch review, the first has the advantage that it should respect input rewriting <graywolf>The second one, while easier, hard-codes the INPUT, so guix build --with-input INPUT=SOMETHING-ELSE will not do much <csantosb>The winner is `this-package-input`, thank you ! <orahcio>Hi, Is there some reference to make mirror for guix substitutes? <tazjin>orahcio: do you mean hosting a new mirror? I've just done this, so might be able to answer some questions (though our setup is a bit unorthodox) <orahcio>thank you tazjin, I will see your reference <jakef>ci.guix.gnu.org seems to be down <orahcio>tazjin: Could you share the technical specifications for setting up this type of mirror server? <tazjin>orahcio: put a bunch of storage in a box with a fast internet connection, configure nar-herder and nginx, should be good to go! <tazjin>cbaines said when I asked that for a full replica of bordeaux about 30TiB of space are required (the mirror I set up doesn't proactively mirro old store paths, only new ones, so ours is smaller atm) <dcunit3d>is there any way to create the /root/.config/guix/current profile when it wasn't created by installation (without unpacking a tarball, though i guess maybe that would work if it merges with the existing store) <kkremitzki>Hello all, I sent an email to guix-devel@ about 12 hours ago and it doesn't seem to have gone through, but I think it was my first message to that list, so some delay is not surprising, but, is that typical? <identity>kkremitzki: yes, your email needs to be approved by a moderatar, might take a day or two <dcunit3d>i've reverted the configuration to one where services.guix installs to /gnu/store and /var (so just the barebones `services.guix.enable = true;`). <dcunit3d>i just ran `rm ~/.config/guix/current && guix install guix && guix package -p ~/.config/guix/current -i guix` <dcunit3d>then `bash` for a new shell. `guix install -r guix` to remove from ~/.guix-profile <dcunit3d>then exit. another new bash shell. `GUIX_PROFILE=~/.config/guix/current; source $GUIX_PROFILE/etc/profile` <dcunit3d>and finally `guix pull` works as expected.... so i'm guessing people running guix on nix already had it installed. <yelninei>Does someone have a good system to keep a bunch of custom guix build invocations gc-rooted and those roots up to date? <sneek>Welcome back yelninei, you have 1 message! <sneek>yelninei, janneke says: yes that or -- and that's what i pushed -- we also filter out slirp4netns <yelninei>i started with a simple Makefile but as things got more complicated I am now looking into the arcane magic of make macros and am regretting the decision <yelninei>janneke: thanks, there is also a little typo in the comment in devel-hurd64.tmpl (hurd64-qcow2 vs hurd-qcow2) <podiki>yelninei: beyond the --root option to register as gc root? <podiki>or else use a manifest and install into a specific profile <yelninei>podiki: I have 3 different custom packages defined in scheme files that take a reference to all of their inputs (as a hacky way to get just one root for a lot of packages) + a bunch of roots for things in commencement.scm that i dont want to lose (gcc-final for the hurd takes 3-4h to rebuild, guile is another 1h, etc). I want these for different systems or even cross compiled and the amount of roots/Makefile rules to manage explodes <yelninei>right now i have rewritten it into makefile defines for guix build invocations parametrizing the system/target and the expression to build. It works but surely there has to be a better option <podiki>perhaps look at cuirass for inspiration? <podiki>sounds like that's sort of what you want, various specs that are built (and built on changes) and kept available <yelninei>that could work. I wanted to try it anyways for building and serving my own substitutes, but this could be the excuse I need to finally do it <Kolev>Do Guix-installed packages show up on foreign desktops? <lilyp>Kolev: depends on your foreign desktop <lilyp>you typically have to logout and in again for changes to be picked up, but if you're on a distro that handles flatpaks fine, guix should be no issue (from my personal experience with various versions of ubuntu) <csantosb>Kolev: problems with your chromebook (if I remember correctly) ? <Kolev>lilyp, I'm using Fedora Workstation. <Kolev>csantosb, the reason I have Fedora on my Chromebook is because audio doesn't work with Guix, and the Chromebook needs nonfree firmware. <csantosb>And how are things going ? Not taking too much space ? <Kolev>csantosb, not taking too much space.