IRC channel logs
2026-01-16.log
back to list of logs
<Wurt>Hi, is the guix/mentors group very busy? I would love a review of my first pull request, but I understand that everyone has limited time. How long should I wait before pinging for a review? <gabber>Wurt: do you want an interactive review (here)? <Wurt>gabber, I would love that. Thank you! <gabber>the complete restructuring of the package is somewhat unfortunate, since now the whole package looks different (and is marked as such in the diff) and not just the parts you actually changed. <mange>You can change the "ignore whitespace" option in Codeberg (up top, next to the "files viewed" text), but I agree the restructure is unfortunate. <gabber>mange: thanks! i was not aware of that! <mange>Was there a good reason to change from the git repo to a tarball? In the past Guix has opted for tarballs as the primary source, but I don't think that's the case any more and git repos are becoming more commonly used. <gabber>mange: are you doing the review now? <mange>Review is too strong a word. I was just looking at it. <gabber>it's all good, i just don't want to state the exact same things you do, only seconds later (: <Wurt>I think this issue arises because the previous version has an "unnecessary" 'let', gabber. Do I need to make a change? <gabber>you move the definitions of the let into the package, but that does not really make the package more readable. especially lines 1149-1151 <gabber>i'd leave as much of the package for the update (only bump the version, the hash and fix the /usr/bin thing) <gabber>and put cosmetic changes in a second commit. converting from quasiquotes to g-exps, indentation and (if necessary) getting rid of the let <Wurt>I change the fetch method too. I will rewrite the changes in two commits, thank you! <gabber>WDYT? i can see that you change it, but i am not sure why that would be necessary or wanted (from a Guix project perspective) <Wurt>I read other pagure.io packages that fetches from an archive, so I think that could be better. I tried to explain that I the pull request message (maybe I wrote that in a wrong place). <mange>There's exactly one other, right? newt? <gabber>Wurt: i read the reasoning in the commit message, but even with that reasoning, the change does not really add any value. as stated above, we have an slight, implicit preference for directly fetching the sources from the repositories <Wurt>Okay, I misread you. Thanks again, mange and gabber, for the review; I hope I can write many more commits for Guix. <gabber>Wurt: thank you for your time and effort! and i have absolutely no doubt that your contributions will land and improve Guix for good! <RavenJoad>I just packaged rassumfrassum, Joao Tavora's (the author of eglot) answer to Emacs' eglot only supporting one LSP server per-buffer. Would it make sense to highlight that fact somehow in the description? If yes, how? <RavenJoad>Particularly for "guix search eglot" support. <apteryx>can't seem to C-c an eval/container job <Wurt>I think I messed up my pull request by force-pushing the wrong commit. Could someone help me fix it (#5597)? I'm considering creating a new PR. <RavenJoad>Wurt: Couldn't you just hard reset back to the old commit from before your force-push then apply your new commits on top of that? <Wurt>RavenJoad, I panicked and already created a new PR. However, the original PR was merged (even though it contained zero commits), and I don't think I can re-open or reuse the same PR. <RavenJoad>Wurt: The PR was "merged". I _think_ it says that because the commit you force-pushed to was already in the repo. I don't think the PR was actually closed. <Wurt>RavenJoad, the old PR and the new PR share the same branch. Or maybe I do not understand you. <RavenJoad>They share the same branch. But I'm thinking the "merge" snapshotted the page somehow. I honestly have no idea. I don't know how Codeberg handles this kind of situation (nor do I know everything that happened). <ieure>The Guile tooling for Emacs is so bad. :( <ieure>Example: I'm hacking on gnu/services/monitoring.scm. C-c C-k to load/compile the module prints a warning, "warning: 'go-github-com-prometheus-node-exporter' is deprecated, use 'prometheus-node-exporter' instead." <ieure>If I C-c C-k again, Geiser breaks with: "In procedure port-column: Wrong type argument in position 1: #<closed: string 7fea5fa2e4d0>" <ieure>Irrecoverable, you have to kill the REPL and start over. <ieure>Perhaps it is the Guix deprecation warning code which is bad. <mange>If I start a REPL by just doing C-c C-k in services/monitoring.scm (and answering "yes" to the prompt), then I get the same error on each C-c C-k. The REPL doesn't break, though. <ieure>mange, Error or warning? There are no errors, only a warning. <mange>This is an error, isn't it? "In procedure port-column: Wrong type argument in position 1: #<closed: string 7f540522e4d0>" <ieure>The REPL continues to work, but the file you're hacking on does not load into it. <mange>Oh, yeah, of course - because the compilation has failed (while trying to print a warning). <ieure>I don't really understand Scheme error handling, but it feels like this stuff shouldn't be printing at all. If this were CL, I'd be signaling a condition and the CLI tooling would have handlers for those which print to the console. I assume Scheme has to have something similar. <mange>Common Lisp's "signal" (as opposed to "error") is pretty unusual in the language landscape. Not many languages have a way to signal up the stack "something happened - please handle it, but I'm continuing anyway". <mange>You can implement something yourself, of course, but Scheme doesn't have it in the standard. (There might be an SRFI for it somewhere.) <mange>You don't have to sell me on Common Lisp, I'm already on board. :) <ieure>I'm not sure how it all works, but I do see that (rnrs condition) exists and has a &warning condition. Guile docs aren't clear on whether this unwinds the stack or not, but it seems like surprising behavior to unwind for a warning. <ieure>Mm, I guess since you're supposed to (raise) those warning conditions, they likely do unwind. <mange>I think warnings are continuable exceptions, so you can use raise-continuable? There are also non-unwinding exception handlers according to the manual, but I'm unfamiliar with them. <ieure>Yeah, I'm still learning Scheme. It is my least favorite Lisp so far. <ieure>(Out of Emacs Lisp/Clojure/Common Lisp) <mange>That's unfortunate, but I kind of know what you mean. I do think the Scheme tradition branched off from those other lisps a fair while ago, and generally made this more "fixed". I feel like those lisps embrace polymorphism and their dynamic nature at runtime a lot more than Scheme does. <ieure>Never had these problems with SLIME, CIDER, etc. <ieure>Scheme stuff feels so fragile. :( <apteryx>(set! gradle-project->cache.json gradle-project->cache.json) fixes it <bdju>Hm... I did pkill -9 on adb and fastboot in case there were any stray processes and then did `sudo adb devices` and that seemed to work. Not entirely sure what happened there. <bdju>I also had this in dmesg: 2026-01-16T04:15:13,085091-06:00 adb[21944]: segfault at 103f57cd ip 00007fedba4b2722 sp 00007ffc49b6ed90 error 4 in libc.so.6[a0722,7fedba43a000+15b000] likely on CPU 3 (core 1, socket 0) <bdju>I guess it's working now, so whatever. <apteryx>bdju: if you have the android-devices-udev package or similar extending your udev-service-type, you shouldn't need sudo <bdju>Yeah, I realize that I shouldn't need sudo, but in practice I've never been able to get that working. <bdju>I've got some udev-service-type thing in my config with android-udev-rules that wasn't working that I commented out years ago. <bdju>Oh, neat. Maybe I'll give that a go then. <apteryx>I'm using a desktop config so the snippet modifies the existing services <bdju>I kept service in front of udev-service-type but tried copying the rest of what you had, I don't think that config => bit is gonna work in mine. <apteryx>(serivces (cons* service1 service2 ... (modify-services %desktop-services x))) <bdju>This seems like it's gonna be a huge pain. I'm just gonna comment it out and keep using sudo. Thanks anyway. <apteryx>there's also a way to use simple-service to extend udev-service-type more simply, I think that's what the manual shows <elevenkb>Is there any way to run guix shell in a guix home container? <Wurt>Hello, what are the criteria for adding a package to (gnu packages xdisorg) or (gnu packages wm)? I want to write a package definition for Wayneko, a Wayland add-on that creates a virtual pet on your desktop that follows your cursor. <untrusem>does guix foundation have plans to participate in gsoc? <ekaitz>sneek: later tell futurile please ping me later if you are here and want to talk <yelninei>does someone familiar with cvs know how i can find out the revision to use with cvs-fetch? HEAD works but is not deterministic <RavenJoad>Is there a reason why Pandoc is so old? 2.19.2 in Guix was uploaded in 2022. I just wanted to check before I attempt to update it for my own channel. <ieure>RavenJoad, Yes, last meeting of The Cabal, we all agreed to leave it at the old version, specifically to annoy you. <cbaines>there will be a reason, but it might just be that it has quite a few dependents and there's not really a process for keeping packages up to date at the moment <dariqq>i never encountered test failures because of a buggy testing framework before <dariqq>but surely there has to be a better way to detect a 64bit integer type than only checking int, long and void* <ieure>RavenJoad, There are 30k packages in Guix, and 102 committers. Best case, 294:1 package:committer ratio. Unless one of those 102 people has a need (or sees/reviews/pushes a PR from a user with the need), stuff doesn't get updated. <ieure>This is the fundamental answer for the overwhelming majority of "is there a reason X is Y?" question around Guix. <RavenJoad>Ok, that's what I thought. I was worried about some technical reason around Haskell packages changing how they did things or needing to change. I can just update it in my own channel then. <ieure>RavenJoad, Why not send a PR? <RavenJoad>Right now, one problem at a time. I want to see how hard it would be first. <RavenJoad>Once I figure out how much work it would be, then yes. I would like to submit a PR. <jmcf>Hello! I am currently considering migrating over to Guix from NixOS and, after my research, I have two questions I would like some clarification on, if possible: <jmcf>1. I am currently using an impermanence (root on tmpfs) setup. While I have found some example configurations using a similar setup on Guix, which suggests it is possible as well, I would like to know what the minimum persistent file set would be. For instance, on NixOS, it is sufficient to persist /nix for the system to boot, with other files <jmcf>being required only as the user desires. Would /gnu be sufficient for Guix? I have seen /var/guix being included in these configurations, is that also a requirement for booting? <jmcf>2. Are 1.4.0 and latest analogous to NixOS' versioned (eg. 25.11) and unstable channels? <Rutherther>/var/guix is not a requirement for booting, but it is a requirement for using Guix itself. It stores the database, gc roots and all :) Nix has that in /nix/var. I mean... pretty much everything in /var should be persistent, that's what that folder is about <Rutherther>no, 1.4.0 is by no means analogous to any channels. It's just a tag that doesn't change. Guix releases are mostly meant for installation and they are not maintained. The release is made and stays the same forever <Rutherther>I would expect only /gnu/store and /boot being required for the boot itself, but I have not tested that <jmcf>Ah, I see, so really, persisting /nix is already inherently including the database/gc roots, Guix just stores them separately. <jmcf>So 1.4.0 and so on are more analogous to the Arch Linux install images, which are just based off of a particular commit. <Rutherther>jmcf: Yes! And those commits are generally better tested than the other commits <jmcf>Thank you for the information, I'll go back to tinkering :) <Wurt>What are the criteria for writing a package for (gnu packages wm) or (gnu packages xdisorg)? I want to package Wayneko, a little program that shows a little pet at the bottom of your Wayland desktop. Is this the correct place to ask about this? Or should I write a Codeberg issue? <cbaines>Wurt, maybe put it by oneko in the toys module <cbaines>finding exactly the right module doesn't really matter though, that can be discussed at the review stage <Wurt>Thank you, cbaines. I think the toys module would be a better fit in this case. <civodul>Rutherther: hey! is everything on track? <Wurt>I noticed that in some modules, the packages are not sorted lexicographically. Is there a reason for this? <Rutherther>civodul: Hi, I think pretty much yeah. I have pretty much cleaned up the 1.5.0 milestone, only a few issues remain. And 2 of them can be removed as they're not completely critical. Not sure how the release communications are going, though. Haven't talked with Noé since last week's meeting <Rutherther>civodul: btw I am also not sure if Efraim has the access to ftp.gnu.org, got no reply <civodul>well at worst apteryx or myself can take care of uploading things <Rutherther>any ideas on who should be signing the artifacts? is it the one uploading them? the one generating? (well some of them are generated by CI, so that wouldn't be possible completely I think) <Rutherther>and I was also wondering if it's fine if the artifacts are generated on device running unfree software. Because riscv64 definitely won't be built by CI. And I am afraid AArch64 maybe also not (but maybe it could be, we will see). The devices I am able to generate the images are running Linux etc. <civodul>the person uploading them is signing them, typically with the gnupload.sh script from Gnulib <civodul>info "(maintain) Automated FTP Uploads" <civodul>Rutherther: i emailed ftp-upload@gnu.org, Cc’ing the maintainers <civodul>i nominally don’t have the authority for this, but we’ll see if it works <civodul>i basically followed the procedure in maintain.info <civodul>it takes 5mn, i don’t understand why we’re doing this late, oh well <civodul>i’ll take a look at the manual URL issue above <Rutherther>not yet, but the list is in the news issue. I am hoping Noé will do it / is doing it, and in case not, I will do it tomorrow evening <civodul>it really should be someone else, or several someone elses :-) <civodul>i mean you alone cannot take care of everything, no burnout please :-) <Rutherther>civodul: I mean I wouldn't be on the release team if I saw more actions <Rutherther>civodul: I would rather want to focus on the core work, but I think releases make sense, so I wanted to step up when it seemed there might be no release, since it was taking so long to start with it <civodul>Rutherther: sorry i lost track of this one; i thought it was “just” a matter of adding an ‘if’ but apparently it’s harder? <Rutherther>civodul: yes it is just a matter of an if :) It's just I don't think it's very clear what the fallback should be. And what platforms the fallback should be on <Rutherther>civodul: since neither gdm, sddm nor slim currently build on other architectures than x86_64 and aarch64 <Rutherther>on riscv64, powerpc64le it doesn't due to uninvestigated issues <Rutherther>the current proposal is: gdm on x86_64 and aarch64. slim on other architectures <civodul>don’t bother about riscv64 and powerpc64le: they’re not supported by Guix System <oliverD>I have this issue in Gnome where I start up and it takes 15 minutes before I can click on anything inside windows (i can still use Win+tab to go between windows). Is this just an issue with older laptops? <oliverD>Clicking other stuff like the date and time or bringing up activities/desktops sometimes works and sometimes doesn't