IRC channel logs
2025-11-07.log
back to list of logs
<thanosapollo>when working on guix, should one use (setq-default geiser-guile-binary '("guix" "repl")) ? Haven't seen any mentions of it in the docs and I've been using it lately, is there a reason not to use the guix repl this way? <eikcaz>thanosapollo: there are infinite possible ways to invoke guile. I'm sure there are plenty of situations where setting it to guix repl is bad, but if it works for you, then it's probably fine. <apteryx>anyone knows how to choose a different guile for the build in our test environment (e.g. for 'make check TESTS=tests/debug-link.scm') ? <apteryx>looks like there's a fluid: (%guile-for-build (package-derivation store %bootstrap-guile)) <apteryx>also, some derivation procedures such as gexp->derivation take a #:guile-for-build argument. <apteryx>ah, it comes from test-assertm, which calls open-connection-for-tests, which sets the %guile-for-build parameter with (%guile-for-build (package-derivation store %bootstrap-guile)) <apteryx>for the hurd-vm-shepherd-service, where is the disk image kept? <apteryx>and is the store of the childhurd shared with the host nowadays, or it uses its own separate/in-image store? <janneke>apteryx: all in the same /gnu/store, the childhurd has its own store <janneke>sharing is not trivially possible; hurd has no ext4 support <apteryx>I see I can provide (image (const "/out/of/store/writable/hurd.img")) to use an out of store image... in this case is the image not managed at all by the service, i.e. I need to build it myself? <apteryx>janneke: I think the host store could be shared via SSH IIRC; I'm not sure if this would work well but if it did, it would simplify the setup a bit, avoiding having to build large disk images when building the world on Hurd. <apteryx>maybe I'll get around trying to implement this at some point <apteryx>could be an option: `use-host-store?' or similar <apteryx>the default being volatile storage... does this means it keeps everything written to storage in RAM? <apteryx>(and isn't the disk-size irrelevant for this default use case?) <apteryx>ACTION has a lot of question regarding the hurd-vm-service-type :-) <yarl>(package-transitive-inputs r-igraph) is not supposed to include r-simplermarkdown (via r-digest)? <trev>how come ghostty isn't in the repo yet? <apteryx>janneke: I think using this as in the example throws: (image (const "/scratch/virtual-machine/childhurd.img")) <yarl>Oh I see, that's recursively on their propagated inputs. <janneke>apteryx: hmm, i would have thought that could work <janneke>apteryx: iirc, childhurds use -snapshot, yes <janneke>so when doing heavy development, i usually run qemu by hand on a -devel.img that i populate/manipulate etc using losetup mounts <xxd>What is the fastest update cycle setup for Guix? <xxd>Can I have a setup on par with e.g. Debian speed wise if using precompiled binaries? Should I pull less? Can I pull only upon security fixes? What is the deal here <jlicht>apteryx: total tangent, what client-side tooling do you use to post to your pastebin from emacs? And which pastebin service are you running on the server? <sham1>There isn't(*) a difference between you compiling a package and using a substitute from a substitute server. And pulling only for security fixes makes no sense, Guix is rolling release and so on pull you always get the latest(**) state when you pull <sham1>(*): There shouldn't be, anyway. If there is, it's a bug. (**): You can pin your channels to specific commits, but even then, you get all the state up to said commit <sham1>You can also of course do the whole -funroll-loops thing akin to Gentoo using Guix, but then you of course cannot use substitutes unless you set it up yourself <sham1>In general, the kinds of performance gains you would gain with tuning the compilation for your specific hardware nowadays would be on the order of magnitude of singular percentages, if even that <identity>sham1: i think xxd uses speed as in «speed of guix pull && guix system reconfigure» <sham1>That would also make sense, indeed <identity>i just pull when i see something relevant getting updated, like security fixes/updates to software i use <sham1>I usually update my channel pins on Mondays <sham1>xxd: Anyway, `guix pull` can certainly be slow at times since you need to compile a new version of `guix` any time stuff changes, but as far as `guix system reconfigure` is concerned, I don't think it's all that much slower than using `apt`. At most you need to download new packages, and that's slow anywhere. One just hopes that you can download the given binary from a substitute server, because if not, you're on your own compiling stuff, and *that* is slow <yarl>I don't know if that's relevant but is pull then wait for 1 day then reconfigure/upgrade (to let CI does it things) an idea? <yarl>Substitutes are not available right away when source (repository) is. <sham1>Yeah, that sounds sane enough <yarl>Especially on powerless hardware, e.g. small arm board <Deltafire>heh, "How often do you guix pull?" doesn't seem to have been one of the questions on the survey <kestrelwx>`time guix pull` was 7m30 real, 4m40 user, is that slow? <xxd>Ultimately the answer is then... pull less than apt upgrade? <sham1>Probably. It's not like you'd be running `apt update && apt upgrade` that often on Debian either <kestrelwx>I just pull whenever and forget about it on background. <Rutherther>pull is not like apt upgrade, pull is more like apt update <xxd>kestrelwx: If pull should be seen like apt update, then yes 7m is slow. <yarl>xxd: guix pull is not 'equal' to apt update. <yarl>The systems are not the same. <xxd>Also there seems to me to be some odd things, for example if the package is large (e.g. TexLive) then a pull seems to... download everything? On apt an update wouldn't DL it. Anyway, I nerfed TexLive for this reason <xxd>yarl: It was in response to Rutherther's comment. <kestrelwx>I think most of the time for me it's CPU bound since building modules for other channels takes a while. <yarl>There is no really equivalent of apt update under guix imho. <yarl>It updates a local database of remote binaries availability. <yarl>then when you apt update, you can apt upgrade just after. <yarl>guix pull is longer but it's an irrelevant comparison. <yarl>guix pull does much more. <yarl>s/much more/not the same/ <xxd>Ok but there is no way to speed it up? Say you have 5 machines can you do a pull on one machine and propagate to the rest? <Rutherther>xxd: of course, you can deploy anything from your store, including profiles with guix <Deltafire>xxd: you can share substitutes - look up guix-publish-service-type <gabber>can guix daemon run as unprivileged users on foreign distros or is that a Guix System exclusive feature? <Rutherther>gabber: it's feature mainly used on foreign distros currently. As the guix-install script tries to get you to install unprivileged daemon. Whereas on guix system you have to go and explicitely enable it, without any message from guix <Rutherther>yarl: of course there is no direct equivalent, but it's the closest. The result of apt update is that you know about new packages and new package versions. The result of guix pull is that you know about new packages and new package versions. That the way to get to those results is implemented very very differently, that's another thing. <Rutherther>xxd: no, guix pull does not download packages you installed, it updates only guix itself <gabber>Rutherther: so the install script by default installs an unprivileged daemon? nice <Rutherther>gabber: no, it asks you which you want to install and the default choice is unprivileged as far as I can tell <hanker>Is there a way to make a `plain-file` into an executable? <Rutherther>xxd: if really your texlive packages has been upgraded, you must have meant "guix upgrade" / "guix package -u". And that yes is sort of like apt upgrade, while here it's important that it updates only the ~/.guix-profile, not ~/.guix-home nor /run/current-system <Rutherther>hanker: plain-file itself cannot be executable. But you can make a simple gexp along with computed-file that will take that file, copy it and make it executable. But at that point, depending on what you wanna do, it might be better to use call-with-output-file instead of plain-file <hanker>I want to make a `/etc/qemu-ifup` script. So, an executable in `etc-service-type`. Since it's a small program, I'd rather inline it inside the config <xxd>If you use guix publish, do the clients still have to locally hash everything again right? Which will be part of the time consumed? <hanker>I can definitely work with `call-to-output-file`. <Rutherther>hanker: also note that local-file with #:recursive #t, copying a folder, will keep executable flag if that was something you could do instead <xxd>Part of the time consumed by Guix (guix system reconfigure, or guix package -m manifest.scm) is the reproducibility correct? So what is the actual time saved by having a local guix publish server, can you run guix package -m machine1.scm once for multiple machines or do you need to run it on each? Or would you have to containerise? Correct me if I am misunderstanding. <xxd>Ultimately the question is given trusted machine_0, can I have faster reconfigure/package on machine_k <Rutherther>xxd: sorry I don't know what you mean that part of the time is the reproducibility <Rutherther>you can run guix package -m machine1.scm on one machine and distribute it to others via "guix copy". Then you would have to give up the regular guix way on the other machines though, managing it all on your own instead of using guix package on the other machines <xxd>Rutherther: For me a running Guix setup is much slower to update than say a Debian or Ubuntu one, or e.g. Arch or something else. So while I appreciate the benefits and dissimilarities of Guix, I would still like to have a faster update cycle, even if it depends on building containers somewhere else, or having an own build farm, etc. <xxd>Rutherther: Guix copy is not containerised though, it just copies over the store? That would be an option yes <Rutherther>yes, it is much slower, because it's functional & transactional. While it can be a bit faster through deployment, still, you need to do much more and distribute much more on functional package managers as any input change changes the output <Rutherther>again I do not know why it would be important something is 'containerised', only builds are containerised and you don't usually do many builds as most stuff can be substituted. And the containerised builds wouldn't be any faster if they weren't containerised either. So containerisation is not something slowing down guix or anything like that <Rutherther>another way is not using guix at the target machines at all and just distribute files built by "guix pack", at that point you will never be able to reuse any parts of the store though, but on the other hand if you were to do updates like once per month, you wouldn't reuse much either way <xxd>Okay I think guix pack is closer to what I meant by container. <xxd>Though my impression of guix shell --container was that it would be faster but I suppose not, only if the actual dependencies are small it would be fast <Rutherther>faster than what, and why? The time to get inside the shell is similar to shell without --container flag. And as for working in the container, I don't really know why it would be faster than a regular shell <xxd>One question -- suppose you run a substitute server with only very few packages, would guix pull from this server be fast? Does guix pull only configure for those packages available in your definition or would it always try to pull new definitions across everything? <cluelessguixer>Are guix containers broken in the latest update? "ERROR: In procedure close-port: In procedure fport_write: Operation not permitted" <Rutherther>xxd: you do not run pull against substitute servers, you run pulls against channels - git repositories - with source code <xxd>Rutherther: So if I specify a channel with smaller list of packages available it will only update for those? <Rutherther>xxd: it doesn't update packages, it updates guix itself. Meaning if you have a channel with packages X, Y, Z and you pull from it, the only packages you will get are X, Y and Z and no other packages, it doesn't matter guix version you use now, what packages it knows about. Of course this is a hypothetical, you always have to pull from guix channel implicitely, that's how it is with current guix. So you still would also get all packages in guix channel... <Rutherther>... available, with their latest version that's in guix alongside of this <xxd>It seems to be that a minimal subset Guix would have been useful. But anyway. Thank you for the explanations. <yarl>Rutherther: Technically, if using a custom guix channel? <Rutherther>xxd: I don't think so, this part is already at building derivations outputs that can be substituted and they don't take that much disk space. The most time consuming tasks happen elsewhere during guix pull <Rutherther>yarl: if you managed to make a channel with all the scripts from guix and their dependencies, sure. I don't think it will help you much in speeding up "guix pull" though <xxd>I suppose you can work from an older Guix commit and then update X, Y, Z only on your substitute where they have certain security/update requirements. <Rutherther>you still have to go through fetching all the channels and authenticating all the commits and computing guix derivation, then the only part you save time on is the build of the scheme files, but this is usually substituted with guix channel <Deltafire>updating is fairly slow, but you don't have to sit watching it.. go grab a cup of tea or something while it updates ;) <apteryx>jlicht: hey! It's emacs-scpaste, which only needs to know the host name of your server (and that you have SSH access to it). <apteryx>The pastes are then served via a web server, e.g. nginx <padtole>ieure, i want to apologize for speaking earlier as if you were trying to suppress my idea as if it were associated with software piracy <padtole>ieuere i reread our conversation and it sounds like we were on different pages regarding how common it is for outputs to differ on upgrade. i misinterpreted this as you trying to harm me and responded poorly. i am sorry about this. <padtole>i still believe it is common for outputs to be identical on upgrade, and that including this in design could simplify things <padtole>i understand that piracy is unrelated to this topic and it was weird and crazy for me to include it <Deltafire>regarding removing packages, are they not marked as deprecated first, before removal? <Rutherther>Deltafire: depends. If they do not build, no need for that. If they do they generally should first be marked as deprecated, per the deprecation policy <csantosb>When a package doesn't build, don't we advertise it as an issue first, to give a change to fix it before removal ? <mononoke>I've accidentally run `guix home reconfigure` as sudo; should I be worried about cleaning up any mess this might have made? <identity>mononoke: it should not cause any major problems, but the home generation might root some stuff in the store (basically, some wasted disk space) <mononoke>identity: would gc take care of that, or would that be something I'd need to root out myself? Not a terribly huge deal thankfully but it will for sure bother me lol <identity>mononoke: i used ‹root› as in ‹a garbage collection root› as in you have to remove the root yourself so unused objects in the store are no longer referenced by the root, which would prevent the objects from being garbage collected <mononoke>Tell me if I'm off base here at all, could I do something like home delete-generations (not worried about rolling back on this system since I'm just tinkering) and see which store entries have duplicates afterwards for any packages in that config to discover my offending objects? or is that not how it works? <Rutherther>mononoke: why would you do that? Just remove the root's guix home profiles and you are done <mononoke>Rutherther: how do I do that? Apologies, still learning how things function/are connected <Rutherther>unfortunately guix home doesn't really have a good way to uninstall completely, so it is done manually - first I would reconfigure as root to mostly empty home-environment. Then remove "/var/guix/profiles/per-user/root/guix-home*", manually. And lastly, remove the symlinks to store from root's home, possibly only /root/.profile, but maybe more, just look through its home and look for symlinks to /gnu/store <mononoke>Rutherther: thank you very much, I see all of my user dotfiles in the root dir and .profile etc. so that sounds like the right thing to do. <Rutherther>yeah, I suggested to reconfigure to an empty home environment first, because that will remove most of the dotfiles <mononoke>That makes sense and is for sure a lot simpler than what I was going to try to do. A novice overcomplicating things! <mononoke>Seems that did the trick to tidy up just fine. TYVM again <ieure>Anyone use mpd-service-type? Tried setting it up yesterday, but ran into a ton of problems immediately. <ieure>Main one is that I want MPD to talk directly to my audio hardware, without Pulseaudio/Pipewire/whatever. But the user it's run as isn't in the `audio' group, so it can't access the hardware. Managed to add the user to that group, but it still complains that it can't open the sound hardware. <ieure>If I `su' into the mpd user and run the exact command Shepherd runs to start the service, it works fine. wat <ieure>Not really sure what's going on with that, I didn't see anything in the code or config that seemed like it was actually spawning mpd as that user. <defuser>I am trying to write C code, how do I cross-compile it to RiscV? <defuser>clang --target=riscv64-unknown-linux-gnu -march=rv64gc wish.c -o output <defuser>In file included from /home/akshit/.guix-profile/include/stdio.h:28: <defuser>In file included from /home/akshit/.guix-profile/include/bits/libc-header-start.h:33: <defuser>In file included from /home/akshit/.guix-profile/include/features.h:548: <Rutherther>please do not send multiple lines here, use a paste site <defuser>Trying to build gcc-toolchain with target riscv64-linux-gnu fails too! <defuser>:shrug: I don't really have much idea <defuser>I am trying to specify the target using clang to riscv64, and it tries to include that file <identity>well stubs-32.h is not present in the 64-bit toolchain <Rutherther>yet it is being included by the stdlib :) yes, that is the problem indeed, it shouldn't be included in the first place <defuser28>hmm, is there anything I can do to solve this? Most online guides point to installing riscv64-unknown-elf-gcc which is not available on guix <Rutherther>defuser: Not sure why clang-toolchain is broken with riscv64. As for gcc, using target on gcc-toolchain is not the right way to make a cross toolchain. The right way is this: https://paste.debian.net/1405035/. Then in a shell from this manifest, you get the command riscv64-linux-gnu-gcc and I can successfully compile hello world program with that <Rutherther>I would avoid guix installing multiple toolchains, or any toolchain at all cost. Guix is deeply incompatible with installing multiple toolchains, you can easily get into issues, even gcc-toolchain + clang-toolchain will lead to nothing compiling. Rather use shells for toolchains <FuncProgLinux>gnu-build-system auroruns the autogen.sh scripts on git sources but glib-or-gtk-build-system doesn't...is that a bug or a feature? xD <defuser28>I don't know if the output is correct or not <Rutherther>defuser28: you can see through "file a.out" that it's an executable for risc-v architecture. Linked against glibc etc. etc., meaning it's of course meant for targets running linux, not bare metal <defuser28>BTW can I just install it directly or will that lead to problems? <defuser28>Doesn't it need to be called explicilty by riscv64-... command? <Rutherther>yes, I am talking about files in include and lib folders <defuser28>That is why you shouldn't install both clang and gcc too right <padtole>i have successfully booted a t60 bios with gnuboot built on guix with a script like https://bpa.st/FS7A :D slow work to test things and move to packages <Rutherther>defuser: yes, but even installing one and using the other in shell that's not --pure / --container can lead to issues <Rutherther>that's why I would rather not install a shell at all <defuser28>I had installed the riscv one before asking you <defuser28>I changed tty to tty4 and removed it and now the current profile shows no package installed <Rutherther>did you do "guix package -m" with the manifest I sent you? <Rutherther>when doing -m with guix package, you are not telling it to add packages from the manifest, but to replace your packages with it. So you have uninstalled all packages you had with that. You might rollback to an earlier generation to get them back <defuser28>How do you install a package from a manifest then? <Rutherther>you can't add packages from a manifest. Yes, using either -e or -f with expression that will give you the package you want to install will work <padtole>i guess you could add to the manifest to merge with your profile manifest <FuncProgLinux>That picked my curiosity, I made a package definition inside a manifest and could install such package using (concatenate-manifests) :o <FuncProgLinux>but the package I declared used sources inside the same git repo and the manifest has no cache, so the package gets built & installed every single time i open a shell <ieure>"piqued my curiosity" is the phrase, FYI. <FuncProgLinux>ieure: 🫠 sorry, my broken English sometimes doesn't help lol <trev>defuser28 may be confused about the difference between manifest and package definition <trev>i volunteer Rutherther to clarify as to not make a fool of myself <defuser28>wait let me try, manifest was the kind of file that Rutherther provided, package definition is the one that uses git, gcc-toolchain, etc to define how to actually build a package <Rutherther>defuser28: a manifest contains multiple packages and it's made for defining how a profile should look like (profile is basically a union of multiple packages in one place). Package definition means just one package <FuncProgLinux>defuser28: Well you can have package definitions inside manifests but not the other way around as fas as I know <ieure>FuncProgLinux, No need to apologize, <FuncProgLinux>Can the FHS emulation be used inside a package definition? :O <defuser28>Btw, suggest some good IRC client. I intend to participate in the community too, but I can't see the messages that were sent when I wasn't connected to libera.chat <ieure>defuser28, IRC doesn't retain message history, so a different client won't fix that. You need an IRC bouncer (znc is a popular one) which runs on a computer that's on all the time, so it can buffer the messages and play them back. <FuncProgLinux>defuser28: Emacs ERC or IceDove in Guix are the ones I use. But I think ERC is better if you wish to extend it <ieure>defuser28, Or to let go of the inbox-style of chat which is inexplicably prevalent, and lean into the fundamentally ephemeral nature of conversations. <ieure>Or pay $5/mo for IRCCloud, which solves the scrollback problem for you. <Rutherther>note that #guix in particular is logged and url to the log is in the motd <ieure>You can read them, if you like. <meatoid>they won't always be there, but it is enough for me in most situations <defuser28>basically a client that uses the logs to fill in messages when you weren't online <meatoid>clients generally can't do that cos it's not an IRC feature <meatoid>however, i do remember seeing and IRCv3 protocol about it somewhere... <meatoid>my workaround is leaving kvirc running on my home computer all the time <Deltafire>defuser28: i'm using weechat, it runs on a server (via tmux) and has clients for android, web and emacs <defuser28>also, WHY is this community even on IRC nowadays when better protocols exist? <ieure>Yes, there are practical and freedom problems with any alternative. <ieure>I also, personally, prefer IRC, by a lot. <meatoid>informal chats should be ephemeral. else you end up with i.e. people using discord as a documentation webpage <meatoid>I remember one project whose documentation was a discord chat room with links to twitter posts... *shudder* <ieure>Discord is *so noxious*. Had to sign up for a yearly volunteer thing I do, and it's absolutely wretched. <defuser28>hmm, you know I a starting to see this point of view too <ieure>The options are basically: Slack, Discord, Matrix, Mattermost, XMPP. <defuser28>this conversation seems a lot more "friendly" compared to when I had to use discord for a project <FuncProgLinux>ieure: I also tried making a discord like 2 months ago to help a friend of mine, I nope-d out of there when it asked for my phone number ._. <defuser28>ieure Has anybody done a in-depth comparision for them? <meatoid>IRC strikes a good balance of lightweight, easy to use, private and ephemeral enough without making that the whole thing <ieure>Slack and Discord are immediately disqualified for commercial / proprietary; I think Mattermost isn't widely deployed enough for people to have any idea what it is; Matrix sucks awfully. <ieure>So XMPP, maybe? Client support situation doesn't seem great. <defuser28>> The options are basically: Slack, Discord, Matrix, Mattermost, XMPP. <ieure>defuser28, I don't think anyone in the Guix community has, I assume someone has likely done something like what you're asking for. <defuser28>yeah, well got my reading priority for tomorrow! <meatoid>I tried XMPP once, lack of good clients is the issue as ieure said. Otherwise it seems pretty good, and I like the oldskool AIM vibes <ieure>I have seen numerous criticisms of Matrix from a usability standpoint, and it seems like its E2EE is complicated and not very good. <FuncProgLinux>I used XMPP with Pidgin on trisquel. It's good but didn't find anyone else that used it as welll :( <ieure>Yeah, I used XMPP in the 2000s, it was fine as a Free version of AIM, YIM, or MSN Messenger, etc. <defuser>though have to get used to the commands <ieure>A thing I appreciate about IRC is that you have a wide variety of clients, many of which are highly customizable. <ieure>The corporate chat options are all very limited and inflexible. <defuser>@FuncProgLinux I was talking about the / commands <defuser>No autocomplete for usernames here though <ieure>defuser, Tab has completed nicks in ERC for me, for ever. <FuncProgLinux>defuser: Ah I don't know about those as well, I only used like 3 to register and validate my e-mail for libera. But I get curious when people sends actions like ***user is afk <ieure>Doesn't appear to be a custom binding or anything. <FuncProgLinux>Ahh ERC also displays notifications on your Emacs modeline if you are mentioned on any channel. <FuncProgLinux>IceDove sends a notify event but no systray or logs if your DE doesn't support those <FuncProgLinux>defuser: There's erc-sound documented on the emacs-wiki if you want audio bells <meatoid>I wish there was an embeddable "libemacs" that could make all the text fields of applications integrate with an emacs server or smth <meatoid>then we could have purpose-built GUI apps with the text power of emacs <FuncProgLinux>meatoid: Wasn't the 'better-readline' a thing called blesh? or something? <defuser>I need to move to EXWM, but Niri is just too damn nice T_T <ieure>meatoid, libreadline has been around for that, for ever. <ieure>meatoid, But it supports a variety of bindings. <meatoid>ieure: but like, imagine if readline used your emacs config <FuncProgLinux>meatoid: It would conflict with evil and I would need emacs-readline-evil too xD