Created attachment 253889 [details] graphics/wallhaven-cli wallhaven-cli is a command-line interface (CLI) tool designed for interacting with the Wallhaven image repository. Wallhaven is known for its extensive collection of high-quality wallpapers. https://github.com/r3tr0ananas/wallhaven-cli
Created attachment 254132 [details] graphics/wallhaven-cli Updated to v2.0.3
Is there any particular reason why you define GO_BUILDFLAGS? We add -s to GO_BUILDFLAGS dependending on the debug settings, so it's not clear why you would add it unconditionally. Remove "that allows you" from COMMENT to keep it nice and short. Port looks ok otherwise.
(In reply to Robert Clausecker from comment #3) Thanks for giving a look. Ok, I will remove that from comment. I put 'GO_BUILDFLAGS= -ldflags="-s -w"' to reduce binary size and improved performance. I think that these flags omit debug flags from the binary. Or Should i just use ${STRIP_CMD} from ports framework?
(In reply to Yusuf Yaman from comment #4) No, you should just not fiddle with the build flags unless they must be changed for some reason. Read /usr/port/Mk/Uses/go.mk for the default build flags; you'll find that stripping is included unless building in debug mode. We strip all binaries unless debugging is explicitly enabled, so it won't be necessary to change the flags like this. I'll leave that out when I commit your patch. Another question: why did you use USE_GITHUB? Usually, our tooling should be able to automatically download Go modules using just the module path. But sometimes that fails, so if that's the case please just say so.
I also found the tool expects that it is named wallhaven to work. If I run it, it'll just say something like /usr/local/bin/mksh: wallhaven: inaccessible or not found instead of displaying an image. Please either patch that or install the binary as wallhaven.
(In reply to Robert Clausecker from comment #5) Another question: why did you use USE_GITHUB? Usually, our tooling should be able to automatically download Go modules using just the module path. But sometimes that fails, so if that's the case please just say so. Thanks for the information. I removed GO_BUILDFLAGS. Actually using GO_MODULE is not giving any error but while latest version of the program is v2.0.3, in module, it says it's v1.0.6. I wanted to use latest version but it doesn't work well with GH, it says import lookup disabled etc.. Can you wait a little before committing while I will inform the project maintainer to update Go module's versions? I wonder why it does show v1.0.6 in go module version while latest release tag is v2.0.3 in GH repo. Thanks.
Also, I will attach the recent patch after all things are done.
(In reply to Robert Clausecker from comment #6) That's interesting because the port already installs as "wallhaven". I don't know how to solve this.
> Can you wait a little before committing while I will inform the project > maintainer to update Go module's versions? I wonder why it does show v1.0.6 in > go module version while latest release tag is v2.0.3 in GH repo. This could be because the major version is v2. I've had similar issues before with finance/ticker. If you can't work this out, it's ok if we just USE_GITHUB to fetch the port. > That's interesting because the port already installs as "wallhaven". I don't know how to solve this. Hm weird. Maybe I did something wrong when testing. Please disregard my findings and let me know when you have finished writing a new patch. I will then check again and look more carefully into this.
(In reply to Robert Clausecker from comment #10) > If you can't work this out, it's ok if we just USE_GITHUB to fetch the port. I'll wait for the project maintainer to update the Go module versions. If we are going to use GITHUB, I am confused if I should add "modules" extension to the USES Go. Adding "modules" extension to Uses Go results in error: cannot find module providing package github.com/spf13/cobra: import lookup disabled by -mod=vendor. It builds fine without "modules" extension but this time I have to manually use modules2tuple to create GH_TUPLE. > let me know when you have finished writing a new patch. > I will then check again and look more carefully into this. Okay, thanks.
Here is the GH issue if you would like to track the progress. https://github.com/r3tr0ananas/wallhaven-cli/issues/7
Created attachment 254531 [details] graphics/wallhaven-cli.patch Now Go module v2 has been published and here is the recent patch. Thanks.
That looks good.
I guess you haven't committed yet and new release is just dropped including a minor fix in code. I want to update the port.
Please send me a patch that applies on top of the previous patch with changes to update to the new version so I can test it. I will likely commit around Tuesday as I am waiting for feedback on some patches in my current batch.
Created attachment 254533 [details] graphics/wallhaven-cli.patch Update v2.0.4 -> v2.0.5
(In reply to Robert Clausecker from comment #16) Okay, i will send the diff.
Created attachment 254534 [details] diff-from-2.0.4-to-2.0.5.diff
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=7e81061dd6793abc6228cdaf6591f4a1aa72d053 commit 7e81061dd6793abc6228cdaf6591f4a1aa72d053 Author: Yusuf Yaman <nxjoseph@protonmail.com> AuthorDate: 2024-10-26 13:04:14 +0000 Commit: Robert Clausecker <fuz@FreeBSD.org> CommitDate: 2024-10-28 12:42:00 +0000 graphics/wallhaven-cli: CLI for wallhaven to browse wallpapers in terminal wallhaven-cli is a command-line interface (CLI) tool designed for interacting with the Wallhaven image repository. Wallhaven is known for its extensive collection of high-quality wallpapers. WWW: https://github.com/r3tr0ananas/wallhaven-cli PR: 281760 graphics/Makefile | 1 + graphics/wallhaven-cli/Makefile (new) | 22 ++++++++++++++++++++++ graphics/wallhaven-cli/distinfo (new) | 5 +++++ graphics/wallhaven-cli/pkg-descr (new) | 3 +++ 4 files changed, 31 insertions(+)
Thank you for your contribution.
(In reply to Robert Clausecker from comment #21) You are welcome and thanks for giving a look.