Created attachment 243617 [details] trivial patch
Should I also increment PORTREVISION for such minor changes, not affecting actual port build?
Created attachment 243620 [details] fixed patch (with incremented PORTREVISION)
Thanks for the patch. PORTREVISION is only for functional changes. Cheers, Franco
^Triage: [tags] in issue Titles are deprecated. ^Triage: Simplifying title ^Triage: If there is a changelog or release notes URL available for this version, please add it to the URL field. Note: Since this will change the package that is created from the port (the metadata will change), I think bumping PORTREVISION is OK. It also helps with reproducible packages. Thanks!
Thank you for clarification. Agree with modifications needed. I'm to remove keywords from all my issues' titles. Just what should I use instead of [PATCH] tag? Patch=true checkbox of attachment files?
Also, could you clarify how the Importance field should be estimated, what constitutes "many people": many of the current port users or many of all the FreeBSD users base (like with the case of some severe kernel bug)? May I have few examples when to use what, please (for both ports/base system)? Thanks,
I was hoping that we could move past PORTREVISION bumps for non-binary changes at least. They are still annoying for library changes which I know are done for legacy tooling reasons only as well.
(In reply to Andrey Korobkov from comment #5) Exactly.
(In reply to Andrey Korobkov from comment #6) Some cases: For security updates, it should be Affects many people. For non-popular leaf ports (like cad/openvsp for instance) I use affects only me. For ports that are near the root of the dependency chain of multiple ports (like cmake or gcc, etc) I would use affects many people.
For base system the same principles apply (or I would say so). If it is a security bug, affects many people. If build is broken for a very, very, really very specific combination of options, and nobody else cares/uses that weird combination, probably "affects only me". If something is commonly used and has a bug/a need from improvement and other people have expressed their concerns, then "affects many people" would be appropriate.
(In reply to Franco Fichtner from comment #7) I understand your POV, I only learned about reproducible builds in the project very recently. It all comes with a cost. The important thing is if the benefits outweigh the costs.
Committed, Thanks!
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=8bc78a52dca094a306588bae5e5b2a22a8fb8dc8 commit 8bc78a52dca094a306588bae5e5b2a22a8fb8dc8 Author: Andrey Korobkov <alster@vinterdalen.se> AuthorDate: 2023-07-26 06:56:07 +0000 Commit: Fernando Apesteguía <fernape@FreeBSD.org> CommitDate: 2023-07-27 06:25:08 +0000 security/suricata: Update WWW to changed upstream URL PR: 272726 Reported by: alster@vinterdalen.se Approved by: franco@opnsense.org (maintainer) security/suricata/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)