Potentially switch to github.com/gopacket/gopacket instead of github.com/google/gopacket ?

[steev]

Debian testing has applied patches and rebuilt almost their entire repository in order to have 32bit architectures report time type as _TIME_BITS=64 - because of this change, it seems that the google/gopacket dependency now causes a failure to build on 32bit arm architectures c.f. https://gitlab.com/kalilinux/packages/naabu/-/jobs/6843360661#L1515

The Debian go maintainers submitted a patch to gopacket/gopacket which seems like it's at least somewhat more actively maintained at gopacket/gopacket#52 which they accepted and merged in.

Experimentally, in Kali, I switched over to using gopacket/gopacket instead, and the build of naabu does seem to work fine, the CI also reports successful builds c.f. https://gitlab.com/kalilinux/packages/naabu/-/jobs/6852393372 , so I'm asking the naabu project to consider moving to the gopacket/gopacket repository, or, if you are uncomfortable with that, perhaps forking the google/gopacket repository, and applying the pull request mentioned above to it, and using that instead?

[Mzack9999]

@steev Thanks for this suggestion! We have experimentally switched to the mentioned fork, sadly the original library from google seems almost abandoned (last commit 2y ago). At some point probably we will need to implement some abstracted lightweight implementation supporting transparent libpcap, user space raw sockets and so on, dropping cgo alltogether