| Summary: | Missing Icons in Breeze Light and Twilight. | ||
|---|---|---|---|
| Product: | [KDE Neon] neon | Reporter: | duha.bugs |
| Component: | Packages User Edition | Assignee: | Neon Bugs <neon-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bizyaev, christoph, jr, nate, neon-bugs, s_chriscollins |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Neon | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=487374 | ||
| Latest Commit: | https://invent.kde.org/frameworks/breeze-icons/-/commit/ddac172cba33db77143b9df4e5ad32be4e19cff6 | Version Fixed In: | Frameworks 6.16 |
| Sentry Crash Report: | |||
|
Description
duha.bugs
2024-05-23 22:55:22 UTC
Any chance libplasma can cause this? If it affects apps at all, then no. Even if it's Plasma only, I doubt it. All these icons are drawn using Kirigami.Icon, which is in Kirigami, not Libplasma. Can't reproduce that with either master or the 6.2 packages that NixOS ships. If somebody who can reproduce that and do a package build in the way it happens, one could try if e.g. https://invent.kde.org/frameworks/breeze-icons/-/blob/master/src/lib/CMakeLists.txt?ref_type=heads Using here qt_add_resources instead of qt_add_big_resources would help, as people said that might be an issue. Yes it was qt_add_big_resources being optimised. Use of qt_add_resources fixes it. And stopping use of dh_dwz debhelper script also seemed to stop the problem. Nice! Please see bug 499674. *** This bug has been marked as a duplicate of bug 499674 *** We would go back to binary big resource and have a test that detects the LTO fail. But packagers would need to disable LTO. Git commit 75fd5c16d1cf0bb6756d4dedd073fed2ef6ee325 by Christoph Cullmann. Committed on 17/06/2025 at 16:42. Pushed by cullmann into branch 'master'. use big resource variant, else we OOM on 32 bit machines this has issues with LTO, we have a unit test that tells if stuff got lost in the DLL fix the resource loading for static library building, uncovered by the new unit test Related: bug 499674 M +1 -0 .gitignore M +5 -1 autotests/CMakeLists.txt A +68 -0 autotests/resourcetest.cpp [License: LGPL(v2.0+)] M +3 -2 src/lib/CMakeLists.txt M +9 -0 src/lib/breezeicons.cpp https://invent.kde.org/frameworks/breeze-icons/-/commit/75fd5c16d1cf0bb6756d4dedd073fed2ef6ee325 Git commit ddac172cba33db77143b9df4e5ad32be4e19cff6 by Sam James. Committed on 19/06/2025 at 21:22. Pushed by cullmann into branch 'master'. Disable LTO for qt_add_big_resources In fa44b11bc2b36d5c3cfc5c3403ea75b2fff57253, we went from qt_add_big_resources to qt_add_resources because the former breaks with LTO, then we recently went back to qt_add_big_resources in 75fd5c16d1cf0bb6756d4dedd073fed2ef6ee325 to fix the build on 32-bit machines. That leaves LTO broken: try to use CMake to disable LTO for kbreezeicons rather than asking distributors to disable LTO manually. I tried to use CMake's support for LTO/IPO to disable it per-target but it doesn't actually pass -fno-lto or anything if you're not using CMake's support to enable LTO in the first place. Bug: https://bugs.gentoo.org/956679 Bug: https://bugreports.qt.io/browse/QTBUG-41301 Related: bug 499674 M +11 -0 CMakeLists.txt https://invent.kde.org/frameworks/breeze-icons/-/commit/ddac172cba33db77143b9df4e5ad32be4e19cff6 |