IRC channel logs
2024-06-11.log
back to list of logs
<freakingpenguin>Hi Guix! I'm trying to take the alias list expected by home-bash-service and reuse that same list in a custom mixed-text-file to keep aliases consistent between a different shell. This alias list contains gexps and it works fine for home-bash-service, but my mixed-text-file contains raw gexp forms and not the lowered output I'd expect. https://paste.debian.net/1319873/ <freakingpenguin>Not sure why it works for home-bash-service and not my custom mixed-text-file <freakingpenguin>I'm guessing there must be some further action I need to take before ungexping the alias list. <mange>I assume the issue is that you're using #$ to splice a regular list into a gexp, but this doesn't work recursively. If you lift the #$ to around the (map ...) and use #~(string-append "alias " key " " #$value) for the individual items that might escape things properly. <freakingpenguin>mange: Thanks! Wow, that expression looks very, very weird but it does seem to at least be closer to correct. The gexp forms are gone and I have store paths so I should be able to figure it out. <wolfdog>it'd be nice if Guix avoided computing the Guix derivation multiple times per system reconfiguration when using `guix-for-channels` inside the guix-configuration ... <wolfdog>if `guix pull` accepted an expression for channels it'd be pretty neat <wolfdog>mostly since i use different sets of channels per machine (i guess i could use the same everywhere, but i only use some of them in one machine so it feels a bit unclean) <wolfdog>i guess one can just add a file that just returns the channel set one wants to use and use guix pull with that, but it feels a bit hacky.. <wolfdog>ACTION thinks maybe this is a symptom of me overengineering my setup... <wolfdog>well seems like using `guix-for-channels` doesn't avoid the chicken-and-egg problem I was thinking of either. I need to run `guix system reconfigure` twice when updating the channels to get it to actually use the newer channels <wolfdog>sometimes I wonder if I'm making my life too complicated with this OS, but I can't seem to get away from it... <wolfdog>eh i think i'll just cave in and use the same channels list for all my machines <wolfdog>should make things marginally easier.. <mange>Also, I think your keys are just strings, right? No need to #$ them in a call to string-append. <freakingpenguin>mange: Ah, I tried using list but had problems with it looking like (list ((string-append ...))). I didn't realize I could ungexp-splice directly into a list call! <freakingpenguin>If I don't ungexp key it looks like it just inserts the datum key into the builder <freakingpenguin>mange: Thanks again for the help! This saved me a ton of time debugging. :) <wolfdog>is it normal that when removing a service from my system configuration, shepherd will sometimes hang when applying the configuration? <sneek>adanska, you have 1 message! <sneek>adanska, RoundDuckKira says: I got the dm changed successfully thanks!!!! <adanska>sneek: tell RoundDuckKira great! how did you get it to work? <sneek>RoundDuckKira, adanska says: great! how did you get it to work? <f1refly>I think something weird happened on my system. In my ~/.guix-profile/bin I have `java` version 17, which has to be provided by openjdk@17 according to `guix locate java`. However, when I run `guix package --list-installed`, there's no openjdk at all in that list! Where could it come from? <f1refly>I have run some shells containing openjdk@17:sdk for work recently, but how could those have bled into my profile? <adanska>hmm. maybe its a propogated input in some package you have installed? sounds dumb but thats what first comes to mind... <f1refly>yes, I just tried installing openjdk@21:jdk and it tells me that openjdk@17:jdk is pulled in by prismlauncher (that I just installed a few minutes ago) <adanska>f1refly: yes, i was right. You just installed prismlauncher right? it propogates openjdk17:jdk <f1refly>minecraft won't launch because the java version is too old and my project won't build because the java version is too old x) <adanska>might just have to use the flatpak launcher, then <adanska>ive never encountered this problem since im not a java dev :p <f1refly>I recommend you don't become a java dev if you can avoid it <f1refly>I'll try transforming the package to use jdk21 <f1refly>hm, I think it wants both qtbase@5 *and* qtbase@6? <civodul>ACTION attempts to rebase core-updates to fix git-manpages hash <cbaines>given it was rebased very recently, hopefully you'll encounter very few conflicts <cbaines>unfortunately the data service isn't keeping up with these frequent changes, it still hasn't started to process the revision pushed yesterday <civodul>luckily they don’t lead to many rebuilds <civodul>so that should become less and less expensive? <civodul>‘git rebase’ takes ages with all these commits <cbaines>did you have any further thoughts on #70878 civodul? If not, I might go ahead and push that, as I'm hoping it'll speed up the data service a bit <civodul>and it’s always a bit scary to me, it’s hard to see what you did <civodul>in the meantime i look into it on issues.guix, but i’d like to have a closer look in Emacs <civodul>git-fetch doesn’t have that problem though: either we use builtin:git-download, or there’s a single download builder <civodul>(commit c0b2d08bf473ccc6a95e0ed38ce966befb83c0c1) <civodul>actually 8599fccef84a2930280a5b2844829cfbafd593b0 did that for svn-fetch too <civodul>so maybe i misunderstood the goal of this patch series <civodul>oh but 264fdbcaff9c078642355bace0c61c094b3581fc broke it <cbaines>well, assuming you want the files to be the same for different hashes <civodul>right, i guess we should mention in the commit log that this restores uniqueness of the build script, which was broken by 264fdbcaff9c078642355bace0c61c094b3581fc <civodul>personally i’d prefer a minimal patch that augments #:env-vars and uses it in ‘build’ <cbaines>civodul, I think the commit message already mentions that <civodul>you can remove “I think” from the log :-) <civodul>cbaines: now that i actually wrapped my head around it, it looks great to me! <civodul>i can’t say it by email because debbugs won’t let me, but apart from “I think” :-) i’m totally fine with these changes <cbaines>great, I'll tweak the commit message and push these changes in a bit <civodul>“remote: Sending notification emails to: guix-commits@gnu.org” hmm <Guest44>If I only require Java JRE, is openjdk the correct package? <podiki>nevermind, maybe just slow at the moment (timed out but works now?) <civodul>hmm, something’s wrong with ‘guix publish’ on ci.guix <civodul>it had one thread spinning in GC_generic_malloc (from scm_make_bytevector) <civodul>i restarted it and it’s back to life but i’m not sure what was going on <icepic1984>Hey! Quick question. I posted on the help-guix malilng list two days ago. From what i can tell the mails were not forwarded. Is this supposed to happened or did i end up in some kind of spam filter? The mail address i used was freshly registered. <snamellit>I am trying to get the cuirass service running on GuixSD but I keep getting 'invalid field specifier' in the %cuirass-specifications specifications from the README or from the examples. I can start it with a gexp of an empty list. <snamellit>It is not just for cuirass, I get the same for nginx deploy hook. I must clearly lack understanding about gexp expressions. <civodul>icepic1984: this is weird, you might want to retry (the first message can take several hours to reach the list, but subsequent messages reach it immediately, at least when everything goes well) <icepic1984>civodul: ok strange. maybe my setup is broken, but on the second mail i added another mail address of moine as bcc where it successfully showed up. <icepic1984>There isn't a test list where i can test my setup without spaming real conversations by any channge? <civodul>icepic1984: no, but if your email setup works for other uses, it should work here too <icepic1984>ok. Just to make sure, because i am absolutly not familiar with mailing list workflows. If i respond to a discussion, i use "reply-all" (wide-reply in mu4e), which will compose a mail with the original poster in the To: header and the Help-guix@gnu.org address in Cc. <graywolf>I guess technically you could reply just to the list, but most people (me included) seem to reply-all <wolfdog>trying to make an aarch64 image for use in a VM, and I'm mostly confused as to what to put on the bootloader field of the operating system, since `grub-bootloader` fails to build <wolfdog>but with that bootloader set, the image fails to build <wolfdog>hm. there's u-boot-qemu-riscv64-bootloader, but no analog for arm <wolfdog>seems like should be easy to make one for arm <wolfdog>i love how Guix is more easy to explore in comparison to Nix <bigbookofbug>is documentation on the proper way to use common lisp libraries on guix? i have been trying to work with sbcl-cl-gtk4, using asdf and the guix package for it, but asdf doesn't seem to work as it tries to compile in the gnu store, which of course is read-only <bigbookofbug>in the past i haven't encountered this issue with other lisp modules, but anything that works with the cffi bindings doesnt seem to want to load <metsomedog>bigbookofbug: for me (require "asdf") and e.g. (asdf:load-system :alexandria) works well for SBCL and libraries installed with Guix. I had some permission issues (CL compilre trying to write to the Guix store) when using some libraries in ECL (it seems mostly SBCL is tested...). Btw, if you try to mix CL installed from another package manager with libraries installed with Guix you will have problems. <metsomedog>Does one need to assign copyright to fsf to contribute to patches/package definitions to guix? I couldn't see it mentioned in the manual, but I thought this was standard practice for GNU projects. If yes, is it possible to use an alias? <ngz>metsomedog: You don't need to. For substantial commits, you can add your name or alias to the top of the module, in the copyright lines. <metsomedog>bigbookofbug: just fyi: I tried sbcl-cl-gtk in sbcl: (require "asdf") (asdf:load-system :cl-gtk4) and got some error "Typelib file for namespace 'Gtk', version '4.0' not found", might be a bug with the package or something wrong with my environment variables (I'm using guix on another distribution); didn't have those problems with cl-sdl2 and cl-sdl2-image <wolfdog>how can i build an initrd image from an operating system to use for qemu? <wolfdog>does guix system vm not work for running non-x86_64 systems? trying to run an arm64 kernel gives me an error for cirrus kernel module not existing <bigbookofbug>metsomedog: in that case i think it may be an issue with the package itself. that being said, im noticing the same issue with other sbcl packages that involve cffi, so i might take a look at lisp-xyz to see what may be going on there <wolfdog>zeropoint: i am already doing that, running `guix system vm --system=aarch64-linux --no-graphic os.scm` <bigbookofbug>i think the asdf error occurs with anything that pulls cffi, based on the error messages <bigbookofbug>my path was set to sbcl/lib rather than sbcl/share, as i'd been advised to set it to lib in the past. setting it to share seems to have resolved the issue <zeropoint>wolfdog: do you have the qemu service running? That was what was required for it to work for me... <attila_lendvai>using guile is holding back guix. it's not really mature enough for a project of the size of guix... <attila_lendvai>i'm spending way too much time debugging. this time i'm debugging the debugging facilities of guile (display-backtrace), which is written in C and does something funny that interfere with with-exception-handler... not something i should be doing in 2024. <ieure>attila_lendvai, I hear and understand your frustration. Practically speaking, the easiest course at this point is likely to improve Guile rather than change the Guix implementation language. <ieure>I'd suggest focusing efforts there if you want to move the needle on this. <attila_lendvai>ieure, there are countless other, much more mature schemes around <attila_lendvai>using another scheme instead of guile should not be an insurmountable task <ieure>I suggest you give it a try and send some patches. <ieure>I suspect it's more difficult than you think -- Scheme isn't really a cohesive language, and implementations have a lot of variance. For example, you're not going to find an ice-9 module in non-Guile schemes; I count around 2000 references to that in the Guix source. <attila_lendvai>ieure, it's a huge task for one person, especially in a headwind. what i'm saying is that it would probably be worth it for the guix team as a whole to invest into making guix work on multiple schemes <panosalevro>attila_lendvai: that sounds like it would complicate things more <ieure>attila_lendvai, I suggest you start a discussion thread on guix-devel about it. With full warning that it's not likely to be well-received. <ieure>Especially if you aren't willing to do some work to get an understanding of the challenges involved. <ngz>I doubt Guix, as a GNU project, will move away from Guile. Another option is to open bug reports (on Guile side) to help moving the project forward. <ekaitz>attila_lendvai: instead of what ieure suggests, i'd do it in a different direction -> improve guile until it's a better language <ieure>ekaitz, That is my suggestion. <ekaitz>i think if we make a community effort from guix to spark some interest on improving guile we'll find many <ekaitz>i think it could be a very good thing to do to start a thread of people insterested on compilers/interpreters and try to create a mentoring system to attract them to guile's internals <ekaitz>i would certainly take part on that <ieure>Between Guix and Spritely Goblins / Guile Hoot, there is a lot more attention on Guile these days, so this a good time to start thinking about how to address some of its shortcomings. <freakingpenguin>I'd find that interesting as well. Been meaning to write a small patch for Guile but it feels a bit more opaque compared to Guix. <ieure>Its complete refusal to tell me in what file, and/or on what line, an error exists is a frequent source of aggravation for me. <ekaitz>also, the two maintainers guile has are extremely busy... so it's normal that it's not improving at the rate we'd love <ieure>Does it really only have two maintainers? Lord. <attila_lendvai>sure, i can report bugs, and i will. i've spent the past 2-3 hours understanding WTF is going on, and extracting a reproducer... but i've spent that time on something that has been solved already countless times. i'm sorry to be blunt, but improving guile feels like a total waste of effort from my perspective. most of it is still written in C (the buggy display-backtrace included) <ieure>At the risk of overly being reductive, I'll slap down a "well there's your problem right there" <ekaitz>ieure: and one of them is civodul hehe <ekaitz>attila_lendvai: but the fact it's written in C is not a big problem. CPython is written in C too, and there's no problem with that. <ekaitz>(I understand what you mean though) <attila_lendvai>ekaitz, if you say so then you probably haven't used a modern lisp like SBCL. especially when it comes to hacking the compiler/vm itself. <ieure>attila_lendvai, As I said, make a proposal on guix-devel. Be ready to show your work. Be ready to show some proof of concept. I understand you're frustrated, but if you roll in with the attitude you're displaying here, you'll start an flamewar that goes nowhere. <ieure>attila_lendvai, I have no power to do anything about it, but you need to soften your tone. You're coming in real hot about this. <jackhill>Does Guix have a special service for /etc/subuid? I'm not seing anything search the manual, so I guess extra-special-file is the way to go? <attila_lendvai>ieure, re my attitude: my primary source of frustration is that it's not acknowledged. everyone tries to gaslight me to think that guile is fine, it only needs a few more patches. <ieure>I would not assume that people running a niche distribution written largely in Scheme have no experience with other Lisps, for example. <podiki>shortcomings of things like guile documentation and debugging are acknowledged pretty widely from what i've seen <ieure>attila_lendvai, I agree with you; Guile is not that good. I said so. But also, I recognize that Guix is unlikely to move away from it, and the more likely route is to improve Guile, not port Guix. <podiki>there were some discussions and plans (and changes?) to improving docs for guile some time ago, maybe last year <ekaitz>attila_lendvai: I understand your frustration and I share it. Sometimes in a stronger way. But we could redirect this. Not with few patches, but with a massive amount of them. Making Guile better, not only in the interpreter level but also in the set of libraries that come with the default distribution (JSON, Base64...) <attila_lendvai>podiki, for me it's not about the docs. i don't care about docs when it's an opensource project. i usually make progress faster if i jump to the code straight away, especially in lisps. <podiki>i meant as an example that i don't think there is some overall consensus that guile is fine as it is; debugging as well <ekaitz>and also the editor support for repl-driven-development and stuff <freakingpenguin>jackhill: Grepping the source for subuid returned nothing so extra-special-file is probably your best bet <podiki>if you are looking for some big project, rather than starting to port guix i would think a guix/nix daemon in another language would be interesting <attila_lendvai>ekaitz, i'd be happy to port libs if i knew that the lisp under me has at the very least proper debugging facilities. at this age i'm reluctant to work on any project that doesn't have adequate debugging facilities (which means that if i'm motivated enough then i start working on debugging and logging until it's adequate, and only after that continue hacking the actual hack). <podiki>one that could be used drop-in would be even better; currently there is nlnet funded project of finally getting guix daemon in guile <ekaitz>i don't think other schemes are way better either... maybe chez is? but the rest... hmm <ngz>I don't see what's wrong with (pk ...) debugging ;) <ekaitz>attila_lendvai: before I go to bed, what I meant is you have a friend here. If you really want to see a big change in guile, we could try to arrange something. I'll push this forward with you. But I can't do this (too) alone. <ekaitz>we can start with the debugging facilities <ekaitz>in fact I sent a patch long time ago to make a command to remove all the breakpoints inserted in the repl <freakingpenguin>attila_lendvai: speaking of shepherd thanks for being brave enough to hack on that! It must be a pain. <attila_lendvai>and sorry for my venting, but the frustration of the dev in me is growing, while the enthusiastic user in me wants to have fun with guix <ieure>Someone please for the love of god fix the thing where Emacs' scheme-mode can't fill comments. Drives me up the dang wall. Only Lisp editing mode where that doesn't work. <ieure>ex. write ;; large amount of text here, then mark the line and M-q -- in every other Lisp mode, it fills the text and new lines get aligned nicely with a preceding ;; <ekaitz>ACTION runs away, but it's happy to see this kind of converstations if they finally trigger some changes and good dev work <ieure>In scheme-mode, it pukes unaligned, uncommented text all over. <freakingpenguin>ieure: Hmm, I never noticed problems but I also don't mark the line before M-q <ieure>What the crap, it never works for me. <graywolf>It seems you cannot be on the first column though <ieure>Doesn't work for me when marked, does work when unmarked. <ieure>Difficult to reflow an existing paragraph when you've made edits without marking it. <attila_lendvai>the bandwidth limits of the few maintainers... is an entirely new can of worms... <attila_lendvai>but anyway, i should go and sleep on this. i'm not constructive in my current mental state... o/