IRC channel logs
2026-10-24.log
back to list of logs
<Air4x>While I was reconfiguring my home environment, I noticed that canva-emacs-no-x failed at check time because of a timeout. I fixed it with --max-silent-time, should I open an issue on codeberg? <Air4x>Correction, the package is emacs-no-x. <Brainbroke>Is there a way to stop looking for packages on Bordeaux.gnu.guix.org when I guix pull? I am brand new and I think that I can only get packages successfully from the other host. <Brainbroke>Hey- I am also trying to figure out the easiest way to run wivrn-server on Guix. I have the wivrn flatpak and adb installed. flatpak run io.github.wivrn.wivrn opens the flatpak but I cannot get the headset (while connected) to open games. Do you think that installing wivrn differently would help it connect? It is possible that I need a different <Brainbroke>configuration on Guix but I am not certain where on the website to look or ask. <apteryx>jlicht: would you know how to update node-types-node; I think it needs an update for our newer node, but I have no idea where the commit hash selected comes from <untrusem>hako: forgot to reply to your recent mail <PotentialUser-55>hi, im trying to do a guix system reconfigure. and its giving me this error. || guix system: error: aborting reconfiguration because commit 230aa373f315f247852ee07dff34146e9b480aec of channel 'guix' is not a descendant of d58da8a56b75af73a7b5466f7ef8a81679713aa3 || how do i fix this (sorry if i am interupting anything) <hako>PotentialUser-55: Try to re-login? <untrusem>I have seen nix folks, flakes have some problem too <untrusem>I don't know these problems but we could correct them <hako>in the scope of that mail, the difference of nix flakes vs guix channels to me is like inputs vs propagated-inputs <hako>since Guix can't combine multiple revisions of the same channel at the same time. and dependencies declared by one channel will propagate to the user <hako>For example you can do this <hako>nix shell github:NixOS/patchelf#patchelf github:NixOS/nixpkgs/nixos-26.05#hello <hako>they'll have different dependencies, glibc-2.40 for patchelf and glibc-2.42 for hello, for example <hako>the syntax can be implemented in Guix with inferiors actually, but the interoperability between these two packages and their dependencies is very limited. <hako>and currently, building multiple Guix instances is slow <mra>hako: hey! sorry to bug you. I've confirmed that the Rosenthal live image is non-functional on my PC, but the details seem to be a bit weird <mra>when I boot, the kernel printout shows that init[1] segfaults, and then the boot process just hangs <mra>I confirmed that I am able to boot into the official guix image, but for some reason the segfault of init[1] still shows up in the kernel logs, it just does seem to inhibit booting! <mra>was wondering if you've ever come across this before or have any ideas what it might be <hako>mra: the minimal image? I guess it might be related to the graphics driver. does adding "nomodeset" kernel argument in GRUB help? <Brainbroken>I recently had a bunch of errors when booting with Rosenthal but eventually got into the live environment after a few minutes unresponsive. The problems on the live ISO did not seem to stop the installation from working normally. <mra>hako: the minimal image, yes. I'll give that suggestion a try! <hako>Brainbroken: slowness is normal, especially if you want to use the desktop variant, Guix is I/O intensive and the images are not optimized yet <mra>hako: nomodeset didn't fix it, I'm afraid. it still shows a segfault in init[1] and hangs <mra>there is now a new error: "probe with driver amdgpu failed with error -22" <hako>I'll add a installer to Nonguix with less customizations for the installer system itself, maybe you can try it again by then? <mra>hako: weird! that is indeed exactly the segfault I'm getting. I have no idea why I can't boot into the installation image then <mra>if you build a different installer I'll absolutely try it! unfortunately I really haven't got a clue how to make the Rosenthal installer work <mra>untrusem: there are... issues. basically, the base installation image does not contain the kernel modules or user space programs for zfs, so I can neither create nor mount ZFS datasets <mra>so I need an installation image which has the appropriate programs installed to work with ZFS within the installation image <untrusem>hmm I could generate one for you, or hako can with relevant modules to you can use it <untrusem>insteresting, have you tried to generate your own image? <mra>untrusem: I've tried, but I haven't had much success. I don't actually have a machine running guix, so I went through the process of trying to install guix on top of nixos (which is broken, as best as I can tell), then tried again in a VM without any success <mra>untrusem: it's not so unique! I have a laptop and a PC, both running NixOS on top of ZFS. I want to switch to Guix, but I want to keep using ZFS. I'm currently trying to install Guix on top of ZFS on my PC, to rather limited success <Brainbroken>I had the installer hang on my first try, reflashed the rosenthal image onto a second flash drive, and then was able to install successfully. I have no background on Guix- so I am not able to diagnose this. It could be that my low download speed or poor flash drive caused the issue the first time. I went for more than an hour on the USB before the <Brainbroken>installation paused partway through a download. I am using BTFRS so the problem may be unrelated. <untrusem>btrfs on the drive you are trying to install zfs on? <Rutherther>Brainbroken: what version did you use, the 1.5.0 installer? <Brainbroken>It is a nonguix installer with Niri. I selected KDE as an environment during the installation process and haven't gotten back to Niri. I do not have ZFS, so mra's issue may be different. <apteryx> despite node-types-node in inputs, and in the package.json file. <mra>Brainbroken: I've tried two different USB sticks, both Rosenthal installers, and different USB ports on my PC <mra>Haven't had any luck I'm afraid <mra>untrusem: ah, I don't mind the trouble too much. I'm very much trying to do something that is not officially supported. can't be surprised that it isn't seamless! <Rutherther>oh or did you flash both the same one? Did you flash with dd? You should always "sync" afterwards <Brainbroken>I see. I didn't flash with DD, because the first time I tried the command with a bunch of text I did not do it correctly. The ISO was compatible with the KDE desktop ISO flashing tool. I think the download failing was the most likely problem with my first attempt, as the file had already taken about 7 minutes to download when it froze. <csantosb>sneek: later tell dariqq, nope, this is a typo, sorry about that; I was wondering why I had to rebuild all emacs locally to upgrade. <yarl>2 things: Will you work on something about that issue for the rockpro64? It's just so we can coordinate our efforts, or at least so I don't work on something you are about to solve ;). Also, you didn't answer my comment on the gap for u-boot at the beginning of the sd card. <Rutherther>as for the gap I did not answer because I am not sure what a good solution is there... well the best solution would of course be if it's managed by Guix as well:) <Rutherther>but when it's invisible for Guix, I am not sure what to do about it, esp. if you're installing Guix on the same sd card <yarl>Yeah and that depends on the state of the spi. <yarl>And you need to know the platform if it's the responsibility of guix to install u-boot. <yarl>Maybe the best thing to do is to always install u-boot on the target device (on arm) <yarl>if there's already u-boot on the spi, this guix-installed-u-boot just won't be used. <yarl>And that's not a problem. You just loose a few MBs <yarl>I'm not confident about these, my only recent experience is with the rp64 <Rutherther>yarl: I don't think that's possible solution though, there are actual UEFI platforms on aarch64. The installer for aarch64 is mainly meant for those <Rutherther>aarch64 desktop computers are UEFI only afaik. Installing u-boot on them will not do anything <Rutherther>and I expect that even single board computers will be using efi out of the box in some time, but that's only a speculation <yarl>One thing, "won't do anything is not a problem", just a few MBs lost. Another thing, can we know which one is pure UEFI? So that we only install u-boot on _not_ those. <Rutherther>EFI is pretty much the only standardized. I don't think you can make a generic u boot installer, because it behaves differently on most systems... different offsets and so on <Rutherther>having a u boot installer would be much more effort <yarl>I'm not talking about the installer <yarl>But about the installation <yarl>But that's the same problem. <Rutherther>it's not the same problem, with the installer the user is someone who just expects it to work on their platform... click through it, the installer says all good, installed, and now if it doesn't boot, it's an issue <Rutherther>while if a tinkerer comes and does a manual installation, they probably studied where to put the u boot and so on, so they will configure it themselves after possibly few (or more) attempts with issues <yarl>Just a comment : the default rp64 won't boot your installer. <yarl>I had to dd u-boot on the sd. <yarl>for the installer on the usb to boot. <yarl>Now I expect the installer not to remove u-boot! <Rutherther>"Maybe the best thing to do is to always install u-boot on the target device (on arm)" there is just no standard way to do that, that's why Guix doesn't have a single u boot bootloader, but there is per platform, the u boot is built with different defconfig for device and so on <Rutherther>yes, I am aware that the 'firmware' of RP64 doesn't contain UEFI support by default, and agree it would be the best if the installer didn't override the bootloader, but how can it do that? It doesn't know what's on the sd card, how could it know? or assume? <Rutherther>setting it so that the offset is always 8 MB would probably work in this case, but would it work generally? <yarl>Is the per platform u-boot always something like u-boot-XXX.bin? is it always 64 sectors offset? <Rutherther>some platforms boot u-boot from a partition from a file <yarl>I suppose setting a 16MB offset is something that can't harm. <yarl>And it will at least work for this situation. <Rutherther>agreed, esp. if that's just the default and overridable <yarl>Overridable how? I mean what form would it take in the config? <Rutherther>hmm, this is not about the config, or? It's about the partitioning, no? or am I misunderstanding? <Rutherther>I believe that in the installer you can set offsets of the partitions, so it would just default to 16 MB for the default partitioning it gives you on aarch64 <yarl>I think you can't at the moment. <yarl>I had to use fdisk directly then use manual partitionning in the installer. <yarl>But yeah, that's the idea. <yarl>Also, I think the installer is not verbose enough. <Rutherther>you're right, trying it now and you can specify size only, not offsets <yarl>I won't be there for a few hours. I'll let you know if I make some progress! <yarl>My pleasure! Thank you too! <haugh>I'm trying to export my guix keyboard config to configurations like org.freedesktop.locale etc. Any ideas? <yarl>Tihs time I really go afk ;) <jlicht>apteryx: yeah that's needed since typescript version 6 <vurdie>Hey all! I noticed that the Guix graphical installation wizard warned me that my video card is non-free (and I don't have integrated graphics). How would I go about finding a similar-spec graphics card that has free drivers available? <vurdie>Thank you for your input, but I believe #nonguix is not the right place for this question, as I am looking for a free alternative to my graphics card, not for a non-free driver for my current one <untrusem>and I commend you for this but I won't be to help much about graphics card <dlowe>vurdie: radeon cards have free drivers <vurdie>dlowe: My card is pretty modern (radeon 6700 XT), and from my reading, I understood that it requires proprietary binary blobs. What do you suggest? <Sneed1911>vurdie: An older amd card is probably your best bet. Couldn't tell you how old. The NVK drivers now in nouveau also work surprisingly well if you're just looking for a card with useable specs. All of my nvidia gpus are hybrid laptops and while I generally don't use the discreet gpu, in my testing offloading using NVK/vulkan works great. <RavenJoad>I need the Zig compiler to see the C header <bits/c++config.h>. C_INCLUDE_PATH and CPLUS_INCLUDE_PATH only have the top-level include directory set, i.e. "/gnu/store/...-gcc-14.3.0/include". But because of how Guix does its layout for gcc-toolchain, I also need to find the architecture-specific headers too, the ones in "/gnu/store/...-gcc-14.3.0/include/c++/x86_64-unknown-linux-gnu". Does Guix already have a system to set that kind of <RavenJoad>I am using the gcc package rather, but the problem remains. <vurdie>Sneed1911: Sounds good, thanks! Would you be keen to recommend a decent-spec gpu model with free drivers that you currently use? (I don't favor amd over nvidia or vice versa) <dlowe>vurdie: it doesn't require them. The radeon drivers work great. You can squeeze out a small bit of extra performance with the amdgpu drivres. <dlowe>I'm running a 9700 XT so I don't think "older" is really a factor <vurdie>dlowe: You have a point. If you don't mind, could you share what packages you've included in your config to make your card work? <dlowe>vurdie: clarification: I'm using the amd card on debian, not guix, but using the free drivers. I would think the basic guix desktop would include them as part of the normal package. <Sneed1911>vurdie: apologies if your gpu does work, I assumed it needed a blob from the mainline kernel. Regarding nvidia, anything Pascal architecture or newer. Rtx 2000 series can be found for around $100 usd used, especially if you're fine with around 8gb vram. You'll just need vulkan-tools and related packages, drivers are all in nouveau. <vurdie>dlowe: Thanks for clarifying, I will ignore the warning the installation gave me for now. I'll attempt to go forward with the installation in the meantime and see what I can do without adding non-free packages <vurdie>Sneed1911: That's what I assumed too, but I yet have to figure that out. Thanks for the advice! <untrusem>vurdie: you can use usb tethering too from your phone if you don't have ethernet :p <vurdie>untrusem: Good tip, especially since my Wi-Fi card is also on the non-free hardware warning list, but fortunately I do have ethernet on my motherboard. Thanks for the heads-up :) <noxi>Is there a way to create a netns from system's config.scm? In the same way other `ip` commands can be automated from `static-networking-service-type`. <nmeum>just to make sure I don't mess up: team branches can be (and should) be forced pushed, right? (e.g. to rebase against current master) <RavenJoad>Is there anyone from the Zig team here? I wanted to find out why -Dtarget=... is not passed during the check phase with "zig build test"? <RavenJoad>DragonMaus: My question is about how/why Guix's zig-build-system invokes Zig. Sorry, I can see how that read like I meant to ask a Zig question. I meant this as a Guix question. <untrusem>RavenJoad: we have only person in zig team <jungy>I was hoping to set up a hunchentoot server on my guix box. But unfortunately, it seems like sbcl is unable to find libcrypto. How do I provide access from one package to another? openssl is installed. <jungy>Unable to load in guix shell as well. <jungy>Truth be told I can skip using this, since I'm not hosting it as HTTPS. I'm just worried because for whatever reason it seems to only listen on loopback even if I set it to 0.0.0.0, and I figured it *might* be due to failed dependencies. <jungy>ah well, water under the bridge. It works, and a web 1.0 site doesn't really need SSL. <RavenJoad>untrusem: You said the zig-team has only one person? I read through teams.scm and it seems to be Ekaitz. <RavenJoad>Ah, right. The Guix tree I checked is quite old. I was definitely looking at the wrong one. <untrusem>also 0.17.1 will be releasing in upcoming months <bytesurfer>we need more scientific calculating apps in guix :S <bytesurfer>Only until I fdigure outhe amn way to package rust stuff <ArneBab>bytesurfer: have a look at guix import crates --help <bytesurfer>but I cannot seem to figure out the endless stream of missing packages that it complains about <bytesurfer>Is the guix approach to port everything to guix rather than build from crate?