[Pkg-privacy-maintainers] Bug#767235: torsocks: FTBFS on hurd-i386

[Hefee]

Hey,
 
> 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().

Thanks for your fast explanation.

Okay digging deeper into the code I see, that also the linux part on compat.h 
has these numbering [1]. So it is not that uncommon.

[1] https://salsa.debian.org/pkg-privacy-team/torsocks/-/blob/debian/sid/src/
common/compat.h?ref_type=heads#L74

The change on configure.ac I understand, that this reflects in the correct libc 
version. But buildd is actually fine with the configure step, so is that still 
needed?

torsocks.h okay it changed their hunks, but seems fine.

I think the change on syscall.c is not needed anymore, as they changed to 
negative logic [2].
https://salsa.debian.org/pkg-privacy-team/torsocks/-/blob/debian/sid/src/lib/
syscall.c#L87

I now have a feeling, that I understand and could ask upstream, if you can 
update the patch for the new version. At least hunks have changed and it would 
be nice if we propose a working patch for upstream.

I'm a little bit lost in the preprocessor macros. Is __GNU__ only only true 
for Hurd?

Regards,

hefee
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://alioth-lists.debian.net/pipermail/pkg-privacy-maintainers/attachments/20260219/f231d906/attachment.sig>