FWIW this is at kde overlay commit db3a6d11f, upstream 82bd5f377, while my previous (good) upstream is/was 3adba639b. The ebuild error is: * Applying override-include-dirs.patch ... patching file CMakeLists.txt Hunk #1 FAILED at 156. 1 out of 1 hunk FAILED -- saving rejects to file CMakeLists.txt.rej patching file config-gentoo.cmake patching file kcms/CMakeLists.txt Hunk #2 succeeded at 38 with fuzz 1. patching file kcms/touchpad/backends/x11.cmake [ !! ] * ERROR: kde-plasma/plasma-desktop-9999::kde failed (prepare phase): * patch -p1 failed with /tmp/portage/kde-plasma/plasma-desktop-9999/work/plasma-desktop-override-include-dirs-1/override-include-dirs.patch I've not fully analyzed or bisected yet, but at a quick git log look the only upstream commit in that range that touches CMakeLists.txt and thus is a culprit candidate is: * commit 2bc13c89f | Author: Aleix Pol <aleixpol@kde.org> | AuthorDate: Fri May 20 01:31:25 2022 +0200 | Commit: Aleix Pol Gonzalez <aleixpol@kde.org> | CommitDate: Sun May 29 23:40:52 2022 +0000 | | PipeWireThumbnail: Port to KPipeWire | | It's the same components just in a different place. No need to do much | porting. | | CMakeLists.txt | 3 +++ | applets/taskmanager/package/contents/ui/PipeWireThumbnail.qml | 6 +++--- | 2 files changed, 6 insertions(+), 3 deletions(-)
(In reply to Duncan from comment #0) > at a quick git log look [it should be] > > * commit 2bc13c89f Confirmed. That one fails, previous 20942617f the patch still applies.
Yeah, that upstream commit adds an ecm_find_qmlmodule(org.kde.pipwire 0.1) line right in the middle of the evdev/xorg-server/synaptics lines (near line 177) the gentoo override patch deletes.
Regarding kpipewire, there's a current thread on kde-core-devel (which I'm subscribed to as a newsgroup via gmane.io) ATM titled KPipeWire in kdereview . Based on that kpipewire's not very mature yet and should probably be hard-disabled in plasma-desktop for now, but it could be time to start looking at packaging it for later (maybe you already are), at least. (FWIW, no pipewire or pulse either one, here, no need, so I hope it's not going to be a hard dep any time soon.)
Created attachment 783002 [details, diff] updated override-include-dirs.patch (working hack) [This is addressed primarily to other -9999 users I see from other bugs, who don't seem to have updated recently so haven't yet CCed here, to prevent duplication of effort in case they do before the gentoo/kde overlay gets a fix.] I wouldn't call this patch production-ready as it simply deletes the problematic kpipewire find line, but just to get plasma-desktop-9999 building again here's what I did: Handling this patch is a bit different than most as the current gentoo patch is stuck in a tarball. But the tarball can remain as-is -- all we need is an updated patch, which can be stuck in $FILESDIR, with the appropriate PATCHES line in the ebuild modified accordingly so the $FILESDIR patch is used instead of the one in the tarball. I'm attaching the updated patch for convenience (drop it in $FILESDIR), but all I did to it was add lines 33 and 34 (deleting the "ecm_find_qmlmodule(org.kde.pipwire 0.1)" call and a blank line), and bump the existing line count on line 25, accordingly. Then delete or comment the existing ${WORKDIR}/${XORGHDRS}/override... line in the PATCHES array in the ebuild (line 122) and replace it with: "${FILESDIR}/override-include-dirs.patch" That got plasma-desktop building again for me. (No other complications ATM, against upstream d2e474581 . =:^)
Any way to get this soon fixed? When will this hit the releases?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/proj/kde.git/commit/?id=bc3dd15a963e3fdd1cd7ba2bace856d66d981c9e commit bc3dd15a963e3fdd1cd7ba2bace856d66d981c9e Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2022-06-28 21:25:17 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2022-06-28 21:25:17 +0000 kde-plasma/plasma-desktop: Bump override-include-dirs to v2 Closes: https://bugs.gentoo.org/848771 Package-Manager: Portage-3.0.30, Repoman-3.0.3 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> kde-plasma/plasma-desktop/Manifest | 1 + kde-plasma/plasma-desktop/plasma-desktop-9999.ebuild | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/kde.git/commit/?id=7cacab8ee4e01f37956e58f177fe931912e175df commit 7cacab8ee4e01f37956e58f177fe931912e175df Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2022-06-28 21:27:57 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2022-06-28 21:28:10 +0000 kde-plasma/plasma-desktop: Add new dependency Upstream commit 2bc13c89fce7a86a12d33b1bfc96f38f971be498 Bug: https://bugs.gentoo.org/848771 Package-Manager: Portage-3.0.30, Repoman-3.0.3 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> kde-plasma/plasma-desktop/plasma-desktop-9999.ebuild | 1 + 1 file changed, 1 insertion(+)
(In reply to Duncan from comment #3) > (FWIW, no pipewire or pulse either one, here, no need, so I hope it's not > going to be a hard dep any time soon.) Umm... Regarding 7cacab8ee, I would have expected the kpipewire dep to be optional, either USE-flag based or, since it's RDEPEND only and not really necessary at runtime either, simply einfo notified, presumably in pkg_postinst, particularly given: a) requiring the pipewire ecosystem is big dependency add when it's not necessary b) being RDEPEND only it's not necessary to build c) it's not necessary to run either, as demonstrated originally by the workaround in comment #4, and now by the fact that I'm running just fine using a null-pkg kpipewire ebuild in my overlay d) the kpipewire description itself says it's flatpack-support related, something many gentooers are likely to be unenthusiastic about given the whole flatpack idea is rather antithetical to gentoo philosophy, both bundled-deps-wise and flexible-build-from-source-wise. [I considered whether to file a new bug or reopen this one, since this one was originally about the broken patch, not the pipewire dep directly. But given that the dep-adding commit pointed at this bug as well, I decided to reopen. Which means changing the now no longer accurate bug title as well. Would a new bug still have been better?]
(In reply to Duncan from comment #7) > (In reply to Duncan from comment #3) > > (FWIW, no pipewire or pulse either one, here, no need, so I hope it's not > > going to be a hard dep any time soon.) > > Umm... > > Regarding 7cacab8ee, I would have expected the kpipewire dep to be optional, > either USE-flag based or, since it's RDEPEND only and not really necessary > at runtime either, simply einfo notified, presumably in pkg_postinst, > particularly given: > > a) requiring the pipewire ecosystem is big dependency add when it's not > necessary > b) being RDEPEND only it's not necessary to build > c) it's not necessary to run either, as demonstrated originally by the > workaround in comment #4, and now by the fact that I'm running just fine > using a null-pkg kpipewire ebuild in my overlay > d) the kpipewire description itself says it's flatpack-support related, > something many gentooers are likely to be unenthusiastic about given the > whole flatpack idea is rather antithetical to gentoo philosophy, both > bundled-deps-wise and flexible-build-from-source-wise. a) I am expecting pipewire to be a very strong default if not required very soon. b) By your own example, you patched it out, so you are asking for an extra effort to make it optional, when it is unclear for how long this will make sense considering (a) c) It is clearly not regarded as optional by upstream by nature of how it is implemented in the build system, so unexpected warnings or even errors may happen in the future. pkg_postinst will not cut it. d) The description was taken verbatim from the repository, but it is clearly not going to be limited to flatpak use by going over README.
Revisiting the code, it seems there is still a way for this to be optional at runtime (and depending on plasma-workspace[screencast] as well), but it has been broken upstream at least once already.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/proj/kde.git/commit/?id=9c818a45460219c1a1793cdfe28e6f17f254f505 commit 9c818a45460219c1a1793cdfe28e6f17f254f505 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2022-07-07 12:35:57 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2022-07-07 14:16:03 +0000 kde-plasma/plasma-desktop: Add IUSE screencast for the time being This may break at any time, but we can justify the flag atm for its dependency on kde-plasma/plasma-workspace[screencast]. At the same time this flag has a less than ideal name but we will keep it in sync with kde-plasma/plasma-workspace for ease of use anyway. Closes: https://bugs.gentoo.org/848771 Package-Manager: Portage-3.0.30, Repoman-3.0.3 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> kde-plasma/plasma-desktop/metadata.xml | 1 + kde-plasma/plasma-desktop/plasma-desktop-9999.ebuild | 6 +++--- 2 files changed, 4 insertions(+), 3 deletions(-)
(In reply to Larry the Git Cow from comment #10) > The bug has been closed via the following commit(s): > > https://gitweb.gentoo.org/proj/kde.git/commit/ > ?id=9c818a45460219c1a1793cdfe28e6f17f254f505 > > commit 9c818a45460219c1a1793cdfe28e6f17f254f505 > Author: Andreas Sturmlechner <asturm@gentoo.org> > AuthorDate: 2022-07-07 12:35:57 +0000 > Commit: Andreas Sturmlechner <asturm@gentoo.org> > CommitDate: 2022-07-07 14:16:03 +0000 > > kde-plasma/plasma-desktop: Add IUSE screencast for the time being > > This may break at any time, but we can justify the flag atm for its > dependency on kde-plasma/plasma-workspace[screencast]. At the same > time this flag has a less than ideal name but we will keep it in sync > with kde-plasma/plasma-workspace for ease of use anyway. > > Closes: https://bugs.gentoo.org/848771 > Package-Manager: Portage-3.0.30, Repoman-3.0.3 > Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> > > kde-plasma/plasma-desktop/metadata.xml | 1 + > kde-plasma/plasma-desktop/plasma-desktop-9999.ebuild | 6 +++--- > 2 files changed, 4 insertions(+), 3 deletions(-) The only problem is that kde-plasma/plasma-workspace-9999 fails to build with disabled screencast flag. [57/1339] : && /usr/bin/x86_64-pc-linux-gnu-g++ -fPIC -march=native -mtune=native -O2 -pipe -fno-operator-names -fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Werror=init-self -Wvla -Wdate-time -Wsuggest-override -Wlogical-op -fdiagnostics-color=always -Wl,--no-undefined -Wl,--enable-new-dtags -Wl,-O1 -Wl,--as-needed -shared -Wl,-soname,libtaskmanagerplugin.so -o bin/libtaskmanagerplugin.so libtaskmanager/declarative/CMakeFiles/taskmanagerplugin.dir/taskmanagerplugin_autogen/mocs_compilation.cpp.o libtaskmanager/declarative/CMakeFiles/taskmanagerplugin.dir/taskmanagerplugin.cpp.o -Wl,-rpath,/var/tmp/portage/kde-plasma/plasma-workspace-9999/work/plasma-workspace-9999_build/bin: bin/libtaskmanager.so.5.25.80 /usr/lib64/libQt5Quick.so.5.15.5 /usr/lib64/libQt5QmlModels.so.5.15.5 /usr/lib64/libQt5Qml.so.5.15.5 /usr/lib64/libKF5ItemModels.so.5.96.0 /usr/lib64/libQt5Network.so.5.15.5 /usr/lib64/libQt5Gui.so.5.15.5 /usr/lib64/libQt5Core.so.5.15.5 && : FAILED: bin/libtaskmanagerplugin.so : && /usr/bin/x86_64-pc-linux-gnu-g++ -fPIC -march=native -mtune=native -O2 -pipe -fno-operator-names -fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Werror=init-self -Wvla -Wdate-time -Wsuggest-override -Wlogical-op -fdiagnostics-color=always -Wl,--no-undefined -Wl,--enable-new-dtags -Wl,-O1 -Wl,--as-needed -shared -Wl,-soname,libtaskmanagerplugin.so -o bin/libtaskmanagerplugin.so libtaskmanager/declarative/CMakeFiles/taskmanagerplugin.dir/taskmanagerplugin_autogen/mocs_compilation.cpp.o libtaskmanager/declarative/CMakeFiles/taskmanagerplugin.dir/taskmanagerplugin.cpp.o -Wl,-rpath,/var/tmp/portage/kde-plasma/plasma-workspace-9999/work/plasma-workspace-9999_build/bin: bin/libtaskmanager.so.5.25.80 /usr/lib64/libQt5Quick.so.5.15.5 /usr/lib64/libQt5QmlModels.so.5.15.5 /usr/lib64/libQt5Qml.so.5.15.5 /usr/lib64/libKF5ItemModels.so.5.96.0 /usr/lib64/libQt5Network.so.5.15.5 /usr/lib64/libQt5Gui.so.5.15.5 /usr/lib64/libQt5Core.so.5.15.5 && : /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: libtaskmanager/declarative/CMakeFiles/taskmanagerplugin.dir/taskmanagerplugin.cpp.o: in function `int qmlRegisterUncreatableType<Screencasting>(char const*, int, int, char const*, QString const&) [clone .isra.0]': taskmanagerplugin.cpp:(.text+0x1d): undefined reference to `Screencasting::staticMetaObject' /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: taskmanagerplugin.cpp:(.text+0x16f): undefined reference to `Screencasting::staticMetaObject' /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: taskmanagerplugin.cpp:(.text+0x1a1): undefined reference to `Screencasting::staticMetaObject' /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: taskmanagerplugin.cpp:(.text+0x333): undefined reference to `Screencasting::staticMetaObject' /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: taskmanagerplugin.cpp:(.text+0x3a3): undefined reference to `Screencasting::staticMetaObject' /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: libtaskmanager/declarative/CMakeFiles/taskmanagerplugin.dir/taskmanagerplugin.cpp.o: in function `int qmlRegisterType<ScreencastingRequest>(char const*, int, int, char const*) [clone .isra.0]': taskmanagerplugin.cpp:(.text+0xa17): undefined reference to `ScreencastingRequest::staticMetaObject' /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: taskmanagerplugin.cpp:(.text+0xb78): undefined reference to `ScreencastingRequest::staticMetaObject' /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: taskmanagerplugin.cpp:(.text+0xbb4): undefined reference to `ScreencastingRequest::staticMetaObject' /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: taskmanagerplugin.cpp:(.text+0xd33): undefined reference to `ScreencastingRequest::staticMetaObject' /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: taskmanagerplugin.cpp:(.text+0xd9a): undefined reference to `ScreencastingRequest::staticMetaObject' /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: libtaskmanager/declarative/CMakeFiles/taskmanagerplugin.dir/taskmanagerplugin.cpp.o: in function `void QQmlPrivate::createInto<ScreencastingRequest>(void*)': taskmanagerplugin.cpp:(.text._ZN11QQmlPrivate10createIntoI20ScreencastingRequestEEvPv[_ZN11QQmlPrivate10createIntoI20ScreencastingRequestEEvPv]+0x7): undefined reference to `ScreencastingRequest::ScreencastingRequest(QObject*)' /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: libtaskmanager/declarative/CMakeFiles/taskmanagerplugin.dir/taskmanagerplugin.cpp.o: in function `QQmlPrivate::QQmlElement<ScreencastingRequest>::~QQmlElement()': taskmanagerplugin.cpp:(.text._ZN11QQmlPrivate11QQmlElementI20ScreencastingRequestED2Ev[_ZN11QQmlPrivate11QQmlElementI20ScreencastingRequestED5Ev]+0x18): undefined reference to `ScreencastingRequest::~ScreencastingRequest()' /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: libtaskmanager/declarative/CMakeFiles/taskmanagerplugin.dir/taskmanagerplugin.cpp.o: in function `QQmlPrivate::QQmlElement<ScreencastingRequest>::~QQmlElement()': taskmanagerplugin.cpp:(.text._ZN11QQmlPrivate11QQmlElementI20ScreencastingRequestED0Ev[_ZN11QQmlPrivate11QQmlElementI20ScreencastingRequestED5Ev]+0x17): undefined reference to `ScreencastingRequest::~ScreencastingRequest()' /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: libtaskmanager/declarative/CMakeFiles/taskmanagerplugin.dir/taskmanagerplugin.cpp.o:(.data.rel.ro._ZTIN11QQmlPrivate11QQmlElementI20ScreencastingRequestEE[_ZTIN11QQmlPrivate11QQmlElementI20ScreencastingRequestEE]+0x10): undefined reference to `typeinfo for ScreencastingRequest' /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: libtaskmanager/declarative/CMakeFiles/taskmanagerplugin.dir/taskmanagerplugin.cpp.o:(.data.rel.ro._ZTVN11QQmlPrivate11QQmlElementI20ScreencastingRequestEE[_ZTVN11QQmlPrivate11QQmlElementI20ScreencastingRequestEE]+0x10): undefined reference to `ScreencastingRequest::metaObject() const' /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: libtaskmanager/declarative/CMakeFiles/taskmanagerplugin.dir/taskmanagerplugin.cpp.o:(.data.rel.ro._ZTVN11QQmlPrivate11QQmlElementI20ScreencastingRequestEE[_ZTVN11QQmlPrivate11QQmlElementI20ScreencastingRequestEE]+0x18): undefined reference to `ScreencastingRequest::qt_metacast(char const*)' /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: libtaskmanager/declarative/CMakeFiles/taskmanagerplugin.dir/taskmanagerplugin.cpp.o:(.data.rel.ro._ZTVN11QQmlPrivate11QQmlElementI20ScreencastingRequestEE[_ZTVN11QQmlPrivate11QQmlElementI20ScreencastingRequestEE]+0x20): undefined reference to `ScreencastingRequest::qt_metacall(QMetaObject::Call, int, void**)' collect2: error: ld returned 1 exit status ninja: build stopped: subcommand failed. * ERROR: kde-plasma/plasma-workspace-9999::kde failed (compile phase):
Okay. I think we are nearing the end of optional screencast flag.
(In reply to jospezial from comment #11) > The only problem is that kde-plasma/plasma-workspace-9999 fails to build > with disabled screencast flag. > FAILED: bin/libtaskmanagerplugin.so > /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../x86_64-pc-linux-gnu/bin/ > ld: > libtaskmanager/declarative/CMakeFiles/taskmanagerplugin.dir/ > taskmanagerplugin.cpp.o: in function `int > qmlRegisterUncreatableType<Screencasting>(char const*, int, int, char > const*, QString const&) [clone .isra.0]': > taskmanagerplugin.cpp:(.text+0x1d): undefined reference to > `Screencasting::staticMetaObject' See https://bugs.kde.org/show_bug.cgi?id=456655 Culprit plasma-workspace commit is (emails incomplete for anti-spam, remembered here, forgot in the above kde bug): * commit bf4dd6353 Author: Aleix Pol <aleixpol@kde> AuthorDate: Wed Jun 29 16:27:01 2022 +0200 Commit: Aleix Pol <aleixpol@> CommitDate: Tue Jul 5 12:47:56 2022 +0200 libtaskmanager: Use KPipeWire Since then, there's the following commit, so the intent is for it still to be optional, but that commit just dumps the required, it doesn't fix the problem, thus kde bug 456655 as mentioned above. (I'll also link this bug there.) commit fed29855f | Author: Aleix Pol <aleixpol@> | AuthorDate: Fri Jul 8 20:10:10 2022 +0200 | Commit: Aleix Pol Gonzalez <aleixpol@> | CommitDate: Sun Jul 10 15:48:23 2022 +0000 | | KPipeWire isn't actually required | | Just some features will be missing
(In reply to Duncan from comment #13) > (In reply to jospezial from comment #11) > > The only problem is that kde-plasma/plasma-workspace-9999 fails to build > > with disabled screencast flag. > > See https://bugs.kde.org/show_bug.cgi?id=456655 There's an MR on that bug that fixes it. I built with it (just fine) and rebooted so am running it now.
(In reply to Duncan from comment #14) > (In reply to Duncan from comment #13) > > (In reply to jospezial from comment #11) > > > The only problem is that kde-plasma/plasma-workspace-9999 fails to build > > > with disabled screencast flag. > > > > See https://bugs.kde.org/show_bug.cgi?id=456655 > > There's an MR on that bug that fixes it. I built with it (just fine) and > rebooted so am running it now. The above bug is now marked fixed in (kde) master now, by: ------------------------- Git commit 92c08071b6df6afcbfbd230d815f87809985f34f by Aleix Pol Gonzalez, on behalf of Michael Pyne. Committed on 18/07/2022 at 22:57. Pushed by apol into branch 'master'. libtaskmanager: Fix build when PipeWire is not installed. The CMake code is careful not to include PipeWire when it is not installed, however what it *does* include (taskmanagerplugin) still has a dependency on Screencasting classes, which prior to this are gated under the PipeWire check. Since these classes only require Wayland, not PipeWire, I fix the build error by reducing the CMake check for PipeWire to only add the PipeWire-specific bits when PipeWire is present, and to build the screencasting stuff unconditionally. The ECM logging code is named after PipeWire but doesn't depend on it either so that is also built unconditionally to avoid build failures about a missing "logging.h". ------------------------
Tying up some comment loose ends... (In reply to Andreas Sturmlechner from comment #8) > (In reply to Duncan from comment #7) > > > > Regarding 7cacab8ee, I would have expected the kpipewire dep to be optional, > > a) I am expecting pipewire to be a very strong default if not required very > soon. As noted in comment #13, referencing upstream fed29855f (tho to your credit the commit was after your comment), it is now explicitly optional, with breakage being a bug. > b) By your own example, you patched it out Updating a gentoo patch not upstream (tho the "working" patch I used did patch out a an entirely unnecessary cmake find kpipewire call, because kpipewire wasn't actually required; see next). > c) It is clearly not regarded as optional by upstream When you wrote that there was indeed some question, but as mentioned above, upstream fed29855f makes it explicitly optional (sometime breakage not withstanding) (In reply to Larry the Git Cow from comment #10) > The bug has been closed via the following commit(s): > commit 9c818a45460219c1a1793cdfe28e6f17f254f505 > kde-plasma/plasma-desktop: Add IUSE screencast for the time being > [T]his flag has a less than ideal name but we will keep it in sync > with kde-plasma/plasma-workspace for ease of use anyway. (Haven't synced in a couple days, assuming the flag name hasn't already been changed...) Indeed the USE flag name is less than ideal. Not sure whether it's worth changing both flags to pipewire/kpipewire (presumably) or not, but given the now explicit upstream policy the flags are looking less temporary than they were, and if they are to be changed, doing that before they hit a non-live version, or at least before they hit a stable version, would be less disruptive.
