| 20 Sep 2025 |
 emily | netcat = libressl.nc.overrideAttrs (old: {
meta = old.meta // {
description = "Utility which reads and writes data across network connections — LibreSSL implementation";
mainProgram = "nc";
};
});
| 18:07:23 |
| emily | baffling use of .overrideAttrs | 18:07:29 |
| emily | oh I guess it's an output | 18:07:32 |
| emily | I guess netcat-openbsd is Debian's fork and libressl.nc is closer to upstream OpenBSD netcat? | 18:08:19 |
| emily | looks like Arch prefers nmap's ncat or openbsd-netcat (https://wiki.archlinux.org/title/Network_tools#Netcat), Homebrew packages GNU netcat as netcat… | 18:09:44 |
 aloisw | It was that way even for the previous actual netcat-openbsd package. I do not know whether OpenBSD uses the netcat included in LibreSSL but presumably yes. (On the other hand netcat-openbsd does not depend on any TLS library, so unsure whether Debian patched that out or it was already that way upstream). | 18:09:54 |
| emily | (and indeed has no OpenBSD netcat; I guess the Debian one doesn't compile on Darwin. not sure if their libressl includes it) | 18:10:16 |
| emily | my assumption is TLS was added later and the Debian fork happened ten million years ago. | 18:10:35 |
 Marie | I had also had to replace libressl for netcat since it doesn't build on ppc | 18:14:02 |
| Marie | * I also had to replace libressl for netcat since it doesn't build on ppc | 18:14:08 |
| Marie | (and that was easier than fixing libressl) | 18:14:26 |
| aloisw | Incorrect, Debian patches it out: https://salsa.debian.org/debian/netcat-openbsd/-/blob/debian/latest/debian/patches/build-without-TLS-support.patch?ref_type=heads | 18:16:19 |
| emily | as in you built libressl.nc with OpenSSL? | 18:16:23 |
| emily | ah, it uses libtls of course. so no chance to get TLS without LibreSSL. | 18:16:51 |
| emily | probably we should just use netcat-openbsd then. | 18:16:59 |
| emily | unless nmap's version is good. | 18:17:09 |
| aloisw | Although that does lose TLS support and drags in more Debian junk. | 18:17:30 |
| emily | does anyone actually use nc(1) for TLS? it's always openssl(1) IME. | 18:17:58 |
| emily | I was hoping the broken = stdenv.hostPlatform.isDarwin; in netcat-openbsd would be outdated, but it is sadly now. | 18:18:25 |
| emily | * I was hoping the broken = stdenv.hostPlatform.isDarwin; in netcat-openbsd would be outdated, but it is sadly not. | 18:18:26 |
| emily | netcat.c:817:14: error: call to undeclared function 'accept4'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
817 | connfd = accept4(s, (struct sockaddr *)&cliaddr,
| ^
netcat.c:817:14: note: did you mean 'accept'?
/nix/store/8f25drv3142v3pijkqyx03gags0rscw0-apple-sdk-11.3/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/socket.h:700:9: note: 'accept' declared here
700 | int accept(int, struct sockaddr * __restrict, socklen_t * __restrict)
| ^
netcat.c:818:15: error: use of undeclared identifier 'SOCK_NONBLOCK'
818 | &len, SOCK_NONBLOCK);
| ^~~~~~~~~~~~~
netcat.c:1152:42: error: use of undeclared identifier 'SOCK_CLOEXEC'
1152 | if ((s = unix_bind(unix_dg_tmp_socket, SOCK_CLOEXEC)) == -1)
| ^~~~~~~~~~~~
netcat.c:1155:42: error: use of undeclared identifier 'SOCK_CLOEXEC'
1155 | if ((s = socket(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC, 0)) == -1)
| ^~~~~~~~~~~~
netcat.c:1222:7: error: use of undeclared identifier 'SOCK_NONBLOCK'
1222 | SOCK_NONBLOCK, res->ai_protocol)) == -1)
| ^~~~~~~~~~~~~
netcat.c:2102:17: error: use of undeclared identifier 'IPTOS_LOWCOST'
2102 | { "lowcost", IPTOS_LOWCOST },
| ^~~~~~~~~~~~~
| 18:18:59 |
| emily | I suppose this is why Homebrew packages GNU netcat. | 18:19:10 |
| Marie | no, i just did netcat = prev.netcat-gnu | 18:19:13 |
| aloisw | Not sure about users. At least the libvirtd module did originally not depend on netcat-openbsd for TLS (which was the Debian fork at that time I think), but for unix socket (https://github.com/NixOS/nixpkgs/pull/1087). | 18:25:46 |
 ghpzin | Just FYI I figured out how to "fix" mesa with gcc15, apparently rustPlatform.bindgenHook just propagates gcc/glib by default.
So everything that has that hook can use gcc instead of clang (maybe even always uses them, depending on whether bindgen cares about order in BINDGEN_EXTRA_CLANG_ARGS). | 18:44:57 |
| emily | as in your fix is to just make it use Clang instead? | 18:45:26 |
| ghpzin | As in just removing hook and leaving bindgen fixes it. | 18:45:43 |
| ghpzin | * As in just removing hook and leaving bindgen fixes it, yes. | 18:46:14 |
 dramforever | ... is it including two copies of <stdatomic.h> | 18:46:18 |
| dramforever | and breaking #include_next? | 18:47:13 |
