Changes: https://github.com/danmar/cppcheck/releases/tag/2.9
Created attachment 237516 [details] update patch
Please use upstream release tarball found here (.tar.bz2): https://sourceforge.net/projects/cppcheck/files/cppcheck/2.9/ Does it pass Poudreire and "make test"? Runtime tested on? Best regards, Daniel
Yes: [fbsd-14-x64-local] [2022-10-25_21h22m00s] [committing:] Queued: 33 Built: 33 Failed: 0 Skipped: 0 Ignored: 0 Fetched: 0 Tobuild: 0 Time: 01:03:46 Testing Complete Number of tests: 4104 Number of todos: 337 Tests failed: 0
Oops, sorry. Tested on -CURRENT amd64
> Please use upstream release tarball found here (.tar.bz2): Please don't. > Runtime tested on? Have you tested cppcheck-gui as well?
(In reply to Dmitry Marakasov from comment #5) Please elaborate why we shouldn't use upstream release archives which is also what Porters Handbook says USE_GITHUB section?
(In reply to Daniel Engberg from comment #6) We've discussed that before, I see no point in repeating myself. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263962#c1
(In reply to Dmitry Marakasov from comment #7) That your personal opinion, we have Porters Handbook for a reason and as I've suggested to you before file a PR about it if you disagree. Ports should be seen as a group effort and we strive for consistency. Best regards, Daniel
There's no reason for documentation and consistency(In reply to Daniel Engberg from comment #8) > I've suggested to you before file a PR about it if you disagree I have no time nor interest to contribute to the handbook, so please file the PR yourself if you consider this issue important. That how group effort works. > Ports should be seen as a group effort and we strive for consistency. Ports should be seen as a maintainable collection of recipes which build and install third party software, and I've stated why using upstream tarballs hinder this goal. If you don't agree with these, we may discuss. I'm not going to discuss false goals like thoughtlessly following incorrect, incomplete and ambiguous documentation or upholding consistency for the sole sake of itself, even where it's not, at the cost of quality.
Sorry it took so long to reply. devel/cppcheck-gui does build successfully in poudriere on -CURRENT: [2022-11-04_21h09m01s] [committing:] Queued: 194 Built: 194 Failed: 0 Skipped: 0 Ignored: 0 Fetched: 0 Tobuild: 0 Time: 16:57:29 It also appears to function correctly from the minimal testing I've done.
cppcheck-gui doesn't build for me. But I'm going to merge cppcheck-gui into cppcheck to simplify things - it build fine this way.
Sounds good to me! On a side note, I noticed that using the --clang=clang on -CURRENT crashes cppcheck pretty fast. The --clang option is marked as experimental, so I guess it's not surprising. I'm guessing that something has changed in LLVM/clang in -CURRENT that broke the integration.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=a309971953b0f7693db1c28c4468c8ede7c0286d commit a309971953b0f7693db1c28c4468c8ede7c0286d Author: Dmitry Marakasov <amdmi3@FreeBSD.org> AuthorDate: 2022-11-07 16:36:48 +0000 Commit: Dmitry Marakasov <amdmi3@FreeBSD.org> CommitDate: 2022-11-08 12:09:17 +0000 devel/cppcheck: update 2.7.5 → 2.9.1 - Merge cppcheck-gui into cppcheck to simplify maintenance and testing - Install manpage into canonical location PR: 267262 Submitted by: jailbird@fdf.net MOVED | 1 + devel/Makefile | 1 - devel/cppcheck-gui/Makefile (gone) | 7 --- devel/cppcheck/Makefile | 51 ++++++++++------------ devel/cppcheck/distinfo | 6 +-- devel/cppcheck/files/patch-cli_CMakeLists.txt | 6 +-- devel/cppcheck/files/patch-gui_CMakeLists.txt | 10 ++--- .../patch-gui_test_benchmark_simple_CMakeLists.txt | 12 ++--- .../patch-gui_test_xmlreportv2_CMakeLists.txt | 6 +-- devel/cppcheck/files/patch-lib_CMakeLists.txt | 12 ++--- devel/cppcheck/files/patch-oss-fuzz_CMakeLists.txt | 6 +-- devel/cppcheck/files/patch-test_CMakeLists.txt | 6 +-- devel/cppcheck/pkg-plist | 6 ++- devel/cppcheck/pkg-plist-gui (gone) | 16 ------- 14 files changed, 60 insertions(+), 86 deletions(-)
(In reply to commit-hook from comment #13) It seems that tag was changed and now github file size doesn't match distinfo size: => danmar-cppcheck-2.9.1_GH0.tar.gz doesn't seem to exist in /usr/ports/distfiles/. => Attempting to fetch https://codeload.github.com/danmar/cppcheck/tar.gz/2.9.1?dummy=/danmar-cppcheck-2.9.1_GH0.tar.gz fetch: https://codeload.github.com/danmar/cppcheck/tar.gz/2.9.1?dummy=/danmar-cppcheck-2.9.1_GH0.tar.gz: size unknown fetch: https://codeload.github.com/danmar/cppcheck/tar.gz/2.9.1?dummy=/danmar-cppcheck-2.9.1_GH0.tar.gz: size of remote file is not known danmar-cppcheck-2.9.1_GH0.tar.gz 3827 kB 4752 kBps 01s => Fetched file size mismatch (expected 5471242, actual 3919074)
(In reply to Oleg Sidorkin from comment #14) The main problem I see is that there does not appear to be a 2.9.1 release; the latest I see is 2.9 (Aug 28). The supplied patch also says 2.9 in the updated Makefile. And the distfile lists the same sha256 checksum I get when I download the 2.9 tar.gz from github. I am not sure where 2.9.1 came from?
(In reply to Craig Leres from comment #15) Maybe this one: https://github.com/danmar/cppcheck/releases/tag/2.9.1
(In reply to Oleg Sidorkin from comment #16) Ok but the sha256 for that file doesn't match the current distinfo.
Created attachment 237978 [details] patch Here's a patch that fixes distinfo and unbreaks building this port.
(In reply to Craig Leres from comment #18) poudriere checks are fine with GUI flag enabled
There seem to have been a tag slip with 2.9.1. Anyway, I've updated the port to 2.9.2.