IRC channel logs

2024-07-20.log

back to list of logs

<azert>etno: I’ve seen that you unbroke the libuv build, congrats
<azert>You got your pull requests merged
<etno>sneek: later tell azert I wish I could have made use of the stub detection macros, but CMake didn't help. Lua-luv now goes a bit further in the build tests. Current failure is with calling getsockname() on a UNIX socket.
<sneek>Got it.
<azert>etno: good to know, i think that libuv itself also has an extended tests library
<sneek>Welcome back azert, you have 1 message!
<sneek>azert, etno says: I wish I could have made use of the stub detection macros, but CMake didn't help. Lua-luv now goes a bit further in the build tests. Current failure is with calling getsockname() on a UNIX socket.
<azert>etno: you might be interested in this, https://lists.gnu.org/archive/html/bug-hurd/2005-03/msg00216.html
<azert>I wonder what libuv does for FreeBSD
<etno>azert: interesting indeed! Libuv keeps an optional attribute for the socket object. I think that this would address the problem in the right way ?
<etno>Optional attribute==path used for binding
<azert>it would address it in the libuv way
<azert>Yep
<etno>A complete fix would be to have a reference to some sort of underlying file identifier and resolve it canonically in each process context. That seems overcomplicated to me.
<etno>And probably indeterministic as well
<etno>I mean, the same file can be in several places even for one process.
<etno>So... The real fix would be to not use getsockname() :'-D
<azert>I think that the philosophy of libuv is to unify semantics across systems for apps using libuv. If Hurd does the same as FreeBSD and others not supporting this function, that fits the goal
<azert>Anything better would be an issue :D
<etno>:D
<etno>Searching for the FreeBSD macro conditionals might lead to the right place. I'll see if I can spot it. 👍
<azert>It might also be in the FreeBSD specific file
<etno>Btw, I am not sure how to contribute the patches to debian maint. Maybe a PR on salsa with the quilt series ? But this is not the right channel
<azert>They will be picked up eventually with the future releases
<etno>I was under the impression that some particular patches could be taken for the same upstream version (bumping the number after the dash)
<etno>Indeed, the next upstream version is likely to be broken, since we don't have Hurd builders in the libuv repo