IRC channel logs
2025-10-05.log
back to list of logs
<bdju>Sweeeet, freed 866 GiB this time according to guix gc. According to df I'm at 754G free now so like 465G freed actually. I think someone told me last night that hard linking doubles the space saved so that is prob the difference. <aitor>the stick is ready and i'm going to install it. Thanks for your help, I'll let you know tomorrow how is it going <aitor>oops... "How it's going...", I meant to say <wakyct>hi Guix, wondering if for the fundraising campaign 5/month could be an option, or maybe the 10/mo was chosen b/c of processing fees? <wakyct>anyway I donated one-time for now <tesseract>umanwizard: yes, I am using guix on another distro. thanks for clarifying. <dgr>why is the custom ammount missing? AFAIK it's one of the options that brings in a lot of money as stated by toher projects doing fundraisers. I just noticed that the FSF page allows a custom amount. Also see https://kde.org/fundraisers/yearend2024_hw/ for inspiration 😉 <loquatdev>Hello, all. I accidentally wiped my bootloader partition on my main machine. I used the installation ISO to chroot into the installation, but now it seems unable to reconfigure my home environment properly, producing errors about failing to backup my .bashrc. When I log back into that user, my home environment profile is not loaded at all. Is there <loquatdev>a way I can completely remove the home environment data from that user and `guxi home reconfigure` as if it is the first time again? <loquatdev>I suspect I broke something relating to the home environment when I reconfigured from the chroot. <loquatdev>Is there a reason that guix has to receive and index objects a second time when running "guix pull" as a user and then running "sudo guix system reconfigure"? <loquatdev>It seems like the derivation is built just fine when running the command as a normal user. The only thing it can't do is symlink the new system. <dcunit3d>if i build guix on one x86_64 computer, particularly using --localstatedir=/gnu/var, will the artifacts be portable to another computer? ... i'm assuming yes lol <dcunit3d>but i tried a build on omarchy by supplying guile packages from AUR and the tests were just very very slow. <dcunit3d>i tried to renice the process tree :( it didn't work <dcunit3d>thus, i think there's a problem with the build, which is why i'd like to see the tests run/complete. i did run with make -j6 <dcunit3d>i have a nixos computer over here. i feel like i'm more likely to get more solid deps there. i also have guix installed there as well. <hako>apteryx: Re: "should it rather read s/modify/register/". I used "modify" since the definitions were already imported in rust-crates, for "register" I read it as adding new definitions, which is the work of importer. WDYT? <futurile-afk>wakyct: yeah it's the processing fees. I can also create a link for 1 donation per year - but it felt like it would make the donation page too complicated. A one-time donation is great - thanks very much for supporting the project. <futurile-afk>dgr: the custom amount isn't fixed (it worked fine when I tested it) - if you're doing it through Stripe you can click it and change the amount right? <futurile-afk>dgr: if it's not working for you pleae tell me and I'll look into it further <futurile-afk>dgr: the monthly contributions one are fixed, so there didn't seem to be a way to allow someone to pick any amount on Stripe. But you can donate any amount you want through Open Collective (or FSF) <Rutherther>sneek: later tell loquatdev: when you run guix system reconfigure, guix script checks if you're doing a forward update. To check that, it needs to see the commits in the repo. Since it's executed as root, the checkout under /root/.cache is used for that rather than the one you use as a user. If you want to share the checkouts, see shared-cache-service-type <lilyp>rust gurus, how do I add a new cargo package? <lilyp>(using the lockfile importer) <Rutherther>jonsger: because drv is already a finished derivation that includes the arguments from the package that led to it. All transformations operate on package level <efraim>after importing the package and then the second import with the crates I build the package with -K so I can inspect the build environment to see what needs to be removed in snippets from the crates <lilyp>is there a way of telling the importer to look for newer versions already packaged and automatically substitute them? <lilyp>e.g. glib-0.20.0 → 0.20.10 <futurile-afk>It just flashes teh screen at me, no bloody error message <ray1729>@futurile have you enabled issues for the repository? Under repository settings, Units, Issues there's a checkbox <futurile>ray1729: thank-you, that was it. The project is at the org level so I was looking for the setting there, but it has to be enabled at the Repository level <futurile>ray1729: great - that's been driving me mad for a week! <bdju>Has anyone else noticed qutebrowser having issues displaying any web pages recently? Everything is just blank. Also, I lost my tabs. <kestrelwx>QSG_RHI_BACKEND=vulkan LD_LIBRARY_PATH=$(guix build vulkan-loader)/lib qutebrowser <ekaitz>futurile: do you plan to make a post with the status of the campaign after a few weeks? <futurile>ekaitz: yes, I was going to post on social a few times (hopefully enough that people see but not so much that it's annoying) and then post on the blog the status. <ekaitz>futurile: great! it feels like it's going well, but it's hard to put numbers to what it looks like from the outside. <yarl>futurile: You are steve, right? <yarl>I sent an email to both you and tanguy about the guix foundation. I wonder if you got it. <luca>How long will the donation campaign last? <efraim>I might need to pull out my debugging cables. My pine64 with a fresh image comes up, is noticed (sshd, by my router, etc), and then immediately becomes unreachable <futurile>ekaitz: we've had about ~20 recurring subscriptions I think (not a proper count, just quickly counting them in my inbox). So that's good progress for a couple of days. <futurile>luca: I don't know - a few weeks I guess. The limiter is that most users probably don't go to the Guix web site, or read the email list that much. So they may not know we need support. In general we probably need to fundraise more often because we're only currently receiving about 1-2k of donations a year, when we need more like 12-15k <futurile>sneek later tell yarl hey I've responded to your email, I need Tanguy to confirm the address just to be certain <dcunit3d>so i've built guix, but how do i create the installable .tar.gz? do i run make dist-all? <craigbro>ah, I just did this: make guix-binary.SYSTEM.tar.xz <craigbro>where SYSTEM is the appropriate value for my machine, see output of: ./pre-inst-env guix pack --list-systems <craigbro>that presumes you are in the guix src dir <craigbro>dcunit3d: are you trying to cross-compile that tarball? <craigbro>also, I had a similiar experience with the tests being slow.. <Ironsmith>for your second question untrusem i don't know for sure, but i believe it has something to do with making local channels compatible with guix generations/rollbacks, when you run `guix pull` it takes a snapshot of the state of all sources, including the specific commit for your local channel, and then if in the future you ever need to rollback to <Ironsmith>some previous generation it would be able to retrieve that earlier state in your local <Ironsmith>if your goal is to do quick prototyping/iterations on a package definition, i would recommend not using a source, instead you can `guix build`/`guix install` the .scm file directly <untrusem>that what I do generally, I use the `-L` flag for this. <jnms>So gdb doesn't work under qemu binfmt, causing for example a compiler's test suite to fail. Do I just disable every test that fails under qemu? <hanker>when packaging Python, should linters (e.g. black) be included in `native-inputs` ? <Rutherther>hanker: anything that is somehow ran during the build should be in native-inputs, yes <dcunit3d>craigbro: yeh, kinda. i want to customize `./configure --localstatedir=/gnu/var` in the build <dcunit3d>i need to install on arch and then replace the /gnu/store that was created for a nixos system with services.guix <dcunit3d>hopefully i can settle onto one system soon. i'd prefer guix actually. it just all makes more sense to me <hanker>> hanker: anything that is somehow ran during the build should be in native-inputs, yes <hanker>yeah, but linters wouldn't be run during the build normally <kestrelwx>Are you writing a `guix.scm` file for development? Then you want native-inputs. If you're packaging for a channel they shouldn't be included. <Rutherther>hanker: some linters are ran during builds. If the linters you are talking about aren't, then they shouldn't be in inputs of a package at all <hanker>> Are you writing a `guix.scm` file for development? Then you want native-inputs. If you're packaging for a channel they shouldn't be included. <hanker>I'm wondering if I should include dev stuff in `native-inputs` or in a separate `manifest.scm` <csantosb>ekaitz: what about moving kicad to electronics ? Engineering is full of non electronics related packages. <kestrelwx>efraim: Did you try with passing vulkan.so to ld? <efraim>kestrelwx: my local copy of qutebrowser already wraps the binary with LD_LIBRARY_PATH <efraim>I figured my computer is powerful enough that I can do the rebuilds to try to find a solution <kestrelwx>efraim: I'll look in the source if I find anything that might work. <efraim>there's a couple more spots that dlopen libvulkan.so(.1)? so I'll make a "fancy regex" in the substitute* if just patching vulkan.hpp doesn't do it <efraim>(ins)efraim@3900XT /tmp/qtwebengine-everywhere-src-6.9.2$ grep libvulkan\.so . -R | grep dlopen <efraim>at least it wasn't a password :) <ekaitz>csantosb: I'm fine with the idea but not with the implementation -> it would break manifests that use it by importing the package <ekaitz>csantosb: i believe many devs are ok with that kind of package moves, but I don't like them a lot <kestrelwx>'src/core/compositor/vulkan_implementation_qt.cpp' Would having full path to our vulkan matter there? Seems it is called now and then. <csantosb>ekaitz: the same manifest argument applies for any package move, right ? <efraim>kestrelwx: I'm not sure, nixpkgs doesn't set QT_VULKAN_LIB in any recipe <csantosb>ekaitz: which means that once one package lands somewhere, it must stay there forever <ekaitz>csantosb: it doesn't mean that, many packages are moved. It means *I* don't like the moves. :) <efraim>(ins)efraim@3900XT ~/workspace/nixpkgs$ guix shell qutebrowser vulkan-loader qtwayland -- sh -c 'QT_VULKAN_LIB=$GUIX_ENVIRONMENT/lib/libvulkan.so qutebrowser --temp-basedir' <efraim>19:48:11 WARNING: GBM is not supported with the current configuration. Fallback to Vulkan rendering in Chromium. <kestrelwx>QSG_RHI_BACKEND=vulkan QT_VULKAN_LIB=$(guix build vulkan-loader)/lib/libvulkan.so.1 falkon -p/tmp/falkon works. <kestrelwx>Though that's probably not surprising, but QSG.. that's QtQuick var I understand. <efraim>kestrelwx: 70 minutes for the full build. I've added that file to the list and the others in the dlopen list, hopefully this does it <FuncProgLinux>I'm using e.w.w and it works fine but I think it could be useful to have the Webkit widget for pages that need JS <kestrelwx>efraim: I can break Jami with QSG_RHI_BACKEND=vulkan, so probably that needs to be done on QtQuick side? Since Jami is built without. <efraim>guix shell qutebrowser vulkan-loader qtwayland -- sh -c 'QT_VULKAN_LIB=$GUIX_ENVIRONMENT/lib/libvulkan.so.1 QSG_RHI_BACKEND=vulkan qutebrowser --temp-basedir' worked <efraim>oh, yeah, that's basically what I was using for my wrapper <efraim>yeah, I guess that's not really news <kestrelwx>efraim: Just QSG_RHI_BACKEND is not enough is it? <efraim>[10313:10347:1005/205000.522543:ERROR:vulkan_instance.cc(112)] Failed to load 'libvulkan.so.1': libvulkan.so.1: cannot open shared object file: No such file or directory <efraim>[10313:10347:1005/205000.522572:ERROR:vulkan_implementation_qt.cpp(40)] Failed to initialize vulkan instance <efraim>vulkan_implementation_qt.cpp might be enough, but we'll still need to see about patching vulkan.hpp <kestrelwx>I didn't check thoroughly, but it's probably unreachable. <kestrelwx>:./src/3rdparty/chromium/gpu/vulkan/vulkan_cxx. <kestrelwx>18:#define VULKAN_HPP_ENABLE_DYNAMIC_LOADER_TOOL 0 <kestrelwx>efraim: If you still have 6.9.3 could you try just setting QT_VULKAN_LIB? I'd guess it won't work. <bjoli>Hiya folks! I just stopped fighting myn nmutsble base distro and decided to run guix in a <bjoli>Distrobox container. Which OS is the best host for guix? <efraim>kestrelwx: qutebrowser built against qtwebengine@6.9.3 with QT_VULKAN_LIB set did Just Work™ <kestrelwx>So it is 2 bugs perhaps. I think the other one is qtbase, though. <efraim>so qtwebengine@6.9.3 at least would solve the QSG_RHI_BACKEND part <efraim>or at least work around, QtQuick is part of qtbase? <kestrelwx>efraim: I think we need to patch 'src/core/compositor/vulkan_implementation_qt.cpp' still. Also, that Qutebrowser is not built with QSG_RHI_BACKEND right? <luca>lowkey best host for guix is guix system :P <efraim>kestrelwx: patching the dlopen libvulkan instances and vulkan_implementation_qt.cpp in qtwebengine isn't enough, it still can't find the library <efraim>./src/core/compositor/vulkan_implementation_qt.cpp and ./src/3rdparty/chromium/third_party/angle/src/common/vulkan/libvulkan_loader.cpp both have QT_VULKAN_LIB, which was all that was needed for qtwebengine 6.9.3 <efraim>I have been, but I was going to switch to 6.9.3 <kestrelwx>I'm trying to think of Qt apps that use Vulkan and not WebEngine so I can show that they crash/don't work. So far Jami crashes. I dmed you resolution for that. <efraim>tuba was really blurry for me today <efraim>might've been my glasses, it just appeared fine <efraim>I have GDK_BACKEND set to wayland <kestrelwx>qtdiag6 from `qttools` is good enough i guess. <efraim>qtbase has vulkan-headers as an input so we could patch it somewhere to add the full path to libvulkan.so.1 somewhere <kestrelwx>Just to confirm guix shell qttools -- qtdiag | grep vulkan gives you related errors? <efraim>and the error message matches qtbase-everywhere-src-6.9.2/src/gui/vulkan/qbasicvulkanplatforminstance.cpp:80 <efraim>I haven't checked for anything similar, but I'm sure it's everywhere <efraim>uh, no, that's the only 'Failed to load %s:' in qtbase <redacted>I'm trying to package a Zig program, and the runpath validation step is failing. I'm fuzzy on what exactly the issue is. <redacted>"error: depends on 'ld-linux-x86-64.so.2', which cannot be found in RUNPATH"" <efraim>redacted: that sounds like gcc:lib, but I don't know much about packaging zig programs <Rutherther>luca: gdm-service-type is the only service that starts it. You are bringing it in with that set-xorg-configuration <redacted>efraim: Yeah, it looks like it's trying to link against a library it's not finding. <redacted>guix locate tells me that library is living in... fhs-union64? Hmmm <kestrelwx>efraim: I think we want to bump QtWebEngine if possible, so that we don't have to patch the upstream regression from linked QTBUG. <kestrelwx>And we still need to patch that code for Vulkan loading. <nmeum>redacted: ld-linux-x86-64.so.2 is the glibc dynamic linker. however, the binary should likely refer to it by an absolute store path. the runpath validation likely tells you that it found a binary which refers to it by a relative path instead of an absolute path in the store <efraim>kestrelwx: right, qtwebengine 6.9.3 "fixes" the QSG... variable <efraim>so patching libvulkan.so to point to the full path in qtwebengine won't be enough to fix the problem. I'll try an ugly patch in qtbase. <kestrelwx>I think it doesn't have to be ugly, did you see my dm? <redacted>nmeum: And so presumably I have to figure out how to tell Zig where the linker is. I'll dig around for that. <kestrelwx>It goes through a list of paths, worst case we can just add ours after the one user forces and before the default it would. <efraim>kestrelwx: yeah, that file, but I mean hardcoding it in so it can be switched with substitute* is kinda ugly, and definately can't be upstreamed <kestrelwx>Where is that function called from? Maybe the default value could be ours and then we could have that exposed upstream in CMake or so. <efraim>src/plugins/platforms/vkkhrdisplay/qvkkhrdisplayvulkaninstance.cpp:12 <kestrelwx>efraim: We could also just wrap "$PATH" probably? <redacted>Looks like Zig checks /usr/bin/env for information on where the linker is. Odd. <efraim>kestrelwx: patch applied to qtbase, now building out to qttools <luca>Rutherther: Thanks! Removing it worked perfectly :D <redacted>In case anybody searches for this in the IRC archive: the answer was setting #:zig-release-type to "safe" <redacted>I have yet to learn why that is, but that's the answer <kestrelwx>efraim: I'm now curious if that concers Qt5 applications also. <kestrelwx>For `guix shell qttools@5 -- qtdiag | grep vulkan` it seems to be the case. <kestrelwx>Please test unpatched `qtwebengine@6.9.3` and patched `qtbase`, I believe this should work also, if this is not too much trouble. <Deltafire>the unclean mounts on reboot are getting a bit annoying