Hello, Hefee, le jeu. 19 févr. 2026 13:05:26 +0100, a ecrit: > we are now in 2026 so this is open since more than 10 years now :( I would > like to fix this. Unfortunately I do not understand why this patch fix the > usage > on hurd. > > Can you explain why this fixes the issue?
Looking at the change, it seems to be circumventing the fact that syscall() is not really defined on GNU/Hurd. Instead of defining arbitrary values for TSOCKS_NR_*, we could as well put the syscall redirection code inside #ifndef __GNU__ since there is nothing to redirect, applications running on GNU/Hurd won't ever be using syscall(). Samuel > Actually you need to convince upstream to add your patch. I want to have a > minimal diff with upstream, that's why I would only include it in Debian if > upstream accepts the patch. I can also forward a MR, but without being able > to > explain it does not make sense to forward a MR. > > https://gitlab.torproject.org/tpo/core/torsocks/-/merge_requests > > Regards, > > hefee > > -- > > On Donnerstag, 20. Juli 2017 11:58 Petter Reinholdtsen wrote: > > [intrigeri 2014] > > > > > Hi David, > > > > > > could you please have a look at this Debian bug report: > > > https://bugs.debian.org/767235 > > > > > > Thanks in advance! > > > > > > [Dropping the "patch" tag, as it seems unclear that the patch actually > > > does the right thing.] > > > > As far as I can tell, the tsocks_syscall() function is not used on Hurd, > > thus failing to hijack connect(), close(), socket() and several other > > system calls.
