IRC channel logs
2023-10-07.log
back to list of logs
<kyo_>Is GUIX not being able to be installed on SeaBios coreboot. A Guix Issue or a SeaBios issue. I don't want to ask questions in here, if I am in the wrong channel. <fnat>What's the convention when sending a revised patch, is the new patch revision 1 or 2? <frescalls>good evening guixers, how would I go for booting a pinebook pro from nvme? can I use the image from the website? <apteryx>mirai: strangely, #$(this-package-input "subversion") is what seems to make the git def go into a circular dependency <Kolev>Posted my Guix Home config to guix-help. <mirai>could it be because subversion is defined after git? <mirai>what happens if you reorder it above the git package? (weird but I've seen strange things due to ordering before) <apteryx>hm... it means that using this-package-* does not get fully delayed? <apteryx>not sure if I should report this as a bug or ? <Kolev>Glad I have a functioning system independent of my Guix install... <mirai>apteryx: I think its worth reporting <mirai>if it isn't it ought to be documented somewhere <apteryx>hm, wait, I hadn't uncommented the problematic block <Kolev>What paste program do you use, that it goes to Debian Pastezone all the time? <mirai>hint: you can use #; to comment sexps <mirai>I think that (search-path-as-list …) call isn't correct <apteryx>even the LD_LIBRARY_PATH bit gets it to hang <mirai>the "lib/perl5/site_perl" has to be within a string <mirai>though that's probably not what's causing the cycle trouble <mirai>(you also might need to '#$ / quote the list) <mirai>What happens if you omit subversion? <apteryx>it works if I just comment out ;(this-package-input "subversion") <mirai>and the subversion package is defined above git right? <apteryx>adding]; (pk 'subversion #$(this-package-input "subversion")) anywhere in a phase gets the build to hang and blow up the memory <mirai>the easy way out would be to use assoc-ref inputs <mirai>btw shouldn't the first argument of search-path-as-list be within a list? <mirai>for the append-map call you might want to filter the duplicates out <apteryx>I'll use assoc-ref until it's understood, thanks <apteryx>delete-duplicates should be defined in the scope of tE top module level (which is the scope in #$), as #:use-module (srfi srfi-1) is in the module declaration, yet it doesn't know about it <apteryx>mirai: you were right about the 1st arg of search-path-as-list must be a list, not a string <mirai>you might want to sort the list first before running it through delete-duplicates <mirai>see the SRFI-1 comment for it <apteryx>mirai: phase `split' succeeded after 0.0 seconds I'll pass for optimizations ^^' <apteryx>that's be nice; I've inverted the relationship of inheritance between git-minimal and git <apteryx>Kolev: seems you are making progress! <apteryx>I remember a couple sleepless nights in 2016 to get started... a good investment in retrospective <apteryx>(I had mistakenly erased my main system of the time when attempting a dual boot with Guix System, so it had to work) <apteryx>do you know which config is causing the error? try to narrow it down <apteryx>then show us the problematic configuration so we can review it <Kolev>apteryx: see readme. Its my home config <apteryx>which of the two services is causing the shepherd error? <apteryx>maybe you need to preserve the base %home-services ? <apteryx>not sure where these vars come from, nevermind <apteryx>I don't know about the problem you're seeing though. I'd comment out stuff and narrow the exact section causing problems, perhaps try to start shepherd manually and see if it spits something more useful <vivien>lilyp, for the dbus system socket location, mirai had a point in a discussion earlier: the socket should indeed be in /var/run, because guix does not consider /run and /var/run identical (in /run, you have /run/current-system, for instance). So glib is wrong about its runtime directory. I’m trying to build it with /var/run as its runtime directory, we’ll see <vivien>if that fixes the issue. The fix would be way simpler. <atuin>I have added a couple of channels but when running `guix repl` I can not find the modules defined on them, is that expected? or am I doing something wrong? <vivien>atuin, you have to run guix pull first <atuin>I can see in the manifest after guix pull that they are using the latest commit <lilyp>vivien: there should be an easy glib configure flag to do so; sadly, it's a gnome world rebuild either way <atuin>vivien: should they be in the union derivation that contains guix modules? <vivien>atuin, you should be able to see them in ~/.config/guix/current/share/guile/site/3.0/ <jbnote>Hello, would there be a way to tie random store entries to a GC root? I'm using guix build --sources=transitive a lot (or just downloading sources from repl scripts) and i'd like to have "generations" or "profiles" of sources to be able to handle GC gracefully. I know how to do this for final packages, but I just don't know how to do this, either from guile or commandline, for other intermediate entries. Any help would be much <atuin>vivien, indeed they are there <atuin>seems guix repl does not add that path to the %load-path <vivien>Does which guix print /home/.../.config/guix/current/bin/guix? <vivien>If so, the black magic command "hash guix" might help. <atuin>yeah it does `/home/atuin/.config/guix/current/bin/guix` <atuin>mmm interesting ... guix system reconfigure seems to find the modules properly, it's using the new functions there <vivien>The wisest thing I can tell you now is "Try rebooting". <atuin>Yeah, I can reproduce with my own module :D thanks again <cdo256>Is packaging subversion projects supported? <cdo256>Ah yes sorry I only looked in the manual <janneke>oh, that seems to missing from the manual! <janneke>cdo256: would you care to file a bug and/or create a patch for that? <mange>Hey Guix! I'm trying to fix a bug I've run into in Guix Home, but I don't know how to test my changes because my configuration uses definitions from a private channel, and ./pre-inst-env doesn't load them. Does anyone have any ideas? <mange>I've tried using "guix time-machine --disable-authentication --url=file:///path/to/my/checkout" but I just get constant "updating substitutes from ..." messages for ages. I've not been willing to let it run long enough to find out if it ever actually finishes. <civodul>mange: hi! i’d have suggested the ‘time-machine’ approach, i wonder why it keeps updating substitutes <civodul>could be that all the recent grafts hinder performance a lot <mange>Yep, that was it. I've just managed a home reconfiguration using time-machine. Thanks for affirming my approach, civodul! <vivien>apteryx, do you want to reply to #66099, or should I address lilyp’s remarks first? <mirai>mange: indeed, it's super slow here as well <vivien>lilyp, I think it’s better to keep the hardware description files in /etc, so that a user can generate a local hwdb.bin index with what is known to work on the system. If we want to have this on foreign distros, we must keep "hwdb.d" as the directory name (systemd uses "hwdb.d" too) <PotentialUser-85>hi i've managed to get a working sway config but i can't get the foot terminal to work in it properly. I get an "Error: opening terminal foot" message when trying to use nano and can't clear the terminal. seems like something to do with terminfo. I tried moving the share folder (includes terminfo) from the package's folder in the gnu store onto my <PotentialUser-85>system at /share and /usr/share but that didn't change anything. any help would be appreciated. i'm pretty new to guix so apologies if this is a bit of a noob question <PotentialUser-85>also alacritty doesn't have this issue, just foot, which i would prefer to use <PotentialUser-85>also i'm having an issue with my wifi connection dropping out regularly, i'm using the same wpa_supplicant process I was using in the liveusb which had no issues at all. however every few minutes or so on the installed system I have to run dhclient -v <interface> again & regularly to restore connection. if anyone could help point my in the right <snape>jbnote: you can use 'guix build -r' to create gc roots <snape>example: 'guix build hello -r ~/hello' <snape>will create a symlink in your home to the hello store dir *and* add it as a gc root <snape>that is, symlink it in /var/guix/gcroots/auto <apteryx>rekado: something broke r-smoother & friends on arm and i686 recently <apteryx>not r-smoother but r-rsqlite and others <apteryx>may want to restart the failed builds <apteryx>"Resource not found: /build/2182838/log/raw" <apteryx>civodul: I think the above error is new on Cuirass ^ <mirai>apteryx: re jami transducer, although I've replied with an explanation for why it was needed I think we can revisit the whole telephone.scm afterwards <mirai>I see some places where we can refactor it to make it cleaner <apteryx>vivien: done, I don't have much to say! <apteryx>jami is currently somewhat broken due to Qt 6.5 turning out to be not yet supported :-/ <civodul>mirai: re ‘with-store’, no: ‘with-store’ takes care of closing connections <civodul>however ((lower-gexp serialized-ini) store) is not okay :-) <civodul>rather: (run-with-store store (lower-gexp serialized-ini)) <apteryx>mirai: I'll merge bug#63985 to master after testing the jami system tests still works, if that's OK with you (and lilyp) <mirai>I tested on my end but can't hurt testing some more <apteryx>oops: error: maybe-string-list?: unbound variable <apteryx>I tried: make check-system TESTS=jami-partial <mirai>did you apply the whole series? <apteryx>yes... maybe I need to clear the .go? <mirai>I removed `string-list?' recently <mirai>jami-partial isn't a thing tho <mirai>make check-system TESTS="jami-provisioning jami-provisioning-partial" is though <apteryx>grep --include='*.go' -rl jami-configuration | xargs rm did it <graywolf>Hi, if I have a program calling dlopen with just a library name, how it that usually handled under Guix? <graywolf>It fails to load the library, but I am unsure what "proper" solution is. Some wrapper script? Patching the source somehow to contain full path? Any other ideas? <civodul>graywolf: hi! often such programs honor a search path environment variable, like WHATEVER_PLUGIN_PATH <civodul>in that case, add it to the ‘search-path’ field of said package <ryblade>having trouble installing a guix system. everything appeared to work fine until i rebooted, now grub says "error: no such device [hash]", "error: unknown filesystem" and going into rescue mode. <graywolf>civodul: Thanks for the tip, will check if firefox's NSPR supports something like this. <graywolf>Assuming it does not (I expect), is usual fix to add support for it, or use absolute path? <PotentialUser-85>ryblade something similar happened to me, i had btrfs fileystem but ext4 in my config.scm <ryblade>PotentialUser-85: i'm using btrfs too, but i have (type "btrfs") in my config.scm <ryblade>using encryption too, btrfs on luks, no lvm <ryblade>made sure to use pbkdf2 just like the manual says to <PotentialUser-85> "Error: opening terminal foot" message when trying to use nano and can't clear the terminal in sway. anyone able to help me with this? i know it's to do with terminfo but im not sure how where to go from there <apteryx>civodul: fyi, I'm working on a fix for bug #65924 <civodul>apteryx: oh, i started looking into it an hour ago :-) <PotentialUser-85>ryblade might be worth mounting it on the liveusb and checking what grub.cfg looks like <apteryx>civodul: I'm think to spin a feature branch just for git <ryblade>PotentialUser-85: any way of installing curl in the liveusb environment? i could upload my grub.cfg and config.scm to a paste service (ix.io) if i had curl on here. <apteryx>I already have the clean slab (dropped gexps and labels, inverted inheritance relationship between git-minimal and git), now looking at adding coreutils and sed <civodul>apteryx: oh that’s even better indeed <civodul>now, we have a scheduling issue: there’s a need for ungrafting as well, including glibc <civodul>so it would be wasteful to build a branch “just” for Git <ryblade>never mind, realized guix install works the same, haha <ryblade>it's the provided /etc/configuration/desktop.scm with the most minimal of changes <PotentialUser-85>ryblade seems fine to me but im sure others in here would know a lot more than me. the only thing i can think of is in config.scm there's no distinction between home/root in the device label, i'd double check it's okay to use "cyproot" twice <ryblade>PotentialUser-85: well i am using subvolumes, that is how it would be done with mount <ryblade>and that's the thing, it all seems fine, yet it doesn't boot... <apteryx>civodul: I suggest we sync to get the ungrafting and git stuff on core-updates <jpoiret>GRUB+/boot on LUKS2 doesn't work unfortunately <whereiseveryone>I think this is a friendlier/better written debugging tutorial in the manual than guile's: <jpoiret>ryblade: it's not if you have /boot on LUKS2 <jpoiret>next grub version will fix this and should get released soon <jpoiret>other distros work around that by using custom patches or generating the grub binary themselves and including the crypto modules themselves <jpoiret>I spent some time writing proper patches that got into upstream for this but unfortunately they didn't apply on 2.06, only on master, and thought the next version would come fast enough <ryblade>think i should try with -latest or downgrade to LUKS1? this will just be a general purpose desktop, not a production environment. not sure if it would make more sense for me to be on -latest or -1.4.0. <jpoiret>you can use the latest RC version, i did that for one of my friends and it worked <jpoiret>then once the version gets an official release you can use that instead <jpoiret>you'll have to write the package definition yourself though, i don't have it lying around <jpoiret>just inheriting grub-2.06 and updating the source field should be enough, as well as disabling tests (last time I checked the test suite had some big changes that made it not work with our current packaging) <jpoiret>it's probably the best solution, and because you can put arbitrary package definitions in your config it's very clean <ryblade>sounds a bit daunting, is there some documentation i could read that explains this process? this will be my first time using guix. <ryblade>would "9.3 Defining Package Variants" in the guix manual be what i'm looking for? <jpoiret>no, and i'm not too sure that it's documented straightforwardly in the manual (ie. it's mostly a combination of stuff explained all over) <jpoiret>otherwise LUKS1 can be upgraded to luks2 in place iirc <ryblade>ah. in that case i'm gonna just go with LUKS1 and upgrade when LUKS2 is supported. thank you for your help, jpoiret! <civodul>cbaines: hi! dover seems to be down; could you take a look? <civodul>hmm what’s the solution when grub-install fails with “Could not add entry to BootOrder: No space left on device”? <vivien>lilyp, now I understand what you mean with the "hardware" rename. It does not require the eudev source code to change, it just means that the UDEV_HWDB_PATH search path should search in lib/udev/hardware. The udev-service-type uses neither /etc/udev/hwdb.d nor $eudev/lib/udev/hwdb.d, it only relies on UDEV_HWDB_PATH <vivien>So we don’t need to change the hard-coded /etc/udev/hwdb.d or $eudev/lib/udev/hwdb.d paths <vivien>Let me recompile the webkits, check the VM, and tomorrow you’ll get a v9 <efraim>civodul: check /sys/firmware/efi <efraim>and also /sys/firmware/efi/efivars <vivien>Is this information in the manual? I got burnt one day, and I remember the solution was non-trivial <vivien>Sadly I don’t remember how I solved it, but it had something to do with cache file in directories similar to those indicated by efraim <civodul>efraim: the intertubes seem to suggest removing /sys/firmware/efi/efivars/dump-* <efraim>that sounds right. make sure it's just the dump-* files <efraim>otherwise there's some sort of no-nvram flag <apteryx>do we have some sugar to prepend to a file in Guix? <civodul>no, though this can be achieved with ‘substitute*’, if that’s enough for your use case <civodul>efraim: removing the dump-* files wasn’t enough <vivien>I often do: rename the file, and write in its place the prolog + "include renamed-file" <civodul>vivien: yeah, that’s what ‘substitute*’ does (pretty much the only way to do it) <vivien>I mean, use the target language to understand the include directive <vivien>In C, that would be #include "renamed-file", for instance. <vivien>I would be surprised if you could not include a file verbatim in m4 <lilyp>mirai: m4 is certainly a language, why? <Kolev>apteryx: Do I need to provide any more info for SSH issue? <mirai>lilyp: it works in a rather different way than what's usually expected from other languages <mirai>though I can see that it does act like one, yes <lilyp>except that m4 is actually useful