IRC channel logs
2026-07-07.log
back to list of logs
<PotentialUser-55>Hey this might be a stupid question but given the latest vulnerabilities, is it still safe to install guix via the install script at this point in time? <PotentialUser72>Thank you, ieure. I think you provided me with the missing clue. Maybe it was some other (system) user that placed `elfutils` into the store, and my user installed the non-bin output to my profile. <jlicht>btw, I don't know what exactly changed /w our ungoogled-chromium build, but it is (finally/again?) quite fast in day-to-day usage \o/ <jlicht>as in, the binary, not the build; the build is slow :D <ngz>Hello. I’m getting a strange error whenever I try to run "guix build" or "guix shell", i.e., whenever I need to access to substitutes : "guix substitute: erreur : rename-file : Permission non accordée". It doesn’t look like a network error. So I am a bit puzzled. Do you have any idea? <gabber>what do i do when emails to other guix project members (team members, committers, etc) get bounced? does anybody feel responsible? i obviously can't email them <ngz>Ouch, I have to "guix pull --no-substitutes". <futurile>gabber: what do you mean "feel responsible" <graywolf>How do reviews work on codeberg? Are they supposed to be added automatically, or should I just pick some that seem fitting? <futurile>graywolf: if you're in a team you're notified about PRs that impact that team, so you can do a review. <futurile>graywolf: I often just go through and find ones that seem like they haven't had any attention <graywolf>futurile: Probably better phrasing would be "are they requested automatically?" <graywolf>I created a PR, but no reviewers were added, so I am confused :) <noe>graywolf: a review is automatically requested for a team when you modify a file that “belongs” to that team (see etc/teams.smc and CODEOWNERS) <graywolf>Riiiight, so embeded team does not own gnu/packages/embeded.scm <gabber>futurile: is this maybe in the realm of the maintainers collective? <nutcase>The rrror is "‘__builtin_isnan’ is not a member of ‘std’". Is that a problem with the program, with my guix system or with the combination. Any idea how to solve it? <dariqq>nutcase: Some c++ headers (fenv/math, ... ) are broken because of #include_next <nutcase>dariqq: that means it's a problem with the source code? <sham1>IIRC it's a problem with the way GCC is done in guix <dariqq>you could try with guix shell -D hello for the environment that should work <sham1>Hmm, world rebuild stuff still seems to be stuck in some places. But it seems to be going forwards, so that's good. Maybe soon we'll get a new version of curl! <nutcase>dariqq: guix shell -D hello worked, thank you <dariqq>i think the later gccs are misconfigured because of that because they cant resolve the include_next during configure time correctly (and there are already lots of hacks in place to make this work). I had the idea to just replace #include_next with absolute paths but have had no time to try to make it work <janneke>okay, after a reconfigure and reboot, i've got no DSN; ideas? <janneke>ACTION booted back into previous version <-- amazing that we have this! <futurile>janneke: I think this is some bug about network-manager, there was a new entry. <janneke>ah, i read " Openresolv update requires restarting NetworkManager" <janneke>and went: "I've got no idea what Openresolv is, and upon a reboot NetworkManager will be restarted anyway" TL;DR <janneke>i think this title is terribly misleading <janneke>i believe it should read something like: "Do this or DNS will fail..." <csantosb>Unbound variable libpisp; the variable exists in (gnu packages networking) <graywolf>csantosb: yes, but the package that uses it was moved to (gnu packages photo) <csantosb>I'm not on aarch64-linux, but I'm pulling now ... so far, so good. <graywolf>Well there is (if (target-arm?) (list libpisp) '()) so I assume amd64 will work <csantosb>Right; (gnu packages networking) is missing in (gnu packages photo) <graywolf>csantosb: simple adding the use-modules will lead to circular imports no? <dcunit3d>if using guix deploy to deploy with custom code... is the -L $loadpath approach available? or do i actually need to manage commit signing? <dcunit3d>phew lol ... is the -L $loadpath expected to exist on the server? <dcunit3d>i have a lot of custom stuff that's not appropriate for guix/nonguix/etc, but i have very little interest in maintaining a custom channel <dcunit3d>i had everything split up in my dotfiles into two main guile module namespaces. i just finished migrating it <graywolf>No, I explicitly use `guix deploy -L .' to be able to deploy from my laptop without having to sync the code around the servers <dcunit3d>if i had anything (packages/etc) to contribute, i'm finding it's so much better to just contribute it <graywolf>Though custom channel is often useful as well. E.g. if you have a package defined locally only, you cannot do `guix shell THE_PACKAGE' on the server, since the definition is not available. <graywolf>You can of course install the package via guix deploy <dcunit3d>yeh, but for now my "channel" (for which i had basically never updated .guix-channel) is defined in my dotfiles. it just occurred to me. this is very dumb for git commit signing <graywolf>In practice what works (for me) is to have most of the packages in my channel, and just few private ones and most of the configuration locally <dcunit3d>so like "containerizing" all the dependencies for real-world usage requires creating abstractions that are otherwise not needed. <dcunit3d>for me it means duplicating code between the "dc" and "ellipsis" module namespaces. this ends up being very confusing, since IDK how to search for & eliminate unneeded #:use-module delcarations <graywolf>yeah just find whatever works for you :) it is always easier to start locally, you can always factor the stuff out into a channel later, iff you will find value in that <dcunit3d>i'm planning on creating another subdirectory to define some system images without `define-module` <dcunit3d>yeh i think that makes things easier to manage, though i'm still discovering how to split shared code into modules (or services) for systems. like for package lists, splitting them into services somehow is helpful. then the logic travels with the service dependency instead of one-of public symbols <yelninei>oh god (guix build syscalls) is so full of red flags :( <yelninei>all these hard coded constants, libc structs, comments saysing "Don't do this" and doing it anyway <yelninei>i am (finally) trying to move all these into C but that file is 2500 lines long <optimal>dcunit3d: `guild compile -Wunused-module` will let you know about unused modules <krisbalintona>optimal: Oooh, that's a good tip. I'm new to Guile: is there a way to do that with one's Guix config? <dcunit3d>i think guix will try to load what's in GUILE_LOAD_PATH and if a '*.go' file is alongside a '*.scm' file, it will load the compiled '*.go' as long as the '*.scm' file isn't a newer version <dcunit3d>guix emits some warnings, but guild would compile them with some extra info. i think you get `guild` by installing `guile` <dcunit3d>i'm looking at my environment to ensure that i'm running the correct `guild` for those commands, since i'm also using guile-ares-rs and that requires some guile dependencies <dcunit3d>hmmm actually it compiles to ~/.cache/guile/ccache <dcunit3d>lavandula: did you recently modify /etc/guix/acl? <lavandula>i am extending the guix service but i read through the code and it should join the list of keys i added and the default config keys <lavandula>the bordeaux keys are in there, and i presume berlin as well <lavandula>(dont want to overload codeberg with my pulls!) <dcunit3d>i had a similar error about 2 days ago because i added a key to /etc/guix/acl, but it wasn't in the correct format <dcunit3d>you aren't pulling the whole thing (it's not a full clone bundle with everything) <dcunit3d>git finds the deltas that you need, then assembles them into "packs" (i think that's the term). it then sends only the changes you need. <dcunit3d>guix will store the raw sources it downloads for package builds/etc into /gnu/store, where they are hashed and can't be modified.... i don't think it needs to do an entire clone though. <dcunit3d>idk how that works. "commits 9edb3f6 to a4685b6 (17 new commits)..." implies that it's fetching only what it needs somehow <dcunit3d>when you do the full "git clone", you definitely feel it. it takes like 10 minutes <lavandula>although im not on the same network atm and if i wanted to id need to figure out how to do it through a jump host... <lavandula>i might have found a similar issue where i added an empty key, which might be causing it? but i cant check right now because i cant deploy... <dcunit3d>guix copy will "respect the user's .ssh/config". you can define a jump host in ~/.ssh/config <dcunit3d>idk that guix deploy will also do that, but it probably uses the same underlying SSH library <dcunit3d>it's worth a try. i know it's tough to pass SSH CLI args to `guix copy` and i've never used `guix deploy` <dcunit3d>bc the error message is similar to one I had where one of the keys in /etc/guix/acl wasn't wrapped in the correct s-expression <lavandula>(define %guix-keys (list (plain-file "empty.pub" ""))) <lavandula>like so except it was just in the middle because i havent filled it in yet <lavandula>for the record: guix deploy did with with a jump host defined <lavandula>it is a bit unergonomic relying on external files to do that, and it would be nice if i could use scheme to define which host i want based on the network, but doing that with jump hosts seems unrealistic. unless i instantiate a proxy over the jump host that then... <lavandula>mm yes it was the empty key in the acl. thanks! <dcunit3d>lavandula: look up "clone bundle" and "git pack-objects". it's probably less overhead than you think <lavandula>ooh thats nice! but i dont see how that would help with jump hosts? especially if i dont want to bother copying modules over (with git) every time <dcunit3d>bc it may not make that much of a difference to codeberg whether you use the official guix repository or not <dcunit3d>it's just like one less piece of information that you need when specifying channels <lavandula>ah well theres also the network speed. my mirror is hosted locally so its very very fast, whereas codeberg is halfway around the world <lavandula>it has dramatically sped up pull time for me... <lavandula>enough so that id recommend everyone run a mirror if they dont have one nearby, honetsly <dcunit3d>i'm just getting around to setting up the mdns substitutes... <lavandula>apoorv569: that looks like something you can learn more about by looking into the kdenlive build config for both in guix and in kdenlive source tree. you could also check if its your config file causing issues. <apoorv569>yes i was using and it was working find but some update broke it. <apoorv569>its not a guix issue but a guix package issue.m <apoorv569>i dont have time to look into such a big project source tree. <lavandula>was it commit e8c9b97 that broke it or something else? <dcunit3d>i have a feeling it's `frei0r-plugins-1.7.0` <lavandula>1.7.0 was added in 2019, the source uri was updated in january, and ffmpeg frei0r filter tests were disabled a month ago <krisbalintona>lavandula: Is there some article that shows how to host your own (private) Guix mirror? (New to Guix things btw) <lavandula>well the guix mirror is just the source code, not the substitutes. substitutes are a bit harder but https://guix.moe is a nice effort from hako <lavandula>so all you need is a git server... which is pretty trivial. i set it up on a forgejo instance so its all nice and fancy but honestly as long as you can run git clone against a url it should work <lavandula>then you just have a script or something pull from codeberg every day or 8 hours or whatever <lavandula>apoorv569: does it also break with just guix and not your channels? try with guix time-machine <apoorv569>would it work if i use guix shell --pure with time-machine? <krisbalintona>lavandula: Oooh that's what you mean. When you said mirror I thought you meant a substitute server <lavandula>substitute servers are not *that* hard if they are just caches or mirrors, there are some nice efforts (again, see hako's work especially) to make lovely interfaces for hosting them <lavandula>but custom substitutes mean you need to build and yeah it can get complicated from what i understand <apoorv569>krisbalintona: not sure what you are looking for, but you coulr build on one machine and use guix deploy to push updates all other systems on your network or even across different networks over ssh <apoorv569>there is also guix publish or something i think never used it though <lavandula>i think deploy is more for system configuration? <dcunit3d>apoorv569: i just replied. it seems to work for me <apoorv569>lavandula: yes but you could put all the packages and what not in each system's config <lavandula>i mean yes? but honestly that just feels wrong, putting everything into the environment. also that would use a lot of storage space, which is no longer cheap by any means <dcunit3d>try passing --debug to kdenlive and i think you'll get more info <dcunit3d>it's also by default building with qtbase-6.9.2-debug, qtdeclarative-6.9.2-debug, ffmpeg-8.1.2-debug... so unless it later strips debugging symbols, there's a chance it could be debugged <dcunit3d>it's failing to load the driver. i have AMD <apoorv569>yea but this is not the error i get when i run the binary i have installed on profile <lavandula>also looking at your channel ive deduced you're using xorg? that could be another problem <apoorv569>no idea.. but thats not the error i get when the installed one. <apoorv569>i have niri installed as well can try on wayland too.. one sec. <dcunit3d>idk how to check coredumps on a guix system <lavandula>probably issues with the channel that shall not be named, then, check the packages/nvidia.scm file <apoorv569>lavandula: i see.. I'll check on the other channel i guess. <lavandula>yeah, try with time-machine to limit the channel to guix <apoorv569>ok works with just guix channel via time-machine <apoorv569>i guess it's the other channel that is causing the issue.. <lavandula>*clap* free *clap* software *clap* saves *clap* lives *clap* <apoorv569>I'm trying again guix and the other one minus my channel with time-machine <lavandula>compiling the compiler's compiler with the compiler compiler compiler <apoorv569>intrestingly it works this as well.. though it found no HW accelerators.. <ieure>Always. I pulled the GPU from my desktop machine because it was such a hassle and I could never get it *really* working right. Both Guix and Debian. <apoorv569>what the hell.. it works now with guix shell without time-machine as well.. <lavandula>if you have an nvidia gpu its best to put it in a machine with a microslop windows oem license and then virtualize a vm to do anything you need to do with it <ieure>lavandula, I'd rather not run the GPU than run Windows. <apoorv569>unfortunately nvidia is better at certain things and i got it for a reason.. its a used old gpu btw. <lavandula>so true but alas there are some things... davinci resolve, solidworks, the a company's multimedia software <apoorv569>no i dont use those things.. local ai and transcoding amd games are my use case.. <lavandula>ive been putting off reading the gcd-008 thread for so long because its so active, but at this point theres 162 unread messages and im scared <lavandula>apoorv569: yeah and thats after i read through half of it <lavandula>mm yes its the most discussed gcd by a wide, wide, wide margin <apoorv569>from the issue on the repo? yes i have updated after that couple of times because i experimenting with some packages i was writing for guix.. <apoorv569>well.. its late night, ill again tomorrow now.. <look>i just tried kdenlive on nvidia, works fine with hw enc and dec <look>you need to graft ffmpeg and mesa to the nvidia versions <ieure>Hey folks, please take the nvidia talk to #nonguix, it's offtopic for this channel.