[24.10] - backport changes to snort3, vectorscan, and gperftools

[graysky2]

📦 Package Details

Maintainer: me
_{(You can find this by checking the history of the package Makefile.)}

Description:
This PR is a backport of recent changes to net/snort3/ libs/gperftools libs/vectorscan. It also includes removing libs/hyperscan and brings openwrt-24.10 into parity with main.

Supersedes: #27667

---

🧪 Run Testing Details

I have not run tested on 24.10

• OpenWrt Version:
• OpenWrt Target/Subtarget:
• OpenWrt Device:

---

✅ Formalities

• I have reviewed the CONTRIBUTING.md file for detailed contributing guidelines.

If your PR contains a patch:

• It can be applied using git am
• It has been refreshed to avoid offsets, fuzzes, etc., using

  make package/<your-package>/refresh V=s

• It is structured in a way that it is potentially upstreamable
  _{(e.g., subject line, commit description, etc.)
  We must try to upstream patches to reduce maintenance burden.}

[BKPepe]

I am closing your previous PR - #27667 , there was no need to open a new one. You just need to rebase your branch. :) Never mind, though.

[graysky2]

Thanks. I wanted to the the other one for diffing purposes. Seems like some of the CI failures are unrelated (failure to download Packages.gz or a bad signature) but one failure for x86/64 is due to a missing uuid.h from another package?

[BKPepe]

While looking at it, I am not sure how did you end up with this, because most of those gperftools commits are already in OpenWrt 24.10.

[graysky2]

On my branch which was branched from openwrt-24.10, to see the difference:

git diff master -- libs/gperftools/Makefile

Then to see the commits:

git log master --not HEAD -- libs/gperftools/Makefile

I had to manually inspect each commit with git show xxxxx ... there must be an easier and more reliable way to know which commits need to be cherry-picked.

[BKPepe]

Yes, there are definitely other and much more efficient ways to solve this, but we can't duplicate commits in the branch. Then we really won't be able to make sense of it anymore.

And at the same time, we definitely can't bring breaking changes into the stable branch. You want to add vectorscan to the stable branch and simultaneously remove hyperscan. We can't do that without adding PROVIDES to hyperscan. The question is, what about the header packages. I'd gladly remove them, but again it's about breaking changes, but fortunately very few people use those headers/runtime packages. I wouldn't be worried about that.

But I can't solve almost every pull request for you, that's not possible.