IRC channel logs

<psycotica0>> Now I understand this, thanks; I'm just a bit surprised.

<psycotica0>I was also surprised once, but there is something nice about the simplicity.

<psycotica0>It means that shell scripts, or python scripts, or game assets in an XML file or whatever all are accounted for. Guix doesn't need to be extended to support whatever tool it's using, it just finds things that are referenced and makes sure the references work on the target machine.

<psycotica0>But there are drawbacks, like most scripting languages don't hard-code absolute paths but instead search a path, and so the auto-detection doesn't work, which is why propogated-inputs exists. And if you had a file format that encoded paths in something other than UTF8 strings that would also not be detected and would need explicit handling. But for being so simple it works surprisingly well!

<ieure>It's feels like one of those "the stupidest thing that could possibly work" solutions.

<ieure>(this isn't a negative thing)

<untrusem>ieure: ahh i saw the update

<untrusem>I have updated the hashes

<untrusem>will make a pr today for librewolf

<ieure>Thank you!

<untrusem>i am at hillhacks.in currently, so not been able to use my laptop that much

<ieure>untrusem, Okay, no problem. Just let me know if you need me to make the PR.

<untrusem>no i can do it

<ieure>Sounds good.

<bdunahu>if a package's output .pc file names a dependency in Requires.private, does it go in propagated-inputs?

<apteryx>bdunahu: yes;

<apteryx>but sometimes we patch the .pc to remove the Requires.private if the list is huge and was autogenerated by e.g. meson

<bdunahu>apteryx: a page on freedesktop.org says that Requires.private is only used by dependents when static linking, but most outputs are dynamic libraries. Is that why we can just remove the field?

<apteryx>it's tricky; the problematic part of pkg-config is that private requires may still be needed to find headers, IIRC

<apteryx>pkgconf has new features that make it possible to mark something as truly private, as in only necessary when building static archives

<apteryx>I think meson knows how to generate pkgconf-flavored .pc that makes use of these new tricks

<apteryx>(and use them at build time too)

<apteryx>bdunahu: I think a reasonable approach is try removing the Requires.private field and see if it breaks any of its users

<apteryx>if it doesn't, then that's good, and we avoided propagation

<bdunahu>it already seems like dependents of the package I'm looking at (radare2) are able to use it's .pc files just fine even though it's not propagating any of the right stuff, which is why I asked originally

<bdunahu>I guess I should just remove all of them since it probably won't break if it isn't already

<bdunahu>thank you apteryx!

<apteryx>yw, have fun!

<retropikzel>Is it possible to add arguments to programs with (wrap-program)?

<csantosb>for example ?

<yelninei>bjc: Got a bit further, XOpenDisplay is aborting, libxcb sets the error to XCB_CONN_CLOSED_FDPASSING_FAILED and then exits

<bjc>the thing i never seem to understand is how this works on debian but not guix

<bjc>are you cross-compiling for the x build or native?

<yelninei>both dont work, recvmsg sets MSG_CTRUNC in msg.msg_flags, so I guess it is libc? linux man pages say "some control data was discarded due to lack of space in the buffer for ancillary data."

<yelninei>debian probably has some patches that were never upstreamed

<yelninei>bjc, glibc recvmsg gets a msg_controllen of size 76, it reads 2048 so it is correct to set the truncate flag

<yelninei>bjc: increasing the buffer works and x11 forwarding works. Not sure yet why glibc claims that the received buffer is so large

<mlxdy>Hi, qemu and distrobox should be installed locally or globally?

<bjc>i run qemu out of my user profile most of the time

<bjc>yelninei: so recvmsg is returning 75? but it goes on to fill up a 2k buffer anyway?

<bjc>or is the msg actually 2k, but recvmsg is only giving back 75?

<bjc>i'm not au fait with x11 protocol, but i'd be real surprised if the handshake portion uses packets that are larger than most mtus

<yelninei>xcb allocates a buffer of ~80 bytes. this gets passed to recvmsg. recvmsg says that the actual message is 2048 so it sets the MSG_CTRUNC flag to indicate truncation. xcb dies because of that

<yelninei>the size in libxcb seems right. so why does pflocal/pfinet (?) think the siuze is so large

<yelninei>bjc: On debian amd64 the len is always 0 which also does not look right but that is ofc large enough

<bjc>2k is very suspicious and feels like there's a buffer somewhere

<bjc>i'm confused if recvmsg is returning 0 on debian how any messages are getting through

<bjc>that should indicate the port is closed

<yelninei>aah it was not implemented before so always returned 0 (i still have the image from last year)

<yelninei>i think the fix is 4cb81d779d1d3e1d5db0c76bffe71b9c91b3aa1d , oh god this was annoying to debug

<bjc>is that in glibc?

<bjc>and if you got an x server working just now, i'm sorry that bug was so annoying to track down but from my perspective it was very worth it =)

<yelninei>its in hurd/pfinet so easy to patch. I am rebuilding everything right now as it still needs a fix for how the cross glibcs get build (to have a bash that can actually be executed

<yelninei>a (cross) compiled x server is a whole new level just because the current mesa package is very linux specific

<bjc>that pfinet change makes sense and answers why the buffer is 2k

<yelninei>i guess for a native x server it would not go over pfinet

<bjc>unix domain these days, though no idea on hurd

<yelninei>while debugging this has been annoying it so rewarding when you finally find out what goes wrong (although i am not sure if I would have been able to figure the fix myself)

<bjc>it's been a while since i've felt that reward. mostly i just feel a sense of relief

<bjc>like i can *finally* stop gnawing on this bone

<yelninei>i love this kind of things. But then you spend hours chasing down a bug for a single character diff at the end

<bjc>so what do i need to get x working? ;)

<yelninei>The hurd patch from the commit above, https://codeberg.org/guix/guix/pulls/9062 and https://codeberg.org/guix/guix/pulls/9037 for x11 forwarding

<argp>Hey, I'm enjoying the guix shell for projects. But some dependencies also have info pages. Is there a way to make Emacs read the info pages for dependencies loaded from project?

<yelninei>For x itself the thing is currently on my branch https://codeberg.org/Yelninei/guix , you might need parts of https://codeberg.org/guix/guix/pulls/9096 to fix cross compiling

<yelninei>argp argp add info-reader (or emacs) to the shell. This will setup INFO_PATH

<argp>yelninei: That worked if I open info inside the shell. But running Emacs when loading the project didn't load the Info pages.

<argp>I'm using direnv and emacs integration

<argp>The INFOPATH is updated. I wonder if Emacs is scanning and caching the info pages.

<yelninei>i dont know how direnv works, is it updated inside emacs itself?

<argp>Yeah, the Emacs package runs the direnv which runs the guix shell and generates a list of environment variables. Emacs package then loads those variables.

<argp>So when I'm doing (getenv "INFOPATH"), it shows the same value as guix shell when the current directory of emacs is in the project.

<argp>Is there a better way for loading manifest.scm? I'm using this because its documented in the cookbook.

<argp>I switched to using envrc instead of direnv.el and its working as expected now.

<yelninei>ihave never been more happy to see xeyes

IRC channel logs

2026-06-06.log