IRC channel logs

<Alicia>I narrowed down a testcase for the multiprocessing python module issues: https://ion.nu/tmp/hurd_multiprocessing.py.txt . on GNU/Linux it runs and exits without any output

<nexussfan>interesting

<damo22>ENOENT = 0x40000002, /* No such file or directory */

<damo22>that is the hex value of your error

<Alicia>ok :)

<Alicia>I figured I'm getting the error because it's trying to connect to a socket by the name "" (empty path), but it's unclear why the path is empty on Hurd

<damo22>ok

<youpi>getsockname doesn't return a path on unix sockets on the hurd

<youpi>because they are essentially anonymous

<youpi>at best we could record the path that was used for creating it

<youpi>but even that is not really an easy thing

<youpi>so application should just remember where they have created the socket...

<damo22>can we name them uniquely with a random string??

<damo22>s/??/?

<damo22>eg, sock-anon-abcd123456

<youpi>numbering is not the problem

<youpi>being to open it again is

<youpi>as in: where do you open it

<damo22>i dont know how sockets work

<youpi>possibly we could return a /servers/socket/2/foobar

<youpi>which applications can then open, whichever path was used to create it initially

<youpi>but then we don't have the unix permissions

<youpi>so it will be unsafe to do that

<Alicia>oh, I made a mistake in my troubleshooting and thought I was getting a path back from getsockname, but yeah just doing self._address=address a few lines down from the setsockopt call seems to fix it. or work around it at least

<youpi>really, can't applications just remember where they have put their sockets...

<youpi>even on linux it's quite meaningless to return something in getsockname

<youpi>the admin may have moved the socket

<damo22>ok

<Alicia>for now the icecat build is continuing :) will see what turns up next in the morning

<nexussfan>nice :D

<azeem>I have the same getsockname() problem with Perl

<azeem>but there even Perl itself doesn't know and wants to check on send()

<azeem>looks like on Linux I can move the socket as root and it still works

<Alicia>next up in the icecat journey: getting "memory allocation of 11665424 bytes failed" in one of the rustc invocations. from htop it doesn't seem like I'm out of RAM but there are probably better ways to check that

<Alicia>(back on 64bit Hurd, with 16GB RAM)

<etno>Hi ! I would like to get 'bear' to build in debian, so I am working on porting google-perftools and grpc.

<etno>(I don't even understand why bear depends on this...)

<azeem>probably for remote debugging or something

<etno>I think that the tool is made of a client part started with each compiler call, and a server part building the database. This is way overkill

<etno>grpc build is not completed, the directory weights 5GB :-S

<azeem>maybe you can tune debian/rules to only build some essential parts of it

IRC channel logs

2026-03-16.log