IRC channel logs
2025-07-12.log
back to list of logs
<eikcaz>wowzers, first time dealing with forge-style merge requests. I thought I'd be nostalgic for mailing-list style, but this is nice. <luca>Hi, are questions regarding packaging of non-free software allowed here? (even if they won't be added to upstream guix) <ekaitz>luca: questions about packaging are allowed <ekaitz>they are just usage questions... if you want to use that for nonfree software that's your problem :) <identity>#nonguix may be more appropriate depending on the specifics <ekaitz>luca: your anubis is preventing me from opening... <luca>I'll add an exception. Still fine tuning these stuff <ekaitz>i'm being flagged as a bot everywhere <identity>luca: iirc VVVVVV is packaged in the guix gaming channel <luca>hmmm. I am also using librewolf and it passes right on through. Maybe some extension like ShelterJS?ke JS Shelter? <luca>identity: I can't find it <luca>also sorry for the letter spaghetti there. JShelter <ekaitz>this-package-input has to be in a gexp afaik <ekaitz>#~(...) + #$(this-package-input ...) <ekaitz>there are many packages that use it arguments <luca>To be completely honestl, I still don't _get_ it. But it helps that there's a ton of examples in guix.git <ekaitz>luca: i'll explain it in the less accurate way possible (hehe) <ekaitz>the #~ acts like the `, it creates a piece of code where everything is quoted by default, but some parts can be expanded <ekaitz>that expansion is going to convert whatever you give to it to a "path" <ekaitz>but for that, the #~ has some magic attached, that's why you need it <ekaitz>(it uses the store monad and so on, if i'm not mistaken) <luca>So (extremely oversimplified) #~ quotes everything, but not everything can be quoted and these need to be given #$ ? <luca>Awesome, I'll take a read <ekaitz>luca: not really the #~ is adding context to the expression you add it to <ekaitz>now we are talking about gexps i have a question! <ekaitz>what is preventing me from using #$package-that-is-not-a-dependency in some phase? nothing. But that will make the package to be installed. <jlicht>installed as in, available in the store? and referenced subsequently? <csantosb>You mean a random #$emacs in a phase will pull emacs and propagate it into the profile !? <jlicht>because I don't think that it would be treated as a propagated input. <ekaitz>csantosb: no, it wouldn't propagate it, but will create it and put it in the store <ekaitz>so, somehow, it would be an "input" <ekaitz>and I'd be able to reference to its contents with #$ <ekaitz>so... somehow to me is weird, because it's not enough to read a package's inputs to know what it installs with itself <csantosb>I'm wondering what if you use `package-inputs`; does this appear as an input ? I don't think so. <ekaitz>csantosb: feature probably, but... hmmm <apteryx>that issue had to do with an outdated e2fsprogs IIRC <untrusem>What's a good way to run #HomeAssistant on #guix? <luca>If it's not packaged then probably docker <luca>Does anyone know it it's possible to install-file with a different name? In particular I want to take an input (with a mangled name from the store) and put it in package output with another name. mk1dk1x03546ylw4l5wwv83n87ddjaxa-data.zip -> data.zip <luca>or maybe this is the wrong way to go about it and the program should use the mangled up name <ekaitz>luca: you can use copy-build-system and give it an install plan <luca>Really just a good excuse to learn more about guix packaging :D <ekaitz>luca: for that you could use (substitute* ...) and make the change with it <ekaitz>maybe your solution is better, but as you are using this as a "good excuse to learn more about guix packaging"... <ekaitz>`substitute*` lets you use a regex to replace a part of a file <luca>ekaitz: coming from void linux there it's not really a good idea to use substitute* (or sed) as it makes it less clear what exactly you are changing. So patches are preffered (of course "it depends"). If I was a bit better at regex I think subsitute would be ok here as well. But in this case it looks like I have to change 2 lines instead of just one <luca>But it is also important to learn what guix users would do in this case! So thanks for the tip <vntsuyo>what can I do to prevent Guix from rebuilding all system packages every time I do system reconfigure if I do garbage collection very often? <futurile>vntsuyo: you see it building grub or something, what do you mean build system packages? <futurile>vntsuyo: you should see it say it's activating the profile and then it restart the services <futurile>vntsuyo: if you see it do a guix pull every time, then maybe a problem in your config where you're using something that doesn't cache (e.g. guix-for-channels) <luca>Anyone know how I can tell guix NOT to delete the build directory after it fails? <luca>guix build --keep-failed <csantosb>luca: 9.1.4 Debugging Build Failures gives a nice example about how to reproduce the build env <sneek>Welcome back ekaitz, you have 1 message! <ekaitz>csantosb: yep, it's a feature but feels odd too <ekaitz>i think that's why it makes sense to use this-package-inputs <bhoot>Its been a week. What are the general etiquettes followed for guix contribution? Should I tag someone from team-ocaml in that PR? Or should I patiently wait for someone to get to the PR on their own? <ekaitz>bhoot: the ocaml team has been notified, as they are the "owners" of the file <ekaitz>we have less commiters/reviewers that we'd like to <bhoot>Oh. As long as they've been notified, its alright. <ekaitz>i just looked at it diagonally and feels palatable, but it's several commits and I don't have the time to review it in detail <bhoot>That's fine. Thank you for taking a peek. I can wait. <bhoot>In the meantime, if I wanted to make use of such packages locally, would the best way be to add my local guix repo as a channel in channels.scm? <ekaitz>you might prefer to use a separate channel <ekaitz>bhoot: it deosn't have to be the Guix repository, it's probably better to have just a simple channel <untrusem>yay bhoot, you are now contributing, 😌 awesome <csantosb>bhoot: as another option, just expand your $GUIX_PACKAGE_PATH with the path to the module containing the packages <bhoot>ekaitz: So I followed the Contributing guidelines, and added my PR package in my guix fork. Putting it again in a separate simple channel would again be more work. <bhoot>What I would love to have is that I keep submitting new packages but now have to wait for them to be approved and get merged in the official guix repo <ekaitz>bhoot: I maintain a channel for myself, I just copy-paste things. But yeah, you could do what csantosb suggests <bhoot>thank you. I will try out your suggestions <csantosb>My approach: keep a local scm file with your updates, and use it as usual; then, when merged in guix, just remove the packages from it <ekaitz>bhoot: thank you for your contributions <bhoot>untrusem: thank you! yes I have another one in pipeline - kdesrc-build, to see if I can get a kde development workflow running on guix. but that one seems to be a long road. <bhoot>csantosb: so when you make a PR, do you copy-paste the new package into an appropriate module in guix repo? <csantosb>Yes, as a simple example see #1101; I've been using it for a while in a local csb.scm file. When I'm happy with it, I submit the pr. When accepted, say in one month, I remove it from the csb.scm file. <csantosb>No need to wait for the pr to be accepted to use it, I mean <bhoot>csantosb: cool. that works too. 