IRC channel logs
2025-10-10.log
back to list of logs
<Guest48>is there any way to replace the hash in the package definition inplace with guix build?ย It is annoying to have to copy and paste the package hash when updating definitions <Rutherther>Guest48: when updating a package, consider using guix refresh that will change the version and change the hash <apteryx>there's no 'dmesg' output inside a 'guix system container' <apteryx>I think I'd need the equivalent of what '--privileged' does in docker, so that the container root has CAP_SYS_ADMIN, perhaps? <Ironsmith>hello guix! i want to use a package for my login screen via greetd but i don't want to add it to the global profile. is this approach good? <Ironsmith>i added this service and then referenced the packages in question withing a #~( ... ) like so: <Ironsmith>`(service greetd-service-type ... (default-session-command #~(string-append #$cage "/bin/cage -ds -- " #$gtkgreet "/bin/gtkgreet")) ... )` <Ironsmith>^ this is working currently, but i want to know if it's because potentially `cage` and `gtkgreet` are in my cache, so eventually it might not work? i did a `guix gc` and it still works after that thouh <Ironsmith>i also noticed some examples in the codebase that use `(file-append <package> "/bin/executable")` so for example i would have to change `#$cage` to `(file-append #$cage "/bin/cage")`, is that needed? it seems to work fine without it <sibl>I have to kill and run udisksd as root manually for gnome-disks to work, is this a common error ? I could see it online but I never found a fix <apteryx>would anyone have a need to play with linux capabilities in containers? <apteryx>I had wrote some code for it, but I couldn't make it work for the use case I had in mind (rsync with noatime flag), so it's been dormant. <apteryx>sibl: perhaps polkit issue? worth reporting <Rutherther>sneek: later tell Ironsmith: yes, it is fine. cage is referenced by your greed config and that in turn by your system, so gc won't collect cage. Using file-append or ungexping directly is matter of preference. The former is usually better when you do not even have to make a gexp, but in your case you need it for appending the arguments and gtkgreet as well <mra>quick question: i've been working on a pr, but i want to tidy up the commit history. is the correct way to do this to rebase history as I please and then force push the branch, or would that mess up the pr? <adanska>mra, rebase and clean up history, then force push. thats the indended workflow :) <adanska>on the PR page it will still show your old commits, but when you go into the commits and changes tabs it will reflect your updated PR <mra>adanska ah, awesome! wasn't sure if the force push would screw up the visibility of my old commits on the pr itself. thanks! <charlesroelli>Hi all. If I do "guix package --dry-run --install python python-toolchain", I get an error about conflicting entries for python. If I do "guix shell python python-toolchain" there is no error and "ls -l `which python`" points in the python-toolchain folder. Why does the second command not signal an error? <futurile>charlesroelli: you need `python-wrapper` in your guix-shell invocation. <futurile>charlesroelli: you can see the details of python-wrapper with 'guix search python-wrapper' - all it's doing is making python3 available as python <futurile>charlesroelli: your first one `guix package --dry-run --install python python-toolchain` should be telling you the specific packages that are conflicting in your default profile <charlesroelli>Thanks futurile. Even in a temporary profile, e.g. with "guix package --dry-run --profile=`mktemp -d` --install python python-toolchain", the command still fails because the "python" and "python-toolchain" are (I think) not meant to be used together. I'm curious why "guix shell" does not also show an error in this case. <charlesroelli>We found the incompatibility between python and python-toolchain in https://codeberg.org/guix/guix/issues/3345. I guess there is some design difference between "guix package --install" and "guix shell" that explains the lack of an error in "guix shell", but I don't understand it. <futurile>why are you trying to install both anyway, the info for python-toolchain says it includes python? <csantosb>Codeberg is down again ... I wonder how they'd manage a huge migration to their servers <futurile>so I think you only need python-toolchain and python-wrapper, on the assumption that you're trying to do some sort of python development <futurile>charlesroelli: I don't know about `guix shell`, but the `guix package --install` is definitely because you can't use `python` and `python-toolchain` together. It explictly tries to tell you they are conflicting 'profile contains conflicting entries for python' <kestrelwx>I think in `guix shell` you can use `qtwayland` and `qtwayland5` without it complaining, so maybe it is different. <charlesroelli>futurile: yes, it was indeed a mistake to install both, so the error from "guix package --install" makes sense. But why can "guix shell" create an environment with conflicting entries? <Rutherther>charlesroelli: the lack of error of guix shell is explained by the fact that shell explicitely allows the conflicts to happen <Rutherther>charlesroelli: another thing is that python-toolchain is a 'historic' wrapper for python propagating python and inputs that were earlier necessary for building. 1. It shouldn't really be used in shells, 2. it's not necessary to use it - you can just use python, python-pip etc. <mra>csantosb: it's working fine for me? <csantosb>mra: Back to life now; it's been down for a few minutes, this is something which happens randomly <mra>csantosb: hm, yeah, I have found codeberg mildly unstable. I suppose it's just an infra issue? <mra>I can't imagine how much scraping traffic they must have to deal with from llm companies. i only just noticed how badly openai is hitting my server <futurile>it's more stable than the FSF infrastructure. The reality is that the LLM stuff is off the charts, then you've got idiots DDOS'ing them, and they're massively underfunded compared to the proprietary services like github <futurile>codeberg has a tiny cluster, and if you look at their accounts they probably don't receive as much money as a single 5 person github team <mra>futurile: I should really donate to codeberg. they're such a fantastic service <futurile>mra: donate to Guix and then the intention is to donate to Codeberg as they're critical infrastructure for the project. <futurile>mra: 'intention' meaning we discussed it previously, but didn't have enough funds yet. It is critical path for the project so really it is the right thing for us to do. <mra>futurile: I have been wanting to donate to fix too! I think I might just support both projects :) <nutcase>I have s segafult during boot, that's not 100% related to guix I think, because I'm not using linux-libre: "[ 1.540441] init[1]: segfault at 3fff00 ip 00000000004d4953 sp 00007ffe56ece2a0 error 4 in guile[d4953,401000+201000] likely on CPU 3 (core 12, socket 0)" <nutcase>Is this relevant in this IRC room or am I completely wrong? <mra>nutcase: hard to tell. dump the entire crash log into a pastebin and put the link here? <mra>hard to say anything with only a single line from the logs <mra>oh, my bad, i assumed that this was causing a kernel panic <futurile>mra: well donating to either Guix or Codeberg is brill. I want to find the right way to talk about 'free software' being free, but infrastructure isn't! <mra>futurile: went ahead and donated to both. i love me some good software :) <mra>and the world keeps reminding me of the value of having projects that aren't funded by VC <futurile>mra: cool - appreciated! Yeah know what you mean, even though I've spent my entire career practically in VC-backed. Reality is we need multiple forms of funding in this world <Deltafire>if a segfault occurs with PID=1 then it's logged as a KERN_EMERG regardless as to whether there is a handler installed for it <Deltafire>i don't know why we only started seeing this message around July this year, the code i've been looking through hasn't been modified for years <cricri>hello, hello... is the guix versioning scheme somewhere documented? I gave it a try and pinned my guix channel to version tag 1.4.0. Intuitively, I would have guessed this must be a stable version of guix. To my suprise, the build of my os configuration failed with this setting. <cricri>Also I wonder, what the meaning of those v1.4.0+sha_tag tags might be? <Deltafire>1.4 is ancient, only use for initial install then update to master asap <Rutherther>cricri: guix is rolling, you aren't supposed to pin it to a version. That way you would be opening yourself to outdated software, almost certainly with security vulnerabilities <cricri>And... tag 1.4.0 points to a commit that is 2 years old. When is the next version release scheduled? <Rutherther>even if new version came out yesterday, you aren't supposed to use it except for installation to get updated software without security vulnerabilities <scrambler>To update guix, do guix pull, sudo guix pull, hash guix. You will get a newer version of guix. I don't know if there even is a version release scheduled. From the website you download 1.4 or Latest, and either way you are meant to upgrade it <cricri>ok, I won't pin to versions anymore. if I understood correctly the tags just mark some milestones where certain goals have been reached? <Deltafire>i think they just mark the commit of the latest install ISO <Rutherther>cricri: exactly, they are good installation candidates where people tested thoroughly they can be installed everywhere supported and that certain packages/services have to be working so that people do not end up with broken installations right away. They are still only tags that do not move, so when you use them no updates, not even minor can go to them <Rutherther>unfortunately guix does't have enough maintainers to get some sort of stable versions like other package managers commonly do <scrambler>apteryx, I thought you were referring to some kind of SCP themed text-based game someone made in Emacs, and was slightly disappointed to see that it is for spreadsheets <apteryx>you need an ssh + webserver, and then you can send regions or whole buffers to it with M-x scpaste from Emacs <apteryx>if you want to download the file you remove the .html suffix from the url <apteryx>or click on the 'original' link at the bottom of the paste <mra>ooh, diy pastebin is nice <mra>for some reason my landlord's isp blocks paste.rs, which was my go-to pastebin <ColdSideOfPillow>especially this from the README: "[it] uses Emacs' font-lock as its syntax highlighter instead of relying on a third-party syntax highlighter" <ieure>ColdSideOfPillow, Ah nice, Phil (technomancy) is a good dude. <ColdSideOfPillow>ieure: yes, I was pleasantly surprised to see that it is written by technomancy <simendsjo>How are people dealing with secrets for services? I cannot add it to the store. It cannot require user intervention. Store it in a plain text file only readable by the service user and load it at runtime? <tpf>hello, in my code, I define several variables (for example log-file-path). Then, I load a user config file that uses set! to customize them. It works, but you can't use the user config variables from the repl without first loading the main file. And that make quick testing somewhat cumbersome. How would you approach this problem? <tpf>will using define in the config file just overwrite the variables? <scrambler>simendsjo, can you use direnv and a .envrc file? <ieure>tpf, Would have to see what the code is doing to give a recommendation. <simendsjo>scrambler: In what way? I want to create a shepherd service which starts a service like Immich. It needs a database connection, so it needs the password available somewhere. <ieure>simendsjo, I haven't used it, and it's not built in, but it's probably the best approach right now that doesn't involve rolling your own. <Rutherther>simendsjo: pretty much that, yeah. For making it more declarative it's possible to use an encrypted file that you then have a key for on your system and have a separate service that decrypts the file/files and puts it/them to a correct place your service expects. This is what sops-guix implements <Rutherther>but the underlying principle is still to have a file readable by the service <tpf>I changed the set!(s) to define and it worked like I wanted it to. <kestrelwx>tpf: It shadows them rather than an overwrite. <kestrelwx>So, if it's accessed from outside the scope of the user module you'd see the old values. <tpf>kestrelwx: thanks, that makes sense <simendsjo>ieure: I already use gpg and password-store. Sops looks extremely extremely feature rich in comparison, but probably overkill for what I need. I guess I can create something similar, and pass DATABASE_PASSWORD="$(pass show immich/database-password)" in the service. Not fan of storing secrets in the definition and store even if it's encrypted though. Maybe just a bit too paranoid. <ieure>simendsjo, Yeah, I'm with you on feeling iffy about exposing sensitive data, even ciphertext. <kestrelwx>I think somebody mentioned making a different secret service for Guix without secrets as state couple days earlier, which I'm also looking forward to. <jlicht>it seems both emacs-magit-annex and emacs-git-email are broken on master due to them missing cond-let <simendsjo>kestrelwx: By "without state", you mean the secrets will not be added to the store or definition? It has to be available somewhere though, and securily fetched only by the ones which has access. So I suspect it requires some manual setup per user/service to supply a secret without recording it. <jlicht>ieure: the change you made yesterday wrt the node-team jobset worked out, thanks again <ieure>jlicht, Great! Thanks for letting me know. <tpf>Sorry everyone! just realized that I was on the guix channel instead of the guile one. Apparently guix users generally know guile :) <kestrelwx>simendsjo: I can't find the conversation I remember right now, so until the universe confirms otherwise I'm assuming I dreamt it up. :P <simendsjo>kestrelwx: If you're dreaming, so might I, because when you mentioned it I remembered it too ;) <kestrelwx>Well, I'm off now, so perhaps we can discuss it in the dream world's dream world. Good night! <ygrek>i installed guix via install.sh on debian, guix install works but guix pull complains "error: Git error: SSL error: received early EOF <ygrek>" (I install nss-certs and set environment variables as per manual - didn't help) <ieure>ygrek, You're probably pulling from Savannah. Also, there's a Debian package for Guix, if you prefer that. <Rutherther>libgit used in guix 1.4.0 doesn't support redirects <ygrek>there is no debian package :) it was removed from trixie <ieure>Oh, I thought it made it into trixie. <ygrek>(i would prefer debian package to start from yes) <ieure>Well, sounds like there's some .deb kicking around the mirrors you could install. <ygrek>and savannah has some certificate problems? it is some temporary problem? <ygrek>ieure, i would be happy to use something semi-official if you have a pointer <scrambler>I dont think there's anything wrong with savannah on a fresh install <scrambler>wouldnt it pull from there and then you get new mirrors? <Rutherther>ygrek: codeberg is the official repository now, savannah is only a mirror. When 1.4.0 came out savannah was the main one <ygrek>but install.sh still installs the one with savannah? so it means every new user gets into this issue? <Rutherther>install.sh installs the 3 year old 1.4.0 release that points to savannah as the default channel you pull from, yes <ygrek>pulling works with codeberg, thanks! <ieure>scrambler, Savannah has major problems no matter how old the install. <ygrek>i think this deserves some note in the manual, because it recommends using install.sh and doesn't mention this.. <scrambler>I swear I have used the script and it worked <ygrek>i installed twice with same result before asking here <Rutherther>no, it didn't leave a broken installation. Savannah is down. That happens sometimes (or like most of the time) <Rutherther>it's been getting progressively worse throughout the last months <characteristic>not only savannah, but most of the stuff under gnu.org; it is practically impossible to access email archives now <scrambler>ok ok ok I was worried for a moment I had been wasting time getting already borked installs to work <ieure>Yeah. Blame lies with the so-called "AI" scraper bots destroying the open Internet. But also GNU for not doing much to mitigate it. <FuncProgLinux>I ended up setting up a tarpit on my servers to slow them for good <ygrek>guix pull: error: Git error: unknown style 'zdiff3' given for 'merge.conflictstyle' <ygrek>so apparently it is using ~/.gitconfig :] <ygrek>phew, at least it is not re-pulling from scratch <ygrek>actually i am wrong, it does from scratch, another 20 minutes till next error i guess :( <ElephantErgo>Hey everyone, I'm trying to compile a kernel for aarch64 from an x86_64 machine in order to make a custom installer for my Pinebook Pro, and I stumbled upon something kinda strange that's presenting a road block for me. It looks like --target=aarch64-linux-gnu and --system=aarch64-linux produce derivations with different hashes? Why is this? Can I somehow force the installation image I'm creating to use a specific store item to get <ElephantErgo>around this? I'm not able to use --system to emulate compilation in a decent amount of time, but I've had a successfull compilation using --target, so I'd like to use the --target derivation if I can <ieure>ElephantErgo, This is a known issue. I *think* (but don't know 100% for certain) that `guix deploy' may help here. Otherwise, you have to build on aarch64 hardware (slow, if you have a PineBook), or under QEmu on amd64 hardware (also slow). <ieure>ElephantErgo, I believe the hash differs because the package has a cross-compiler as input instead of a native one. <ElephantErgo>ieure: I was thinking it had something to do with the cross compilation itself making it a different (but equivalent) package. That makes sense. Thank you <ieure>ElephantErgo, Package hashes are hashes of inputs, not outputs. <ElephantErgo>I'll have to take a look at Guix Deploy. I did manage to get *a* Guix image to boot on the PineBook, but I am getting the impression that I can't get the internet working even with a wired connection? I'll have to fiddle with that route a bit more <ElephantErgo>ieure: Interesting! I did not know that, that's good to know. I ought to lurk in here more ๐ <ieure>ElephantErgo, Hashes have to be of inputs, otherwise substitutes wouldn't work. The hash is the key used to look up the substitute, if you have to build the package to know the hash, that defeats the purpose. <ElephantErgo>That makes a ton of sense. That also makes it really make sense that it'll hash differently, then! <ieure>ElephantErgo, I haven't run Guix System natively on aarch64 (yet), but my assumption is that networking should be the same as amd64, so wired should be fine, as well as USB dongles that don't require firmware blobs. <ieure>I don't think the PBP has an Ethernet port, though? <ElephantErgo>It doesn't itself, but I was connecting a dock intended for the PinePhone. I was getting blinking, but no packets coming through when I pinged Google <ElephantErgo>I might be missing something I needed to do to initiate connection, though. Any thoughts? <ieure>ElephantErgo, Depends on what services are in the image, if you have a desktop env, you should have network-manager, which will bring the connection up. <ieure>network-manager should autoconfigure when the Ethernet cable is plugged in. <ElephantErgo>OH, you're right! The last time I tried I didn't have Network Manager, but the current image I have does! Let me give that a shot real quick ๐ <ieure>ElephantErgo, nmtui will configure network-manger from a terminal, if you do have nm, but don't have a DE. <ieure>You *may* need to create a wired configuration there. <ElephantErgo>BINGO! ๐ It created itself, and pinging google 100% works!