kwm@, can you please help with USES "iconv:wchar_t"/"iconv" - you added it in commit https://cgit.freebsd.org/ports/commit/?id=36b017c5ac6549ffa2431727f6f095fcbdf705ad
and in commit https://cgit.freebsd.org/ports/commit/?id=0bebae225ad1901ebffa99412280f31336255319
Do we need it now?
It build and run fine, but I don't know how to test this.

Found example in print/scribus-devel.

Fixed typo.

Released 3.1.0 with nice features:

• WITH_BINARY_VERSIONING (default OFF) Similar as for libraries the binaries, manpages and resource locations created by FreeRDP project are postfixed with the API version. Recommended if packagers want to install the package alongside FreeRDP 2 without conflicts.
• RDTK_FORCE_STATIC_BUILD (default OFF) Build and link RDTK statically into shadow server. Recommended for packagers as this library is not really used outside of FreeRDP-shadow.
• UWAC_FORCE_STATIC_BUILD (default OFF) Build and link UWAC statically into wlfreerdp. Recommended for packagers as this library is not really used outside of wlfreerdp.

In D43127#982976, @tcberner wrote:

There seems to be a lot of work done to not install manpages... xmlto does not look like such a heavy build-dependency that would call for that effort :)

In D43127#982922, @diizzy wrote:

Why do we need both versions in tree?

In D43127#982976, @tcberner wrote:

There seems to be a lot of work done to not install manpages... xmlto does not look like such a heavy build-dependency that would call for that effort :)

?
2 lines only:

MANPAGES_BUILD_DEPENDS= xmlto:textproc/xmlto
MANPAGES_CMAKE_BOOL=    WITH_MANPAGES

In D41863#982973, @arrowd wrote:

If the -DPipeWire_FOUND=NO approach worked, update the diff

ping

In D41863#964975, @arrowd wrote:

Does just passing -DPipeWire_FOUND=NO to CMake work?

In D41863#959445, @arrowd wrote:

Can't this be done via CMAKE_DISABLE_FIND_PACKAGE... too?

ping

In D41048#955081, @arrowd wrote:

There is something strange going on with this diff. When trying to apply it via arc patch D41048 I do get the audio/mumble-server port, but it contains PORTNAME=murmur and PORTVERSION=1.3.3. Maybe this is because the patch doesn't apply.

@vvd can you please refresh it?

I don't know how to do this correct in one patch: 1) rename port, 2) update to new version.
So patch can look weird and possible not all tools can work correctly with it. This part:

In D41864#955078, @arrowd wrote:

Looks good, although I didn't run-test it. But it should be fine, right?

Yes, I'm using it with PIPEWIRE OFF. With ON it's same as without this patch.

Forgot to add "Differential Revision" in commit message.
https://cgit.freebsd.org/ports/commit/?id=3f1b38acfda124fc8f03fe5f4edfef10ef214501
https://cgit.freebsd.org/ports/commit/?h=2023Q3&id=fc4ebc143c4b097ec1ea90fa6831a3125c8619de

ping :-(

In D41864#954323, @arrowd wrote:

In D41864#954311, @vvd wrote:

How to determine this if ecm_find_qmlmodule is called and not find_package directly?

Just a bit of searching: https://github.com/KDE/extra-cmake-modules/blob/ed9b7b7eb95bb66e92f2eff39ad8cf3b36cb1b76/modules/ECMFindQmlModule.cmake#L52

How to determine this if ecm_find_qmlmodule is called and not find_package directly?

In D41864#954301, @arrowd wrote:

In D41864#954296, @vvd wrote:

In D41864#954190, @tcberner wrote:

ecm_find_qmlmlodule seems to call find_package, so you might be able to use CMAKE_DISABLE_FIND_PACKAGE_xyz

What is "xyz" in this case?
Not PIPEWIRE, not KPIPEWIRE.

xyz stands for what is passed into find_package: https://cmake.org/cmake/help/latest/variable/CMAKE_DISABLE_FIND_PACKAGE_PackageName.html

In D41864#954190, @tcberner wrote:

ecm_find_qmlmlodule seems to call find_package, so you might be able to use CMAKE_DISABLE_FIND_PACKAGE_xyz

What is "xyz" in this case?
Not PIPEWIRE, not KPIPEWIRE.

In D41864#954190, @tcberner wrote:

Not a fan of carrying a patch for this.