IRC channel logs
2026-07-06.log
back to list of logs
<tachymelia>hey uhh. now that the whole, substitutes being broken on rootless daemon systems is fixed, is there. Any way to guix pull and reconfigure without having to rebuild the entire world and without having to rollback to the Extremely Vulnerable version to get substitutes <tachymelia>even just reconfiguring with (privileged? #t) is requiring a world rebuild, presumably bc of the different daemon <tachymelia>I am resorting to manually running validate-guix-ownership to move to privileged daemon and then manually spawning a privileged daemon from a shell <tachymelia>uhh! once I get everything updated I might do a quick writeup in case anyone else has this issue, I'll post it here once I do <Guest81>hi all. im running into an issue with building a local package. i have a define-module setup (i.e (`define-module (<package-name>)` but i always get an error with `guix package -f <local-scheme-file.scm>` any ideas what could be the issue with my code? here is a link <ieure>Guest81, Also, wondering why this paste doesn't have `define-module' in it, when your message says that your setup is using `define-module'. <Guest81>ieure sorry, here is the define-module here. the error i get is the "1 dependencies couldnt be built" <Guest81> #:use-module ((guix licenses) #:prefix license:) <Guest81> #:use-module (guix build-system gnu) <ieure>Guest81, Do not paste into the channel, use a pastebin. <ieure>Guest81, "1 dependencies couldnt be built" means the build for one of the inputs to your package is broken. <ieure>Guest81, You'd have to look at the build log for that package to see what's wrong with it. <ieure>Hmm, what you pasted doesn't have any inputs though. <Guest81>ieure with inputs, you mean the dependencies? <Guest81> (list libx11 libxrandr libevdev gtk+))` this is what youre looking for? <ieure>Guest81, Those are inputs, yes, but they're commented out in your paste. <ieure>Guest81, Inputs in Guix are analogous to (but not precisely the same as) dependencies. <Guest81>oh i see. sorry. i also used `guix download` as well to get the tarball on the system <ieure>Okay... what's the relevance? <Guest81>i thought maybe by using `guix download` it would retrieve the files i needed in order to build the package. <ieure>Guest81, The build process will download the source as needed. Your package specification is using the upstream Git repo, not a tarball, so having downloaded the tarball via any means does nothing. <Guest81>ohh...that makes sense! the upstream for the package is 0.6.x...do i need to specify that in the versions definition? <ieure>0.6.x is unlikely to be a precise version. <ieure>Guest81, You need to paste the error you're getting into a pastebin and/or paste the full package definition you're building. Right now, I can't see the error you're getting, nor can I build your package to get it myself. <ieure>Without one or both of those (preferably both), I can't help. <ieure>Guest81, 0.6.x is a branch for development of versions 0.6. You need to specify a precise commit or tag to build from a source repo. "v0.6.7" looks like the correct tag to me. <ieure>...you're simply building an incomplete package definition. <ieure>Yes, you are not specifying a commit or SHA of the source. <ieure>Correct those and try building again. <ieure>Guest81, The relevant part of the error output you're likely getting is "fatal: invalid reference: v0.6.x" which is Guix telling you that you haven't specified a tag or commit within the source repo to build from. <ieure>It's a branch, you can't build from a branch, because the underlying ref will change on the next commit pushed there, which will break your package. You must specify a tag or commit SHA. <ieure>I have to step away, that info should get you past the problem you're stuck on. <ieure>You will likely find new and exciting problems after. <Guest81>but i get the same error as before. im having trouble getting a paste but ill see if someone else can try. <ieure>Read *all* the output, it will tell you why it didn't work. <Guest81>hmm..ok it was the hash...but now the error i get says `\ 'configure' phasebuilder for `/gnu/store/d204cpskw7h9mmmgdnvc9ngcf6lf82f0-opentabletdriver-v0.6.7.drv' failed with exit code` <Guest81>its gotta be the build-system right? <Guest81>im not quite sure what to make of it. <czan>Looking at the git repo, this is in C#? I don't know that we have a build system for this, so it might require some work to get a functional package. <czan>Well, the first step would be to know how to build it manually. Then that will need to be encoded into phases in the package build. That's assuming it can build using mono (since .Net isn't packaged in Guix at present). <Guest81>czan i have mono. but im a little confused on how to even start with this. afaik the package has a script to automatically build it <dcunit3d>what should the ownership be for links in /var/guix/profiles/per-user/myuser? <dcunit3d>if symlinks owned by `myuser:myuser` point outside of the store, `guix gc` can't see them, so garbage collects the underlying store items <dcunit3d>i changed their ownership, but then couldn't pull, getting an error that tells me to change ownership of `/var/guix/profiles/per-user/myuser` back to `myuser:myuser` <czan>Guest81: I would try to get it building in a "guix shell" with something like "guix shell mono -- bash ./build.sh". If you can get that working, then we can encode that in a build. <tachymelia>dcunit3d: myuser:myuser, sadly. I think it's a known bug with the unprivileged daemon, #6023, but it doesn't look like it's been touched <Guest81>@alright. i got this `fatal: bad revision 'HEAD'` <czan>What command did you run to get that message? <Guest81>czan `guix shell mono -- bash ./path/to/git/package/build.sh` <czan>You probably need to cd to ./path/to/git/package before running build.sh, if it's doing some git shenanigans. <Guest81>czan now its successful. so then, i just add that command into my scm file for the package? <czan>The build happens in an isolated environment, though, so you might find you need to add more inputs (like, for instance, mono). The build you ran in a "guix shell" might have picked something else up from your broader system. <jfred>tachymelia: Thanks, I might end up needing that - my system is in a bit of a broken state too it seems <Guest81>czan i see. add `mono` under `native-inputs` then? <tachymelia>jfred: np! lmk if anything in the guide's confusing :p <czan>How confident are you that this will build with mono? I'm having a look, and it looks like it's relying on using dotnet a bunch. <czan>But to answer your more specific question: I think mono might be a normal input (i.e. a different field called "inputs", rather than "native-inputs"). <Guest81>czan i suppose somewhat confident. if i have dotnet already on the system, do i add it as a normal input? <czan>dotnet isn't packaged in Guix (based on a look at gnu/packages/dotnet.scm), so I'm not sure how you'd add it as an input. <czan>I need to step away from my computer for a while now, so I will have to stop helping for now. Good luck! Hopefully you'll have worked everything out before I return. :) <Guest81>czan i hope so. thank you for the help! <adanska>If im writing a service configuration with `define-configuration` and i need enums, should I use (rnrs enums) or `define-enumerated-field-type` from (gnu services configuration)? <sham1>You could also do something like (define (choices? choice) (member choice '(these are symbols you can use))) if you don't want to mess with proper enums <folaht>What's the command for building a package? <folaht>I have a package definition I want to test. <adanska>sham1, cool, pretty sure thats basically what `define-enumerated-field-type` does anyway <adanska>folaht, use the -f flag with guix build, and make sure ur scm file evaluates to the package u want to build <folaht>Oh right, how does one evaluate the scheme file again? <adanska>put the variable name of your package at the very end of the file if you've bound it to one using a (define ... ) clause <adanska>folaht, unless you are writing your package within the guix repo itself, in which case build the repository according to the manual and just append your guix build invokation with ./pre-inst-env from the directory of ur guix checkout <folaht>adanska, nah I'm starting out with writing a package on my own channel. I want to start things simple. <folaht>First time I'm ever writing a package. <folaht>Well, second time really, but the first time failed, because there was an easier solution. <adanska>folaht, then do the -f method. if you have inter-module dependencies within ur channel that u need to resolve, use the -L flag to load the directory of ur channel and then perhaps the -e flag like so: guix build -L /path/to/ur/channel/dir -e '(@@ (ur module here) pkg-var-name)' <graywolf>How do I do guix-pull while skipping tests? <graywolf>guix-build has --without-tests, but guix-pull does not accept that argument <adanska>well it just builds the tests, it doesnt run them. theres no way to avoid building that part of the guix derivation, or any part really <graywolf>Hm... I guess I need to build python-minimal on GuixSD than and copy it over to my foreign system? <adanska>it does. I swear CI used to provide substitutes for those derivations too! but CI has been struggling for a while, so perhaps its to do with that. <adanska>oh, does the derivation fail when pulling on ur foreign install? <graywolf>yeah, python-minimal does not build on non-privileged daemon <graywolf>I guess I will just figure out how to switch my foreign systems to daemon running under root. The non-root version is bit too experimental for my taste. <adanska>graywolf, i think thats a good idea! <PotentialUser72>Why aren't the executables (/bin) from `elfutils` included in $PATH? <folaht>How can I tell what the hash code is of the package definition? <trev>folaht: use guix download on the source url <trev>usually i just let it build and tell me the correct hash :\ <folaht>trev, lol, I was tempted to do that, but I thought it would be better if I knew beforehand. <folaht>I did a 'guix download' on the .tar.gz file of the github project. That's the source url isn't it? <folaht>I'm not getting the correct hash I think. <trev>it gives the nix base32 hash <trev>not the sha256 that you probably see on github <futurile>folaht: if you do `guix edit <package>` you can see what guix thinks it is <folaht>I'm a bit confused now. I'll try and post my findings on the forum. <futurile>folaht: what package are you trying to check? <trev>i don't see the hash on guix edit either <futurile>trev: so if you go `guix edit vim` - I get the package definition right, and in there is the hash that Guix has for that package <futurile>trev: then you do guix download to check the source package, like you to ld them <trev>oh yeah...i was assuming that folaht was writing a fresh package def <futurile>yeah, the only way if it's a new package is what you told them - guix download. It's different if you have git over a file, which is what catches me out most commonly <futurile>(funnily enough Ruby packages are quite nice because they have the SHA256 on the ruby gems site) <futurile>folaht: you also need to put the word 'fetchit' on a line on it's own at the bottom of the file <futurile>folaht: because you're using `guix build -f <file>` - it's publicly defining it, but you haven't told it to actually build it yet <futurile>folaht: your alternative option, is to add the current directory to guix's load-path. So you don't have to add anything in the file. You use `guix build --load-path=./ fetchit <folaht>futurile, ah, well I figured out the 'fetchit' at the end of the line earlier. I just update my 'first package' thread. I'm stuck at dependencies now. <futurile>eeych you haven't picked the easiest package for your first one have you heh heh heh <folaht>futurile, awww... I was hoping it would be easy actually. <futurile>if you're interested in packaging generally I wouldn't start with Cargo, and specifically one that looks like it's got embedded crates. I think it will be complicated - but hako might be able to help you <futurile>(I don't want to sound discouraging, it's just going to be a lot for your first attempt) <MichaelGame_Dev>futurile so tips on getting Ruby stuff to work? I am also working on a Rails app haha. I have your list of dev articles to look through, but curious if you had luck specifically with Ruby stuff. <hjolmir_the_peni>> futurile so tips on getting Ruby stuff to work? I am also working on a Rails app haha. I have your list of dev articles to look through, but curious if you had luck specifically with Ruby stuff. <hjolmir_the_peni>have you use `guix gem import`? generally that'll get you most of the way there <futurile>MichaelGame_Dev: I'm not actually a Ruby dev, I've just been working on the packaging because we were falling behind and some people have been sending in package updates. As hjolmir_the_peni said, there's a `guix gem import` command that you can use. <qzdl>looks like boost 1.8.3 patches have changed <qzdl>I'd like to check the previous contents before updating the hash; how to surgically substitute a given drv? i.e. /gnu/store/chzch29xi2gzdxbzk77sb432klkddra1-boost-0001-unordered-fix-copy-assign.patch <qzdl>ok, just ~guix build DRV~ will do, gg <kestrelwx>qzdl: There's a commit on `misc-world-rebuild` that fixes the hash. <noxi>how it feels to `gc` about 300G <elevenk>hey I tried out NixOS for a while but went back to Guix b.c. Guix feels more hackable and well documented. <elevenk>now I have a problem running my first guix system reconfigure. <elevenk>I have to build guix-1.50-5.e343ff0 but can't since the build fails. <ieure>And what commit of guix are you on? <elevenk>The verson of guix in /run/current-system/profile has the commit hash e343ff04 <elevenk>However, I ran guix pull as root first and that version of guix is more recent 2106730 <ieure>What commit does `guix describe' show? That's the guix which is used when you `sudo guix system reconfigure'. <ieure>elevenk, Okay, that's recent, that's good. What error are you getting? <elevenk>ieure: Gosh, I'd have to wait for the build of guix-1.5.0-5.e343ff0 from source to finish again <ieure>elevenk, You don't have a log from the last time? <elevenk>ieure: The log I have doesn't show what went wrong. It failed during tests I think. <ajaxis>Hi! I have a question about offloading with an unprivileged build daemon. The mutual trust uses the private from the root account, but it appears that the daemon cannot access it when unprivileged (permission denied). One solution is of course to use another ssh-key, however that implies a risk where a "normal" user could use that key to gain <ajaxis>access to the remote machine (through offloading). Has anyone had the same dilemma or could give some guidance? <Rutherther>ajaxis: the key used by guix for signing should be owned by the user running guix-daemon, the key is typically /etc/guix/signing-key.asc, you generate it by a command. <ajaxis>Yes, that is for the archive, but not for the ssh connection. <csantosb>elevenk, ieure: `guix weather guix` shows no substitute available, so users need to build it locally <ajaxis>Rutherther: Or do you mean that a non-root key imposes no risk because of signing? (that would seem unconventional) <Rutherther>ajaxis: but the ssh connection is to arbitrary user, that is different handling. The daemon has to be able to read the key, not the user you ssh with <Rutherther>ssh key and the key used for signing are different matter, they are unrelated <ajaxis>Rutherther: Yes, exactly, when the daemon in unprivileged it cannot read a key owned by root <Rutherther>as I was telling you the key is supposed to be owned by the user running guix-daemon, if it is ran unprivileged and your guix signing key is owned by root, it is wrong <ajaxis>This has nothing to do with the signing key. In the manual the private-key field in the build-machine data-type is default to: ~root/.ssh/id_rsa, which is owned by root and cannot be accessed by an unprivileged user i.e. the daemon <ajaxis>Either I could run the daemon privileged, or I could have an ssh-key that is not owned by root (and therefore not requiring root access to gain access to the remote machine). Neither is perfect <Rutherther>I see, I misunderstood what you were saying then <Rutherther>I do not see how you would gain access to a remote machine by offloading, like, yes, you gain the possibility to offload something, but that should be all <Rutherther>if it was possible to do something else, like privilege escalation, that would be a bug <ajaxis>No worries, maybe I was unclear. <ajaxis>But a non-root key could be used by anyone to log-in to the remote machine? <ajaxis>Not necessarily through the daemon, just by using ssh. <Rutherther>why could it? a non-root key does not imply it's accessible by everyone. Do you think other users can access your $HOME/.ssh/id_rsa? <ajaxis>No, but is that not easier, than gaining root privileges? And which user would get that key? <Rutherther>the user that runs guix daemon, presumably 'guix-daemon' if you are using the default configuration <ieure>Right, the usecase is different than the signing key, but the permission constraints are the same. <ieure>Should be readable by the user the guix daemon runs as, and nobody else. <ajaxis>But the "guix-daemon" does not have a home for a reason, if I read the manual correctly <ieure>The key does not have to be under some user's $HOME. <Rutherther>ajaxis: it doesn't have to have a home, you can put the key to arbitrary location and just make it owned by the guix-daemon and chmod to permissions allowing only the user to read it <Rutherther>I do not think gaining privileges to other non-root users would typically be easier than gaining root access <ajaxis>True, but that seems like a weird work-around <ajaxis>especially when the default from the manual is not working with the preferred (an unprivileged guix-daemon) <Rutherther>guix-daemon is still quite new and there are 'many' more problems with it than this one <ieure>Yes, it's something I want, but I'm holding off until it's in better shape. <Rutherther>feel free to report it as an issue, because yes, at bare minimum the manual should give you instructions for this <ajaxis>Okay, I think I will do when I get the time, just was surprised by the behavior and was wondering if I did something wrong! Thank you for the discussion and help! <attila_lendvai_>is anyone using fprintd? i've added (service fprintd-service-type) but `herd status` has no fprintd, and the login screen keeps printing repeatedly that fingerprint failed, without touching the sensor <kratacoa>btw, have the ISOs been updated/is an update planned following the CVEs release? <elevenk>yah, I've been trying to use guix-for-channels to make sure that I only use the latest guix everywhere together with guix pulling _before_ `guix system init`. I still can't avoid building that unsubstitutable guix package, unless I use /run/current-system/.../guix <elevenk>so... my best guess is that the guix package doesn't build any more... and I'll see tomorrow after bed if that was fixed. <graywolf>"Search and filtering is seeing a high influx of requests for this repository,"... I mean, isn't that kinda the point of online git forge? <graywolf>luckily spamming ^R does show the issue list sooner or later <ieure>graywolf, What they mean is "out website is being pummeled by LLM infringement scraper bots" <ieure>Which is now the case with pretty much anything you put on the internet. Sucks. <ieure>Can't wait for this bubble to pop. <graywolf>I recently had to pick a laptop for a new hire and the HW prices are insane, and half the stuff is not even on stock <ieure>There's a huge divide, technical people are heavily pro-LLM, but the sentiment among the general population is overwhelmingly negative. <ieure>I personally can't get enthused about the technology that's literally destroying everything I've created or wanted or liked about computers for 30 years. <singpolyma>I don't think the divide is along technical lines. I know many non techincals who are excited about LLMs and many technicals who are not <graywolf>buddy of mine from college posted on facebook today that after month long hiatus, he decided he just cannot go back and is giving up on programing as a career <ieure>singpolyma, I'm sure there are as many divides as people, but my point is that, generally, within tech, LLMs are popular, and outside of it, they aren't. <ieure>graywolf, If I had a viable option that paid even 50% of what I'm making, I'd be out. Everything is so unbelievably dumb. <singpolyma>That's an interesting assertion. I mostly see tech people being anti-LLM but maybe I mostly see tech people generally <graywolf>Luckily my current place does not push LLM usage, but I did take hefty pay cut when switching <ieure>I dislike the policies where I'm at now, but have heard from folks in my network at shops where the brainworms are much hungrier. Absolute nonsense out there. <ieure>One person was telling me they put up a PR, tested, worked, complete. And they were forced to close it and do the work over, but using an LLM. <graywolf>I mean I heard stories like this, but it is just so hard to believe <graywolf>I would get "nex one do via LLM", but "redo this one" is just... <ieure>Heard it direct from a person I've worked with before and trust. <ieure>I got an official written warning at my job, because someone asked about environmental impact of LLMs, and I mentioned in chat that I struggle with it. <graywolf>uff... I guess sometimes working in relatively-poorer company does have advantages. Agents are *expensive* if actually used. <graywolf>well, I did enjoy are little, depressing exchange, but I think I need a beer, so enjoy rest of your evening :) <PotentialUser72>Why aren't the executables (/bin) from `elfutils` included in $PATH? <ieure>PotentialUser72, Probably because elfutils has multiple outputs, and the binaries are in the "bin" output. <ieure>Guessing that output is not in your profile.