Summary: | kde-plasma/layer-shell-qt:6 built with clang/libc++: plasmashell crashes when right clicking on a panel or desktop w/ layershellqt: Cannot attach popup of unknown type | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Michael Egger <egger.m> |
Component: | Current packages | Assignee: | LLVM support project <llvm> |
Status: | IN_PROGRESS --- | ||
Severity: | normal | CC: | egger.m, gentoo.qxrin, gonegrier.duarte, info, kde, ludicrous_train, mehmetkaratas, parona, rincat, sam, sandyvujakovicj, unhappy-ending |
Priority: | Normal | Keywords: | UPSTREAM |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://lists.llvm.org/pipermail/llvm-dev/2014-June/073465.html | ||
See Also: |
https://bugs.kde.org/show_bug.cgi?id=479679 https://github.com/llvm/llvm-project/issues/48743 https://github.com/llvm/llvm-project/issues/10550#issuecomment-998360621 https://github.com/llvm/llvm-project/issues/36746 https://bugs.gentoo.org/show_bug.cgi?id=933131 https://github.com/gentoo/kde/pull/996 https://bugs.gentoo.org/show_bug.cgi?id=914398 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | emerge info |
Description
Michael Egger
2024-01-29 20:03:17 UTC
Please report to upstream. The issue has been reported upstream https://bugs.kde.org/show_bug.cgi?id=479679, but cannot be reproduced and seems to be a gentoo packaging issue: > Cannot reproduce either with built-from-source Plasma on top of Fedora 39. > I strongly suspect this is a packaging issue. > Maybe the layershell protocol definition is out of date? > Either way please follow up with Gentoo folks about it. Thanks! Please add emerge --info, as always in Gentoo bugs. In case you have added kde overlay at all, please make sure *all* kde-frameworks and kde-plasma packages are consistently at version 5.248.0 and 5.92.0 respectively, no mix with -9999. Do you apply any kind of user patches on top of Qt/Frameworks/Plasma? > Do you apply any kind of user patches on top of Qt/Frameworks/Plasma? There are no custom patches applied > In case you have added kde overlay at all, please make sure *all* kde-frameworks and kde-plasma packages are consistently at version 5.248.0 and 5.92.0 respectively, no mix with -9999. The kde overlay is active but the only thing unmasked is kde-gear-24.02. No -9999 packages are in use for QT/frameworks/plasma/gears: gentoo3 /etc/portage/package.unmask # ls -la total 8 drwxr-xr-x 1 root root 56 Jan 24 16:17 . drwxr-xr-x 1 root root 360 Dec 14 14:10 .. -rw-r--r-- 1 root root 0 Dec 22 15:52 common lrwxrwxrwx 1 root root 61 Jan 24 16:17 kde-gear-24.02 -> /var/db/repos/kde/Documentation/package.unmask/kde-gear-24.02 Created attachment 883644 [details]
emerge info
Maybe you can try without -O3 and lto? Reassigning this to llvm as I think it may be out of scope for kde proj. [12:40] <DavidRedondo> fvogt [12:40] <DavidRedondo> if I compile this program with clang++ [12:40] * DavidRedondo sent a code block: > #include <any> > #include <dlfcn.h> > > struct xdg_popup; > > #ifdef IS_PLUGIN > > std::any get_any() > { > return (xdg_popup*)0xf00; > } > > #else > > int main() > { > auto plugin = dlopen("./plugin.so", RTLD_LAZY | RTLD_NODELETE); > auto get_any = reinterpret_cast<std::any(*)()>(dlsym(plugin, "_Z7get_anyv")); > std::any_cast<xdg_popup*>(get_any()); > } > > #endif [12:40] <DavidRedondo> I get bad_any_cast with libc++ but it works fine with libstdc+++ [12:41] <DavidRedondo> RTLD_LAZY | RTLD_NODELETE is how Qt loads the plugin [12:41] <DavidRedondo> * RTLD_LAZY | RTLD_NODELETE is how Qt loads the plugin I think (4097) [12:49] <fvogt> Does it work if you put struct xdg_popup {}; into IS_PLUGIN? [...] [13:03] <DavidRedondo> fvogt: no that doesn't change anything [13:04] <fvogt> I could reproduce it locally [13:04] <fvogt> "typeinfo for xdg_popup*" is a weak symbol in both objects, so should exist only once [13:05] <fvogt> a.type().hash_code() is different with libc++ though [...] [13:07] <DavidRedondo> fvogt: It also fails if both objects have a defintion of xdg_popup [13:08] <fvogt> https://github.com/llvm/llvm-project/blob/6009708b4367171ccdbf4b5905cb6a803753fe18/libcxx/include/typeinfo#L133 [13:08] <fvogt> With -D_LIBCPP_TYPEINFO_COMPARISON_IMPLEMENTATION=2 it works (as expected) [13:08] <DavidRedondo> So the question is why do we not have a unique_copy of the typeinfo [13:09] <fvogt> Maybe the scope of the weak symbols is wrong [13:10] <fvogt> Oh, hm [...] [13:10] <fvogt> I think I mixed up my binaries, the typeinfo with libc++ is not weak? [13:13] <DavidRedondo> fvogt: for libc++ I have > 0000000000003d98 d typeinfo for xdg_popup > 0000000000003da8 d typeinfo for xdg_popup* > 0000000000002020 r typeinfo name for xdg_popup > 0000000000002014 r typeinfo name for xdg_popup* [13:13] <fvogt> I suggest readelf -sW, easier to read [13:14] <DavidRedondo> but the same with libstdc++ [13:14] <lunarequest[M]> would there be something i can do to fix it? [13:15] <fvogt> https://gcc.gnu.org/legacy-ml/gcc-patches/2009-07/msg01239.html [13:16] <DavidRedondo> fvogt: > libc++ > 10: 0000000000003da8 32 OBJECT LOCAL DEFAULT 19 typeinfo for xdg_popup* > 11: 0000000000002014 12 OBJECT LOCAL DEFAULT 14 typeinfo name for xdg_popup* > 12: 0000000000002020 11 OBJECT LOCAL DEFAULT 14 typeinfo name for xdg_popup > 13: 0000000000003d98 16 OBJECT LOCAL DEFAULT 19 typeinfo for xdg_popup > libstdc++ > 10: 0000000000003dc8 32 OBJECT LOCAL DEFAULT 19 typeinfo for xdg_popup* > 11: 0000000000002014 12 OBJECT LOCAL DEFAULT 14 typeinfo name for xdg_popup* > 12: 0000000000002020 11 OBJECT LOCAL DEFAULT 14 typeinfo name for xdg_popup > 13: 0000000000003db8 16 OBJECT LOCAL DEFAULT 19 typeinfo for xdg_popup [13:16] <fvogt> libstdc++ does the equivalent of D_LIBCPP_TYPEINFO_COMPARISON_IMPLEMENTATION=2 by default [13:17] <DavidRedondo> Interestingly if xdg_popup is defined the typeinfo is weak [13:17] <DavidRedondo> but the any cast still fails [13:17] <fvogt> Ah, that explains why it changed for me [13:18] <DavidRedondo> So what should we do, and who is we in that case [13:18] <DavidRedondo> Qt, KDE, distros? [13:19] <DavidRedondo> https://lists.llvm.org/pipermail/llvm-dev/2014-June/073465.html [13:20] <fvogt> If it's weak in the lib it should work [13:22] <DavidRedondo> Somehow it still doesn't [13:24] <fvogt> binding file ./plugin.so [0] to ./plugin.so [0]: normal symbol `_ZTIP9xdg_popup' [13:27] <fvogt> https://github.com/llvm/llvm-project/issues/10550#issuecomment-998360621 [...] [13:33] <DavidRedondo> fvogt I think if xdg-Popup is not defined it can't use typeinfo at all? [13:34] <fvogt> DavidRedondo: Technically it should be, due to COMDAT merging, but only wirh -rdynamic in that case (I think) [13:34] <fvogt> For some reason even with -rdynamic, clang does not export the typeinfo symbol from the binary [13:34] <DavidRedondo> typeinfo(uncomplete_type) doesn't work [13:34] <DavidRedondo> So it should fallback to the fallback counter thing? [13:35] <DavidRedondo> but even if I define xdg_popup (get_any().type() == typeid(xdg_popup)) is false [13:35] <fvogt> With it defined (i.e. weak) in the executable and LD_PRELOAD it works [13:37] <DavidRedondo> __get_fallback_typeid is only a local symbol [13:37] <DavidRedondo> Are you preloading the plugin? [13:38] <fvogt> Yes, that's the only way to force the executable to use the plugin's symbol [13:38] <fvogt> I can't get the plugin to use the executable's symbol as -rdynamic doesn't work for some reason [13:40] <DavidRedondo> I can't make the preloading work either [13:40] <DavidRedondo> Anything else [13:40] <DavidRedondo> * Anything else I need to do? [13:42] <fvogt> Might be I did the definition in both objects [13:42] <fvogt> Not sure what the best option is, I think something is wrong with the linking still... ELF is weird [13:42] * fvogt will bbl [13:46] <DavidRedondo> Just tell people to compile with the libc++ define? [14:18] <fvogt> DavidRedondo: Supposedly it can be set during llvm build already [14:18] <fvogt> I'll try to ask some toolchain guys here, maybe they already know [14:23] <DavidRedondo> Whole linking and symbol thing is black magic to me [14:23] <DavidRedondo> Not sure who is right or wrong here [...] [14:27] <DavidRedondo> I wonder if this is the same/similar bug [14:27] <DavidRedondo> https://github.com/llvm/llvm-project/issues/48743 [...] [17:16] <fvogt> I'll try to ask the toolchain guys tomorrow, but FWICT there are two options: a) Use RTLD_GLOBAL + declaration of xdg_popup to make it weak b) Tell distros to set _LIBCPP_TYPEINFO_COMPARISON_IMPLEMENTATION=2 Reopened the upstream LLVM bug. Shall we detect this configuration from e.g. plasma-meta and bail out with referencing this bug as long as it is not fixed upstream? (In reply to Andreas Sturmlechner from comment #10) > Shall we detect this configuration from e.g. plasma-meta and bail out with > referencing this bug as long as it is not fixed upstream? I think that's better than nothing for now. I am open-minded to making the change in libc++ but I'm not yet sure if we should. That can/should be done separately. I've hit this bug, too. I tried the libc++ workaround _LIBCPP_TYPEINFO_COMPARISON_IMPLEMENTATION=2 (and LIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2 as well) and I still get the same issue. Is there a proper way to do that? This is how I tried it initially: MYCMAKEARGS="-DLIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2 -D_LIBCPP_TYPEINFO_COMPARISON_IMPLEMENTATION=2" And I also ended up copying the libcxx ebuild over to a local overlay and added in the arguments there. Did I do something wrong? As a user of Plasma 6 with the default libc++ configuration, myself, I'm not quite sure what the consequences would be for other parts of the Plasma 6 ecosystem (apps that might have it as a dependency?) in the long term that aren't affected by this if plasmashell gets blocked as being proposed... And having to change the entire system to stdlibc++ just because right-clicking doesn't work on the task tray and desktop is kind of... bleh. (In reply to unhappy-ending from comment #12) > I've hit this bug, too. I tried the libc++ workaround > _LIBCPP_TYPEINFO_COMPARISON_IMPLEMENTATION=2 (and > LIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2 as well) and I still get the > same issue. Is there a proper way to do that? This is how I tried it > initially: > > MYCMAKEARGS="-DLIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2 > -D_LIBCPP_TYPEINFO_COMPARISON_IMPLEMENTATION=2" > > And I also ended up copying the libcxx ebuild over to a local overlay and > added in the arguments there. > > Did I do something wrong? On my machine the following works: # cat /etc/portage/env/libcxx-typeinfo-comparison # I suggest to build libc++ with -DLIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2, # which mirrors libstdc++ behavior. # See https://bugs.kde.org/show_bug.cgi?id=479679#c23 MYCMAKEARGS="-DLIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2" # cat /etc/portage/package.env/workarounds sys-libs/libcxx libcxx-typeinfo-comparison sys-libs/libcxxabi libcxx-typeinfo-comparison (In reply to Michael Egger from comment #14) > On my machine the following works: > > # cat /etc/portage/env/libcxx-typeinfo-comparison > # I suggest to build libc++ with > -DLIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2, > # which mirrors libstdc++ behavior. > # See https://bugs.kde.org/show_bug.cgi?id=479679#c23 > > MYCMAKEARGS="-DLIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2" > > > # cat /etc/portage/package.env/workarounds > sys-libs/libcxx libcxx-typeinfo-comparison > sys-libs/libcxxabi libcxx-typeinfo-comparison Did exactly this, with sane *FLAGS just to be sure, and it still doesn't work for me. What version are you using? I'm assuming your libcxx and libcxxabi are static-libs? (In reply to unhappy-ending from comment #15) > (In reply to Michael Egger from comment #14) > > On my machine the following works: > > > > # cat /etc/portage/env/libcxx-typeinfo-comparison > > # I suggest to build libc++ with > > -DLIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2, > > # which mirrors libstdc++ behavior. > > # See https://bugs.kde.org/show_bug.cgi?id=479679#c23 > > > > MYCMAKEARGS="-DLIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2" > > > > > > # cat /etc/portage/package.env/workarounds > > sys-libs/libcxx libcxx-typeinfo-comparison > > sys-libs/libcxxabi libcxx-typeinfo-comparison > > Did exactly this, with sane *FLAGS just to be sure, and it still doesn't > work for me. What version are you using? I'm assuming your libcxx and > libcxxabi are static-libs? Yes, those are the versions and USE flags I'm using. I masked llvm 18 and related libraries completely. sys-libs/libcxx-17.0.6::gentoo was built with the following: USE="(clang) (libcxxabi) static-libs verify-sig -test" ABI_X86="(32) (64) (-x32)" FEATURES="usersync strict-keepdir unmerge-logs binpkg-multi-instance sandbox strict news merge-wait binpkg-logs ebuild-locks binpkg-dostrip unmerge-orphans merge-sync buildpkg userfetch xattr binpkg-docompress assume-digests network-sandbox split-log pkgdir-index-trusted parallel-fetch pid-sandbox clean-logs ipc-sandbox preserve-libs protect-owned fixlafiles warn-on-large-env config-protect-if-modified sfperms userpriv qa-unresolved-soname-deps unknown-features-warn nodoc buildpkg-live distlocks multilib-strict usersandbox" sys-libs/libcxxabi-17.0.6::gentoo was built with the following: USE="(clang) static-libs verify-sig -test" ABI_X86="(32) (64) (-x32)" FEATURES="usersync strict-keepdir unmerge-logs binpkg-multi-instance sandbox strict news merge-wait binpkg-logs ebuild-locks binpkg-dostrip unmerge-orphans merge-sync buildpkg userfetch xattr binpkg-docompress assume-digests network-sandbox split-log pkgdir-index-trusted parallel-fetch pid-sandbox clean-logs ipc-sandbox preserve-libs protect-owned fixlafiles warn-on-large-env config-protect-if-modified sfperms userpriv qa-unresolved-soname-deps unknown-features-warn nodoc buildpkg-live distlocks multilib-strict usersandbox" To be sure I also rebuild all of dev-qt, kde-frameworks and kde-plasma packages. (In reply to Michael Egger from comment #16) > > Yes, those are the versions and USE flags I'm using. I masked llvm 18 and > related libraries completely. > > sys-libs/libcxx-17.0.6::gentoo was built with the following: > USE="(clang) (libcxxabi) static-libs verify-sig -test" ABI_X86="(32) (64) > (-x32)" > FEATURES="usersync strict-keepdir unmerge-logs binpkg-multi-instance sandbox > strict news merge-wait binpkg-logs ebuild-locks binpkg-dostrip > unmerge-orphans merge-sync buildpkg userfetch xattr binpkg-docompress > assume-digests network-sandbox split-log pkgdir-index-trusted parallel-fetch > pid-sandbox clean-logs ipc-sandbox preserve-libs protect-owned fixlafiles > warn-on-large-env config-protect-if-modified sfperms userpriv > qa-unresolved-soname-deps unknown-features-warn nodoc buildpkg-live > distlocks multilib-strict usersandbox" > > sys-libs/libcxxabi-17.0.6::gentoo was built with the following: > USE="(clang) static-libs verify-sig -test" ABI_X86="(32) (64) (-x32)" > FEATURES="usersync strict-keepdir unmerge-logs binpkg-multi-instance sandbox > strict news merge-wait binpkg-logs ebuild-locks binpkg-dostrip > unmerge-orphans merge-sync buildpkg userfetch xattr binpkg-docompress > assume-digests network-sandbox split-log pkgdir-index-trusted parallel-fetch > pid-sandbox clean-logs ipc-sandbox preserve-libs protect-owned fixlafiles > warn-on-large-env config-protect-if-modified sfperms userpriv > qa-unresolved-soname-deps unknown-features-warn nodoc buildpkg-live > distlocks multilib-strict usersandbox" > > To be sure I also rebuild all of dev-qt, kde-frameworks and kde-plasma > packages. Ok, I'm on 18.1.5. I will rebuild qt and kde first and then roll back to 17. I'll report afterwards. Even if this isn't useful I just want to rule out a possible missed step. All right, I just finished rebuilding dev-qt, kde-frameworks, and kde-plasma. I can confirm that after a reboot it is working. It's not enough to just build the two libraries, I had to rebuild the above as well. I haven't pinpointed what exactly it is and probably won't hunt for it. I can confirm that after I previously built libcxx & libcxxabi with the MYCMAKEARGS flag I had also rebuilt plasma-workspace which wasn't enough. So, there is something further down the dependency tree that requires the rebuild before the libcxx change kicks in. Not sure if libcxxabi also requires the change and I don't want to rebuild 150 packages to find out. If I ever get around to it, I'll report back here. (In reply to Michael Egger from comment #14) > # cat /etc/portage/package.env/workarounds > sys-libs/libcxx libcxx-typeinfo-comparison > sys-libs/libcxxabi libcxx-typeinfo-comparison libcxxabi MYCMAKEARGS=-DLIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2 doesn't seem required. Did Right clicking works after full rebuild. (In reply to Neko-san from comment #13) > As a user of Plasma 6 with the default libc++ configuration, myself, I'm not > quite sure what the consequences would be for other parts of the Plasma 6 > ecosystem (apps that might have it as a dependency?) in the long term that > aren't affected by this if plasmashell gets blocked as being proposed... > > And having to change the entire system to stdlibc++ just because > right-clicking doesn't work on the task tray and desktop is kind of... bleh. I don't think it is overkill in the sense of "well, the software doesn't work correctly at all, and you're lucky it shows up via a trivial obvious part, rathe r than eating your data." But yes, if we add such a bail out, it should be either a warning, or an error with an env-var to skip it. With inspiration from comments here I tested some dependencies on my laptop with musl/llvm profile, building only qtwayland with libcxx cmake flag did make right click work again. (In reply to kingfared from comment #21) > With inspiration from comments here I tested some dependencies on my laptop > with musl/llvm profile, building only qtwayland with libcxx cmake flag did > make right click work again. You sure! I try the `MYCMAKEARGS="-DLIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2"` only on dev-qt/qtwayland and the right click didn't get solved. But I on the glibc/llvm profile tho. (In reply to Gonçalo Negrier Duarte from comment #22) > (In reply to kingfared from comment #21) > > With inspiration from comments here I tested some dependencies on my laptop > > with musl/llvm profile, building only qtwayland with libcxx cmake flag did > > make right click work again. > > You sure! I try the > `MYCMAKEARGS="-DLIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2"` only on > dev-qt/qtwayland and the right click didn't get solved. But I on the > glibc/llvm profile tho. I also need to rebuild sys-libs/libcxx as well to work (In reply to Sam James from comment #20) > But yes, if we add such a bail out, it should be either a warning, or an > error with an env-var to skip it. Not saying this is a real blocker, but if we have those users, they shall really be warned about this footgun. I'm going to add the workaround warning for now. I still need to find someone to speak to about if we should implement the libc++ setting distro-wide (or someone else is free to do that). The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/kde.git/commit/?id=3c18c4e47fdf33fc3ade6415e554a5e7bb4b2776 commit 3c18c4e47fdf33fc3ade6415e554a5e7bb4b2776 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-06-13 00:57:35 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-06-13 00:58:32 +0000 kde-plasma/plasma-meta: add ewarn for libc++ I still need to find someone to speak to about if we should implement the libc++ setting distro-wide (or someone else is free to do that). Bug: https://bugs.kde.org/479679 Bug: https://bugs.gentoo.org/923292 Signed-off-by: Sam James <sam@gentoo.org> kde-plasma/plasma-meta/plasma-meta-6.1.49.9999.ebuild | 13 +++++++++++++ kde-plasma/plasma-meta/plasma-meta-9999.ebuild | 13 +++++++++++++ 2 files changed, 26 insertions(+) The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3b4f3c13ff83e5a9b0470252393279b02c323d7f commit 3b4f3c13ff83e5a9b0470252393279b02c323d7f Author: Sam James <sam@gentoo.org> AuthorDate: 2024-06-13 00:57:35 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-06-13 00:59:48 +0000 kde-plasma/plasma-meta: add ewarn for libc++ I still need to find someone to speak to about if we should implement the libc++ setting distro-wide (or someone else is free to do that). Bug: https://bugs.kde.org/479679 Bug: https://bugs.gentoo.org/923292 Signed-off-by: Sam James <sam@gentoo.org> kde-plasma/plasma-meta/plasma-meta-6.0.90-r1.ebuild | 13 +++++++++++++ 1 file changed, 13 insertions(+) ... and therefore no longer a blocker. (In reply to Larry the Git Cow from comment #27) > The bug has been referenced in the following commit(s): > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=3b4f3c13ff83e5a9b0470252393279b02c323d7f > > commit 3b4f3c13ff83e5a9b0470252393279b02c323d7f > Author: Sam James <sam@gentoo.org> > AuthorDate: 2024-06-13 00:57:35 +0000 > Commit: Sam James <sam@gentoo.org> > CommitDate: 2024-06-13 00:59:48 +0000 > > kde-plasma/plasma-meta: add ewarn for libc++ > > I still need to find someone to speak to about if we should implement the > libc++ setting distro-wide (or someone else is free to do that). > > Bug: https://bugs.kde.org/479679 > Bug: https://bugs.gentoo.org/923292 > Signed-off-by: Sam James <sam@gentoo.org> > > kde-plasma/plasma-meta/plasma-meta-6.0.90-r1.ebuild | 13 +++++++++++++ > 1 file changed, 13 insertions(+) It should be "-DLIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2" not =1. Also for what I tried, dev-qt/qtwayland need to be rebuild with the flag. (In reply to Rin Cat from comment #29) > It should be "-DLIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2" not =1. Also > for what I tried, dev-qt/qtwayland need to be rebuild with the flag. Just to clarify, dev-qt/qtwayland doesn't need the flag, it just needs to be rebuilt after the libcxx is rebuilt with MYCMAKEARGS=-DLIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2. It depends on if you're passing the similarly-named but different flag for CPPFLAGS, yeah. I'll tweak the PR. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/kde.git/commit/?id=9e81906b42a6f4963297b2c241fc25d245581443 commit 9e81906b42a6f4963297b2c241fc25d245581443 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-06-23 17:49:28 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-06-25 02:44:56 +0000 kde-plasma/plasma-meta: fix libc++ workaround advice Rin Cat points out on the bug that it should be =2, not =1. Also, clarify the need to rebuild packages afterwards. Bug: https://bugs.gentoo.org/923292 Signed-off-by: Sam James <sam@gentoo.org> kde-plasma/plasma-meta/plasma-meta-6.1.49.9999.ebuild | 3 ++- kde-plasma/plasma-meta/plasma-meta-9999.ebuild | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1c83a085d4c37c247d844dfc0b0f9a76e642763b commit 1c83a085d4c37c247d844dfc0b0f9a76e642763b Author: Sam James <sam@gentoo.org> AuthorDate: 2024-06-23 17:49:28 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-06-25 22:32:06 +0000 kde-plasma/plasma-meta: fix libc++ workaround advice Rin Cat points out on the bug that it should be =2, not =1. Also, clarify the need to rebuild packages afterwards. Bug: https://bugs.gentoo.org/923292 Signed-off-by: Sam James <sam@gentoo.org> kde-plasma/plasma-meta/plasma-meta-6.1.1.ebuild | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) |