IRC channel logs

2026-06-11.log

back to list of logs

<FuncProgLinux>For the guix common lispers, do you use guix itself to develop projects or roswell is the recommended for everyone? opinions/experiences from the guix side appreciated :)
<ieure>FuncProgLinux, I don't have a solid answer, but since Roswell is a dependency installer type thing, my inclination is that Guix folks are more likely to use Guix for that.
<gabber>is it possible to use the commit id of a PR as argument for --commit somehow?
<ieure>gabber, Sure, why wouldn't that work?
<gabber>idk! i tried with --commit=8d19456c1703ffde8335c9bb88e778b381b8449b refering to PR 9232
<gabber>but no luck
<gabber>Git error: object not found
<loquatdev>Hello, everyone! Just wanted to say thanks to everyone who's answered my questions recently. I wrangled Guix into booting on a Raspberry Pi Zero 2 W.
<loquatdev>It's an image record that can be flashed to the microsd card, with the option to boot over USB for debugging / iteration.
<ieure>loquatdev, Care to share? This is a thing I also want to do.
<ieure>gabber, Okay, I see, I misunderstood your question. You need to `guix time-machine -C 8d19456c1703ffde8335c9bb88e778b381b8449b -- build guile-osc'.
<loquatdev>ieure: I'm still cleaning up the code but when I publicly upload the repo I'll post the link here :)
<ieure>loquatdev, Alright. I eagerly await it.
<ieure>Hopefully it also works on the 0W/3B/4 ones I have kicking around, or can be fairly easily adapted.
<loquatdev>It should be relatively simple. The hardest part was configuring u-boot; I had to spend a while digging through the menuconfig to get the right settings. Specifically, getting USB gadget mode working.
<loquatdev>I should note it doesn't chain bootloaders like the upstream raspberry pi example does. It uses u-boot / extlinux directly.
<ieure>That's fine.
<gabber>ieure: nah, that don't werk
<apteryx>anyone knows what "[...] the current field definition" means in modify-json-fields? I expected it to be the current value attached to the json field, but it looks like it's the same as the key (field name string)
<dajole>What's the proper way to untar a downloaded binary .tar.gz in a package definition for use with `copy-build-system`? I was trying to find an example of a simple package that uses a similar approach but haven't been successful thus far.
<dajole>(perhaps I'm not searching for the right things, though; or perhaps this is simply the wrong approach; still learning how to package stuff)
<dajole>Ah, if I understand correctly, this is already handled in the `unpack` phase of `gnu-build-system` from which `copy-build-system` seems to be derived. Still a bit hazy about how that works, though.
<czan>That sounds right to me.
<apteryx>dajole: yep
<yaircul>Is GNU Guix developed with the Domain Driven Development paradigm in consideration?
<efraim>ugh I forgot how to run go tests using gccgo
<reyman>Hi !
<reyman>We try to replicate something using guix on fedora, it works on native guix system, but we have problem with certificates , cloning dont't works.
<reyman>so is it possible to set env variable before using git-reference ?
<reyman>to set check ssl certificate to false ?
<reyman>so is it possible to pass option to "git-reference" to desactivate ssl test during packaging
<futurile>morning all
<ste5e>Good morning
<loquatdev>Hello. How do I get into a shell with an aarch64 cross-compiler? I know I can build things with it using --target=aarch64-linux-gnu, but I'd like to test some things from a `guix shell`.
<yelninei> For simple things -e '((@ (gnu packages cross-base) cross-gcc-toolchain) "aarch64-linux-gnu")'. For more complicated setups Ive used Rutherthers cross-shells
<csantosb>loquatdev: for a shell, `guix shell -C -e '(use-modules (gnu packages cross-base))(cross-gcc-toolchain "aarch64-linux-gnu")' coreutils which`, for example
<csantosb>yelninei: Mind developing about Rutherthers cross-shells ?
<yelninei>csantosb: https://codeberg.org/Rutherther/guix-cross-shells . I used it to get an environment that is suitable for cross compiling gcc itself where you need a functional native and cross compiler
<csantosb>Great, thank you !
<Ghil>Quick question, I packaged the nordzy cursor themes, but I'm not sure where to put it? gnome-xyz has plenty of themes, and the bibata cursor theme is in there, but only that one, so I am not so sure they belong there.
<Ghil>Also the file isn't alphabetized I don't think?
<futurile>Ghil: I would find the location of other themes if you can (it helps avoid us packaging something more than once). Not all files are alphabetized - if it's not, put your package close to another one that is similar (and not at the end of the file if possible)
<Ghil>I searched and there are very few cursor themes, the closest match was bibata and it's in there, so I did put it there.
<Ghil>I put it next to an n entry, the first one, so it helps a bit
<Ghil>Welp, I did it, and I'm hoping I did everything right!
<futurile>Ghil: great! first contribution?
<Ghil>It is! I'm learning as I go along slowly, I just wanted to package something to get me used to the process, I'm new to programming things, very new to Guix, it's very fun. I love Guile.
<divya>Ghil: Really glad that you are enjoying and contributing.
<Ghil>Yeah I was getting used to NixOS after 2 years, but had never contributed anything, I'm a hobbyist, so no dev background. Plunged into Guix because of Emacs (natural progression haha) and now I'm learning a real programming language. The config part of Guix is so fun
<cdegroot>Yeah, I switched (although at work we still deploy with NixOS) because I didn't really like the Nix language, Guix is so much cleaner. But, to be honest, both outshine any other Linux distro in existence, so it's splitting hairs vs, say, comparing to Debian or Fedora :)
<ieure>Ghil, Emacs Lisp is a real programming language! It's honestly a pretty decent one.
<divya>:100:
<Ghil>But I didn't learn it yet! I went the Doom-Emacs route and then started hacking together my config from other people's configs. I'm getting my bearings in it, did a few things here and there, but I'm hoping to learn Guile and it rubs off on my ability to learn elisp. Or by the time I'm truly good at Guile, we'll have a version of Emacs running on it (as if)
<cdegroot>It's pretty simple to switch around. I use CommonLisp, Guix/Guile, and Emacs and hardly ever mix them up too badly :-)
<Ghil>haha I'll get there someday :P Lisp is very nice, so I think I'll stay in that bubble for a while
<untrusem>Ghil: I reviewed your pr just now
<Ghil>Oh! 1) Thank you very much! and 2) I will need help to separate them indeed hahaha.
<Ghil>For the indentation, I ran Guix Style on the whole thing before submitting. How do I fix that?
<Ghil>Sorry for the newbie questions :)
<ieure>Ghil, All good.
<untrusem>ok which editor are you using?
<Ghil>Emacs! :P
<untrusem>ok that makes it easy!
<ieure>Ghil, To split the commits, open Magit at your working repo, enter `X x HEAD^ RET' -- this will erase your commit and move its contents into your local changes. Stage one package, commit it, repeat until all the added packages have their own commit. Then forcepush back to your PR source branch.
<untrusem>Ghil, ieure: can you also state the same questions in codeberg? it will make it easy to follow in the future.
<untrusem>ieure: they could use committer.scm
<ieure>untrusem, Never heard of it.
<untrusem>in etc/committer.scm
<untrusem>it automatically makes a commit for you
<ieure>That's cool. I had no idea.
<Ghil>I did ask the questions, as well checking in because that indentation problem isn't one of my lines.
<Ghil>commiter? Is that an Emacs thing or a Guix thing?
<ieure>Ghil, Guix.
<ieure>Emacs things don't have .scm file extensions.
<Ghil>Very true :P haha thank you
<untrusem>> Ghil, To split the commits, open Magit at your working repo, enter `X x HEAD^ RET' -- this will erase your commit and move its contents into your local changes. Stage one package, commit it, repeat until all the added packages have their own commit. Then forcepush back to your PR source branch.
<untrusem>there is not X `x` ieure
<untrusem>Ghil: I will share the procedure in a small writeup
<Ghil>I will be waiting, don't worry I'm not pressed for time or anything if it helps. :D
<ieure>untrusem, Sorry, `X s'
<Ghil>Thank you though :)
<ieure>"Soft reset" is what you want.
<Ghil>Would that erase the comments in the commit ieure? I was thinking about it, we took the time to document it properly on the commit
<identity>Ghil: you can just grab the message and put it somewhere else, meanwhile
<ieure>Ghil, I think Magit prepopulates with the last commit's text, but if not, M-p will bring it back.
<Ghil>Thank you! I am checking my commit and realizing there where some indentations that happened when I saved that file. So there's a lot of commit changes I need to remove. Then I'll split everything
<untrusem>its probably better if you just save all the package definitions in another scheme file and just discard the whole gnome-xyz.scm file and add again one by one
<untrusem>Ghil:
<Ghil>Okay but I'll still have to do this, it formats on save I think.
<untrusem>what the whole file?
<ieure>Ghil, Turn that off then, it'll be in before-save-hook.
<Ghil>Yeah, I checked, there's a lot of hunks in there that just got indented when I saved in emacs.
<ieure>Ghil, FYI, this is not default behavior, it's something you have turned on in your configuration.
<Ghil>Yeah, that's for sure. I liked it because it formatted automatically my code, but man, that will be a nightmare in PR land haha
<ieure>Yes, it is inadvisable for a variety of reasons. I have a guard in my configuration, if user-full-name or user-mail-address is in the header of the file, it cleans up formatting, otherwise it leaves it alone.
<untrusem>do you have committer.scm in etc/ directory?
<ieure>Anything else caused too many problems with the filthy non-Emacs knuckle-draggers at work.
<Ghil>I don't have commiter.scm
<untrusem>I see you have not done the bootstrap and configure bit
<untrusem>I closed my thinkupad, but there is a chapter about this in info manual
<identity>forgot about M-p for commit messages, vc.el does that too
<untrusem>Ghil: for now do it as you are able to, there are many ways to do the same thing, you will just get confused
<Ghil>I will do that, it'll get me used to magit and it's a learning opportunity :D
<untrusem>cool :D
<dcunit3d>is there a discussions feature on codeberg? to discuss potential packages?
<untrusem>dcunit3d: nope
<untrusem>Ghil: did you copy the packages to a new file?
<dcunit3d>i have some stuff that's building from source
<Ghil>I removed every hunks that wasn't in the original, I'm in magit making the split right now!
<Ghil>every hunk that was a formatter error, sorry
<untrusem>ok
<untrusem>Ghil: do you use snippets in emacs like yas or tempel?
<Ghil>no I don't, what are those?
<untrusem>ok there are two ways to automate commit message writing. the committer.scm and snippets
<untrusem>you can take a look at etc/snippets in the guix repo
<identity>Ghil: templates
<Ghil>That would be useful, because now I'm hitting something. Emacs tell me the commit message line is too long. Will that be okay anyway? Or should I do two lines?
<Ghil>gnu/packages/gnome-xyz.scm (nordzy-cursor-theme-nord): New variable.
<Ghil>I was using the comment of a previous build, to standardize
<untrusem>basically once you have staged a change and you do c c to commit you can just write `add` do completion command and it will automatically fills the necessary info for you
<identity>Ghil: just break the line
<Ghil>Will do!
<Ghil>And I'll setup commiter.scm for the next time!
<untrusem>Ghil: you snippets that way, you don't have to manually write messages basically less error prone
<Ghil>Yeah that's really useful
<untrusem>I oughta write a blog post about this
<Ghil>Those snippets are wonderful :D
<dcunit3d>what does a "quota exceeded" mean on forgejo? also, when submitting a PR, do i target a team's branch?
<dcunit3d>here, i'm trying to PR libtpms and swtpm into gnu/packages/security-token.scm
<dcunit3d>that would go to the crypto team, right?
<ieure>dcunit3d, etc/teams.scm is where the file-to-team ownership mapping lives. There may or may not be an active branch for the team's work.
<dcunit3d>if there is, should i PR into that?
<ieure>dcunit3d, You need to ask the team.
<dcunit3d>and i guess i should be working in that branch as well?
<dcunit3d>ok
<ieure>dcunit3d, Stuff generally PRs into master, branches are usually used for longer-lived work or stuff that will cause a lot of rebuilds.
<dcunit3d>ok, got it
<dcunit3d>i'm trying to clean up my dotfiles lol and i have some things still not in guix
<dcunit3d>how do i contact a team?
<ieure>dcunit3d, The members are listed in etc/teams.scm, I believe emails are included, if not, they'll be in the copyright headers of relevant source.
<ieure>Or you can email guix-devel.
<Ghil>So now that there are five commits, do I force push to remove the old one?
<untrusem>yep
<Ghil>Okay! five new commits. I create a PR for each one? making sure haha
<Ghil>ACTION retracted a previous message, but it's unsupported by your client.
<Ghil>Okay no I saw sense, they have been added to the PRs, everything seems good now
<dcunit3d>can we push to agit refs? i can't seem to update my guix fork (i didn't really want one, but i assumed it was required for PR workflow)
<simendsjo>ieure: I spun up Nextcloud now, and while it works, it very slow. What tricks have you added? Redis?
<dcunit3d>if i don't really care to have copyrights, do i need to worry about signing commits?
<dcunit3d>i had assumed that someone would manage my commits & reauthor them. is that a fairly standard thing?
<ste5e>simendjso: redis helps, nextcloud:fpm is supposed to help, but Nextcloud is pretty slow no matter...
<cdegroot>dcunit3d: you own the copyright to your work regardless of what you do. Commit signing is a trust thing. "dcunit3d _actually_ authored this".
<dcunit3d>but if i just want to contribute a few packages, i don't need to sign an agreement do i?
<dcunit3d>all the work is my work. i don't use AI except to ask questions sometimes. i certainly wouldn't use it on this project. (guix import is already far more useful IMO)
<dcunit3d>and all in all, it looks like i can't afford LLM lol.
<cdegroot>if you want to contribute, you need to play by the rules, and commit signing is probably in the rules (and for most FSF-"owned" projects, signing some paperwork as well, for very good legal reasons).
<dcunit3d>i stopped doing that on most of my projects, but i can set it up in the .git/config
<cdegroot>(by assigning your copyright - that you own whether you want it or not - to the FSF, they have a much easier time in court when needed as the sole copyright holder)
<dcunit3d>i see. i know. that's very important IMO
<cdegroot>General advice: only sign contributor agreements with trusted non-profits. You decide what non-profits you trust ;-). Commercial entities invariably end up screwing you over.
<identity>see also <https://drewdevault.com/blog/Dont-sign-a-CLA/> <https://drewdevault.com/blog/Dont-sign-a-CLA-2/>
<ieure>simendsjo, Hasn't been slow for me at all. I didn't do anything special.
<cdegroot>identity: yeah, I agree with him but I still carve out exceptions for well-respected non-profits. Each to their own. As long as you don't sign them with corporations that you don't fully own :-)
<simendsjo>ieure: Maybe I'm just expecting it to be faster? Pressing "Recent" files takes ~1 second to update completely.
<mwette>I seem to have lotsa stale /gnu/store/*.lock files. Use `rm' or other?
<dcunit3d>mwette: check `guix gc --list-failures` or --list-dead
<dcunit3d>hmm nevermind, that didn't do much for mine
<dcunit3d>i think they get removed on `guix gc`, but if you're actively building that can slow you down with repeated work
<mwette>dcunit3d: thanks -- `--list-dead' gave some ; I decided to `guix gc' which cleared them.
<mwette>I'm trying to add intro/authen to my file:/// based channel dir. `guix git authenticate' returns "sucessfully authenticated ..." but `guix pull' says my channel 'is not trusted'. Any ideas?
<mwette>in channels.scm: https://paste.debian.net/hidden/c1ab4fc8
<ieure>mwette, Do you have a .guix-authorizations file? like https://codeberg.org/ieure/atomized-guix/src/branch/main/.guix-authorizations
<ieure>I believe you also need a keyring branch with your key on it... Though if `guix git authenticate' passes, I think that's already set up.
<mwette>ieure: yes: https://paste.debian.net/hidden/895b5b12
<mwette>I have the keyring branch. I assumed `guix git authenticate ..' would catch if not
<ieure>mwette, And is eb30a7196b486b4cecd7b25e0861e77699b3c995 the first commit in your channel?
<mwette>It's not the first commit, does it need to be?
<ieure>I believe it does.
<mwette>But I've used older commits, unauthenticated, to build packages.
<ieure>How?
<mwette>I did not include "introductions" form in channels.scm. guix pull would generate warnings but builds always went through.
<mwette>I'm using 1.5.0 on another machine and that approach does not seem to work.
<mwette>(Or I have something else wrong.) So now I'm trying to set up the authentication machinery.
<mwette>Does every commit to the channel need to be signed?
<mwette>(I'm starting over with a fresh repo. I signed the first commit.)
<ieure>mwette, Yes.
<ieure>Unsigned commits (or commits signed by a key not in the keyring) will make `guix git authenticate' and `guix pull' fail.
<ieure>Unless you disable authentication.
<dcunit3d>ok wow the agit thing is very nice https://codeberg.org/guix/guix/pulls/9248
<mwette>ieure: Thanks. Still struggling. I started all over and then git decided to use my subkey this time, so my fingerprint is not good anymore, and changing them in channels.scm and .guix-authorizations does not help. This w/ aarch64 and snapdragon is a nightmare.
<ieure>mwette, It took me a few attempts to get mine set up, it does suck. At least it only needs to happen once.
<mwette>I can't get it to work. I don't know where I need to use primary vs subkey.
<ieure>mwette, I believe you need to use the signing subkey everywhere.
<ieure>(I might be wrong)
<ieure>Feel free to poke at my channel, you can import my public key and see which one the channel metadata refers to. The same key ID is used everywhere.
<mwette>ieure: thanks for all the help; I'm taking a breather
<ieure>Yep, no problem.
<Ghil>This is a question, not a bump request :P When I make changes to a PR, do I need to do something else apart from replying to the threads?
<ieure>Ghil, Assuming you're already pushing the changes; no.
<Ghil>I did, so I'm fine :) Thank you ieure!