Created attachment 248181 [details]
v1

Regenerated patch after rebase.

Created attachment 248182 [details]
poudriere build -t log (qt5 flavor)

Created attachment 248183 [details]
poudriere build -t log (qt6 flavor)

Comment 4 Robert Clausecker 2024-03-14 09:46:22 UTC

Here are some review comments:

 - please check if you can unbundle httplib.  It is packaged as www/cpp-httplib

Patch looks ok otherwise.

(In reply to Robert Clausecker from comment #4)

> please check if you can unbundle httplib
Robert, unfortunately, not at this time. :-( Of course, I put a reason of that to commit message.

There are some related changes [1] in upstream repo, but not released yet. This will still not allow unbundling (until stable cpp-httplib will be released), but will work like that:
a) if system httplib is in range of supported versions (<=0.14.x currently for latest tremotesf release), use it; b) if not -- use bundled one.

[1]: https://github.com/equeim/tremotesf2/commit/43b8aecb82fb20f18892dc22a775d925614541a7

Comment 6 Robert Clausecker 2024-03-14 10:08:22 UTC

Thank you for the explanation.  I somehow missed the commit message.

Will commit this one with my next batch.

(In reply to Robert Clausecker from comment #6)

2.6.1 just released and I'm working on a new patch. Would you prefer to wait a bit (though not long) or let this will be commited as is and a new PR should be created?

Created attachment 249272 [details]
v2 (alternative, update to 2.6.1)

Just in case it's not too late yet, here's flavors + version update.

Created attachment 249275 [details]
v3 (alternative, update to 2.6.1)

Added CMAKE_ARGS to ensure proper detection of cpp-httplib regardless of ports/bundled one we're using.

Created attachment 249276 [details]
poudriere build -t log (2.6.1, qt5 flavor)

Created attachment 249277 [details]
poudriere build -t log (2.6.1, qt6 flavor)

Comment 12 Robert Clausecker 2024-03-18 20:01:15 UTC

What changed between your current patch set and the previous one?

I would strongly prefer to commit the current patch as otherwise I'd have to retest everything.  Right now, two architectures are pending completion of build tests on 13.3 and then I'm good to commit.

(In reply to Robert Clausecker from comment #12)

As in comment #8 -- version of tremotesf [1]. Plus default flavor became qt6 as in upstream. (I believe slightly different commit message doesn't count here.)

[1] https://github.com/equeim/tremotesf2/releases/tag/2.6.1

(In reply to Robert Clausecker from comment #12)

Sorry for the lots of emails, but I forgot to say yesterday: yes, I totally understand your preference to commit original patch due to some tests being made.

However, while this PR was sitting here, a new minor release was made. For me, it makes sense to rework patches to latest available version (ofc, with some exclusions where lots depends on port being patched, but tremotesf doesn't fall under this category).

I do not object against committing v1 (that was the reason I didn't mark it obsolete), but in such case I'll be almost immediately ready to create another PR with a v3 rework to update to latest release. So, either v1 or v3 will be chosen, I'm fine with that.

Comment 15 commit-hook 2024-03-19 14:21:43 UTC

A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=253998fe7a481ed01515242b5a1a37754f76321e

commit 253998fe7a481ed01515242b5a1a37754f76321e
Author:     Anton Saietskii <vsasjason@gmail.com>
AuthorDate: 2024-02-04 13:28:58 +0000
Commit:     Robert Clausecker <fuz@FreeBSD.org>
CommitDate: 2024-03-19 14:18:27 +0000

    net-p2p/tremotesf: enable qt5 (default) & qt6 flavors

    While here, bundle back cpp-httplib as tremotesf doesn't support 0.15.x
    (version we have in ports, which is also broken on 13).

    PR:             276822

 net-p2p/tremotesf/Makefile | 29 ++++++++++++++++++++++-------
 net-p2p/tremotesf/distinfo |  4 +++-
 2 files changed, 25 insertions(+), 8 deletions(-)

Comment 16 Robert Clausecker 2024-03-19 14:25:59 UTC

Thank you for your contribution.

Please file a new PR for the next update.

(In reply to Robert Clausecker from comment #16)

Wanted to do that quicker, but was busy fixing another port. Anyway, 2.6.1 update is ready in bug #277867