IRC channel logs
2026-04-11.log
back to list of logs
<ianc>anyone in here contribute to guix? I just got started with a few small PRs <mwette>Any instructions out there on how to build rust apps? I see some crates refereced in gnu/packages/rust-crates.scm <folaht>Does dpkg work? Can I install debian packages with it? <vagrantc>the simple answer is yes it works, but not for installing packages for the most part <gnufairy>When using the standalone guix package manager on a distro, say Parabola, how would you find substitutes over tor ? <sneek>Welcome back gnufairy, you have 1 message! <sneek>gnufairy, ieure says: You can use a swap file. Encrypted swap partition needs LVM support, which is currently lacking. <trev>gnufairy: those don't seem related. you can just use torsocks on the guix command. there's no way to set a SOCKS5 proxy right now. or do you actually want .onion server for substitutes? <gnufairy>I want to fetch packages over tor, .onion subs are preffered if possible <test202020>hello. somebody setups greetd-wlgreet-sway-session? example in gnu info is broken. <futurile>I'm at my desk, drinking coffee, randomly browing the Internet while outside it's bright sunshine .... <must ... leave ... desk ... too hard> <adanska>im in the library puzzling over my thesis <adanska>its cool tho guix is a major part of my thesis so i'm essentially guix hacking <noe>adanska, that’s cool! I’m intersted to learn more about it <noe>futurile, ikr!! and all day too; fortunately it is a one-time thing <adanska>noe, basically im using guix and `guix deploy` functionality to create a framework for managing and configuring a fleet of software-defined PLCs <adanska>so im doing a lot with the shepherd to create services that can manage and properly set up the environment for realtime linux processes <adanska>and then doing a lot with getting guix running better and more ergonomically on sbcs like the raspberry pi <noe>adanska, sounds awesome <noe>are you able to guix pull on the raspberry pi? or do you dump a guix system image? <adanska>Currently trying to implement a watchdog service for realtime programs within the shepherd, but honestly its looking to be really challenging simply due to needing to manage network ports and blocking the fibers... i want to keep everything as gexps that run in the shepherd becuase i want access to the services registry of the shepherd, but then i dont get access to fibers, which would be the perfect use case for such a library. so im tossing up between <adanska>just making a standalone guile script that handles it and then maybe the shepherd service itself will read stdout or something and send off the appropriate actions... idk... <adanska>noe, i can guix pull, but it takes foreverrrrr.... i dump the image onto an sd card and intially work from there, but afterwards actually just `guix deploy`-ing is pretty fast <adanska>ive done work so that i can use --system=aarch64-linux but still cross compile the kernel and other packages that take up a lot of comp time/cant be substituted <adanska>i am pretty proud of that! was a huge hack in the end but works almost transperently <noe>gexps running in the shepherd? 😵💫 <adanska>i mean thats what you do whenever you define the `start` and `stop` fields of a shepherd service right? except usually its something simple like a call to `make-forkexec-constructor` <adanska>but theres no reason you cant just have full functional code running there, just need to make sure it isnt blocking and relinquishes control to the fiber scheduler enough <adanska>actually, yeah i'll probably need to make this thing a seperate process just to make sure we aren't bogging down the shepherd too badly.. im not a skilled enough programmer to write something non-blocking with fibres <noe>adanska, that’s on the guix side. But then when you configure your system, it becomes normal shepherd services which don’t use g-exps <test202020>second need to try, but i searching solution comparible with act runner <rovanion>In https://guix.gnu.org/manual/devel/en/guix.html#Submitting-Patches on the subject of updating a Codeberg PR using the AGit workflow I read that "Codeberg automatically figures out which pull request topic corresponds to and updates the associated branch." I just managed to not have this happen, and a new PR opened for me when I wanted to update an existing one. Must $v in -o topic=$v be set to <czan>The topic has to match exactly, and you need to set -o force-push=true. <czan>I don't actually know what happens if you don't set the force-push option... <czan>Oh, wait, that might only be true if you're rewriting commits. If you're just adding then I think only the topic matters. <rovanion>I have no idea what the topic was when I originally pushed my PR. Is there a way to find out? <czan>In the codeberg UI it's up the top, as the "from" branch. <czan>If you link your PR we can tell you. <rovanion>It says s[2]s, but it does that on both my of my two PRs. <czan>"rovanion/development-container-networking" should work, I believe. <rovanion>So the topic name is hidden at the bottom of the page inside a drop-down? Not the easiest to find :D <czan>It's also up the top "wants to merge 1 commit from $topic to master [Agit]". <Rutherther>no, it's at the top " Rovanion wants to merge 1 commit from rovanion/development-container-networking into master AGit " <Rutherther>also, the topic is just the part after the slash <czan>Rutherther: I've wondered about that! I found it works either way, so when I'm copying it from the PR I just always use the whole thing. <rovanion>Perhaps the translation string is incorrect. <czan>It's in the translations for your language. I assume you're in sv-SE? <czan>Looks like the s[2]s should be %[2]s. <Aster1234>I had a fully working system on linux kernel 6.18.20 but after upgrade to 6.18.21 I cannot boot anything anymore (see the link above) <czan>Can you boot into a previous generation? <Aster1234>no I have the same error as from the new generation I can only access the grub console and maybe fix it from there ? <czan>Unfortunately I don't know how to help from here. My first thing to try would be to use a live image to check I can still decrypt the disk (i.e. that there's not some disk-level corruption going on). I have no particular reason to think that would be the issue, though. <Aster1234>and why the previous generation is affected ? The whole idea of rollback is corrupted after this upgrade <Rutherther>that the upgrade itself broke it is just an assumption at this point <czan>That's why my first thought is to investigate things that the generations have in common. <bjc>panicking trying to mount root is pretty extreme <bjc>normally, b0rking an install will get you real error output, at least. kernel ain't supposed to panic, like, ever <bjc>you might be able to fix it from a recovery image. see if you can fsck and mount it from there <bjc>oh, it's also luks. nm. that's outside my wheelhouse <Aster1234>ok I need to prepare some usb stick so it will take some time and btw. the disk itself is fully encrypted btrfs <attila_lendvai>there was recently a change that transfers the encrypted root password from grub to the initramfs. could be related. <Aster1234>could be actually because before it was always asking me to type the password and now it just crash <Aster1234>btw. I've just checked the disk and it works fine, no errors I can mount it on live iso and access all my data <Rutherther>attila_lendvai: are you aware of the associated PR for this change? <Aster1234>In my case I have a coreboot grub payload in my BIOS that is asking me for the disk password and than accessing guix grub that is probably not handling this password correctly and crashing <Rutherther>there is no password, it's just the key. But I am really not sure this can be the case if you are unable to boot even to previous generations that haven't used this new mechanism <Aster1234>I'm afraid the guix grub is always the same for all guix generations <Rutherther>and the grub config has been changed and it seems that could be where the bug is in your case <Rutherther>somehow the initrd is missing in your initrd invocation <Rutherther>try removing the "newc:etc/lukc_script:(proc)/luks_script" and booting then <Rutherther>on the other hand this shouldn't really break anything <Rutherther>Aster1234: are you using extra-initrd, for example to pass through the key-file? <Aster1234>bingo it works now it's asking me 2nd time for a password and booting correctly thanks <Rutherther>but it's a bug ... and I am not really sure why it happens. <Aster1234>and the hack for removing 'newc:etc/lukc_script:(proc)/luks_script' works on both old and new guix generation <Rutherther>yeah... since it doesn't boot with it on both old and new ones it has to be what caused the breakage, not the initrd code then, as I thought at first. <dariqq>is there an issue with the grub change? ive been holding off to update just in case <Rutherther>Aster1234: is the 'List of all bdev systems' really the first message there was on the crashes? <Aster1234>maybe there was one or two more lines that my camera cut I will check again 1sec <Rutherther>I find it really unfortunate it's not even in the etc/news, it's a really substantial change that even if works on all typical setups can break on more customized setups... <dariqq>also i think there should be an option to disable it (or opt in) <Rutherther>I guess the issue could be as simple as it not working with btrfs setup because there is no "(proc)/luks_script" available <Rutherther>yeah, I just tried in a VM adding arbitrary file that definitely doesn't exist and got this failure <dariqq>Rutherther: the issue might be that it is not the guix grub but the coreboot grub that is (trying to) load the luks script <Rutherther>dariqq: it could be, but I would be surprised if it didn't expose this luks_script <scholastic>Hi guys, what IME did you use to write japanese/chinese letters? I'm looking for some options on guix <janneke>scholastic: no idea what an IME is, but i write japnanese with emacs <janneke>M-x set-language-environment and/or M-x set-input-method C-x RET C-\ and M-x toggle-input-method C-\ <janneke>you type the hiragana/katakana and get hiragana, katakana, or kanji <ekaitz>hwpplayer1: congratulations! and welcome <hwpplayer1>where is the guix server(s) for getting packages located ? USA ? <kestrelwx>Official substitute servers are Berlin and Bordeaux. <hwpplayer1>I see so mine are Berlin and Bordeaux right ? Because I didn't change anything <janneke>on guix, one would do: sudo herd status guix-daemon <janneke>so i guess it depends what kind of init system you're using <ekaitz>hwpplayer1: in that case some kind of systemctl thing <mwette>hwpplayer1: ps -ef | grep guix-daemon shows something <ekaitz>hwpplayer1: sudo systemctl status guix-daemon <ekaitz>that should show some command or something <ekaitz>try with `sudo systemctl status guix-daemon` <ekaitz>i don't have a non-guix machine to try it, but it should give you somewhere something like <ekaitz>and below that maybe a command that triggered the service <mwette>I see it w/ ekaitz's systemctl command <mwette>yes, under CGroup: (a bit grayed out) <hwpplayer1>3742 /usr/bin/guix-daemon --build-users-group=_guixbuild --discover=no <ekaitz>and somewhere there doesn't say berlin.guix.gnu.org or something? <mwette>When I type `guix weather glibc' I get error from guix weather that /etc/guix/acl is not readable, it is readable only by user guix-daemon. Any idea? <mwette>hwpplayer1: look at the ExecStart line in /etc/systemd/system/guix-daemon.service. My version has a --substitute-urls arg. <janneke>on my (guix) system, /etc/guix/acl is 444 <mwette>janneke: thanks; all: what is the right bits? <Rutherther>mwette: also do not forget about the /etc/acl folder itself, that should be rx for others <Rutherther>hwpplayer1: the servers are in Germany and France <nckx>Oof, that page still lists Savannah as your trusted Guix-brand source for codes. <lullaby>What is a straightforward way to get the battery level in guix system? I see reference to upower-service, but no links to the service itself. <Rutherther>lullaby: upower is just a monitor, used by some apps. How to obtain the level depends on what your exact use case is <Rutherther>lullaby: if you just wanted to obtain it in the terminal, use acpi, ie. "guix shell acpi -- acpi" or install it to your profile if you use it often <nckx>Even more hac^Wminimal: cat /sys/class/power_supply/BAT*/{status,capacity} <nckx>(acpi gives you a nice count-down though.) <lullaby>I'd like to have it display in the sway bar. acpi looks good! On thinkpad T580 it shows battery1 as charging and how full. battery0 shows not chrging and 0% full. I might have to find out what the purpose of the dual battery setup is. <nckx>Might be an empty slot? I don't know… <nckx>Fun fact of the hour: the source for Guix's openntpd (‘the less bloated ntpd!!1’) package is 1.4 GiB because it's all of OpenBSD. <lullaby>It does have two actual batteries in it. It will boot with one of them disconnected, but not with the other disconnected. maybe one is actually dead haha <nckx>Hmm, (incorrectly2 unsubscribing from the firehose of Codeberg spam seems to have unsubscribed me from everything. <lullaby>ianc sway runs good on guix. Most of my config from sway on gentoo dropped right in. <nckx>ianc: Fine? I don't think there's really an ‘OOTB Guix Sway experience’ but that's why most folks run it. <lullaby>There IS an OOTB Guix Sway experience! BUUUUUUUUUT you have to scroll down to the bottom of the list when the installation media asks you which desktop you want to run. (I missed that the first time and went with i3) <ianc>I might try sway again if I ever get bored with tweaking Emacs and Guix <nckx>I meant more like ‘customised theming and some kool add-ons we've selected for you from our partners’ etc., but yes, it is absolutely supported. (I run Sway.) (I don't think I've ever run an installer-installed system tho.) <nckx>Rutherther: Your summary accurately predicts my enthusiasm for special-casing this, but I agree that it's better to get most set-ups working asap. I'll test it. Won't be immediate since rebuilds are slow and I try to consolidate them. Thanks for working on this. <Rutherther>nckx: I mean, I am also not sure what the best course of action is here, but it seems better to me to support at least some waiting here since if mount fails due to a device missing, there is no way to boot... like I dunno if someone has a disk on USB and they specify it by the device string. Maybe delegating the wait for later could be useful, but then the different ways of specifying the disk would divert <Rutherther>nckx: because with uuid / label we have to wait here in canonicalize as that part is the one actually going to tell you what /dev/X to mount ... So if we decided to wait for strings later than canonicalize, we have to handle string specs differently afterwards <trev>Rutherther: re: kitty update PR. It seems that it looks system-wide for the font using fc-match or looks in the ./fonts dir. So it seems that it is a build time dependency <Rutherther>trev: I do not understand, like it looks for the font through fc-match during the build itself?