IRC channel logs

2025-11-10.log

back to list of logs

<apteryx>Hello, Guix!
<flurando>hi, is there anyone working on implementing the http-proxy switch for nix-service-type? just like how it was done for guix-service-type? I am learning the guix-service-type source code, just checking if anyone is already making progress here.
<flurando>To my understanding, it could be portable, and we even could abstract a step further, so that any sheperd daemon could be wrapped in the same way for their running environment env vars be changed.
<flurando>currently, I directly copied the whole nix-service code, then hardcoded my required http_proxy and https_proxy in the nix-shepherd service, which is, working but ugly...
<flurando>I am wondering whether copy&pasting plus some name substitution would work
<cbaines>any ideas why inkscape on the python-team branch is failing to build for x86_64-linux https://data.qa.guix.gnu.org/gnu/store/fngzilrjv98glhd7ya1845z3zjk6k0ka-inkscape-1.3.2.drv
<cbaines>ci.guix.gnu.org has a substitute, but the build log is very different https://ci.guix.gnu.org/build/15404334/details
<kestrelwx>y
<sneek>kestrelwx, you have 2 messages!
<sneek>kestrelwx, ArneBab says: accorting to reflect.scm, '() becomes null in wasm.
<sneek>kestrelwx, dthompson says: yes, you'll need to acquire a reference to the null object.
<kestrelwx>Hi!*
<civodul>“waiting for locks or build slots...” :-)
<civodul>o/
<cbaines>civodul, I think your help might be needed for parts of https://codeberg.org/guix/maintenance/issues/13 , especially migrating guix-hpc.bordeaux.inria.fr and maybe shepherding.services/shepherd.tools
<civodul>cbaines: yup, will do!
<kestrelwx>Did data just go down?
<identity>with 8ab49a4f58, niri-home-service adds xwayland-satellite to your home profile unconditionally, which is yuck. this should be gated behind a toggle
<identity>it also would work just as well with just adding the xwayland-satellite package to your home profile yourself
<kestrelwx>Could be in a service packages list probably.
<jlicht>identity: it was brought up in review, but decided against
<cbaines>kestrelwx, can you be more specific?
<kestrelwx>`data.guix.gnu.org` didn't load once, then it loaded fine, but only showed an error occured message, and `packages.guix.gnu.org` says it doesn't respond.
<kestrelwx>Right now it seems fine.
<identity>jlicht: could you link to the discussion?
<kestrelwx>I was just seeing if the websites that moved to Hetzner won't load without a VPN anymore.
<cbaines>civodul, 46.224.9.33 is the IP address for the guix-hetzner-2 machine, we can always add a guix-hetzner-2 DNS entry though
<cbaines>you should be able to SSH in, and I can set a root password for you
<cbaines>I've never been brave enough to try guix deploy, so I'm just reconfiguring on the machine
<jlicht>identity: https://codeberg.org/guix/guix/pulls/4076
<civodul>cbaines: it would have been a good opportunity to eat dog f^W^W try out the new Hetzner backend
<civodul>i can ssh anyway, thanks!
<cbaines>civodul, maybe, I guess I'm a bit put off hearing about the problems with hydra-guix-129 and the CI ARM machines
<cbaines>one area for improvement I did find is the networking configuration, I don't think dhcpcd handles IPv6 (at least by default), and the static-networking-service-type isn't able to handle the IPv4 configuration used in Hetzner
<civodul>cbaines: could you add me a password so i can sudo (or remove sudo password for “wheel” members)?
<civodul>cbaines: i’m not sure what problems you heard of; ‘guix deploy’ is far from perfect but it does the job for me
<civodul>(with the SSH backend)
<civodul>could you report a bug regarding static-networking-service-type and the Hetzner config?
<cbaines>civodul, I've enabled passwordless sudo now
<civodul>thanks
<cbaines>here's an issue for the static networking thing https://codeberg.org/guix/guix/issues/4175
<cbaines>kestrelwx, I saw an error as well, I think it's scraping activity, the response code should be 503 rather than 500, but unfortunately the error page is the same
<cbaines>I'll look at customising the error page so it says that it's a load issue, rather than a error
<kestrelwx>Makes sense, thanks.
<civodul>hey, has anyone tried to package Delta Chat?
<civodul>looks like an interesting tool
<Deltafire>possibly, someone mentioned it in here a couple of weeks ago
<Deltafire>just checked the logs, they were working on a bot for Delta Chat - not packaging
<gabber>what's the standard way to tell the build process where to look for the shared object libraries for the package to be built? i have a package that just dumps all the binaries in the same directory, but gnu-build-system doesn't patch the elf. there is an RPATH option for qmake - should i set that to the output directory/lib where i also install the shared object libraries?
<civodul>bordeaux.guix.gnu.org substitutes are pretty slow right now
<nmeum>Guix does presently not have a set of CFLAGS/CXXFLAGS/… that it passes to all packages, right? is there a why there is no common set of compilation flags for Guix? other distros for example pass various hardening flags (-fstack-protector-strong, -fstack-clash-protection, -fcf-protection, …) by default
<adanska>is bordeaux being slow for anyone?
<adanska>specifically serving narifos
<adanska>*narinfos
<cbaines>civodul, adanska, the nar-herder is really struggling, and I'm not quite sure why
<cbaines>I'm surprised it's still working actually as I thought it ran out of file descriptors
<attila_lendvai_>it's very slow for me, too (hungary)
<adanska>oh wow! good to know it wasn't just me. I hope everything's okay :)
<attila_lendvai>there's no way to put it on a temporary blacklist, e.g. from the command line, right?
<adanska>no, you have to respecify --substitute-urls for each command
<adanska>just temporarily export an envvar with all the ones you want
<jodijodington>is it normal that when I'm booting linux (basically right after the grub bootloader screen) I see that some guile script is segfaulting? I can't see it in dmesg so im not sure where the message is coming from. Herd maybe? Everything appears to be functional so I'm not worried but it feels very odd
<singpolyma>Hey all. as of this morning suddenly every nar file I made with guix archive export tells me "guix archive: error: corrupt input while restoring archive from #<input: file 0>" when trying to import or list... any ideas on how to debug this?
<singpolyma>guix archive --export bash | guix archive --list gives me that error and also guix archive: error: fport_write: Broken pipe
<jodijodington>if it helps, I just ran that command and got the same thing so it's not just you
<attila_lendvai>jodijodington, i'm also seeing that segfault at boot. it's not normal, but it doesn't seem to have any ill effect on my machine either
<jodijodington>good to know it's not just my machine
<singpolyma>ok, it seems to be that debian removed guix from stable and my upgrade broke i by installing only guile-3 versions of dependencies
<yelninei>The segfault at boot is harmless https://codeberg.org/guix/guix/issues/735
<jodijodington>never heard of a program handling SIGSEGV lol, that's interesting. I'm glad it's harmless though
<untrusem>civodul, I used arcanechat on android ( deltachat client)
<untrusem>what was the guix command to update the hashes of a package when bumping version?
<untrusem>commit hashes I mean
<FuncProgLinux>untrusem: guix refesh ?
<FuncProgLinux>refresh
<untrusem>ohh yeah
<untrusem>thanks
<benjaminwil>hi there, i've been following the common workflow for rust packaging documentation, but the repository i am trying to package contains the source for two rust crates and ./pre-inst-env guix build always fails to build the second crate because "error: no matching package named 'kak-tree-sitter-config' found" even though i tried to manually add that package to rust-crates.scm
<benjaminwil>i made a paste with the stack trace, a git diff of my guix branch, and the guix import commands i used https://paste.debian.net/hidden/4039b17e/
<untrusem>I just added a package to my channel and found out it is already added into guix proper
<untrusem>lol
<benjaminwil>:')
<gabber>benjaminwil: if your problem persists chances are higher to actually get help when you consult one of the mailing lists
<gabber>that being said: i have no clue about rust packaging (:
<benjaminwil>gabber: thank you for the suggestion! just getting oriented to the whole guix world :)
<gabber>benjaminwil: welcome!
<untrusem>you should open codeberg issue as well
<NaN23>Hello everyone, is somebody going to 39C3 at Hamburg this year?
<NaN23>I plan to promote guix at this event (there are already a lot of Nixers) and think currently about presenting a self-organized session or giving a workshop there. Also would like to connect to other guix users. Ah btw for the people who doesn't know this event, this is Europe's largest hacking event (around 15k persons) organized by the Chaos Computer Club (see events.ccc.de/en or media.ccc.de)
<ElevatorConnoiss>Hello! I have a question about packing patches to a program. I have made a custom package for st to apply the official scrollback patch https://st.suckless.org/patches/scrollback/ . I wanted to add another patch, and I was wondering what the best way to do that. Right now, I'm just defining each patch as an origin and using the (patches) in the
<ElevatorConnoiss>custom st origin to apply them. I was considering making them all into packages because the patches do have dependencies and conflicts, and that would make each one optional--is that possible?
<JodiJodington>ElevatorConnoiss: is this for you or are you going to be distributing these packages? if it's just for you, you could make life a hundred times easier for yourself by making a fork of st where you apply those patches and then telling guix to use that as the origin. At some point, youll get patch conflicts and need to manually intervene
<ieure>ElevatorConnoiss, Normal process for this is to put the patches into gnu/packages/patches and use `search-patches' in the origin, which will apply them.
<ElevatorConnoiss>JodiJodington: I was hoping to contribute them back to the main guix repository; they're official so I figured others might want them.
<ElevatorConnoiss>ieure: Thanks, I'm looking into that now.
<ieure>Rutherther, ugh. So I just found that the root of a mysterious "failed to resolve" error with autofs is due to the system's `mount' not being able to find `mount.nfs'. The mount helper is in the nfs-utils package, which autofs has as an input, but since it's not in the profile, `mount' can't find it.
<ieure>Rutherther, The simple solution here is to propagate `nfs-utils', but I also don't like that. Do you know of any other approach that could fix this without propagating?