Add patch for sysutils/plasma6-kinfocenter.

In D49009#1118524, @makc wrote:

Discussion with upstream: https://bugs.kde.org/show_bug.cgi?id=499828

Discussion with upstream: https://bugs.kde.org/show_bug.cgi?id=499828

This is not just some build option - it is an opportunity to get rid of unnecessary bloatware in the system (like pulseaudio or avahi).

I'm not going to consider PIPEWIRE or any other option for KDE ports until it supported upstream. Moreover, in kde@ we often don't even make options for ports when they are supported upstream and the reason is plain simple: we do not have enough time and manpower to maintain all possible combination of options for a huge chunk software like KDE ports.

In D45025#1028274, @vvd wrote:

• Use DESC commited in https://cgit.freebsd.org/ports/commit/?id=7e9e1b6c9e710d094c9f0d5707a673dbe07cb2af
• I request permission to become a maintainer for this port

Can we go forward?

• Use DESC commited in https://cgit.freebsd.org/ports/commit/?id=7e9e1b6c9e710d094c9f0d5707a673dbe07cb2af
• I request permission to become a maintainer for this port

Small fixes in options.

Vlad, there is no need in making option for everything. Instead, try to minimize list of options when creating ports. Group similar functionality under single option (or use RADIO/MULTI etc), don't make options for features that require light or common dependencies, especially if a feature does not need deps at all. Sometimes having too many options is worst than having no options.
And of course these are not 100% strict rules.

Create PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278718

Upstream committed to master branch all fixes based on our patches - use this commit instead of local patches.

In D41863#982973, @arrowd wrote:

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

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?

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?

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

ping

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.

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

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

In D41864#954311, @vvd wrote:

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

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#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.

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.

Not a fan of carrying a patch for this.

Thanks!

I committed R11:3b2ff2ef194c and R11:f0f843322841 (plus a quick typo fix R11:5f6b3eda2234) to address this issue. You can now set:

DEFAULT_VERSIONS+= ebur128=legacy

in make.conf to use the C implementation tree-wide.

In D41473#944573, @arrowd wrote:

PLUS implies EBUR* and EBUR* implies PLUS? This looks wrong.

All correct:

• EBUR used for PLUS only, so if turn on EBUR, then automatic turn on PLUS;
• PLUS require EBUR.

This is the "logic".

PLUS implies EBUR* and EBUR* implies PLUS? This looks wrong.

"MFH: 2023Q3"?

This version looks better, thanks. I've proof-read the description and added some more information, feel free to change it as you see fit.

Removed sorting USES in patch.
Added short description in summary - was discussed in IRC (#freebsd-desktop @ Libera.Chat).

The change seems to make sense -- the Akonadi plugin in kaccounts was disabled in 2015, and the optional KAccounts integration in Akonadi landed in 2019.

Added #cmakedefine PIPEWIRE_FOUND 1 to pass on option PIPEWIRE_FOUND from cmake to sources.

Address another my comment and it should be fine.

BTW, using spectacle with this patch for 3 weeks - screenshots work fine.

I think it was copy&paste from console issue - tabs replaced with spaces and etc.
"git diff > spectacle.diff" and uploaded file spectacle.diff now.

I think it was copy&paste from console issue - tabs replaced with spaces and etc.
"git diff > krfb.diff" and uploaded file krfb.diff now.

This diff doesn't apply with arc too. Can you please re-generate it using Arcanist?

Can you please refresh the patch?

Thanks for the review!