IRC channel logs
2025-06-26.log
back to list of logs
<kkremitzki>Nice, that explains something I was wondering about a while back, thanks for the asking and the answering <xelxebar>So, trying to system reconfigure for the security update, but the guix package pull no substitute, tries to build, and then fails with a segfault <xelxebar>/gnu/store/3jhfhxdf6v5ms10x5zmnl166dh3yhbr1-bash-minimal-5.1.16/bin/bash: line 1: 5023 Segmentation fault ./etc/teams.scm codeowners > "CODEOWNERS.tmp" <meaty>anyone here know how I can set the dark/light mode setting for gnome apps when I'm not using the GNOME de? <meaty>I can't find anything for it in gnome tweaks <apteryx>hm, so now when builds fail we can't even enter the failed build, right? because of recent changes to the daemon[/] <apteryx>ah, I think somehing weird happened because I used --rounds --with -K <reepca>it should still be possible to enter the failed build, but if running the daemon without root and without CAP_CHOWN then it will be owned by guix-daemon and not world-writable. <bdju>My Sway session just froze, clock stopped and everything. Can still ssh in and do stuff. Anyone else run into something like this? <bdju>I think something similar happened about a month ago. <apteryx>reepca: thanks; my daemon is still running as root, so I should be fine for the moment <apteryx>why are substitutes reverse proxy so slow when there's a cache miss? <apteryx>shouldn't they be able to approximately mirror the available bandwidth from the source, e.g. berlin? <bdju>For now I just rebooted again, Sway wouldn't start from TTY otherwise. I guess this will probably happen again in the next month. <sneek>civodul, you have 1 message! <sneek>civodul, janneke says: ah, to run with the new non-privileged guix-daemon i would need to add (privileged? #f); i haven't done that and so my guix-daemon still runs as root <decfed>would the new unpriviledged daemon have any impact on the SELinux policy file? <civodul>decfed: no idea, would be good to check! <efraim>how do I mark a pull request as reviewed? <jakef>i'm part way the tests. don't think i'll be able to run './pre-inst-env guix build hdf5 --dependents=1' because there's a lot! <gerogaga>Can guix download calculate hashes for packages with sourced via git-fetch? Every time I run guix download on a xcoderberg repo, it calculates the wrong hash. <jakef>gerogaga: pass --commit=TAG or commit hash <kratacoa>futurile: morning. saw your comment and want to take the chance to thank you for blog posts about guix. lovely! <efraim>I found where to mark something as reviewed, from 'Files changed' there's a blue button called 'Finish review' <futurile>kratacoa: you're welcome, hope they were useful! <zimoun>hum, that’s weird. From revision f6147d4, when runnin “guix time-machine -q --url=https://codeberg.org/guix/guix.git --commit=ca552a5ca82cea59c7e616e65bcc5b9118cd5e14 -- describe“, it fails with: « build of /gnu/store/ifmrzibnkbb5lkcwak8hmzk6cyrj0lj2-module-import-compiled.drv failed » <zimoun>Then running “guix build /gnu/store/ifmrzibnkbb5lkcwak8hmzk6cyrj0lj2-module-import-compiled.drv”, I get the message: « guix/build/utils.scm:883:1: invalid character in escape sequence: #\return » <zimoun>Well, I get “guix hash -rx“ on the cached checkout 05abxzfgr1wlzkzqcf9jwcqlkxwbjkzydgcaa4w86cr1s49bl8k1 <zimoun>but elsewhere I get 0klcm1i8f36d637823krcdi8qmdv8ifg8j8cwwdpyin7pds6944q <zimoun>I already removed the local checkout and fully recloned again. Still the same. <zimoun>Ahah! Found it! CRLF! I did not reverted when testing 4b68cbbb8d7541eb786e46aa1277e9a396c4c5f4 « git: Move ‘core.autocrlf’ settings » <viaken>Anyone running NetworkManager with iwd? It should be just deleting wpa-supplicant-service-type from %desktop-services and adding iwd-service-type, right? <viaken>The iwd part works, and NM works other than wifi, but they aren't talking. <emacsomancer>I'm not sure which bit ""Wrong type argument in position ~A (expecting ~A): ~S")" is complaining about, or why it's started now. <viaken>In awesomejit/packages/emacs.scm: <viaken> 202:25 5 (loop (#:phases #<gexp (modify-phases #<gexp-input #…>) #) <viaken>I don't have line numbers handy, but it's one of your emacs packages. <ieure>Is something up with substitutes since the recent security patch? I've noticed an abnormal number of guix package builds. as I'm updating. <ieure>I pulled out a spare machine today, I haven't booted it in a month or so, and no guix substitues are available. <dtx>I'm sure this is a common question but I can't find a good answer. Why does guix have composer-classloader but not the actual composer tool? I don't want to install this junk on a system level, does anybody? <ieure>dtx, The whole point of Guix is to become the single package manager you need, so you don't have to juggle dozens of language/ecosystem-specific ones. <ieure>dtx, And you don't have to install anything on the system level, and other than the stuff you need to boot and log in, doing so is discouraged for *all* packages. If you want to use some Python or PHP or whatever package, `guix shell the-package-name' makes it available in that shell without "installing" anywhere. <dtx>ieure, I get that, but the vast majority of these packages are not available in the official packages list, and "guix import composer" doesn't handle (as far as I can tell: importing from existing projects, specific versions, easy upgrades, etc. Isn't the strict adherence here literally just ideology over practicality? <dtx>Just saying because coexistence in the meantime should be easy. <dtx>and by import from existing projects I mean importing everything from composer.json <ieure>dtx, It is not ideology over practicality. Most of these language packaging tools encode assumptions about the system which don't hold on Guix, since it's a non-FHS distro. And since they don't work, using them is not a practical option at all. <ieure>dtx, There's been some recent work on the Rust packaging stuff to derive Guix packages from lockfiles; if you wanted to work on some kind of build-system that did that for PHP/Composer projects, that would be a good place to start. <ieure>dtx, Ultimately, Guix is a volunteer project where the work gets done because it scratches someone's itch. Sounds like you have the itch on this one. :) <dtx>ieure, unfortunately I'm itching all over, and gotta prioritize my scratching. :P <ieure>dtx, I hear you... I quit programming PHP 15+ years ago, so this itch isn't one I have. <dtx>ieure, yeah, this codebase unfortunately isn't going away any time soon. So I'm stuck with it. <dtx>I mean at the end of the day. I can literally just download the binary manually and use it inside of a guix environment, but it just makes me feel dirty. <lilyp>if it makes you feel less dirty, you can spawn a pure shell or even container <lilyp>other than that the only way to get clean would be packaging all your dependencies :) <dtx>lilyp, yeah, that's what I do. <shcv>hola; I'm trying to develop a simple project in guile on guix sd, and was hoping to use guix shell with guix.scm pattern to setup a dev environment <shcv>however, if I do 'guix shell guile --container --emulate-fhs' (to emulate the dev env I"m making), I get "/sbin/ldconfig: /lib/libguile-3.0.so.1.6.0-gdb.scm is not an ELF file - it has the wrong magic bytes at the start." <shcv>I don't *think* that's a problem, but it is odd <shcv>anything I can do to make it go away, or is that a bug in the guile package and how it interacts with --emulate-fhs? <bavier>maybe better to ask on the mailing list.