IRC channel logs

2026-02-23.log

back to list of logs

<pers0n>are guix channels cloned to a specific location locally so i can browse the code without git cloning again elsewhere?
<mange>I think ~/.cache/guix/checkouts should have it.
<pers0n>perfrct
<kestrelwx>Hello!
<efraim>o/
<futurile>morning all
<efraim>o/
<seres_>o/
<jlicht>o/
<jlicht>o/ (in case it did not get through)
<kestrelwx>jlicht: it did fortunately.
<futurile>Today I'm going to give jujutsu a try-out, I just don't love git. Anyone used it?
<efraim>let us know how it goes!
<Alavi_me>git is life
<efraim>live, laugh, morge
<identity>restore, reset, reflog
<charlesroelli><apteryx> is anyone else hosting their own IRC bouncer on Guix? << yes, running a soju service on this box
<jlicht>futurile: magit ruined me for anything else :-)
<identity>jlicht: see <https://github.com/0WD0/majutsu>
<efraim>that sounds like heresy
<trev>does anyone know how to add glibc 32 bit headers to a manifest.scm?
<trev>should i use package->development-manifest and specify the #:target as i686 then include gcc-toolchain or something ?
<civodul>hi trev! i think it’s not feasible, because ‘glibc’ in Guix on 64-bit platforms is built without 32-bit support
<sneek>Welcome back civodul, you have 1 message!
<sneek>civodul, yelninei says: I rebuilt commencement.scm on my branch with coreutils 9.10 and new gash so all new problems should be resolved. Id appreciate it if some of the changes can be moved off to find out what else upgrading perl breaks. I solved it for the 3 texinfos but i am unsure what to do about curl.
<civodul>sneek: seen yelninei
<sneek>yelninei was in #guix 18 hours ago, saying: janneke: I am rebuilding with the new gnumach tag and compat phase removed, the i586 bootstrap did not change in between the commit and now but i dont seem to have any problems (yet).
<jlicht>identity: thanks!
<janneke>A week or two ago i pushed https://codeberg.org/guix/guix/commit/0978ce1e62627531d3aef9fe981f5a154755d28f in the hope to get a https://ci.guix.gnu.org/search/latest/image?query=spec:images+status:success+system:x86_64-linux+hurd64-barebones.qcow2 built...
<janneke>anything i should have done, or could do, to increase the chances of that 64-bit image showing up?
<trev>thanks civodul
<fhang>I'd appreciate it if someone could review and merge <https://codeberg.org/guix/guix/pulls/6624>. It would fix a long-standing issue with Qtile, and I will finally be able to update my system.
<futurile>fhang: according to this - https://ci.guix.gnu.org/search?query=qtile+spec%3Amaster+system%3Ax86_64-linux it's building
<dariqq>had some time to look into my issue with mingw binutils, but i am not sure if it would be better to put it in binutils directly
<fhang>futurile: I do not see any builds for qtile-0.33.0, the one that the PR introduces. Or am I missing something here?
<futurile>fhang: I see qtile-0.34.1 - building on master now
<futurile>fhang: https://ci.guix.gnu.org/build/18115380/details is the first link down
<futurile>fhang: so maybe python-team merged in a new version of Python that means qtile@0.34.1 builds fine; no need to downgrade it
<fhang>futurile: The downgrade is supposed to be a quick fix as I'm not sure when the `python-team` branch will be merged.
<fhang>Unless I missed the commit which makes Python 3.12 the current version in Guix?
<nemin>Per the build logs, it built with 3.11.14
<fhang>Qtile builds successfully with Python 3.11 but crashes at runtime since it needs Python 3.12. It seems that the tests are disable, which might explain why this is not caught.
<mwette>I'm trying to build xyce-parallel on foreign aarch64. It's failing test with "hwloc/linux: failed to find sysfs cpu topology directory". Any ideas what that could be?
<futurile>fhang: you can see the order for merging by each team here: https://qa.guix.gnu.org/
<futurile>fhang: yeah, it looks like python-team isn't actively in the queue
<futurile>fhang: jgart pinged python team - guess wait a day to see if they respond
<fhang>futurile: Thanks, I've seen people mention something about a "merge queue" but never knew where to see it. That link is now bookmarked.
<fhang>futurile: Thank you for your help.
<futurile>fhang: no worries, regressions are annoying!
<mwette>I think I found issue. likely timeout? hwloc-gather-toplogy takes 2m15s
<nemin>Getting a PR merged is such a dopamine rush.
<identity>better get addicted and make more PRs
<intermet>Hi there! I defined and added a dnsmasq service to redirect dns resolution to example.org to localhost. How to make my system use dnsmasq as the DNS resolver?
<atomalabu>if i have the guix package manager, and the guix source tree, can i provision a guix installation on a drive? the system subcommands will just work from any linux host?
<ieure>atomalabu, Yes.
<atomalabu>ieure thank you
<mrh57>does anyone host a prosody (xmpp) server?
<mrh57>I got the guix service up and working, but I don't know how to add modules which are already packaged for guix (e.g. cloud_notify)
<mrh57>pounce/znc such a qol upper
<cricri>Hi all, I am installing guix on a laptop. Something went wrong with uefi/grub and I just wanted to reinstall the bootloader. So I booted from the installer stick again adn do 'guix system init configuration.scm /mnt'. But it fails with:
<cricri>guix system: error: reading file `/gnu/store/xyzhash-eudev-3.2.14-checkout.drv': No such file or directory
<cricri>Why does it look for that file and how can I fix it?
<gnucode>do most packages in guix support downloading the source code via tarballs and git repos ? Or is it usually one or the other ?
<ieure>gnucode, All packages have exactly one source definition, downloading a tarball and clowning git are two of the options for that (there are others).
<gnucode>I'm currently running the Hurd on real hardware on a T420 and the internet speed can vary between 8 - 60 KB/s. I just don't see guix being a quick package manager on the Hurd.
<ieure>Packages don't let you choose the method of obtaining the source, they declare the method in their definition and that's what gets used.
<gnucode>ieure: I guess what I'm asking is...is there some option like "guix package -i somePackage --no-substitutes --onlyDownloadTarBalls
<ieure>gnucode, `guix package -S some-package' will download the source, using whatever mechanism the package declares.
<gnucode>I'm asking if that is an option, because it seems to me that downloading the tarball may be faster, and the Hurd is not sooo fast at cloning git repos. I've been cloning the netsurf web browser repo for 1/2 hour - 1 hour. It's been very slow unfortanately.
<gnucode>ieure: is it possible for a package to declare 2 download methods ? One is a git repo the other is the tarball? or is it exclusive? That package author has to specify one.
<ieure>gnucode, No, as I attempted to explain already.
<ieure>Is the slow speed due to your connection itself, or is Hurd's networking really inefficient?
<gnucode>the Hurd's TCP/IP stack is using an Linux 2.3 or 2.4 TCP/IP stack.
<gnucode>So it's a bit dated. :(
<gnucode>It's possible that the Hurd developers will migrate to using NetBSD's TCP/IP stack, but that has not happened yet.
<gnucode>I am currently using a NetBSD driver for my ethernet nic. I didn't write the code.
<ieure>That cannot be the root of the problem, Linux was deployed at massive scale in the 2.x era and ran some of the largest websites on Earth.
<gnucode>I'm just a hurd user. Not a Hurd developer. Feel free to ask in #hurd or email bug-hurd if you want a more accurate answer. :)
<ieure>Sounds like that's what you should do; I don't run Hurd at all.
<ieure>I did run Linux 2.x on plenty of machines when it was current, networking performed fine. I could saturate 100mbit Ethernet easily.
<ieure>Point being, it seems like you're asking for an... unusual workaround, but maybe the root problem is really where effort should be getting expended.
<ieure>Presumably, you wouldn't need the feature you're asking if the network was faster.
<futurile>I guess you can't even use a different local system to get substitutes
<gnucode>it could be possible that I'm just mis-reading how fast my internet speed is.
<futurile>the other thing that can be happening is that substitute servers we use have variable connectivity
<ieure>Yeah, I'd start by checking throughput and packet loss to another machine on the local net.
<futurile>you could try use a different one -
<attila_lendvai>lack of substitutes for a guix pull that has just finished is easily the topmost negative with day-to-day guix usage. it's exactly the moment when you usually don't want to wait for a browser to build locally...
<futurile><sympathy>
<attila_lendvai>and compared to how the negative it creates, it seems to be pretty easy to address with a two-branch setup
<charlesroelli>mrh57: try e.g. (prosody-configuration (plugin-paths (list prosody-cloud-notify)) (modules-enabled (cons* "cloud_notify" %default-modules-enabled)) ...).
<mrh57>charlesroelli: ah nice! I forgot packages are file-like, worked like a charm
<futurile>attila_lendvai: you saw I brought it up on guix-devel right?
<futurile>attila_lendvai: it's a thread called 'Ideas to improve our commit flow' - a few people took part with ideas
<attila_lendvai>futurile, yeah, and i appreciate it. this situation has been the same from the first day i started using guix (~5 years ago). i also brought it up a few times.
<futurile>attila_lendvai: I'll try pushing it - Rutherther had some other ideas as well - so maybe we can keep up with something
<attila_lendvai>my impression is that the core people, who know enough to fix this, probably also know an escape hatch that is easy enough that this doesn't get too high on the todo list
<attila_lendvai>yeah, Rutherther is a welcome new energy on the team
<futurile>attila_lendvai: yeah, my guess is that over time we all adapt to it and forget it's a sharp corner. I basically go guix pull against a commit 24 hours old so I know substitutes are built
<untrusem>how to use commiters.scm?
<untrusem>this is because csantob mentioned it in https://codeberg.org/guix/guix/pulls/6593#issuecomment-10881704
<futurile>untrusem: ask them on the PR - I actually have no clue - and there's no comment at the top of it
<futurile>untrusem: I'm not an emacs user, so I assume all the scripts don't work for me ;-))
<untrusem>don't tell me you use vim
<futurile>oh yeah! and the cli (guix repl), and a bunch of scripts I have using a 'justfile'
<untrusem>so you are a minority here :p
<untrusem>futurile: actually your posts were the starting point for me in guix, so thank for that
<futurile>untrusem: you're welcome, I'm always happy when someone says they've found them useful
<futurile>untrusem: they started becoming a lot of work - got performance anxiety I think heh heh - and also too long!
<futurile>untrusem: but I should get back to them - I have loads of other topics I'd like to cover
<attila_lendvai>futurile, and what do you do when nonguix also needs to be rolled back... :) i'll go and pick a commit with the new kernels, hoping that is covered
<futurile>attila_lendvai: actually I do both at the same time and look at nonguix's substitute server as well
<futurile>attila_lendvai: https://guix.bordeaux.inria.fr/jobset/nonguix
<futurile>attila_lendvai: I need to script the whole thing
<attila_lendvai>i don't know how to do guix pull --commit= for nonguix, so i guess that's what i talked about above, that it's not a burning issue for the more expert experts than me
<futurile>attila_lendvai: ah right - so what I do is create a channels file. I put the commits to for guix/nonguix into that. And then do a guix pull using that channels file - it means my laptop/workstation/vms all stay on teh same commits
<futurile>attila_lendvai: the only one I use gux pull --commit=xx is for my ubuntu 'root' account
<futurile>attila_lendvai: I described it recently - it's much easier to do than to write an email about: https://lists.gnu.org/archive/html/help-guix/2026-02/msg00063.html
<attila_lendvai>ACTION is back to building a browser locally...
<attila_lendvai>futurile, when i really have to, i do the same. but this time, all i wanted is to add a new package to my emacs. but then i thought to myself, why not also pull before that...
<untrusem>attila_lendvai: your room must be hot now
<untrusem>what browser are you building?
<untrusem>futurile: |ooking forward to it
<attila_lendvai>i have that channel file installed at the default location... then the next issue is when i forget the commit hashes in them... and the errors are not obvious, nor even visible that i'm not pulling with my guix pull
<attila_lendvai>untrusem, from me fuming, i guess... :)
<attila_lendvai>untrusem, it's the tor browser, but it doesn't matter, it could be any large project.
<futurile>totally - I agree it's annoying - I don't really understand why we commit direct to 'master' - it just seems to be inertia
<futurile>on the one hand - when I ask about the CI infrastructure people say it's fast enough - on the other when I create a branch it never get's built. So eveeryone commits to 'master' so their change gets built.
<untrusem>attila_lendvai: yes torbrowers is not having any substitutes for like a week