IRC channel logs
2026-07-05.log
back to list of logs
<YARs2>Hmm... Might be hard to make koboldcpp to play ball with emacs <lavandula>im going to scream. i cannot for the life of me solve this dns problem. down to my final trick. im going to boot into the installation media AGAIN and re-initialize the system and hope that does something? screaming rn <lavandula>like, even when i provide all the files, afaict, locally, including channels, GSR just does NOT want to work without dns!! <ieure>lavandula, What's the problem? <lavandula>(deploying i get several 'Wrong type argument in position ~A (expecting ~A): ~S') <lavandula>mostly coming from shepherd then i think? the configuration dry builds fine on my foreign distro <tachymelia>hey does anyone know wht the... /gnu/store/guix-directory-nnnn.xxxxx directories are? <tachymelia>downloading substitutes keeps failing with permission denied bc of em <tachymelia>guix gc -D also says it isn't part of the store, which. is counterintuitive <EndureAhead>those who use guix with nixpkgs, are there any compromises compared to using nix entirely? <krisbalintona>EndureAhead: I don't, but my first guess would be that obviously with Nix you'd be able to configure your system with the Nix "services" (in Guix terms; I forgot what NixOS calls them). If you just mean package-wise though then there shouldn't be a difference <EndureAhead>krisbalintona: yes, package-wise under guix control. <krisbalintona>EndureAhead: Then there shouldn't be a difference at all. You have the packages and everything is installed in the same places. (As far as I know.) <Elouin>Will `guix pull` continue where it stopped, when i ctrl-c it? Its running now for about 10h and i need to leave and take my laptop with me. <krisbalintona>Do you have substitute servers set up? 10h is a very long time if you aren't intending to compile large packages <Elouin>I am running with `--no-substitutes` due to the CVEs. <krisbalintona>Elouin: Ah yeah, that's a pain. I think but am not sure that packages already during the time of a `guix pull` don't need to be rebuilt when you interrupt the pull then restart it <Elouin>Okay, thanks for the answers. Have no choice, but to interrupt it either way. <spinna>hello. i'm trying to create a guix profile and then later use it as a container (--profile). this works great as-is but if i try to enable fhs it will fail (assuming it's because it installs some extra packages). current workaround is to use --manifest instead but i want to keep instalation and usage in two different steps. anyone has a solution/workaroud for this? <spinna>trev: guix shell: error: '--profile' cannot be used with package options <trev>spinna: give your whole line that you're trying to run <spinna>$ guix package --profile=/tmp/dog --install coreutils <spinna>$ guix shell --profile=/tmp/dog --container --emulate-fhs <spinna>guix shell: error: '--profile' cannot be used with package options <sham1>spinna: if I had to guess, it's complaining because you're trying to use a profile from outside the container inside the container and that it cannot move it in there <Nimous1234>Hi. I noticed in the Shepherd documentation a service type called `Timer`; which acts like a cron daemon and I guess seeks to imitate SystemD's Timers. This is weird cause I know that GNU project already has an standalone cron program called `mcron` which allows crontab definitions in Scheme. Why did Shepherd developers duplicate an already <Nimous1234>available functionality **from** GNU project itself? <sneek>Nimous1234, you have 1 message! <sneek>Nimous1234, untrusem says: jj 0.39 is released :) <sham1>I can't really speak for the Shepherd developers, but I would think that the timers are a lot more robust than the crontab jobs provided by mcron. It also means that since the timers are provided by shepherd itself, it means that each service gets its own log, you can control it with the usual shepherd things, and it doesn't need a separate daemon, which does have value of its own <sham1>Shepherd of course also has other systemd-like things. For example, it literally has a "make-systemd-constructor" and "make-systemd-destructor" which provide the kind of socket activation that systemd offers <sham1>You could easily argue that with socket activation, it tries to also replace the inetd <Nimous1234>Well... I believe separate daemons have the actual value. I'm kinda into the Unix philosophy of doing one thing per program; and don't enjoy seeing SystemD competitors try to replicate SystemD just to compete with it. But in the end, "Gnu is Not Unix" I guess. <Nimous1234>Not to mention Shepherd implements a log daemon, which historically was an standalone daemon. <Nimous1234>s6 init system also has socket activation. But s6 is far from a SystemD clone. <sham1>First, it's spelt "systemd", just saying. Second of all, for better or for worse, more and more daemons are starting to assume a systemd-like way of doing things, and people are more and more likely to be familiar with that way of operating vs. the more traditional init and rc way <sham1>FWIW, the syslog replacement in shepherd is optional and you can use a more traditional logging daemon <Nimous1234>It's true that systemd-like behavior is more and more expected. but replicating systemd in other init systems defeats the purpose of having init systems other than systemd! If our init systems try to be like systemd, then why should the users choose other init systems instead of just using systemd? <sham1>Well for one, systemd is linux-only. Guix tries to also run on Herd, emphasis on tries to <emery>systemd socket activation is a different thing than s6 socket activation and aren't worth comparing with each other <Nimous1234>As the traditional rc notion is concerned: SysV init style is not the only way doing init. s6 uses Runit style init scripts with lots of improvements. It beats systemd in speed, elegance, and simplicity; while being modern and meeting the new expectations of parallelism and whatnot. <Nimous1234>When I talk about non systemd init systems, I'm not implying SysV style or BSD rc style approach. <sham1>Runit is an interesting option indeed. Void does make good use of that <sham1>And also apparently you can use that in Gentoo as well, as an alternative to OpenRC et al <sham1>Now I'm actually curious just how difficult it would be to bolt Shepherd onto Gentoo <Nimous1234>s6 is the successor of Runit. s6 init scripts by default use `execline` instead of a shell, which is way faster and lower footprint than even the most lightweight posix shell. Although you can write your s6 init files in any language. <Nimous1234>And this is important in the context of Shepherd because Shepherd is so resource intensive it can't be used for embedded systems or containers. <Nimous1234>Currently the best s6 integration belongs to Artix Linux. Alpine once announced that they're going to switch to s6 a few years ago but I don't know where that went. There are Alpine-s6 docker containers available tho. <sham1>For containers you probably don't need a full init+service manager, with tini or catatonit being enough for what a container needs <Nimous1234>sham1: True. But just because I can afford 50MB of RAM just for a single process, it doesn't mean I should do it. s6 provides desktop grade functionality with a container level of minimalism; better than anything systemd could ever be. <Nimous1234>Shepherd is more minimal than systemd source code wise, but it's written in an scripting language. <identity>Ā«scripting languageĀ» is not a real category you can put languages in <identity>besides, Guile very much has *two* compilers, a bytecode one and a JIT one <Nimous1234>Guile needs much optimization to produce binaries that are even near Chez binaries performance wise. <Nimous1234>And even more optimization to minimize RAM usage of binaries. <emery>s6 is a huge pain to use though <emery>unless I'm wrong and there is some other reason why it isn't being more widely used <sham1>Well, nothing's stopping you from ripping out Shepherd from Guix and slotting in s6 or what have you. Well, other than practicality <sham1>I don't have evidence for this, but in my mind a reason why many people here use guix in the first place is because of its Scheme nature and usage of the language in many, many places <sham1>That alongside being GNU FSDG compliant and thus fully free software, and the reproducibility are probably the main reasons people use Guix <graywolf>48 hours and still compiling :D now xz-mesboot <Nimous1234>emery: It didn't have a good frontend for a long time. Some time ago they released s6-frontend which simplifies the commands an end user has to run. Artix adopted it recently. Writing s6 init scripts may be a little weird because of `execline`, but is definitely simpler than learning a turing complete Scheme for Shepherd. <Nimous1234>sham1: I don't have problem with Scheme. I just wish Guile was a faster compiler and Guile binaries to be faster and less bloated. <emery>Nimous1234: I'm using s6 and s6 frontend, it's still tedious <emery>if you want to use s6 in guix in a usuable way then you need sufficient abstract from s6 <Nimous1234>emery: I used Artix s6 before they adopted s6-frontend. From your comment, I guess they dropped the ball when developing s6-frontend. <sham1>Well if the problem is Guile being slow, then well... I'm sure the Guile maintainers would be more than happy to get contributions to help with that. Maybe with taking some ideas from Chez <Nimous1234>sham1: I use Guix because it's a better package manager than others. Just the mere fact that I can export to portable formats with `guix pack` means the package manager has powers beyond the comprehension of the average pacman/apt/dnf. `guix pull` makes me think about my life decisions tho... <Nimous1234>sham1: I use Guix because it's a better package manager than others. Just the mere fact that I can export to portable formats with `guix pack` means this package manager has powers beyond the comprehension of the average pacman/apt/dnf user. `guix pull` makes me think about my life decisions tho... <csantosb>Good morning Guix ! Public service announcement: 57fd857c1e3 just lands in Guix; this fixes !9686. <Nimous1234>Is the slowness of `guix pull` due to the slowness of `git clone` or something like that? <csantosb>identity: `guix pull && guix describe` should give you "57fd857c1e3" right now <identity>csantosb: right, i mean that i just pulled and now i will have to pull again :/ <sham1>Oh damn it, I just pulled yesterday! Oh well <roptat>guix pull feels super fast with substitutes now :p <graywolf>csantosb: Civodul wrote on the issue "Iām now working on updating the guix package.", so is the fix effective now or we need to wait bit more for the second part? <csantosb>I'd wait for the official announcement; I just wanted to point out how reactive we are on this kind of problems. <rrobin>having a bit of an issue with my last pull - system build/reconfigure is failing with a cryptic 'guix system: error: empty string is not a valid name'. Anyone else seeing this? <trev>so we're all going to pull? <rrobin>still looking into it - i was finally able system build a minimal os, so maybe something specific to my definition, it will take me a while to track it down <krisbalintona>rrobin: I haven't come across the issue. I suspect that you changed something in your configuration since your last pull, and that's what's to blame for the bug <trev>i did run into errors on yesterday's pull but restarted guix-daemon and then second time was fine <attila_lendvai>anyone who understands gnome? i'm trying to fix gpaste's gnome extension, and i suspect that it's not "exporting" (?) its dir into the GI_TYPELIB_PATH variable of the gnome-shell process, or something like that. the error is: typein:2:1 Error: Requiring GPasteGtk, version 4: Typelib file for namespace 'GPasteGtk', version '4' not found <attila_lendvai>i lack the background knowledge for this. i'd appreciate even a pointer to another extension's package that solves this problem. <sham1>Hmm, guix outputs ^[[K even when run in Emacs' compile. You'd think that the TERM being set to "dumb" would discourage it, but oh well <sham1>"clear line from cursor right". I see <attila_lendvai>i suspect the root problem is that the guix home profile's girepository-1.0 is not part of the gnome-shell env <kurkumat>Is there any particular reason why --build-id is almost universally not passed to the linker in most build systems by default? Except go (it uses its own linker which by default adds .note.gnu.build-id). <krisbalintona>sham1: I have in my init.el `(add-hook 'compilation-filter-hook #'ansi-color-compilation-filter)' so that ANSI escape codes are removed from compilation buffer output <rrobin>krisbalintona: i wish that were the case - problem is it is happening with several of my os configs. And some of them are pretty old. I think I have tracked it down to my code that sets authorized keys for openssh service. Maybe i did something shady with gexp there. <krisbalintona>rrobin: Oh yeah, that would do it too. I would expect something runtime related would be the cause <rrobin>(facepalm) apparently caused by empy name string in (plain-file "" "...) <Avron>I started a guix pull --no-substitutes (guix on trisquel), after a while and it is not complete it seems the computer is doing nothing and the only guix-related process besides the daemon and 3 guix pull processes is /usr/lib/x86_64-linux-gnu/guix/guile \ /usr/bin/guix perform-download /gnu/store/dwqf6346rnfxdbk3w50dhv71j6xw6iyy-expat-2.7.1.tar.xz.drv /gnu/store/czx0kfyn24ysimpb05vx3z13f4sfcp8w-expat-2.7.1.tar.xz <Avron>So it seems it is downloading but I don't do anything else, the computer is receiving less than 1KB/s, so it does not look like there is any download working <sham1>Did you suspend the computer in the middle of that or something similar <sham1>krisbalintona: yeah, that's the way to remove the ANSI codes. I would have just expected them to not get output when it's a dumb terminal, is all <Avron>I did not suspend the computer, after 15 minutes of this, I did ctrl-c, then started again, then it very soon gets into exactly the same situation <krisbalintona>Avron: With --no-substitutes you might have to just wait it out. Since it's attempting to download some files, maybe the upstream server for those files are super slow right now for some reason? <vermiculous>`guix pull` is suddenly trying to pull in i386 architecture. Is this a known bug or have I borked something? <Avron>krisbalintona: I interrupted again and ran the guix pull --no-substitutes again, there is one new commit, then linux-libre-6.12.17-gnu was downloaded at 1.8MiB/s and after that it is stuck on expat-2.7.1 again. Are those from different servers? <MichaelGame_Dev>Question about running binaries on guix. I have the binary downloaded. Normally I just do ./app_name and it'll run. In Guix when I do this I get the message: cannot execute: required file not found. <MichaelGame_Dev>Is there something I need to enable in Guix? I have a nix file that some used to get this running on nix. I guess I may need some of the packages mentioned in that. <ieure>MichaelGame_Dev, Guix is pretty much the worst possible distro to run random binaries from the Internet with. It doesn't follow FHS, so libraries aren't in the right place. You have to run it in a container with --emulate-fhs or find some way to build the program from source. <MichaelGame_Dev>^ got ya. I'm getting close with a shell and that flag. Just an SDL video driver issue I'm trying to figure out <ruined>This might be a silly question. My understanding is that from guix 1.5.0, installs on foreign systems using guix-install.sh will default to the unprivileged/rootless guix-daemon. If this is true, is it still correct to upgrade the build daemon with " sudo -i guix pull ", or should this be done under a different user? <MichaelGame_Dev>Also ieure I got it. I had to add preserve and pass in the wayland display. I saved the command off for now, need to see if I can add it to my manifest. But it came right up! <Avron>ruined: yes (guix-daemon not as root) and yes (sudo -i guix pull + systemctl restart guix-daemon, if the distro is using systemd) <ruined>thank you, Avron. So, the guix-daemon user is running the guix-daemon binary pulled by the root user? <futurile>MichaelGame_Dev: it has a mixed manifest and a bash script, so you can have it in your personal /bin and then just run it to start your binary - see the FHS section of that post <MichaelGame_Dev>futurile thank you. I'll check it out. It's for a game engine I use. I put the programs needed in a manifest. But there are still several flags needed. So I'll take a look. I haven't tried to build the game yet, but the engine itself comes up and runs as I'd expect! <futurile>MichaelGame_Dev: ack, yeah so there's some clever ways you can automate starting a container (with FHS) shell. Probably not strictly necessary when you're just trying to get started, but cool if you're going to be constantly starting a "dev environment" with your game engine/tools etc in one place <MichaelGame_Dev>futurile yep, that's the plan eventually. I need to make sure I can actually package the game, I suspect I'm good there. For there, it's just a matter of git or rsyncing back and forth. Does your article talk about automating using them? <MichaelGame_Dev>futurile very cool stuff. I can see what you mean combining the script and manifest. Thanks for linking that. <vermiculous>Correction from earlier, guix pull is pulling i686 bootstrap binary not i386. <dcunit3d>i've been using that to build a derivation that flattens the scheme modules for channels i depend on so all the completion/etc is based on compiled symbols <dcunit3d>but usually the build takes awhile, so i register a GC root... hmmm maybe i didn't update the profile <dcunit3d>oh... nevermind i always forget to update ./env/dc-config/guix/channels.scm <ryanprior>Anybody succeeded at hauling their rootless installs out of purgatory yet or are we still figuring that out <graywolf>guix daemon not running under the root user <ryanprior>dcunit3d: my understanding is that the bug fixed in that PR did not affect people who installed Guix to run the daemon as root. <dcunit3d>idk, i literally fixed my FHS system last night <dcunit3d>i was noticing inconsistencies in file/group ownership in the store. so i finally went through the newer versions of the installer script. i was missing an entry /etc/subgid and started seeing new warnings about it when i pulled my channels yesterday <dcunit3d>i had a weird source-based installation on arch about a year ago <dcunit3d>i think that's maybe loosely related. i had installed with the rootless daemon, but i don't think it was set up correctly or something. <ryanprior>I was previously using the Debian package, but switched to the installer script a couple days ago <haugh>Is it correct that installing guile without a version spec yields version 3.0.9? <graywolf>haugh: you mean by `guix install guile'? <haugh>No this was installed via guix system reconfigure, using specification->package <dcunit3d>ryanprior: you may want to read through the installer script and check what it changes, as well as the systemd guix-daemon.service. for me it was an issue bc of an older installation <dcunit3d>i'm not sure how to fix my gnu store though <dcunit3d>i'm hoping that it's magically fixed my `guix copy` issues lol <dcunit3d>yayyy it maybe did (fingers crossed lol) <dcunit3d>copying the `guix pull` result anddd.... computing derivation... <dcunit3d>i was having weird ssh issues where `guix` was unavailable in PATH. this had weird results. <qzdl>o/ if anyone knows off the top of their head: may one reconfigure the guix-daemon in the installer before proceeding? `guix system describe' and `/run/current-system' do not have a `configuration.scm' <dcunit3d>qzdl: what's blocking you, specifically? <dcunit3d>my guix is a bit rusty. what do you mean by reconfigure the guix-daemon? why doesn't configuration.scm exist? <qzdl>I'm just booted from a custom installer image before latest security updates, so want to avoid --no-substitutes for the whole world lol <qzdl>dcunit3d: I would reconfigure the system after a given commit, in order to `herd restart guix-daemon' (^ for subs) <dcunit3d>you can specify substitutes in the CLI commands, but i think they need to be from authorized sources <qzdl>yeah but even authorized subs are a vector per latest CVE <qzdl>safest bet is just to upgrade first <dcunit3d>it gets the substitutes over HTTPS right? idk the CVE <dcunit3d>that's a lot of churn & uncertainty for malware to hook into <qzdl>from what i understood, the exec happens before tls verification <dcunit3d>is there an updated tarball for guix 1.5 on guix.gnu.org? <kestrelwx>podiki: Hi! Is it ok to target bunch of Wayland updates onto `mesa-updates` or you'll do it yourself when the next round start? Don't think it's anything important and it's just `guix refresh` anyway. <dcunit3d>it's just a tarball, so if you can boot into an image where the store's file system is not mounted, you can unpack the tarball into the store <qzdl>still, might beat building the bootstrap in tmpfs haha <dcunit3d>there would be some weird setup doing that and it depends on whether your booted installation image is ISO-9660 and/or writable <dcunit3d>idk how to hook the new guix-daemon (and everything else) so that runs when you restart the system though <dcunit3d>it's probably a terrible idea, especially if it's a custom image with extra channels. <qzdl>yeah think I'll just take the L and let it rip <dcunit3d>well it looks like i need to reconfigure the guix-daemon on my nixos <qzdl>for sure asap, is quite high CVSS on this one <qzdl>rootful build daemon is rootful <dcunit3d>you can also just rip the disk out and start over <dcunit3d>i think you can also validate the store items. the store's basically like a merkle tree AFAIK <dcunit3d>the deeper into the store, the more branches will change <podiki>kestrelwx: sure, that sounds good; mesa is overdue for an update cycle, should get to that sooon <pinoaffe>is there a canonical way to make shepherd services that don't run as root? <ieure>pinoaffe, Many daemons have config options to set the user they run as, that's probably the closest thing to a canonical way. They still start as root, then drop privs. <pinoaffe>that still feels rather ad-hoc, and if at all possible I'd prefer it if shepherd/guix handled dropping privs, rather than lots of different implementations across different services <pinoaffe>i guess that a variant of make-forkexec-constructor would probably do the trick <qzdl>pinoaffe: what about `least-authority-wrapper'? <ieure>pinoaffe, Shepherd/guix cannot make a program drop privs, only start without them. Depending on the program, that may not work, ex. a web server might need root to bind to :80 and :443, but drop privs after it's done so <yelninei>shepherd has the option to drop pribileges after fork and before execing the application <gabber>why can iāall of a suddenānot push to master anymore: "initial commit <hash> is signed by <apteryx> instead of <me>"? <gabber>i know i had this before, but i can neither remember why this came up nor how i reselved it the last time <gabber>ah, and for some reason it wants/tries/needs to authenticate all commits since i became committer (~190k). huh? <qzdl>but we use wg-quick with extra-steps atm <gabber>which COMMIT and what SIGNER key should I pass to `guix git authenticate`? the first one in the history and the key of the committer who signed it? <qzdl>gabber: maybe silly question, but have you tried regular channel intro? <qzdl>9edb3f66fd807b096b48283debdcddccfea34bad & "BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA" <gabber>or setting the commit to HEAD and the SIGNER to my own key id also worked <gabber>test202020: what information is missing? <gabber>and WDYM by `rootless guix available in substitutes`? <gabber>is it the first time you pull after installing a somewhat aged image (e.g. 1.5.0)? <test202020>gabber: no, today i trying rebuild guix from source for get latest fix for rootless <gabber>sometimes servers (codeberg) are somewhat slow, but if it is a recent installtion it shouldn't take too long <ryanprior>I keep seeing "jimctl" and don't know what it is but it amuses me each time I see the warning <test202020>previous try guix rebulding with error (connectivity/yeah) but why? substitutes not available? <ryanprior>I assume it is a tool for controlling a guy named Jim <qzdl>test202020: in general, see docs on --verbosity and --debug, and watch the processes on your system (i.e. guixbuild) <gabber>test202020: and no, `guix pull` should not depend on substitutes <ryanprior>you can run guix pull without substitutes but only if you're willing to wait a couple days for it to complete (depending on your hardware) <test202020>qzdl: debug 5 show me many/ but slow step no have verbose. is computing guix derviation with warning <qzdl>ye i guess there's not much to say when computing the fixed point <gabber>ryanprior: what will be substituted then? the channel checkouts? their compiled bytecode? <test202020>i see :trying user guixbuilder0 and waiting for next verbose. if that not looped on that step. <qzdl>test202020: I suppose you could run under strace, or use ebpf to see whats happening on the system in general (syscalls, file handles etc) <test202020>step is building path guix 1.5.0-5.e343f0-checkout.