IRC channel logs
2025-04-18.log
back to list of logs
<nomike>I've submitted a path to improve the documentation here. <vagrantc>ACTION ponders proposing a GCD to make that a documentation policy somehow :) <nomike>I'm sometimes having a hard time with the documentation anyway because things are so spread out. Like in Submitting Patches there is talk about running `guix lint`and stuff. But on that page it's not mentioned that you need to run this with `./pre-inst-env` and in the chapter where that is mentioned, there is no mention of `guix shell`. <meaty>speaking of development tools, is there a way to have "guix edit" ever open an editable buffer? Even if you run guix from a userspace clone, guix edit opens the copy kept in the store right? <nomike>For veterans these things are obvious, but for me as a newbie they're not. And I don't have the mental capacity to read the whole manual front to back first. That's not my learning type and not how my brain works. I need to get hands-on at some point. When I want to add an application to guix which is not yet packaged, I search on google and read the page about packing. But it feels like there is a dependency tree of 20+ pages, all <nomike>linking between each other which I need to read. <nomike>Probably some level of repetition in the docs would be better. It's fine having a chapter explaining `guix shell` in detail, and another for documenting `./pre-inst-env`, but basic usage of those tools to the extend required to run `guix lint` and `guix style` when develop a packaging patch, would be immensely helpful. <meaty>indeed, the manual leans heavy on using the index and hyperlinks to find what you need <vagrantc>nomike: that is more what the guix cookbook aims to be ... <meaty>maybe all these "development commands" that are only useful with ./pre-inst-env could be moved to their own executable? i.e. guixdev lint/style/edit <vagrantc>meaty: ./pre-inst-env guix edit PACKAGE ... always used to work for me <vagrantc>the problem is that it is so flexible there are many ways to do all those things <vagrantc>but i also suffer from the extensive-yet-never-quite-what-i-find-personally-helpful problem with the documentation for guix too :/ <meaty>vagrantc: indeed, I realized afterwards. It would be nice if emacs-guix could use pre-inst-env <vagrantc>and i've had commit access for years now ... !!! i sometimes wonder weather i should. :) <anemofilia>Ok, I'm very confused now. I just `guix shell gammastep man-db` and got a `guix shell: error: unsupported manifest format`. Reversed the order of the arguments: it worked. Reversed it back: same error. Trying to investigate it, I wrote a couple of manifests with these two packages in different orders, using packages->manifest and specifications->manifest. Couldn't came with a manifest file that gave me that behaviour, but, now, the command that errored <nomike>vagrantc, daym <dannym@scratchpost.org> told me to talk to <ludo@gnu.org> as they is interested in hearing about challenges newbies like me face. I will try to contact them before I forget everything. <vagrantc>anemofilia: the term manifest might be overloaded there ... e.g. having multiple similar but functionally different meanings :( <anemofilia>vagrantc: Yeah, I tried to make myself clear, but I think it wasn't that good too <anemofilia>Every ocurrence of manifest after describing the error is actually "manifest file" <[>compsize builds are failing <nomike>BTW: Is there some definition as of when I should add a copyright notice for myself in a source file? Danny told me that there is some legal requirement for this due to US copyright law and that he believes it's at 15 lines of code. But he wasn't sure. <helaoban>the recent switch from syslogd to shepherd's system-log (commit 190a427) seems to have broken guix containers <helaoban>I can't start the system-log service inside a container <helaoban>fails with > exception caught while executing 'start' on service 'system-log' <helaoban>> in procedure open-fdes: Operation not permitted <jA_cOp>When adding a phase with `modify-phases`, how can I provide one that doesn't take any inputs? it would be nice if the docs for `modify-phases` described (or linked to) what signatures are allowed for a phase procedure <ruther>jA_cOp: All phases are always called with all arguments that exist. So there is no way to not 'accept' something, the most you can do is ignore it <jA_cOp>ruther: ah right, thanks - I tried (lambda (_) ...) but (lambda _ ...) works, makes sense :) <jA_cOp>I also tried (lambda* (#:allow-other-keys) ...) but that doesn't seem to work either, FWIW <ruther>jA_cOp: I think that is a limitation of lambda*, see its docs, it has #:allow-other-keys syntatically under #:key <ruther>[#:key vardef... [#:allow-other-keys]] <helaoban>civodul: shepherd system-log under guix reads from /proc/kmsg, but inside a guix container /proc/kmsg is restricted, so the system-log service can't start <helaoban>I think this means that guix system containers are default bricked unless shepherd-system-log-service-type in $base-services is overridden <helaoban>with a custom system-log-configuration that sets the kernel-log-file argument to #f <helaoban>but it maybe makes more sense for shepherd upstream to gracefully handle not being able to open /proc/kmsg, seeing as kernel-log-file is optional <helaoban>that would handle cases like this where doing a bunch of service inheritence overrides is cumbersome <helaoban>happy to file one in the morning when I get up! it's bedtime us west coast :) <futurile>heh - have a good sleep dreaming of shepherd bugs ;-) <bdju>My USB devices all quit working on my PC. I can ssh in and the machine isn't frozen. Is there something I can run to make it reload USB stuff? <bdju>Maybe a herd service or something. Happened overnight while I was asleep, no recent upgrades. <bdju>It's internal ports, dock ports, everything. <bdju>I'll try a guix system reconfigure. <futurile>and run dmesg to see if your kernel is giving any errors <futurile>I'd do that _before_ you reconfigure so you can see if there's some root cause <bdju>dmesg had some stuff, yeah, but I've had random reconnects before so wasn't sure how notable it was. <bdju>No change after reconfigure (without pull). <bdju>BTW, not sure if I had syslog yet, I see in the news something about changing to the Shepherd's system log, but I have over 150 days uptime. <bdju>I'm doing a pull and another upgrade now. <bdju>I fear that something will be broken even worse next time I reboot, like LUKS or swaylock or something, but at some point I'll probably do it anyway as I don't seem to have a lot of options. <civodul>helaoban: could you report the details to bug-guix, in particular showing how it fails in containers? <jA_cOp>When searching around it seems like the unused-modules linter was replaced with a Guile flag, -Wunused-module. How can I pass this flag when using `guix repl`? Or any other convenient way to use this for checking my Guix modules? <yelninei>civodul: just forwarded the bug to bug-hurd (with an example daemon in C). The example still needs something else (i.e. shepherd) to start and pass the socket, I hope it is enough to reproduce the issue <civodul>yelninei: perhaps a single process that does listen(2) + select(2) in the parent, then fork(2), and then accept(2) in the child, would reproduce it? <civodul>well, with SOCK_NONBLOCK on the initial socket and F_SETFL to clear it after select(2) <civodul>(fun to realize that the C version of this API has become almost unfamiliar to me :-)) <PotentialUser-93>Hi all~, I am still not sure to understand why when removing a package from a profile guix needs internet connection ? <yelninei>civodul: i think I would need a lot more time to get this to work fully self-contained with my limited experience in C. <yelninei>PotentialUser-93: Maybe because of grafts (and profile hooks) <ruther>PotentialUser-93: It's not true guix remove would need an internet connection per se. It can, if you don't have everything to make the build, but it's not necesary. If you didn't run gc or made sure to gc root everything, you wouldn't need internet connection for it <ruther>(everything meaning everything necessary to build your profile) <ruther>PotentialUser-93: That is not right. It needs to build a new profile with all the packages except the one you want to remove <PotentialUser-93>also I just realized guix-home unset my `GUIX_PROFILE` in `~/.guix-home/setup-environment`, so I get the warning from `guix` when I install something <ruther>PotentialUser-93: Nothing is removed when you do guix remove from your disk <PotentialUser-93>but what does it need to "build" ? everything is already there, he "just" need to copy the profile without the symlink to the binary I remove no ? <ruther>PotentialUser-93: that is correct that home unset your GUIX_PROFILE, that variable should be unset! It should be set to A only when sourcing etc/profile file of profile A. <ruther>PotentialUser-93: No, Guix doesn't work like that, it doesn't look at the older profile contents like that. <ruther>It builds from scratch, the only thing it will look at from the old profile is the manifest file that tells what packages should be used <PotentialUser-93>"It should be set to A only when sourcing etc/profile file of profile A." I dont understand that part, the warning message asks me to add two lines in my bashrc but I cannot do it easily because of how guix-home works, I should do it another way ? <PotentialUser-93>I think I get it, if I dont `gc` and if I dont `pull` when I remove a package from my profile it wont need to build anything, is that right ? <ruther>No, guix home already does it for you if you've properly configured it. But you need to relog if it was the first time you got the profile set up <ruther>that is correct, it shouldn't be set... <ruther>the warning message isn't telling you to set guix_profile, it is telling you to source the file, with GUIX_PROFILE set at the time you source it. <ruther>What is the contents of your $PATH variable - does it include the profile -~/.guix-profile/bin? <ruther>PotentialUser-93: look inside the file it tells you to source - ~/.guix-profile/etc/profile and I think you will understand <ruther>PotentialUser-93: Great, then everything is fine, and you won't get the warning next time <ruther>PotentialUser-93: yes, because at the time you got the warning, you weren't using that profile <PotentialUser-93>oh I understand and indeed, just installed the `hello` package and didnt get the warning <PotentialUser-93>my $PATH is still more "complicated" than what I would like it to be, in my guix-home config I setup my PATH with the minimum I need (without guix path since guix-home adds them I think), but guix home added in .bash_profile `.local/bin` and `perl5/bin` automatically (which is then duplicated in my $PATH), it adds those because of the package I <ruther>PotentialUser-93: I don't think that is the case, guix home isn't adding variables like that based on packages being installed <ruther>PotentialUser-93: how does your home-environment configuration look like now? <Rutherther>PotentialUser-93: the way you have it you should have it only once, unless the setup-environment is sourced twice somehow, are you sure you still get it twice after relogging? <PotentialUser-93>my PATH is like this `/home/azz/.local/bin:/home/azz/perl5/bin:/home/azz/.guix-home/profile/bin:/home/azz/.guix-home/profile/sbin:/home/azz/.guix-profile/bin:/home/azz/.guix-profile/sbin:/home/azz/.config/guix/current/bin:/home/azz/.guix-home/profile/bin:/home/azz/.guix-home/profile/sbin:/home/azz/.config/guix/current/bin:/usr/local/sbin:/usr/local <PotentialUser-93>/bin:/usr/sbin:/usr/bin:/sbin:/bin` there are twice `/home/azz/.guix-home/profile/{bin,sbin}` and `/home/azz/.config/guix/current/bin` <partosqq>need your help, how i can work around this issue? <partosqq>uv: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=402c987835bd98a5d3b7a028febf980efe6ad71c, for GNU/Linux 2.6.32, stripped <partosqq>uv: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=402c987835bd98a5d3b7a028febf980efe6ad71c, for GNU/Linux 2.6.32, stripped <azval>I mean you get an error when you try to execute this ? <ieure>partosqq, Are you trying to run binaries downloaded from the internet? <ieure>partosqq, Running random software not obtained as a Guix package is not a well-supported usecase on Guix. <azval>are you using the Guix distro or only the package manager ? <ieure>A major goal of Guix is to replace other software installation methods. <partosqq>do you have any idea how i can run aider on Guix distro? <azval>what error do you get when trying to run the binary ? <partosqq>i thin it will work in side guix shell --container --emulate-fhs <partosqq>but i dont wont run my emacs in side container <ruther>partosqq: either package it propoerly, or use one of the workarounds, like emulating fhs or manual patchelf to patch the interpreter and possibly rpath <partosqq>ruther: do you know, how i can find location of ld-linux-x86-64.so.2 in Guix? <ruther>guix build glibc, under /lib/ld-linux.ARCH.so of the out output. But it will be changing, and possibly removed after you gc if you don't package it properly. Packaging it can mean as little as patchelf in the build script, for example nonguix already does that in binary-build-system. <partosqq>ruther: so you suggest to prepare build script, with patchelf to uv? <azval>the issue with guix-home hanging after the symlink step seems to be related to `herd` being stuck for some reason, when I do `herd status` it just hangs <ieure>partosqq, The issue with uv is not the crux of your problem. <ieure>partosqq, The aider install script just depends on uv and wraps a call to it. The best path is to ignore the aider install instructions and create a Guix package for aider which doesn't use uv. <ieure>partosqq, But, this is going to be a lot of work. The easier path is to run a FHS container, as others have mentioned. <partosqq>ieure: but i dont want run my emacs inside container <ieure>partosqq, Then you have a lot of packaging work ahead of you to use this thing. <partosqq>now, after patchelf, i've got PermissionError: [Errno 13] Permission denied: '/home/moon/.local/bin/uv' <hako>uv is currently available on rust-team branch <hako>guix time-machine --branch=rust-team -- shell uv <ieure>bdju, Happens all the time, the code is buggy, try again. <alex-iam>hi everyone. I have a similar issue with uv. I am trying to package uv binary, and with patchelf it works, but it can't execute any python interpreters it downloads. When I pass linker explicitly - interpreter starts. I can live with the system one for the time being, but want to get this to work. Not sure where to go from here as systems programming is not my thing really. So I need your help. Any thought on this? <bdju>This is try 2 or 3, but okay. <ruther>alex-iam: there is no way other than patching those python interpreters as well. Better to just not use package managers that aren't self contained on Guix System. <alex-iam>ruther: I use it in guix shell. And I can't really stop using uv, it is everywhere now. As for patching, I doubt it is possible at runtime, or is it? <ruther>alex-iam: it doesn't matter if it's in a guix shell or not, the only thing that would matter if it's a container emulating fhs <ruther>alex-iam: I have no idea what you mean by 'patching at runtime' <alex-iam>ruther: maybe I'm not using the right language, I apologise. I mean that uv is patched during build time, python interpreters need to be patched on the fly, after they are downloaded. Is it possible? <ruther>alex-iam: it would be possible if you patched uv to do that. <old>bdju: I often get that error and it's a real pain. I can't let guix do the upgrade and leave the computer for that reason .. <alex-iam>ruther: you mean, patch uv so it will patch interpreters, am I understanding you right? Where do I dig to learn about it? Thanks a lot btw! <ruther>alex-iam: yes. I have no idea where to learn about it. I doubt anyone tried. If people want to use a self-contained package manager, I doubt they will start with one that is relying on FHS, so I wouldn't expect any resources on that. <podiki>you could just run everything in the fhs shell though <podiki>containerized, but is probably the easiest tool available without rewriting as above <lee-thomp>If I'm reviewing someone's patch and the only issue with it is an old base commit (patch won't apply) is it fine to comment the usual 'LGTM' and then send a v2 patch to fix? <ruther>PotentialUser-84: please send multiple lines through a paste site. You've just sent a lot of messages, and some of them were removed <ruther>PotentialUser-84: there just isn't (gnu services pam) in the guix channel, so (use-services-module pam) doesn't make sense <ieure>ruther, Also their custom module isn't in Guile's load-path. <ruther>it probably is in the second case based on the changed error message <ayys>are there any docs for packaging a guile library for guix? I don't have guix setup, and have no idea how to get started. I am on NixOS so not sure if installing guix is the right way forward? <ieure>ayys, Not sure about docs, but there's lots of Guile libs already packaged, which you could rip off. <ayys>ieure: any lib you can think of that has a nice clean package setup? otherwise, I'll peruse the guile library list page for one. <ieure>ayys, Not offhand, I haven't done anything with guile libs. Any package with a guile- prefix will be a good place to start. Most are in guile-xyz.scm <ayys>also, sorry this is a _very_ noob question: what files should I look for in a repo to find guix configuration? <ruther>ayys: what do you mean by guix configuration? <ieure>ayys, Guix configuration for what? <PotentialUser-84>Thanks. I wanted to set PAM env vars. But ChatGPT gave the wrong answer. It refered me to pam module. <ruther>PotentialUser-84: the pam-root-service-type is in gnu system pam. You can grep the source or use guix system search command <ieure>ayys, Package definitions are in Guix itself, not the individual repos. <ieure>ayys, gnu/packages/guile-xyz.scm in the Guix repo is what you want to look at. <ieure>PotentialUser-84, so-called "AI" is extremely stupid and often the opposite of helpful, as you discovered. They're especially bad with niche languages like Scheme, since there's much less data to train on. <ayys>oh I see! Ok that makes sense. So I will clone the guix repo and look around there. <lee-thomp>can I send in a v2 for someone else's submitted patch if the only issue is that it stems from an old base and I include 'From: User <user@example.com>' in the v2 patch email? <ruther>lee-thomp: I wouldn't do that, your e-mail is not going to be counted as genuine, and that is if your e-mail provider is even going to allow to put that in From, it probably won't <lee-thomp>an example may be helpful: take a look at the v5 patch for the issue #77185 I opened <lee-thomp>where csantosb added the 'From:' line in the description <lee-thomp>`mumi send-email 0001-whatever.patch --annotate' crashes saying "ex/vi: Vi's standard input and output must be a terminal" <lee-thomp>`git send-email --annotate' runs fine however and opens vi <JodiJodington>was wondering if there was a way to find out what package provides a `glib-compile-resources` command? I know about `guix locate` but that only works for already installed packages <alex-iam>podiki: thanks to you btw, I overlooked your message at first, sorry. This might be the solution I wanted. <lee-thomp>okay so am I correct in thinking that `mumi send-email' doesn't automatically tag a patch as 'v2', 'v3' etc? <futurile>lee-thomp: yeah, it's a thin wrapper around git send-email <lee-thomp>futurile: oh wait so would `mumi send-email -v2' then do what I expect? <futurile>lee-thomp: I *think* so, I just sent it "--help" and the error showed it sending it to git send-email - so makes sense - try it <lee-thomp>okay I think that worked, now #77822 has a v2 patch <futurile>heh heh heh I feel your pain, I always mess it up and have to do it more than once <lee-thomp>futurile: what do you think, now send in a v5 or just leave it as it is? <JodiJodington>JodiJodington: found glib-compile-resources, it was hiding in "glib:bin" :/ <PotentialUser-84>How to install `make`? I have used this: ` ) %base-packages))`, but it didn't work. Still cannot find the command, make. <ruther>PotentialUser-84: make is in package called make <PotentialUser-84>No. It's in the module `base`. But after adding base, it still showed this: <ayys>I ran `guix pull` multiple times with the same output. <ruther>Yes, it's in module (gnu packages base), that is where the make package is defined. You need to use the module it is in with use-modules or use-package-modules. <ruther>Read what guile modules are in the manual <ayys>\sha256 hash mismatch for /gnu/store/61wwpsl8drzmggxy6xa5c2941n0fs7bb-gnutls-3.7.2.tar.xz: <ayys> expected hash: 0li7mwjnm64mbxhacz0rpf6i9qd83f53fvbrx96alpqqk9d6qvk4 <ayys> actual hash: 0ncvc51yxibs395yywm6z4654i3wvv24hrhcgxlsbzrpvihkbsl5 <ayys>hash mismatch for store item '/gnu/store/61wwpsl8drzmggxy6xa5c2941n0fs7bb-gnutls-3.7.2.tar.xz' <ayys>I suppose from this, I am going to summise that gnutls needs to be updated in the guix package repository? <ruther>PotentialUser-84: please send the whole file <ayys>PotentialUser-84/ruther: sorry for being spammy! <ruther>ayys: yes, this needs to be investigated and probably fixed in Guix. <ruther>ayys: The hash usually shouldn't change, but it happens occasionally. <ruther>PotentialUser-84: I see. The variable is called gnu-make. <ayys>what are the odds of this happening the first time I run `guix pull`~! I would love to know how you guys would go about debugging this! Is there a docs page for this? <PotentialUser-84>Thanks. It is gnu-make. However, when i used guix search gnu-make. Why can't I find it? <ruther>PotentialUser-84: because guix search searches package names, not variable names <bdju>Okay my upgrades finally went through. Nice. <ruther>PotentialUser-84: you would need to use specifications to have the same names as you get from guix search. <dariqq>ayys: The hash mismatch is either that you downloaded a corrupt file or the gnutls tarball has changed on the download servers. The second one would be worth investigating <ayys>dariqq, how can I check if its a corrupted file? Is there a way to clear all caches from guix? <ieure>ayys, The odds of that error happening at all should be low. <ayys>ok I was able to clear my cache, running `guix pull` again. <ayys>I just ran rm -rf ~/.cache/guix <ieure>That has no effect on the error you got. <ayys>oh alright. how do I check if I am downloading a corrupted file? <ieure>But it does mean you'll have to re-clone the whole Guix repo, which is going to be extremely slow. <ayys>yeah, that is what's happening. That was stupid of me! <ruther>ayys: it will be downloaded again on rerun, the corrupted file wouldn't be saved anywhere. So just doing another guix pull would suffice to check if the file you get is the same again <ayys>I ran `guix pull` 3 times with the same result. <ruther>(It's unlikely the download would corrupt the file twice in the same way) <PotentialUser-84>I have installed gcc, gnu-make, cmake on my system. Why Emacs can't build vterm? <ruther>PotentialUser-84: probably because you didn't source the environment variables, you would need to relog. <dariqq>also gnutls-3.7.2 is not the version currently on master <ruther>PotentialUser-84: and you should get gcc-toolchain, not gcc <ieure>PotentialUser-84, You're trying to install vterm with some third-party thing, don't do that. Install the emacs-vterm package in your profile. <ieure>PotentialUser-84, In general, you should be using Guix packages for any software you want on Guix. Substantially all third-party package managers have a lot of assumptions about the environment they run in which don't hold on Guix System. <ieure>And having set up a bunch of Emacs stuff recently on my newish work macOS machine, the Guix way of managing Emacs stuff is *so* much better than what other OSs/distros provide. <ieure>I hope to give a talk about this at the next EmacsConf. <ayys>that's interesting! do you install emacs package via the guix repo instead of from *elpa? <ieure>ayys, Yes. Guix manages all my packages for everything. <lilyp>not just that, I also use a little-known side effect of Guix' packaging to have optional packages :) <PotentialUser-84>Could you please explain how Guix way of managing Emacs so better than other OSes? How it compares to NixOS and Arch? I'm very interested in this and I want some input from the most experienced people. <ayys>ieure, neat! I tried it on nixos via emacs-overlay to have it read all my `use-package` lines and install packages from it. But that meant everytime I changed my emacs config, I had to rebuild the whole system! I gave up soon after. <ruther>It is similar to emacs.withPackages if that is what you know already... <ieure>ayys, It's especially nice for stuff like native-comp (everything's precompiled, so you don't compile when Emacs starts), and tree-sitter grammars. I add `tree-sitter-whatever' to my profile and that's it. On this mac, I have to rummage around for the right URL and maintain `treesit-language-source-alist', it doesn't work a good portion of the time, I have to manually install stuff etc. Guix stuff, I say I need whatever grammar, it's <ruther>ieure: everything is native compiled as long as you replace emacs-minimal input with emacs <ieure>ayys, You only have to reconfigure the system if you put the Emacs stuff in your operating-system config. I have mine in Guix Home, `guix home reconfigure' if I want to change something. It is a bit slower, but also means that my actually used config doesn't drift from what's in source control. <ieure>PotentialUser-84, Basically everything I'm saying here, you add the packages to your profile and it works, there's way less to manage overall, and what you do manage has less compliexity. <ieure>It especially shines with packages that interact with non-elisp components. <ayys>pretty neat stuff! I've been meaning to try out guix for a while now. The alure was finally too strong for me so I am setting it up this weekend. I still use the nix bound config for the same exact reason ieure! Yeah it's slow, but atleast it's reproducable (even though it compiles all the emacs packages everytime I change my font!) <ieure>tree-sitter grammars, LSP servers, that sort of thing. Those are *hugely* easier on Guix than other systems. <ieure>At least, that has been my experience. <ayys>right, so I am currently blocked by the hash mismatch error from gnutls. Is there anyway to bypass this step? <ayys>aha! 61wwpsl8drzmggxy6xa5c2941n0fs7bb-gnutls-3.7.2.tar.xz: HTML document, ASCII text, with very long lines (882) <ayys>so it was a corrupted download. But perhaps the issue is on the server side? <ieure>Definitely looks like it, maybe curl the URL and see what the result is? <ieure>That should definitely not be returning HTML. <ruther>ayys: you can guix gc -D it then. But you shouldn't have it written in the store in the first place... <ruther>so it's a bit strange it ended up there <ieure>It looks like the GnuTLS domain expired and was taken over?! <ayys>not sure what the URL is. I found the file in `/gnu/store` <ieure>The definition for the gnutls 3.7.2 package uses a mirror:// URI. <ruther>the other ones are ftp anyway, so why would they give you an http response <ieure>ayys, Any chance you're on an ill-behaved VPN? <ieure>Or a corporate network with security happening at the network layer? <Rutherther>oh, it's crysys.hu? that one is misbehaving mirror then. It was removed recently. <ruther>Oh apologies I replied with account that I didn't mean to reply with <ieure>ruther, Oh, that's unfortunate. It's removed in current Guix, but is of course still there for installs of 1.4.0. <yukitsubaki>Hi. I just installed GuixSD today and am confused with the proper way to have (apoligize for my probably incorrect terminology), the user profile be loaded. For example if I run =guix install icecat= the binary isn't actually present in my path until I set the GUIX_PROFILE and then source it. But confusingly in the manual (specifically in "Getting Started") it seems to imply that I should only need to do this if I am not on Guix System <yukitsubaki>("Unless you're on Guix System ..."). Did I mess up the installation somehow? <ruther>The only thing I can think of is to put something like 127.0.0.1 www.crysys.hu (as long as you aren't running https server) to /etc/hosts to workaround this xD <ruther>yukitsubaki: that is true just for the first time you install anything. At that time you will get the profile. And it will be sourced on next logins automatically. <ruther>yukitsubaki: so you an relog to update your environment <ruther>ayys: That's not the correct one, mirror crysys.hu is the one used here. And they disabled their mirror few months ago... <ayys>oh I see I see. Can I remove the mirror from my local install somehow? <ruther>ayys: Not easily. See the possible workaround I outlined few messages ago <ayys>aah let me try that out! <ieure>I think work has restarted on Guile-Emacs, but I'm not sure it's daily driveable. <ieure>...I also like Emacs Lisp better than Guile. <ieure>Probably an unpopular opinion, especially in here. But I do. <ayys>ruther: mapping to localhost fixed the issue for me, thanks! <ruther>but this is really unfortunate... I think it would be good to do something about this until the next Guix release, like to make it possible to easily disable mirrors manually <ieure>I think the best path is to do a new release. <ruther>yeah, but the same problem can occur <ieure>It merits a guix-devel discussion for sure. <PotentialUser-84>I put this in my config.scm. However, `emacs` points to emacs-next-pgtk. How to try guile-emacs? <ieure>PotentialUser-84, I'd suggest `guix shell guile-emacs', that'll give you a subshell with that package available. <ieure>I don't tnink `emacs' is the name of the binary for guile-emacs. <ieure>You can `ls $(guix build guile-emacs)/bin' to see what binaries it comes with. <yukitsubaki>ieure: I'm just happy with any Lispy languages in general. The consistency and generality is really my favorite part. Of course there are always little things that are better or worse with different implementations, but all of them feel so much better than other languages that I really just feel happy with any thing that lets me use Lisp. Maybe I just hate other languages too much to feel differences between different Lisps... <ieure>yukitsubaki, Sure, to each their own. <ieure>PotentialUser-84, It mostly formats as I write it, because I have RET rebound to `reindent-then-newline-and-indent'. When refactoring, I sometimes select the function/form or the whole buffer and C-M-\ to reindent it. <ieure>You could also reindent the buffer in your before-save-hook. <PotentialUser-84> (setf (alist-get 'guix-style apheleia-formatters) '("guix" "style" "--whole-file")) <PotentialUser-84>I want to use this to auto format it. However, `guix style` doesn't support a stdin flag. <ieure>PotentialUser-84, You need to use a paste service. <ieure>PotentialUser-84, Yeah, `guix style' is purpose-built for formatting Guix package code, it's not a good fit for the usecase of formatting arbitrary Scheme. <lilyp>there was a pull request to make it work better not just for guix scheme, but also elisp <lilyp>well, patch series rather than pull request, but ykwim <PotentialUser-84>`(setf (alist-get 'guix-style apheleia-formatters) '("guix" "style" "--whole-file" inplace))` <ieure>PotentialUser-84, Looks like there's no package for that yet. <ieure>Do we really require a language server for shell scripts? <ieure>Make your own package for it. <ayys>blasphemy! I am kidding ofcourse. I am doing the opposite actually, trying out Guix on Nix. Guix is literally installing as I type this. <ruther>muaddibb: on guix system? what tutorial? just add the nix-service-type to your system services. <muaddibb>ayys: nothing against nixos, I just like lisps <ayys>I am on the same boat :) <muaddibb>ruther: I did, but I'm getting an error. I'm hoping I did something wrong and the fix is simple and I don't have to read the whole nix manual <muaddibb>did adding the service work out of the box for you? <ieure>muaddibb, What's the error? Can you paste it? <ieure>(using a pastebin, if it's >1 line) <ieure>PotentialUser-84, Emacs 30.1? Emacs 31.0 isn't out. <ieure>PotentialUser-84, Emacs 30.1 is the latest release, it came out in February. There is no Emacs 31 yet. <ieure>PotentialUser-84, Guix doesn't have Emacs 30.1 packages yet, work is underway for that. You can install emacs-next, which is a pre-30.1-release snapshot. <PotentialUser-84>can i package the emacs 31 development version from source? will it be difficult? <ieure>PotentialUser-84, It's easy to create package variants like that; but whether they work correctly or not is another thing. <PotentialUser-84>thanks. How about Neovim 10? I can only see Neovim 9.5, on which lsp-config couldn't even work. <lilyp>If you plan to be using emacs 31, check out the emacs-team branch :) <ruther>PotentialUser-84: Neovim update is blocked on tree-sitter update that is available on rust-team branch, but not merged yet to master <ieure>PotentialUser-84, Same answer. In the ideal case, `guix shell neovim --with-latest=neovim' will Just Work. <ieure>PotentialUser-84, But it depends on the package, its changes, etc. <muaddibb>ayys, ieure, any ideas of what the problem with my nix could be? <ruther>you haven't added nixpkgs channel <csantosb>sneek: later tell lee-thomp, I see no problem applying #77822; just "mumi current 77822 && mumi am @0", in emacs-team branch <muaddibb>ruther: that was it! thanks! I thought just adding the nixos channel was enough. <bdju>My USB devices are working again after updating + rebooting, and so far nothing seems more broken than before. <bdju>I have no idea, and I'll probably never know. Hopefully it doesn't happen again... <bdju>All USB devices just quit working while I was asleep for some reason. <lee-thomp>I'm stuck writing a system service for ZNC. I can start up znc but it seems to be looking for its config at `//.znc/configs/znc.conf' instead of the `/srv/znc/.znc/configs/znc.conf' that I've created (znc user is already made with /srv/znc home, I can run manually with `sudo -u znc znc -f' and everything works fine this way) <sneek>lee-thomp, you have 1 message! <sneek>lee-thomp, csantosb says: I see no problem applying #77822; just "mumi current 77822 && mumi am @0", in emacs-team branch <muaddibb>bdju: things like that happen sometimes xd. <ruther>lee-thomp: the service runs in minimal environment, the HOME is probably not set, you would need to set it through the #:environment-variables <ruther>lee-thomp: or probably better pass the full path to the config via a flag if that's a possibility <lee-thomp>ruther: I hadn't thought about using environment variables this way thanks, and now that I look at it I think there's an option for calling znc that could work also <lee-thomp>I think I've now got ZNC set up, testing testing 1 2 3 <zjabbar>As far as I can tell, this is a "stale bytecode" problem. I need to somehow get Guix to recompile my emacs packages, but I can't seem to figure out how to do that on my machine. Is it known that Guix can have issues with incorrect bytecode versions, or am I going down the wrong rabbit hole? <zjabbar>I have tried to GC everything related to org-roam and start "fresh". I deleted generations and made sure there wasn't anything with org-roam in my /gnu/store. But I still encountered the same issue after reinstallation. In other words, the last message in that issue chain did not work for me. Downgrading org-roam via package transformation also did not work (for a different reason, emacsql was a different version and some variables