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!

Clarify _USE_QT* explanation.

Someone with a doc-commit bit, which excludes me :) -- please go ahead.

Who's going to commit this?

Looks good to me

apply comments from @tcberner for SDDM

Thanks for working on this update of the handbook chapter.
Can you run textproc/igor over your changes and fix the issues that are reported (alignment of sections, tabs vs. spaces, etc.)?

Re-fixing.

Actually, I was in doubt about that but portlint said "looks fine". :)

I think I was doing it wrong just bringing the diff of the later modified files instead of everything related.

Updating "LICENSE_FILE" to reflect the current absence of the doc folder.

• I downgraded from the v1.0.1 (what is dead now) to v1.0 since I could not find a way to use the "COPYTREE" builtin find feature to avoid directories but just its files. The v1.0 does not have the doc directory.

Submitting a new diff.

Removing the x11-fonts/ohsnap update from the diff, what was accidentally included.