[digikam] [Bug 372093] New: corrupts image file when crashing
https://bugs.kde.org/show_bug.cgi?id=372093 Bug ID: 372093 Summary: corrupts image file when crashing Product: digikam Version: unspecified Platform: Kubuntu Packages OS: Linux Status: UNCONFIRMED Severity: major Priority: NOR Component: Metadata Assignee: digikam-de...@kde.org Reporter: ka...@posteo.eu Target Milestone: --- After having seen a few mid-work crashes, some image files are corrupted in the sense that they load, but only contain the upper part of the image. It seems the write to the image file stopped mid-file, presumably caused by a program crash. In most of the crash situations digikam was in the process of changing metadata to a bunch of images. My guess is that it was not only changing this metadata in its database, but also inside the image files itself. When the process crashes while rewriting an image file, this file doesn't seem to be protected against corruption. (I. e. it seems the file gets overwritten directly instead of writing a copy and replacing the former file only when he new copy was written correctly.) [NB: It would take me weeks to find my way through the source code. If someone might point me to the src file taking care of overwriting image file in the relevant cases, I _might_ be able to submit a code proposal.] -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 372093] corrupts image file when crashing
https://bugs.kde.org/show_bug.cgi?id=372093 --- Comment #3 from Kai --- I only worked with JPGs in that case. It will be a few days before I have access to that computer again. I'm going to add all the version details then. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 372093] corrupts image file when crashing
https://bugs.kde.org/show_bug.cgi?id=372093 --- Comment #5 from Kai --- Created attachment 102484 --> https://bugs.kde.org/attachment.cgi?id=102484&action=edit corrupted example jpg corrupted example jpg -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 372093] corrupts image file when crashing
https://bugs.kde.org/show_bug.cgi?id=372093 --- Comment #6 from Kai --- sorry for taking this long I got the version from the kubuntu-backports for ubuntu trusty, which - sadly - is v. 4.0.0 (cannot set this version number in the metadata of this bug entry). LibExiv2 is tagged with version 0.23 here. Up to now I only used this version that I can install from packages sources. Nonetheless I uploaded a <1M corrupted jpg file to demonstrate what I'm trying to describe (the file should be 5M to 8M). -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 372093] corrupts image file when crashing
https://bugs.kde.org/show_bug.cgi?id=372093 --- Comment #8 from Kai --- Seems fair enough. I'll try that way. please close this bug report as "outdated", "not a bug", or something like this (seems I cannot switch to theses states myself - only to resolved) Thanks for bothering! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 438253] Deleting a large number of tags takes much more than 24h
https://bugs.kde.org/show_bug.cgi?id=438253 --- Comment #7 from kai --- Hello Gilles, Sorry, I cannot test this, because - I do not use digiKam anymore - I removed the ITCP tags directly from the image files. Kindly close the issue Best regards Kai -Original Message- From: bugzilla_nore...@kde.org Sent: Montag, 1. Mai 2023 09:25 To: kai.hackenb...@gmx.net Subject: [digikam] [Bug 438253] Deleting a large number of tags takes much more than 24h https://bugs.kde.org/show_bug.cgi?id=438253 --- Comment #6 from caulier.gil...@gmail.com --- @kai digiKam 8.0.0 is out. This entry still valid with this release ? Best regards Gilles Caulier -- You are receiving this mail because: You reported the bug.= -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 488941] Plasma 6.1 Screen turn off on login into a Wayland session if HDR is enabled
https://bugs.kde.org/show_bug.cgi?id=488941 Kai changed: What|Removed |Added CC||m...@kmoschcau.de --- Comment #15 from Kai --- Hi, I can still reproduce this after just having upgraded the nvidia drivers from 555.58 to 555.58.02. I have `nvidia-drm.modeset=1` and `nvidia-drm.fbdev=1`. When I start into the Wayland session from SDDM with HDR enabled, I loose all display output and switching to a different tty no longer works. I can boot up to SDDM, switch to a different tty, disable HDR in `~/.config/kwinoutputconfig.json` and then just start the Wayland session no problem. Also enabling HDR when already in the session works. Operating System: EndeavourOS KDE Plasma Version: 6.1.1 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.2 Kernel Version: 6.9.7-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-9700K CPU @ 3.60GHz Memory: 31.2 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 2080/PCIe/SSE2 Manufacturer: Gigabyte Technology Co., Ltd. Product Name: Z390 AORUS MASTER -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 478875] SDDM and kscreenlocker does not accept enter key in X11 when qt6-virtualkeyboard is installed
https://bugs.kde.org/show_bug.cgi?id=478875 Kai changed: What|Removed |Added CC||hatesh...@web.de -- You are receiving this mail because: You are watching all bug changes.
[krdc] [Bug 482081] New: Translation of local keyboard layout fails when not set to en-US
https://bugs.kde.org/show_bug.cgi?id=482081 Bug ID: 482081 Summary: Translation of local keyboard layout fails when not set to en-US Classification: Applications Product: krdc Version: 23.08.5 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: VNC Assignee: uwol...@kde.org Reporter: kn5i02...@mozmail.com CC: aa...@kde.org Target Milestone: --- SUMMARY Only when the local keyboard layout is set to English (US) the keys are transmitted almost correctly. STEPS TO REPRODUCE 1. Set local keyboard layout to something different then English (US). In my case German. 2. Connect to a remote with VNC. 3. Try to type any special characters. OBSERVED RESULT 1. When the local and remote keymap is set to German: "@" -> "²", "&" -> "/", "-" -> "ß", "_" -> "?", "|" -> "’" 2. When the local keymap is set to German and the remote keymap to English (US): "@" -> "2", "&" -> "&", "-" -> "-", "_" -> "_", "|" -> "\" 3. When the local and remote keymap is set to English (US): seems to work fine 4. When the local keymap is set to English (US) and the remote keymap to German: almost correct. like typing on a German keyboard EXPECTED RESULT Keyboard input should be transmitted correctly. SOFTWARE/OS VERSIONS Linux: Arch Linux 6.7.6-arch1-1 KDE Plasma Version: 5.27.10 KDE Frameworks Version: 5.115.0 Qt Version: 5.15.12 -- You are receiving this mail because: You are watching all bug changes.
[krdc] [Bug 482081] Translation of local keyboard layout fails when not set to en-US
https://bugs.kde.org/show_bug.cgi?id=482081 Kai changed: What|Removed |Added CC||kn5i02...@mozmail.com -- You are receiving this mail because: You are watching all bug changes.
[kded-appmenu] [Bug 483335] New: Application menu throws an error and is empty with some Qt5 applications
https://bugs.kde.org/show_bug.cgi?id=483335 Bug ID: 483335 Summary: Application menu throws an error and is empty with some Qt5 applications Classification: Plasma Product: kded-appmenu Version: 6.0.0 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Titlebar menu button/popup Assignee: plasma-b...@kde.org Reporter: kn5i02...@mozmail.com Target Milestone: --- SUMMARY When starting some Qt5 applications (krdc, kmymoney, qt5-tools, keepassxc, sqlitebrowser) the following error is displayed in system logs and the application menu is not accessible (empty or hidden). ``` 12/03/2024 13:20kded6 org.kde.plasma.appmenu: Got an error 12/03/2024 13:20kded6 org.kde.plasma.appmenu: Got an error 12/03/2024 13:20kded6 org.kde.plasma.appmenu: Got an error 12/03/2024 13:20kded6 org.kde.plasma.appmenu: Got an error ``` STEPS TO REPRODUCE 1. Open an application, watch the logs and search for the application menu. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.7.9-arch1-1 (64-bit) (available in About System) KDE Plasma Version: 6.0.1 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 -- You are receiving this mail because: You are watching all bug changes.
[kded-appmenu] [Bug 483335] Application menu throws an error and is empty with some Qt5 applications
https://bugs.kde.org/show_bug.cgi?id=483335 Kai changed: What|Removed |Added CC||kn5i02...@mozmail.com -- You are receiving this mail because: You are watching all bug changes.
[kded-appmenu] [Bug 483335] Application menu throws an error and is empty with some Qt5 applications
https://bugs.kde.org/show_bug.cgi?id=483335 --- Comment #2 from Kai --- (In reply to Nicolas Fella from comment #1) > Is plasma5-integration installed? No, it wasn't. Only plasma-integration. Manually installing plasma5-integration solved the problem. Thank you. -- You are receiving this mail because: You are watching all bug changes.
[korganizer] [Bug 483707] New: When selecting a end date for a recurring event the wrong date is saved
https://bugs.kde.org/show_bug.cgi?id=483707 Bug ID: 483707 Summary: When selecting a end date for a recurring event the wrong date is saved Classification: Applications Product: korganizer Version: 6.0.0 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: recurrence Assignee: kdepim-b...@kde.org Reporter: kn5i02...@mozmail.com Target Milestone: --- SUMMARY When selecting a end date for a recurring event the date before the selected date is used. STEPS TO REPRODUCE 1. Create a recurring event with a end date ending "on" a specific date 2. See that the event ends one day before the selected date OBSERVED RESULT The saved date to end the recurring event is one day before the selected event. EXPECTED RESULT The selected event should be used. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.7.9-arch1-1 (64-bit) (available in About System) KDE Plasma Version: 6.0.0 KDE Frameworks Version: 6.0.2 Qt Version: 6.6.2 -- You are receiving this mail because: You are watching all bug changes.
[korganizer] [Bug 483707] When selecting a end date for a recurring event the wrong date is saved
https://bugs.kde.org/show_bug.cgi?id=483707 Kai changed: What|Removed |Added CC||kn5i02...@mozmail.com -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 480102] New: Not possible to install krita ai diffusion
https://bugs.kde.org/show_bug.cgi?id=480102 Bug ID: 480102 Summary: Not possible to install krita ai diffusion Classification: Applications Product: krita Version: 5.2.1 Platform: macOS (DMG) OS: macOS Status: REPORTED Severity: grave Priority: NOR Component: Usability Assignee: krita-bugs-n...@kde.org Reporter: kai.sim...@t-online.de Target Milestone: --- SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. 2. 3. OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 480102] Not possible to install krita ai diffusion
https://bugs.kde.org/show_bug.cgi?id=480102 kai changed: What|Removed |Added CC||kai.sim...@t-online.de -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 440279] Find box partially obscured by panes' titlebars when loading split layout from file
https://bugs.kde.org/show_bug.cgi?id=440279 Kai changed: What|Removed |Added CC||hatesh...@web.de -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 486813] New: Many error messages because a not existing item could not be deleted
https://bugs.kde.org/show_bug.cgi?id=486813 Bug ID: 486813 Summary: Many error messages because a not existing item could not be deleted Classification: Applications Product: kmail2 Version: unspecified Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kdepim-b...@kde.org Reporter: kn5i02...@mozmail.com Target Milestone: --- Created attachment 169344 --> https://bugs.kde.org/attachment.cgi?id=169344&action=edit Screenshot of error messages SUMMARY Sometimes my complete desktop gets filled with error messages, because a not existing calendar item can not be deleted. Even though the logs suggest that this is a problem with the calendar synchronization I opened this bug for kmail because the error messages belong to kmail. OBSERVED RESULT Sometimes my complete desktop gets filled with error messages, because a not existing calendar item can not be deleted. These windows open almost simultaneously. I have collected the following output from the log files and attached a screenshot of the error messages. ``` 09/05/2024 15:08kioworker Detected locale "C" with character encoding "ANSI_X3.4-1968", which is not UTF-8. Qt depends on a UTF-8 locale, and has switched to "C.UTF-8" instead. If this causes problems, reconfigure your locale. See the locale(1) manual for more information. 09/05/2024 15:08akonadi_davgroupware_resource org.kde.pim.davresource: Unable to fetch collections 320 "Invalid responses from backend" 09/05/2024 15:08kioworker Detected locale "C" with character encoding "ANSI_X3.4-1968", which is not UTF-8. Qt depends on a UTF-8 locale, and has switched to "C.UTF-8" instead. If this causes problems, reconfigure your locale. See the locale(1) manual for more information. 09/05/2024 15:08akonadiserver org.kde.pim.akonadiserver: Error while handling command DeleteItems on connection kalendarac-1686444273 (0x57b8ac82a020) 09/05/2024 15:08kalendarac "No items found" 09/05/2024 15:08kmail "No items found" 09/05/2024 15:08akonadiserver org.kde.pim.akonadiserver: Error while handling command DeleteItems on connection kmail2-3365511548 (0x57b8ac82ac00) 09/05/2024 15:08kalendarac "No items found" 09/05/2024 15:08akonadiserver org.kde.pim.akonadiserver: Error while handling command DeleteItems on connection kalendarac-1686444273 (0x57b8ac82a020) 09/05/2024 15:08akonadiserver org.kde.pim.akonadiserver: Error while handling command DeleteItems on connection kmail2-3365511548 (0x57b8ac82ac00) 09/05/2024 15:08kmail "No items found" 09/05/2024 15:08kalendarac "No items found" 09/05/2024 15:08akonadiserver org.kde.pim.akonadiserver: Error while handling command DeleteItems on connection kalendarac-1686444273 (0x57b8ac82a020) 09/05/2024 15:08kmail "No items found" 09/05/2024 15:08akonadiserver org.kde.pim.akonadiserver: Error while handling command DeleteItems on connection kmail2-3365511548 (0x57b8ac82ac00) 09/05/2024 15:08kalendarac org.kde.pim.akonadicalendar: CalendarBase::internalRemove2: incidence is null, item.id= "22399; summary=Test; uid=12cf5e7b-d84d-46cf-8814-dfc799e82732; type=0; recurs=0; recurrenceId=Tue May 24 14:00:00 2022 UTC+02:00; dtStart=Tue May 24 14:00:00 2022 UTC+02:00; dtEnd=Tue May 24 14:01:00 2022 UTC+02:00; parentCollection=339" 09/05/2024 15:08kalendarac org.kde.pim.akonadicalendar: CalendarBase::internalRemove2: incidence is null, item.id= "22611; summary=Test; uid=14504994-2727-46f0-8bb7-bc88df40a095; type=0; recurs=0; recurrenceId=; dtStart=Mon Mar 6 19:30:42 2023 UTC+01:00; dtEnd=Mon Mar 6 22:30:42 2023 UTC+01:00; parentCollection=339" 09/05/2024 15:08kmail org.kde.pim.akonadicalendar: CalendarBase::internalRemove2: incidence is null, item.id= "22399; summary=Test; uid=12cf5e7b-d84d-46cf-8814-dfc799e82732; type=0; recurs=0; recurrenceId=Tue May 24 14:00:00 2022 UTC+02:00; dtStart=Tue May 24 14:00:00 2022 UTC+02:00; dtEnd=Tue May 24 14:01:00 2022 UTC+02:00; parentCollection=339" 09/05/2024 15:08kmail org.kde.pim.akonadicalendar: CalendarBase::internalRemove2: incidence is null, item.id= "22611; summary=Test; uid=14504994-2727-46f0-8bb7-bc88df40a095; type=0; recurs=0; recurrenceId=; dtStart=Mon Mar 6 19:30:42 2023 UTC+01:00; dtEnd=Mon Mar 6 22:30:42 2023 UTC+01:00; parentCollection=339" 09/05/2024 15:08kmail "No items found" 09/05/2024 15:08akonadiserver org.kde.pim.akonadiserver: Error while handling command DeleteItems on connection kmail2-3365511548 (0x57b8ac82ac00) 09/05/2024 15:08kalendarac org.kde.pim.akonadicalendar: CalendarBase::internalRemove2: incidence is null, item.id= "22685; summary=Test; uid=19289d68-3995-4786-bc3d
[kmail2] [Bug 486813] Many error messages because a not existing item could not be deleted
https://bugs.kde.org/show_bug.cgi?id=486813 Kai changed: What|Removed |Added CC||kn5i02...@mozmail.com -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 445653] New: Plasma Crash Whail Loading Global theme (with use desktop layout from theme checked)
https://bugs.kde.org/show_bug.cgi?id=445653 Bug ID: 445653 Summary: Plasma Crash Whail Loading Global theme (with use desktop layout from theme checked) Product: plasmashell Version: 5.23.3 Platform: Neon Packages OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: k...@davidedmundson.co.uk Reporter: spishock...@gmail.com CC: plasma-b...@kde.org Target Milestone: 1.0 Application: plasmashell (5.23.3) Qt Version: 5.15.3 Frameworks Version: 5.88.0 Operating System: Linux 5.11.0-40-generic x86_64 Windowing System: X11 Distribution: KDE neon User - Plasma 25th Anniversary Edition DrKonqi: 5.23.3 [KCrashBackend] -- Information about the crash: - What I was doing when the application crashed: I just chaneged the desktop global theme, and boom, plasma just crashed - Unusual behavior I noticed: animated elements wernt... well, animated, loading in to an aplication, taskbar just shows practicly just an image on top of the application icon, the splash screen had no animation, and ended shortly in to loading plasma The reporter is unsure if this crash is reproducible. -- Backtrace: Application: Plasma (plasmashell), signal: Segmentation fault [New LWP 1126] [New LWP 1162] [New LWP 1216] [New LWP 1223] [New LWP 1224] [New LWP 1225] [New LWP 1256] [New LWP 1324] [New LWP 1325] [New LWP 1331] [New LWP 1338] [New LWP 1372] [New LWP 1398] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 0x7f99844f2aff in __GI___poll (fds=0x7ffe092981f8, nfds=1, timeout=1000) at ../sysdeps/unix/sysv/linux/poll.c:29 __preamble__ [Current thread is 1 (Thread 0x7f99806479c0 (LWP 1107))] Thread 14 (Thread 0x7f9910dd8700 (LWP 1398)): #0 futex_wait_cancelable (private=, expected=0, futex_word=0x563045b8fcf0) at ../sysdeps/nptl/futex-internal.h:183 #1 __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x563045b8fca0, cond=0x563045b8fcc8) at pthread_cond_wait.c:508 #2 __pthread_cond_wait (cond=0x563045b8fcc8, mutex=0x563045b8fca0) at pthread_cond_wait.c:638 #3 0x7f99848875cb in QWaitConditionPrivate::wait (deadline=..., this=0x563045b8fca0) at thread/qwaitcondition_unix.cpp:146 #4 QWaitCondition::wait (this=this@entry=0x563045c2d5f8, mutex=mutex@entry=0x563045c2d5f0, deadline=...) at thread/qwaitcondition_unix.cpp:225 #5 0x7f99864f2c24 in QSGRenderThreadEventQueue::takeEvent (wait=true, this=0x563045c2d5e8) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qdeadlinetimer.h:68 #6 QSGRenderThread::processEventsAndWaitForMore (this=this@entry=0x563045c2d550) at scenegraph/qsgthreadedrenderloop.cpp:936 #7 0x7f99864f3099 in QSGRenderThread::run (this=0x563045c2d550) at scenegraph/qsgthreadedrenderloop.cpp:1053 #8 0x7f998488145c in QThreadPrivate::start (arg=0x563045c2d550) at thread/qthread_unix.cpp:329 #9 0x7f99837cd609 in start_thread (arg=) at pthread_create.c:477 #10 0x7f99844ff293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 13 (Thread 0x7f992f2fe700 (LWP 1372)): #0 futex_wait_cancelable (private=, expected=0, futex_word=0x56304378be34) at ../sysdeps/nptl/futex-internal.h:183 #1 __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x56304378bde0, cond=0x56304378be08) at pthread_cond_wait.c:508 #2 __pthread_cond_wait (cond=0x56304378be08, mutex=0x56304378bde0) at pthread_cond_wait.c:638 #3 0x7f99848875cb in QWaitConditionPrivate::wait (deadline=..., this=0x56304378bde0) at thread/qwaitcondition_unix.cpp:146 #4 QWaitCondition::wait (this=this@entry=0x5630431db628, mutex=mutex@entry=0x5630431db620, deadline=...) at thread/qwaitcondition_unix.cpp:225 #5 0x7f99864f2c24 in QSGRenderThreadEventQueue::takeEvent (wait=true, this=0x5630431db618) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qdeadlinetimer.h:68 #6 QSGRenderThread::processEventsAndWaitForMore (this=this@entry=0x5630431db580) at scenegraph/qsgthreadedrenderloop.cpp:936 #7 0x7f99864f3099 in QSGRenderThread::run (this=0x5630431db580) at scenegraph/qsgthreadedrenderloop.cpp:1053 #8 0x7f998488145c in QThreadPrivate::start (arg=0x5630431db580) at thread/qthread_unix.cpp:329 #9 0x7f99837cd609 in start_thread (arg=) at pthread_create.c:477 #10 0x7f99844ff293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 12 (Thread 0x7f993dced700 (LWP 1338)): #0 0x7f9982de8508 in g_mutex_unlock () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #1 0x7f9982d9abae in g_main_context_query () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f9982d9b2e8 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7f9982d9b4a3 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7f9984ac261b in QEventDispatcherGlib::processEvents (this=0x7f993b60, f
[plasmashell] [Bug 472790] 100% CPU usage of one core when plasmashell is running
https://bugs.kde.org/show_bug.cgi?id=472790 Kai changed: What|Removed |Added Component|general |generic-performance -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 472790] 100% CPU usage of one core when plasmashell is running
https://bugs.kde.org/show_bug.cgi?id=472790 Kai changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Kai --- problem resolved with next version -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 438253] New: Deleting a large number of tags takes much more than 24h
https://bugs.kde.org/show_bug.cgi?id=438253 Bug ID: 438253 Summary: Deleting a large number of tags takes much more than 24h Product: digikam Version: 7.2.0 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: major Priority: NOR Component: Tags-Manager Assignee: digikam-bugs-n...@kde.org Reporter: kai.hackenb...@gmx.net Target Milestone: --- SUMMARY I want to delete ca. 70,000 tags from the database (not from the images) ca. 90,000 photos are in the database. ca. 80,000 tags are in the database table tags. ca. 80,000 tags are in the database table tagstree. STEPS TO REPRODUCE 1. Start Tag Manager and select ca. 70,000 tags from the list of tags 2. right click on the selected tags and click "Delete" OBSERVED RESULT after 24 hours the process is still running and the application is not responding. In the database table I see about 4 deletions per minute EXPECTED RESULT the deletion process should finish within a minute SOFTWARE/OS VERSIONS Windows: 10 ADDITIONAL INFORMATION The database engine is MySQL The database as well as the photos are hosted on a fast performing SSD. The CPU has 6 cores (12 with HT) RAM is 32 GB My GUESS: The database uses a trigger on deletion in table tags, which removes the related entries from table tagtree. I am no DB expert, but this trigger seems heavy if executed for each deletion of one of the 70,000 to be deleted tags. My Proposal: Can you please send me a DELETE/JOIN statement that I could execute on the directly against the database instead of using Tag Manager. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 438253] Deleting a large number of tags takes much more than 24h
https://bugs.kde.org/show_bug.cgi?id=438253 --- Comment #3 from kai --- Thanks for the extremely fast responses! Deactivating AntiVirus did not help. You mentioned that MySQL behaves slow here. Would you recommend to go back to SQLite? The reason why I want to delete these tags is because digiKam takes ca. 4 minutes to start (just like ACDSee) and I assumed that the number of tags might be the reason. (Btw.: I have that high number of (useless) tags because GeoSetter writes the geo-position (lat and lon) into the ITPC as keywords. However, I do not need them there.) If all fails: Is it possible you send me a SQL statement that deletes all tags "LIKE 'geo:%' from your DB that I can run without corrupting your DB/program logic? -- You are receiving this mail because: You are watching all bug changes.
[plasma-browser-integration] [Bug 488653] plasma-browser-integration-host crashes in Firefox 127.0 after upgrade to Plasma 6.1
https://bugs.kde.org/show_bug.cgi?id=488653 Kai changed: What|Removed |Added CC||kn5i02...@mozmail.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 488941] Plasma 6.1 Screen turn off on login into a Wayland session if HDR is enabled
https://bugs.kde.org/show_bug.cgi?id=488941 Kai changed: What|Removed |Added Version|6.1.1 |6.1.2 CC||kai.uppenbr...@gmail.com --- Comment #22 from Kai --- Can confirm that the bug is still there. I have the Nvidia driver 555.58.02 KDE Plasma 6.1.2 OS is up to date. After login to KDE 6.1.2 + Wayland both monitors go into standby when HDR is activated. After deleting the file "~/.config/kwinoutputconfig.json" the login is possible. HDR is then deactivated. -- You are receiving this mail because: You are watching all bug changes.
[plasma-browser-integration] [Bug 488653] plasma-browser-integration-host crashes in Firefox 127.0 after upgrade to Plasma 6.1
https://bugs.kde.org/show_bug.cgi?id=488653
--- Comment #24 from Kai ---
(In reply to Fabian Vogt from comment #23)
> If anyone is able to reprouce this reliably, please try
> plasma-browser-integration-host with this line removed:
Your patch seems to have solved the problem for me.
Builded with https://aur.archlinux.org/plasma-browser-integration-git.git and
the following modifications:
diff --git a/PKGBUILD b/PKGBUILD
index fb7e900..c37db3c 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -3,14 +3,14 @@
# Contributor: Antonio Rojas
pkgname=plasma-browser-integration-git
pkgver=6.0.80_r1569.g57b9b6a3
pkgrel=1
pkgdesc='Components necessary to integrate browsers into the Plasma Desktop'
arch=($CARCH)
url='https://www.kde.org/plasma-desktop'
license=(GPL-2.0-or-later)
-depends=(gcc-libs glibc plasma-activities-git kconfig-git kcoreaddons-git
kcrash-git kdbusaddons-git kfilemetadata-git ki18n-git kio-git kjobwidgets-git
kservice-git kstatusnotifieritem-git plasma-workspace-git purpose-git qt6-base)
-makedepends=(git extra-cmake-modules-git)
+depends=(gcc-libs glibc plasma-activities kconfig kcoreaddons kcrash
kdbusaddons kfilemetadata ki18n kio kjobwidgets kservice kstatusnotifieritem
plasma-workspace purpose qt6-base)
+makedepends=(git extra-cmake-modules)
conflicts=(${pkgname%-git})
provides=(${pkgname%-git})
groups=(plasma-git)
@@ -27,6 +27,20 @@ build() {
cmake -B build -S ${pkgname%-git} \
-DQT_MAJOR_VERSION=6 \
-DINSTALL_CHROME_MANIFEST=ON
+
+ patch -d $srcdir/${pkgname%-git} -p1 <setWindowIcon(QIcon::fromTheme(service->icon()));
+
+ m_tasksModel->disconnect(this); // prevent further signal emission to not
deref a nullptr https://bugs.kde.org/show_bug.cgi?id=435811
+-m_tasksModel->deleteLater();
+ m_tasksModel = nullptr;
+
+ return true;
+EOF
+
cmake --build build
}
plasma-browser-integration: 6.1.80_r1606.g51427d9a-1
Firefox: 128.0.3-1
Operating System: Arch Linux
KDE Plasma Version: 6.1.3
KDE Frameworks Version: 6.4.0
Qt Version: 6.7.2
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 488941] Plasma 6.1 Screen turn off on login into a Wayland session if HDR is enabled
https://bugs.kde.org/show_bug.cgi?id=488941 --- Comment #45 from Kai --- I can confirm this behavior with separate HDR/WCG settings. - both disabled: Plasma starts - HDR enabled and WCG disabled: Plasma starts - HDR disabled and WCG enabled: no output to screen - both enabled: no output to screen -- You are receiving this mail because: You are watching all bug changes.
[www.kde.org] [Bug 405026] New: php closing tag on techbase
https://bugs.kde.org/show_bug.cgi?id=405026 Bug ID: 405026 Summary: php closing tag on techbase Product: www.kde.org Version: unspecified Platform: unspecified OS: unspecified Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: kde-...@kde.org Reporter: hatesh...@web.de Target Milestone: --- The page https://techbase.kde.org/Welcome_to_KDE_TechBase and all child pages display the following characters at the bottom: "*/ ?>" These should be removed. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 384700] Setting a shortcut for "Toggle Change Colors" is not remembered
https://bugs.kde.org/show_bug.cgi?id=384700 Kai changed: What|Removed |Added CC||hatesh...@web.de -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 384700] Setting a shortcut for "Toggle Change Colors" is not remembered
https://bugs.kde.org/show_bug.cgi?id=384700 --- Comment #5 from Kai --- I can confirm this bug for Okular 1.3.3 with: Qt: 5.9.5 KDE Frameworks: 5.44.0 -- You are receiving this mail because: You are watching all bug changes.
[www.kde.org] [Bug 374398] New: Can't access techbase.kde.org
https://bugs.kde.org/show_bug.cgi?id=374398 Bug ID: 374398 Summary: Can't access techbase.kde.org Product: www.kde.org Version: unspecified Platform: Kubuntu Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: kde-...@kde.org Reporter: hatesh...@web.de Target Milestone: --- Created attachment 103117 --> https://bugs.kde.org/attachment.cgi?id=103117&action=edit Incapsula spoiler When I open techbase.kde.org via Browser (Firefox 50.1.0.), a spoiler opens, saying: "techbase.kde.org - Additional security check is required" (screenshot) I fear that my settings are misinterpreted by the incapsula service. -Javascript diabled -Cross domain requests disabled -network.http.sendRefererHeader = 0 -changed user agent These settings are important for a users privacy and have nothing to do with "malware infection" as the incapsula spoiler pretends. www.kde.org or wikipedia.org works good, even with the above privacy settings. -- You are receiving this mail because: You are watching all bug changes.
[kdepim] [Bug 499075] New: Some loop and high CPU of the akonadi_davgroupware_resource process and logging Cannot connect to agent
https://bugs.kde.org/show_bug.cgi?id=499075 Bug ID: 499075 Summary: Some loop and high CPU of the akonadi_davgroupware_resource process and logging Cannot connect to agent Classification: Applications Product: kdepim Version: unspecified Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kdepim-b...@kde.org Reporter: kn5i02...@mozmail.com Target Milestone: --- SUMMARY For some reason the akonadi_davgroupware_resource process has started to run with a high CPU load and it dosn't stop. OBSERVED RESULT ❯ sudo ps -aux --pid 2609 USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND kai 2609 99.7 0.6 1563092 105768 ? Rl 20:35 62:45 /usr/bin/akonadi_davgroupware_resource --identifier akonadi_davgroupware_resource_1 EXPECTED RESULT SOFTWARE/OS VERSIONS Operating System: Arch Linux kdepim-runtime Version: 24.12.1-1 KDE Plasma Version: 6.2.5 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.1 Kernel Version: 6.12.10-arch1-1 (64-bit) Graphics Platform: Wayland ADDITIONAL INFORMATION .local/share/akonadi/Akonadi.error 2025-01-23T21:30:08 [CRITICAL] org.kde.pim.akonadiserver: Cannot connect to agent instance with identifier 'akonadi_davgroupware_resource_1', error message: '' 2025-01-23T21:30:08 [CRITICAL] org.kde.pim.akonadiserver: Cannot connect to agent instance with identifier 'akonadi_davgroupware_resource_1', error message: '' 2025-01-23T21:30:08 [CRITICAL] org.kde.pim.akonadiserver: Cannot connect to agent instance with identifier 'akonadi_davgroupware_resource_1', error message: '' 2025-01-23T21:30:08 [CRITICAL] org.kde.pim.akonadiserver: Cannot connect to agent instance with identifier 'akonadi_davgroupware_resource_1', error message: '' 2025-01-23T21:30:08 [CRITICAL] org.kde.pim.akonadiserver: Cannot connect to agent instance with identifier 'akonadi_davgroupware_resource_1', error message: '' 2025-01-23T21:30:08 [CRITICAL] org.kde.pim.akonadiserver: Cannot connect to agent instance with identifier 'akonadi_davgroupware_resource_1', error message: '' 2025-01-23T21:30:08 [CRITICAL] org.kde.pim.akonadiserver: Cannot connect to agent instance with identifier 'akonadi_davgroupware_resource_1', error message: '' 2025-01-23T21:30:08 [CRITICAL] org.kde.pim.akonadiserver: Cannot connect to agent instance with identifier 'akonadi_davgroupware_resource_1', error message: '' 2025-01-23T21:30:08 [CRITICAL] org.kde.pim.akonadiserver: Cannot connect to agent instance with identifier 'akonadi_davgroupware_resource_1', error message: '' 2025-01-23T21:30:08 [CRITICAL] org.kde.pim.akonadiserver: Cannot connect to agent instance with identifier 'akonadi_davgroupware_resource_1', error message: '' 2025-01-23T21:30:08 [CRITICAL] org.kde.pim.akonadiserver: Cannot connect to agent instance with identifier 'akonadi_davgroupware_resource_1', error message: '' 2025-01-23T21:30:08 [CRITICAL] org.kde.pim.akonadiserver: Cannot connect to agent instance with identifier 'akonadi_davgroupware_resource_1', error message: '' 2025-01-23T21:30:08 [CRITICAL] org.kde.pim.akonadiserver: Cannot connect to agent instance with identifier 'akonadi_davgroupware_resource_1', error message: '' 2025-01-23T21:30:08 [CRITICAL] org.kde.pim.akonadiserver: Cannot connect to agent instance with identifier 'akonadi_davgroupware_resource_1', error message: '' 2025-01-23T21:35:08 [CRITICAL] org.kde.pim.akonadiserver: Cannot connect to agent instance with identifier 'akonadi_davgroupware_resource_1', error message: '' 2025-01-23T21:35:08 [CRITICAL] org.kde.pim.akonadiserver: Cannot connect to agent instance with identifier 'akonadi_davgroupware_resource_1', error message: '' 2025-01-23T21:35:08 [CRITICAL] org.kde.pim.akonadiserver: Cannot connect to agent instance with identifier 'akonadi_davgroupware_resource_1', error message: '' 2025-01-23T21:35:08 [CRITICAL] org.kde.pim.akonadiserver: Cannot connect to agent instance with identifier 'akonadi_davgroupware_resource_1', error message: '' 2025-01-23T21:35:08 [CRITICAL] org.kde.pim.akonadiserver: Cannot connect to agent instance with identifier 'akonadi_davgroupware_resource_1', error message: '' 2025-01-23T21:35:08 [CRITICAL] org.kde.pim.akonadiserver: Cannot connect to agent instance with identifier 'akonadi_davgroupware_resource_1', error message: '' 2025-01-23T21:35:08 [CRITICAL] org.kde.pim.akonadiserver: Cannot connect to agent instan
[kdepim] [Bug 499075] Some loop and high CPU of the akonadi_davgroupware_resource process and logging Cannot connect to agent
https://bugs.kde.org/show_bug.cgi?id=499075 Kai changed: What|Removed |Added CC||kn5i02...@mozmail.com -- You are receiving this mail because: You are watching all bug changes.
[kdepim] [Bug 499075] Some loop and high CPU of the akonadi_davgroupware_resource process and logging Cannot connect to agent
https://bugs.kde.org/show_bug.cgi?id=499075 Kai changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #1 from Kai --- The problem seems to be solved with the following version or at least I can not reproduce it any longer. Operating System: Arch Linux kdepim-runtime Version: 24.12.2-1 KDE Plasma Version: 6.3.0 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.2 Kernel Version: 6.13.2-arch1-1 (64-bit) Graphics Platform: Wayland -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 502007] When starting kate with autostart no sessions or recent files are available at start
https://bugs.kde.org/show_bug.cgi?id=502007 Kai changed: What|Removed |Added CC||kn5i02...@mozmail.com -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 502007] New: When starting kate with autostart no sessions or recent files are available at start
https://bugs.kde.org/show_bug.cgi?id=502007 Bug ID: 502007 Summary: When starting kate with autostart no sessions or recent files are available at start Classification: Applications Product: kate Version: 24.12.3 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: sessions Assignee: kwrite-bugs-n...@kde.org Reporter: kn5i02...@mozmail.com Target Milestone: --- SUMMARY When starting kate with autostart no sessions or recent files are available directly after starting the plasma user session. STEPS TO REPRODUCE 1. Open kate, open some files and save a session 2. Put kate into .config/autostart or use the autostart settings 3. Log out and Log in again or restart the computer 4. The kate window does not suggest any sessions or recent files OBSERVED RESULT When starting kate directly after the plasma session is started, no sessions or recent files are available. EXPECTED RESULT Sessions and recent files should be available when autostarting kate. It should also be possible to autostart directly into a existing session with --name. SOFTWARE/OS VERSIONS Kate Version: 24.12.3-1 Operating System: Arch Linux KDE Plasma Version: 6.3.3 KDE Frameworks Version: 6.12.0 Qt Version: 6.8.2 Kernel Version: 6.13.8-arch1-1 (64-bit) Graphics Platform: Wayland ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 502007] When starting kate with autostart no sessions or recent files are available at start
https://bugs.kde.org/show_bug.cgi?id=502007 --- Comment #1 from Kai --- (In reply to Kai from comment #0) > STEPS TO REPRODUCE > 1. Open kate, open some files and save a session > 2. Put kate into .config/autostart or use the autostart settings > 3. Log out and Log in again or restart the computer > 4. The kate window does not suggest any sessions or recent files Small correction, this problem only occurs after the system is started. Log out and log in is not enough. > OBSERVED RESULT > > When starting kate with autostart no sessions or recent files are available > directly after starting the plasma user session. Also the session which is used as session with --name in the autostart command is empty after restart. -- You are receiving this mail because: You are watching all bug changes.
[Elisa] [Bug 503425] music doesn't play after unpausing
https://bugs.kde.org/show_bug.cgi?id=503425 Kai changed: What|Removed |Added CC||kai-...@krulltech.de Status|REPORTED|CONFIRMED Ever confirmed|0 |1 --- Comment #1 from Kai --- I can confirm this bug. Pausing for more than roughly 10-15s causes it. Letting it "play" afterwards for some time can fix the issue after a few more seconds, but I encountered cases where it took longer than I was willing to wait/it switched to the next track first. The system journals do not contain any meaningful information besides the regular song metadata output in ffmpeg style. I first noticed the bug when updating from 24.12.3-1 to 25.04.0-1, but today it remains unfixed in 25.04.1-1 (newest release for my Fedora 42 stable). File/Stream/Decoder tested: FLAC, 44.1kHz -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 505413] Non ASCII characters are not displayed when entered into a from field of a pdf document
https://bugs.kde.org/show_bug.cgi?id=505413 Kai changed: What|Removed |Added CC||kn5i02...@mozmail.com -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 505413] Non ASCII characters are not displayed when entered into a from field of a pdf document
https://bugs.kde.org/show_bug.cgi?id=505413 Kai changed: What|Removed |Added Summary|Non ASCII characters are|Non ASCII characters are |not displayed when entered |not displayed when entered |into a from field |into a from field of a pdf ||document -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 505413] New: Non ASCII characters are not displayed when entered into a from field
https://bugs.kde.org/show_bug.cgi?id=505413 Bug ID: 505413 Summary: Non ASCII characters are not displayed when entered into a from field Classification: Applications Product: okular Version First 25.04.2 Reported In: Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: okular-de...@kde.org Reporter: kn5i02...@mozmail.com Target Milestone: --- SUMMARY When entering non ASCII characters into a form field of a pdf document they are not displayed after leaving the edit mode. STEPS TO REPRODUCE 1. Enter a non ascii character into a form field 2. Leave fill mode for form fields 3. Notice the missing characters OBSERVED RESULT Non ascii characters are not displayed in form fields EXPECTED RESULT All characters should be visible SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.3.5 KDE Frameworks Version: 6.14.0 Qt Version: 6.9.1 Kernel Version: 6.14.10-arch1-1 (64-bit) Graphics Platform: Wayland ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 315488] icon-only task manager groups chrome/chromium web apps with chrome/chromium
https://bugs.kde.org/show_bug.cgi?id=315488 Kai Krakow changed: What|Removed |Added CC||k...@kaishome.de --- Comment #37 from Kai Krakow --- The primary problem here seems to be grouping is based on the ClassClass string, not the ClassName string (which would be preferred for Chrome apps). I think this worked properly with Plasma 5.8.0 but now I'm on Plasma 5.8.2 and it's back to the old behavior. I compared Github but cannot see any changes in the code which would explain this (I checked plasma-desktop and plasma-workspace) so I guess the change is somewhere else (something I updated along Plasma). I'd like to patch this myself to get my preferred behavior back. Do you know where to look (maybe the exact commit) which changed this back to grouping by ClassClass instead of ClassName? When I had Plasma 5.8.0 installed, each Chrome app had its own instance on the taskbar (with child windows properly grouped within the correct task icon) even with the correct icon (not the general Chrome icon). All other apps worked correctly wrt grouping. So I think "wontfix" is not a satisfactory resolve status of this bug. Even unity gets this correct. I'm not even sure if the problem was properly understood when looking at the last comments. If working with a lot of Chrome apps, the behavior as it is right now is a real pita. OTOH, I don't want to disable grouping of Chrome altogether as the taskbar gets much too cluttered then. Comment #9 explained well what the difference is. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 315488] icon-only task manager groups chrome/chromium web apps with chrome/chromium
https://bugs.kde.org/show_bug.cgi?id=315488 --- Comment #39 from Kai Krakow --- So maybe this should be reopened? Although some of the discussion points into the wrong direction by saying that explicitly ungrouping applications is the same - but that is not true... So alternatively open a new bug report? I'm not sure... -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 315488] icon-only task manager groups chrome/chromium web apps with chrome/chromium
https://bugs.kde.org/show_bug.cgi?id=315488 --- Comment #42 from Kai Krakow --- (In reply to Kai Uwe Broulik from comment #41) > Yup, Chrome broke it and I updated the mapping rules, will work again in > Plasma 5.8.4 [1]. There was also a logic flaw in the code that I fixed [2]. > > [1] > https://cgit.kde.org/plasma-workspace.git/commit/?h=Plasma/5. > 8&id=7c443aa53900521deab4fcd4641ea5273afc294e I already added this to /etc/xdg/taskmanagerrulesrc (it's the only file by that name on my system, so I'd expect it's the correct location). I restarted the machine to be sure it takes effect. But nothing changed: Chrome is still grouped no matter if I start it as web browser or as app container. The browser shows this in xprop: WM_WINDOW_ROLE(STRING) = "browser" WM_CLASS(STRING) = "google-chrome", "Google-chrome" One of the app windows (started from a .desktop entry created by chrome): WM_WINDOW_ROLE(STRING) = "pop-up" WM_CLASS(STRING) = "crx_ghaboaaodcboidcanphmnidfikjb", "Google-chrome" Desktop entry: $ ~/.local/share/applications $ cat chrome-ghaboaaodcboidcanphmnidfikjb-Default.desktop #!/usr/bin/env xdg-open [Desktop Entry] Version=1.0 Terminal=false Type=Application Name=Autotask Exec=/opt/google/chrome/google-chrome --profile-directory=Default --app-id=ghaboaaodcboidcanphmnidfikjb Icon=chrome-ghaboaaodcboidcanphmnidfikjb-Default StartupWMClass=crx_ghaboaaodcboidcanphmnidfikjb I expect both windows having distinct icons on the taskbar. > [2] > https://cgit.kde.org/plasma-workspace.git/commit/?h=Plasma/5. > 8&id=61860066a4cea845598fa4904607db1bba411356 Is this needed to fix the behavior? I could include it as Gentoo user patch and recompile... -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 315488] icon-only task manager groups chrome/chromium web apps with chrome/chromium
https://bugs.kde.org/show_bug.cgi?id=315488 --- Comment #44 from Kai Krakow --- Okay, works... Gentoo backported some patches to 5.8.3 which didn't compile, I reverted back to the previous patch level with this patch included and now it works. What I am missing is correct icons. That seemed to work previously. But I guess it is now working correctly because now it matches the icon from the KDE launcher. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 348812] Crash in __strstr_sse2 after QSGRenderContext::initialize(QOpenGLContext*)
https://bugs.kde.org/show_bug.cgi?id=348812 Kai Krakow changed: What|Removed |Added CC|k...@kaishome.de | -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 453554] turning one monitor off kills the panel configuration of the second monitor
https://bugs.kde.org/show_bug.cgi?id=453554 --- Comment #6 from Kai Krakow --- Okay, so I'm now on Plasma 5.25 and this original issue seems fixed. But now, when I turn the monitor back on, the background image of that monitor is gone and completely black. I also cannot right click on the background: no context menu would appear. The panels are still there, and switching the panels to editing mode doesn't show the additional button bar to change background images, global design etc on that monitor (but it's shown on the others). Only restarting plasmashell will bring back the background image and context menu function. -- You are receiving this mail because: You are watching all bug changes.
[yakuake] [Bug 435544] Application focus issue
https://bugs.kde.org/show_bug.cgi?id=435544 Kai Eckert changed: What|Removed |Added Ever confirmed|0 |1 CC||gen-...@kaiec.de Status|REPORTED|CONFIRMED --- Comment #11 from Kai Eckert --- I can confirm that the bug still exists, it annoys me to the point that I had to switch off the "keep open" option. Nothing worse than constantly accidently writing stuff into the wrong window. Yakuake 22.12.3 Plasma 5.27.2 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 450068] Use of volatile connector IDs to map containments to screens cannot be made to work reliably and should be replaced with something else
https://bugs.kde.org/show_bug.cgi?id=450068 --- Comment #27 from Kai Krakow --- We probably need a system which stores a containment layout per number of monitors connecting. If an additional monitor gets connected, clone the next "lower count" layout. Then, sort the primary monitor to the beginning. That means, it would have a mapping `monitor counts -> layout` and then just counts the connectors in a predictive order instead of tracking EDIDs or connector names. At least for my use case, I don't care which monitor is connected to which connector, as long as my primary monitor is tracked correctly and all additional monitors are ordered after it. Predictive order could mean: primary first, then order by EDID, model or connector name. But I think there is at least one underlying severe problem here, and it seems to be a race condition: Plasma-shell, kscreen, the desktop background, and nvidia-settings do not seem to always agree about the order of screens. So sometimes, after a screen gets disconnected and reconnected, plasma-shell may end up with panels and backgrounds not matching my previous setup, or it ends up with no background at all (essentially making it impossible to right click) but the panels are still on that monitor. The components need to be synced somehow, it looks like each one gets its own view of the situation while Xorg still messes around with the detection. The setup should be transactional and only the new layout only reflected to the components if the detection phase is complete. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 356225] Panel moves to wrong screen when external monitor is connected
https://bugs.kde.org/show_bug.cgi?id=356225 --- Comment #409 from Kai Krakow --- (In reply to Nate Graham from comment #408) > This bug report is only about Plasma panels moving, not windows. That's a > different issue. Except it may be not... I'm seeing a similar behavior: Usually, windows store their last screen, and when reopened, restore to the same screen. But sometimes after reboot, this seems to be swapped (probably for the same reason panels moved to a different screen), and sometimes windows do not remember their position at all and go to some awkward default state (like horizontally maximized but not vertically) which is probably the same as when a panel "appears" on a disabled screen or not at all (the windows "remembered" screen does not exist in the screen real estate and just spawn at awkward positions, like partially maximized or halfway out of the screen). I just didn't mention it because I think it will be fixed for me when the panels become fixed. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 412005] Konsole crashes when trying to paste (long texts) from clipboard
https://bugs.kde.org/show_bug.cgi?id=412005 Kai Krakow changed: What|Removed |Added Status|NEEDSINFO |RESOLVED Resolution|WAITINGFORINFO |WORKSFORME --- Comment #2 from Kai Krakow --- (In reply to Justin Zobel from comment #1) > If you can reproduce the issue, please change the status to "CONFIRMED" when > replying. Thank you! I cannot reproduce that any longer. Pasting long text may be a bit laggy but it generally doesn't crash any longer. Closing. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 450068] Use of volatile connector IDs to map containments to screens cannot be made to work reliably and should be replaced with something else
https://bugs.kde.org/show_bug.cgi?id=450068 --- Comment #33 from Kai Krakow --- (In reply to Iyán Méndez Veiga from comment #32) > Plasma 5.25.90 has a new issue and it's really unstable and difficult to > replicate. Every morning when I connect the laptop to the docking station I > have no idea what's going to happen. I can have both screen in duplicate > mode, I can have laptop screen on, and external without background, both > with wrong folder view instead of desktop mode, etc., etc. This behavior is > totally new and was introduced in this Beta. I tried to summarize this in > Bug 459368, but I mentioned it here not to loose the big picture. The seemingly random nature of this (as I understand your description) suggests that there is at least one other underlying bug that completely messes up replication of the problem. I'm seeing quite random behaviour with 5.25, and it looks like the different components of KDE/Plasma don't agree on the same state, which probably means there's also some racing between different components. I already suggested that in a previous comment. It's less likely to observe with just two monitors, but with three or more monitors it really gets messy, with different things (backgrounds, panels, folder views) each individually ending up on completely different monitors than what was configured. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 450068] Use of volatile connector IDs to map containments to screens cannot be made to work reliably and should be replaced with something else
https://bugs.kde.org/show_bug.cgi?id=450068 --- Comment #37 from Kai Krakow --- (In reply to Nate Graham from comment #35) > Unfortunately this is exactly right. [...] > The current system needs to be thrown away and replaced with > something better-engineered from the start, which is in progress for Plasma > 5.27. Thanks for confirming, Nate, very much appreciated. To me this means I'll stay silent for that time to not add unnecessary noise, accepting all strange behavior and trying to live with it. I hope this gets back-ported to 5.26 as 5.27 will probably not arrive before summer 2023. My faith is not lost yet. :-) -- You are receiving this mail because: You are watching all bug changes.
[krdc] [Bug 377911] [Wayland] RDP doesn't work under Wayland
https://bugs.kde.org/show_bug.cgi?id=377911 Kai Krakow changed: What|Removed |Added CC||k...@kaishome.de -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 450301] On KWin 5.24 X11 Nvidia, when reenabling compositing, windows begin flickering and flipping upside-down
https://bugs.kde.org/show_bug.cgi?id=450301 Kai Krakow changed: What|Removed |Added CC||k...@kaishome.de --- Comment #12 from Kai Krakow --- I can confirm this. A mostly reliable reproducer is starting a Steam Proton game which has a launcher that detect DirectX capabilities, e.g. the Elite Dangerous Launcher. Such launchers generate a full screen window for an blink of an eye which disables the compositor and automatically enables it again (I'm forcing composition off through a kwin rule which looks for client windows named "(gamescope|steam_app_)", otherwise games stutter unpredictably in my dual monitor setup and both my monitors drift apart with vsync over time (and X11 always syncs all monitors in a single loop thus syncing to the slowest monitor). This tight disable/enable loop seems to be enough to initially trigger the bug but it usually only occurs when the game ends and closes it's final window (tho, not exclusively, it still may trigger the bug when the launcher starts). The game itself is unaffected. Using shift+alt+F12 to disable compositing cures the flipped and flickering desktop but only until I re-enable compositing. Only restart kwin_x11 fixes it. After it happened once, it is very likely to be triggered more easily, a full reboot is needed to get rid of the behavior for a while. Games that do not trigger tight enable/disable intervals for compositing seem to be less likely trigger the bug. "Force full composition pipeline" is enabled to fix tearing in multimonitor setups. It may be part of the problem, I was never seeing that on my single monitor setup (but this is at least 2 years ago). -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 469279] New: Running akonadi servers easily doubles or triples VRAM usage
https://bugs.kde.org/show_bug.cgi?id=469279 Bug ID: 469279 Summary: Running akonadi servers easily doubles or triples VRAM usage Classification: Frameworks and Libraries Product: Akonadi Version: 5.23.0 Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kdepim-b...@kde.org Reporter: k...@kaishome.de CC: c...@carlschwan.eu Target Milestone: --- SUMMARY After a long time, I wanted to give Akonadi a new chance and installed it. After some time I noticed much worse gaming performance related to VRAM pressure. I've monitored nvidia-smi to see that my idle desktop now uses 3.8 GB of VRAM, with a lot of akonadi resource processes allocating 4 MB each from the driver directly but also the Xorg process was ballooned up to 2.7 GB of VRAM usage even after a fresh reboot. Usually, after reboot, Xorg would use around 800 MB of VRAM with some background processes having 4 MB allocated each, result in around 1.2 GB of VRAM usage for a freshly booted desktop, and up to 2.5 GB after some time of use (that's still a lot but a different concern). STEPS TO REPRODUCE 1. Install akonadi 2. Reboot 3. Observe nvidia-smi output after fresh boot and after some time of use OBSERVED RESULT Over 3 GB of VRAM usage after a fresh boot, increasing to almost 5 GB after some time of use. EXPECTED RESULT Stay below 2.5 GB of VRAM with some web browser windows open and Steam running. SOFTWARE/OS VERSIONS Operating System: Gentoo Linux 2.13 KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.9 Kernel Version: 6.1.26-gentoo (64-bit) Graphics Platform: X11 Processors: 20 × 12th Gen Intel® Core™ i7-12700K Memory: 31.1 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 3080 Ti/PCIe/SSE2 Manufacturer: ASRock Product Name: Z690 Pro RS # equery l nvidia-drivers * Searching for nvidia-drivers ... [IP-] [ ] x11-drivers/nvidia-drivers-525.116.03:0/525 ADDITIONAL INFORMATION Dual-monitor setup with "force full composition pipeline" enabled in nvidia-settings. nvidia-smi without akonadi running: Tue May 2 19:33:30 2023 +-+ | NVIDIA-SMI 525.116.03 Driver Version: 525.116.03 CUDA Version: 12.0 | |---+--+--+ | GPU NamePersistence-M| Bus-IdDisp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |===+==+==| | 0 NVIDIA GeForce ... Off | :01:00.0 On | N/A | | 0% 48CP546W / 370W | 2494MiB / 12288MiB | 30% Default | | | | N/A | +---+--+--+ +-+ | Processes: | | GPU GI CIPID Type Process name GPU Memory | |ID ID Usage | |=| |0 N/A N/A 1625 G /usr/libexec/Xorg1734MiB | |0 N/A N/A 2328 G /usr/bin/kwin_x11 149MiB | |0 N/A N/A 2329 G /usr/bin/ksmserver 4MiB | |0 N/A N/A 2331 G /usr/bin/kded5 4MiB | |0 N/A N/A 2509 G /usr/bin/plasmashell 180MiB | |0 N/A N/A 2570 G ...de-authentication-agent-14MiB | |0 N/A N/A 2573 G ...ec/xdg-desktop-portal-kde4MiB | |0 N/A N/A 2680 G /usr/bin/python3.10 4MiB | |0 N/A N/A 2684 G ...lib64/libexec/kdeconnectd4MiB | |0 N/A N/A 2685 G /usr/bin/kleopatra 4MiB | |0 N/A N/A 2686 G /usr/bin/keepassxc 4MiB | |0 N/A N/A 2698 G /usr/bin/kaccess4MiB | |0 N/A N/A 2702 G .../libexec/DiscoverNotifier4MiB | |0 N/A N/A 3942 G ...aw,WebRTCPipeWireCapturer 88MiB | |0 N/A N/A 3945 G /usr/bin/kwalletd5 4MiB | |0 N/A N/A 4159 G ...b64/libexec/kf5/klauncher4MiB | |0 N/A N/A 4301 G ...-browser-integration-host4MiB | |0 N/A N/A 6838 G ...veSuggestionsOnlyOnDemand 10
[Akonadi] [Bug 469279] Running akonadi servers easily doubles or triples VRAM usage
https://bugs.kde.org/show_bug.cgi?id=469279 --- Comment #1 from Kai Krakow --- BTW: Running "kcmshell5 qtquicksettings" and forcing software rendering for plasma completely eliminates the issue (with Xorg staying really low on VRAM) but then plasma loudly complains about non-optimal rendering settings and I fear this can even reduce game performance if an application renders in parallel to a game (as can be observed when forcing software rendering for Discord which completely degrades GPU performance while gaming). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 469281] New: windows with background blur (e.g., konsole) flicker and leave mouse trails
https://bugs.kde.org/show_bug.cgi?id=469281 Bug ID: 469281 Summary: windows with background blur (e.g., konsole) flicker and leave mouse trails Classification: Plasma Product: kwin Version: 5.27.4 Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: k...@kaishome.de Target Milestone: --- SUMMARY When using kwin_wayland, windows which use transparency with background blur flicker during screen updates and the mouse point may leave square blocks of trails in the background color (as if no background blur was used). This can be observed both with NVIDIA and Intel. Disabling background blur in konsole fixes the issue but other windows may (and even the plasma panels) may still be affected, tho the problem is most prominent with konsole. STEPS TO REPRODUCE 1. Enable background transparency/blur in konsole 2. Update screen contents in konsole and move the mouse point around within the window 3. Move the window around OBSERVED RESULT Trails of background-colored blocks are left behind the mouse cursor, konsole window contents may flicker heavily. EXPECTED RESULT No flickering, no mouse trails. SOFTWARE/OS VERSIONS Operating System: Gentoo Linux 2.13 KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.9 Kernel Version: 6.1.26-gentoo (64-bit) Graphics Platform: X11 Processors: 20 × 12th Gen Intel® Core™ i7-12700K Memory: 31.1 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 3080 Ti/PCIe/SSE2 Manufacturer: ASRock Product Name: Z690 Pro RS ADDITIONAL INFORMATION Also happens with Intel (Gen3 iGPU): Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz But usually, flickering cannot be observed with latest Plasma version but mouse trails are still present. The flicker problem mostly went away after I bumped the iGPU shared memory area from 32 to 512 MB (and it also fixed the lockscreen freezing until I "loginctl unlock-session" from alt+F2 and restart kwin which is not feasible with wayland). I disabled konsole background blur on that iGPU for now because it really hurts desktop rendering performance, so it less a problem on that iGPU anyways for me which mostly lefts us with the issue on NVIDIA. -- You are receiving this mail because: You are watching all bug changes.
[kopete] [Bug 145911] display irc style /me
https://bugs.kde.org/show_bug.cgi?id=145911 Kai Krakow changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |UNMAINTAINED --- Comment #5 from Kai Krakow --- Closing as obsolete/abandoned -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 441077] Plasmashell panels may freeze, usually unrelated but unresponsive NFS/SMB mounts are involved
https://bugs.kde.org/show_bug.cgi?id=441077 --- Comment #12 from Kai Krakow --- I partially found automounts triggering the problem. With automounts enabled, right clicking on dolphin window icons or starting konsole (probably every app that is somehow involved in checking mount point stats) can stall either plasma (when a context menu is displayed) or stall konsole startup for multiple seconds up to a minute. Interestingly, just using "cd" to switch to a directory with automount point and running "ls" almost instantly returns and shows the directory. This affects both NFS and local automounts for me but also remote filesystems mounted via kio (and the latter seem to contribute a lot more to the stalls). Once NFS automounts are mounted, the system does no longer stall konsole, kio is eventually cached by then but the dolphin window icon context menu is still affected and blocks plasma while stalled. On a second system which is configured almost identically, the same behavior cannot be observed or it is much less pronounced. -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 469283] New: cannot copy files to smb when accessing a DFS share
https://bugs.kde.org/show_bug.cgi?id=469283 Bug ID: 469283 Summary: cannot copy files to smb when accessing a DFS share Classification: Frameworks and Libraries Product: kio-extras Version: 23.04.0 Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Samba Assignee: plasma-b...@kde.org Reporter: k...@kaishome.de CC: sit...@kde.org Target Milestone: --- SUMMARY When accessing a Windows DFS share through kio, dolphin complains about not enough space in the destination copying data to the share. Running "df" on the kio mount confirms that there are 0 bytes reported free, and the reported file system size is also 0 bytes. From cmdline, files can still be created or copied. Accessing the same share directly from the DFS member reports correct sizes and allows dolphin to copy files to the share. Mounting DFS directly via CIFS kernel support reports the correct values. SMB shares: \\domain.local\DFS\Storage -> 0 bytes free and 0 bytes size \\member1.domain.local\Storage -> sizes reported correctly \\member2.domain.local\Storage -> also reported correctly STEPS TO REPRODUCE 1. Setup a DFS share with two member servers and DFSR sync 2. Access share via DFS share via kio to check for free space 3. Access share directly on member server via kio to check for free space OBSERVED RESULT kio-smb reports 0 bytes free and 0 bytes file system size, preventing kio clients from writing data due to out of space condition (actually, it may complain about insufficient permissions sometimes but that's not true, it's still "out of space"). EXPECTED RESULT kio-smb should report file system stats correctly for DFS shares. SOFTWARE/OS VERSIONS Operating System: Gentoo Linux 2.13 KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.9 Kernel Version: 6.1.26-gentoo (64-bit) Graphics Platform: X11 Processors: 20 × 12th Gen Intel® Core™ i7-12700K Memory: 31.1 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 3080 Ti/PCIe/SSE2 Manufacturer: ASRock Product Name: Z690 Pro RS -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 469283] cannot copy files to smb when accessing a DFS share
https://bugs.kde.org/show_bug.cgi?id=469283 --- Comment #2 from Kai Krakow --- (In reply to Harald Sitter from comment #1) > Please provide reproducible steps for 1. Setup a DFS share with two member > servers and DFSR sync On two Windows Server hosts, install DFS replication services. Install DFS namespace services on at least one host and setup a DFS namespace using the first two hosts as target servers. Then create a replication group between those two members to keep the shares in sync. I'm not sure if DFS replication is actually necessary to show the 0-space-bug, it may be sufficient to use a single DFS target without replication, and just point kio-smb to access the share through the DFS namespace, although using DFS with a single target share is not really that useful. -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 469283] cannot copy files to smb when accessing a DFS share
https://bugs.kde.org/show_bug.cgi?id=469283 Kai Krakow changed: What|Removed |Added Status|NEEDSINFO |REPORTED Resolution|WAITINGFORINFO |--- --- Comment #4 from Kai Krakow --- (In reply to Harald Sitter from comment #3) > Not exactly the level of detail I wanted but it'll do :) > > And you are quite certain this is with kio-extras 23.04? This is a good point... There are two systems, one is more "bleeding edge" and uses the DFS share via VPN link, so I should retest it with 23.04 (because it was recently updated and I didn't retest there since then): # equery b /usr/lib64/qt5/plugins/kf5/kio/smb.so * Searching for /usr/lib64/qt5/plugins/kf5/kio/smb.so ... kde-apps/kio-extras-23.04.0 (/usr/lib64/qt5/plugins/kf5/kio/smb.so) The other system (directly connected to the server LAN segment) has: # equery b /usr/lib64/qt5/plugins/kf5/kio/smb.so * Searching for /usr/lib64/qt5/plugins/kf5/kio/smb.so ... kde-apps/kio-extras-22.12.3 (/usr/lib64/qt5/plugins/kf5/kio/smb.so) That system shows this problem as recently as a few days ago. Do you mean to say that this may have been fixed in 23.04? -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 469283] cannot copy files to smb if accessing as a DFS share
https://bugs.kde.org/show_bug.cgi?id=469283 Kai Krakow changed: What|Removed |Added Summary|cannot copy files to smb|cannot copy files to smb if |when accessing a DFS share |accessing as a DFS share -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 469283] cannot copy files to smb if accessing as a DFS share
https://bugs.kde.org/show_bug.cgi?id=469283 --- Comment #6 from Kai Krakow --- OTOH, this may also be fixed in Dolphin rather than kio (if there's no way around that behavior): If Dolphin detects 0 bytes free and 0 bytes size at the same time, it should infer that there's no information about free space and just try writing the file. I'm pretty sure it's not kio preventing the write due to this condition (because when launching the terminal from Dolphin, it will put me into a kio mounted directory and I can create files there just fine). -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 469283] cannot copy files to smb if accessing as a DFS share
https://bugs.kde.org/show_bug.cgi?id=469283 --- Comment #7 from Kai Krakow --- (In reply to Harald Sitter from comment #5) > > Do you mean to say that this may have been fixed in 23.04? > > Yes > https://invent.kde.org/network/kio-extras/-/commit/ > 46d3f2fd41dece1d49e7295ae986d8e3960e78fb Oh wow... Thanks, I'll try. I add this to the patch queue of emerge and reinstall the package. I'm guessing it will apply to 22.12.3 without conflicts. I'll close this if it works for me. -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 469283] cannot copy files to smb if accessing as a DFS share
https://bugs.kde.org/show_bug.cgi?id=469283 Kai Krakow changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |DUPLICATE --- Comment #8 from Kai Krakow --- Thanks, it is fixed by your commit. Sorry for not taking more attention to my other system which recently updated to 23.04 - I wasn't really aware of that fact when I wrote the bug report. *** This bug has been marked as a duplicate of bug 431050 *** -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 431050] SMB error: "There is not enough space on the disk to write smb://..."
https://bugs.kde.org/show_bug.cgi?id=431050 Kai Krakow changed: What|Removed |Added CC||k...@kaishome.de --- Comment #24 from Kai Krakow --- *** Bug 469283 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 469279] Running akonadi servers easily doubles or triples VRAM usage
https://bugs.kde.org/show_bug.cgi?id=469279 --- Comment #3 from Kai Krakow --- Thanks for investigating. I think this example shows that KDE/Plasma should treat VRAM as a valuable resource, and it affects a lot of other KDE background processes, too. So maybe creating some infrastructure to have one single process display dialogues for background processes may be the way forward. But I understand that this is a big change. As a less intrusive interims solution, Akonadi agent and resource processes could be forced to use Qt software rendering only. It probably won't hurt too much because most of these processes only open simple dialogues, and usually probably only in the event of errors or warnings, not as part of working normally. I found that forcing Qt software rendering for the full desktop to eliminate VRAM ballooning but, as already mentioned, I'm not sure how badly it will affect desktop performance, especially if desktops apps need to render in parallel to a game. Also, it somehow prevents window previews on the taskbar to work so it has a visible impact on user experience. But it may be acceptable for Akonadi dialogues for the time until this is fixed. I found no way to force software rendering only for processes launched by Akonadi, it should be as easy as injecting an environment variable into the launcher but I don't know how or where to do that. There's `/usr/share/dbus-1/services/org.freedesktop.Akonadi.Control.service` but I'm not sure if this is the right place for trying to inject environment variables, or if that is the launcher of the main process at all... -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfig] [Bug 187172] truncated configuration files on power loss or hard crash
https://bugs.kde.org/show_bug.cgi?id=187172 --- Comment #47 from Kai Krakow --- (In reply to Martin Steigerwald from comment #46) > Nowadays where Ext3 should not be in wide use anymore, if at all, and > nowadays where many people use flash based storage, I am strongly for just > making sure to sync where needed. > > That written, I did not see any truncated config file since ages. I still > have "KDE_EXTRA_FSYNC=1" set, but whether this actually really makes a > difference, given some of the comments above, I do not know. Anyway, I'd > just sync by default. It really can't be a performance issue anymore – > except maybe on embedded device with some slow SD card –, especially as > unchanged files are not rewritten anymore. If I remember correctly, you may be using btrfs. On btrfs, this is actually not needed, it works fine without fsync and is actually faster that way no matter the storage technology. I'm running with `KDE_EXTRA_FSYNC=0` since years on btrfs and never had a problem. I suggest that the behavior is kept to optionally disable fsync/fdatasync, but it should befault to "on". The problem is with file systems which do not commit metadata and data properly in a single transaction or in expected order, e.g. xfs does this and writes data lazily or delayed. In that case, xfs ensures that you do not see stale or old data after a crash by zeroing or truncating the affected files. I think ext3/ext4 does something similar unless you use its full journal mode (which is a lot slower, ofc), where xfs probably behaves like ext4 with "journal=writeback". Especially with btrfs, the argument is not whether it's on flash or spinning disks: fsync/fdatasync can significantly slow the system down because btrfs may have a rather long list of outstanding transactions it would have to write then (blocking) until reaching the transaction affected by the sync. This can take a long time and blocks the system even on flash disks. So if this discussion is about whether we should remove `KDE_EXTRA_FSYNC`, I'd rather not have it force-enabled, especially because KDE seems to be very busy with its config files and reads and writes them a lot (similar to the cache directory). IMHO, the variable could be changed to require `KDE_DISABLE_EXTRA_FSYNC=this_is_dangerous_and_I_know_what_I_am_doing`. This may make it more obvious to people who blindly follow some internet guides to "make things faster" that they may be doing something harmful. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 484323] High CPU load of kwin_x11 when locking or turning off the screen
https://bugs.kde.org/show_bug.cgi?id=484323 Kai Krakow changed: What|Removed |Added CC||k...@kaishome.de --- Comment #36 from Kai Krakow --- I can confirm this for 6.1.1. I'm using 4 monitors, one of them is sometimes turned off. Perf data looks like this: # Overhead Command Shared ObjectSymbol # ... ... ... # 24.22% kwin_x11 [vdso] [.] __vdso_clock_gettime 15.66% kwin_x11 libc.so.6[.] __sched_yield 10.43% kwin_x11 [unknown][k] 0x81c00150 1.71% kwin_x11 libc.so.6[.] clock_gettime@@GLIBC_2.17 1.46% kwin_x11 libnvidia-glcore.so.555.58 [.] 0x00b00d13 1.24% kwin_x11 libnvidia-glcore.so.555.58 [.] 0x00b00d00 1.02% kwin_x11 libnvidia-glcore.so.555.58 [.] 0x009eea66 0.78% kwin_x11 libnvidia-glcore.so.555.58 [.] 0x009eea61 0.72% kwin_x11 libnvidia-glcore.so.555.58 [.] 0x00a03904 0.71% kwin_x11 libnvidia-glcore.so.555.58 [.] 0x00b00d30 0.68% kwin_x11 libnvidia-glcore.so.555.58 [.] 0x009eea59 It looks like most of the time is spent in a tight loop getting the clock and yielding. Most of the time is spent outside of kwin_x11 but filtering by dso shows where it is involved: # dso: kwin_x11 # # Total Lost Samples: 0 # # Samples: 5K of event 'cpu_atom/cycles/Pu' # Event count (approx.): 2421254389 # # Overhead Command Symbol # ... ... # 0.12% kwin_x11 [.] KWin::BlendChanges::isActive 0.07% kwin_x11 [.] QtPrivate::QCallableObject, void>::impl 0.04% kwin_x11 [.] KWin::OutputFrame::presented@plt 0.03% vsync event mon [.] std::chrono::_V2::steady_clock::now@plt 0.03% kwin_x11 [.] KWin::ApplicationX11::metaObject 0.03% kwin_x11 [.] KWin::ContrastEffect::shouldContrast 0.03% kwin_x11 [.] KWin::ContrastEffect::doContrast 0.02% kwin_x11 [.] KWin::ZoomEffect::slotWindowDamaged 0.02% kwin_x11 [.] KWin::GlxLayer::doBeginFrame 0.02% kwin_x11 [.] KWin::PaintData::yTranslation@plt 0.02% kwin_x11 [.] KWin::BlurEffect::blurRegion 0.02% kwin_x11 [.] KWin::EffectsHandler::prePaintScreen@plt 0.02% kwin_x11 [.] KWin::ContrastEffect::isActive 0.02% kwin_x11 [.] KWin::EffectWindow::isDesktop@plt 0.02% kwin_x11 [.] KWin::ContrastEffect::drawWindow 0.02% kwin_x11 [.] KWin::GlxBackend::primaryLayer 0.02% kwin_x11 [.] KWin::SlideEffect::isActive 0.02% kwin_x11 [.] QRegion::end@plt 0.02% vsync event mon [.] KWin::SGIVideoSyncVsyncMonitorHelper::poll 0.02% kwin_x11 [.] KWin::OutputLocatorEffect::isActive 0.01% vsync event mon [.] operator delete@plt 0.01% kwin_x11 [.] KWin::GlxBackend::makeCurrent 0.01% vsync event mon [.] QMetaObject::activate@plt 0.00% vsync event mon [.] QtPrivate::QCallableObject, void>::impl # Samples: 1M of event 'cpu_core/cycles/Pu' # Event count (approx.): 737751025988 # # Overhead Command Symbol # ... . . # 0.01% kwin_x11 [.] KWin::BlurEffect::blurRegion 0.00% kwin_x11 [.] KWin::GlxBackend::present 0.00% kwin_x11 [.] KWin::BlurEffect::prePaintWindow 0.00% kwin_x11 [.] QRegion::~QRegion@plt 0.00% kwin_x11 [.] KWin::BlurEffect::blur 0.00% kwin_x11 [.] KWin::GlxBackend::present 0.00% kwin_x11 [.] KWin::GlxBackend::doBeginFrame 0.00% kwin_x11 [.] KWin::GlxContext::makeCurrent 0.00% vsync event mon [.] KWin::SGIVideoSyncVsyncMonitorHelper::poll 0.00% vsync event mon [.] std::chrono::_V2::steady_clock::now@plt 0
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) writing a *ton* of data while re-indexing unchanged files
https://bugs.kde.org/show_bug.cgi?id=404057 --- Comment #44 from Kai Krakow --- (In reply to tagwerk19 from comment #43) > I think the dust has probably settled here after: > https://invent.kde.org/frameworks/baloo/-/merge_requests/131 > and cherrypicked for KF5 > https://invent.kde.org/frameworks/baloo/-/merge_requests/169 These work fine for me, I'm actually using baloo again in production. > There's also been > https://invent.kde.org/frameworks/baloo/-/merge_requests/121 Actually, `MemoryHigh=512M` is quite aggressive. It can lead to swap storms and cache thrashing of baloo under memory pressure because the process itself is already 512M big, this leaves no space for caching which is important for baloo to work with proper performance (consider that memory cgroups also account cache usage). Especially the sub process baloo_file is hurt by this a lot while indexing new files. I personally used `MemoryHigh=2G` to fix this for my system - but this parameter really depends a lot on the system environment. The service shows a peak usage of 1.3G with almost no swap usage (less than 30M), so `MemoryHigh=1536M` may be fine. > and > https://invent.kde.org/frameworks/baloo/-/merge_requests/148 No objections, it makes sense. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) writing a *ton* of data while re-indexing unchanged files
https://bugs.kde.org/show_bug.cgi?id=404057 --- Comment #46 from Kai Krakow --- (In reply to tagwerk19 from comment #45) > Yes, there's been a handful of bug reports where I've "blamed" the 512M > limit. > > I tentatively recommend "MemoryHigh=25%". I don't suppose many people run on > systems with 2G RAM (even as VM's) and having a percentage means Baloo gets > a lot more room to breath on systems with 8G. > > I think "MemoryHigh=40%" is still quite reasonable and I would also include > a "MemorySwapMax=0" to forestall swapping (which does seem to cause problems) MemorySwapMax can lead to OOM situations, even for other processes, if the only swap victim would be baloo. It is fine to swap out some dead pages which the process never uses. And we should be careful with percentages: `MemoryHigh` sets a priority at which the kernel memory manager chooses processes to reduce memory usage (by discard caches, flushing writeback, or swapping anonymous memory). We actually want this to happen, we should be careful to not make baloo the last resort by accidentally giving it the highest memory priority. If we want to limit it, `MemoryMax` should be set (then baloo will never get more memory). But `MemoryHigh` should be set to a reasonable minimum we want to protect for the process so it can make forward progress. Setting it too high creates an inverse effect for other important processes of the desktop. It the lower bound of what is considered high memory usage before making memory available to other processes. Memory is taken away from processes with the highest `MemoryHigh` last. As an idea, baloo could watch `/proc/pressure/memory` and if latencies go high, it could pause for a while and flush its own caches. One cannot try to emulate such a behavior with `MemoryHigh`. Maybe the memory limits should be removed completely, and rather let the kernel do the job using mgLRU (which could be recommended for distributions if it works fine), and then let baloo watch memory pressure instead to throttle itself. The problem is not with baloo reading files and using CPU, it's already highly optimized here. The problem is with how the database uses memmap, so it's directly competing with important desktop processes needing resident memory (it's not designed to compete with other processes for memory). Using memory pressure, we could mark selected memory ranges as "not needed" and flush unwritten data early so it becomes available. I had no more problems with baloo until it added the `MemoryHigh=512M` parameter, so I added another one to force 2G instead. Which makes me wonder if we need that parameter at all. Just my 2 cents, no need to re-open. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489556] New: When screen timer is allowed to run out and auto lock, brightness is turned down
https://bugs.kde.org/show_bug.cgi?id=489556 Bug ID: 489556 Summary: When screen timer is allowed to run out and auto lock, brightness is turned down Classification: Plasma Product: kwin Version: 6.1.1 Platform: Other OS: Other Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: kaiwin...@gmail.com Target Milestone: --- SUMMARY Allow Plasma to auto-timeout so the screen becomes locked, the brightness gets turned down and once you log in, there is no way to turn the brightness back up. You have to reboot for the controls to become available again STEPS TO REPRODUCE 1. Plasma 6.1.1, allow timeout so it locks the screen 2. Once the locked screen is shown, login 3. Go to settings > Power Management 4. No way of adjusting the screen brightness as Power Management is blank EXPECTED RESULT Ability to change screen brightness as before 6.x update ADDITIONAL INFORMATION Operating System: Alpine Linux 3.21.0_alpha20240606 KDE Plasma Version: 6.1.1 KDE Frameworks Version: 6.3.0 Qt Version: 6.6.3 Kernel Version: 6.6.36-0-lts (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-7700 CPU @ 3.60GHz Memory: 15.3 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 630 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) writing a *ton* of data while re-indexing unchanged files
https://bugs.kde.org/show_bug.cgi?id=404057 --- Comment #49 from Kai Krakow --- (In reply to tagwerk19 from comment #47) > That said, I've not noticed the percentages behaving differently than a > defined amount of memory (so, I think a "MemoryHigh=25%" on a 2GB system > acts the same as a "MemoryHigh=512M"). It would be interesting if this was > not the case... No, it should not be different. In the end, it boils down to fixed numbers as can be seen in `systemctl --user status kde-baloo.service`: # Memory: 136.4M (high: 2.0G available: 1.8G peak: 1.3G swap: 18.4M swap peak: 18.5M zswap: 6.9M) (where "high" is calculated from percentage to this number) > I'm pretty sure the "MemoryHigh" is a soft limit, I was able to push the > usage to just a little above the given limit but the process slowed down > (markedly, when I pushed hard), I think when trying to claim more memory. MemoryHigh is not a limit. MemoryHigh is an indicator/hint for the kernel beyond which value the process group is considered to use a high amount of memory. Now, if the kernel needs memory, it will reclaim memory from process groups first that are most above their "MemoryHigh" value. Thus, if you make this very high, the kernel will decide to reclaim memory from baloo last because it is potentially the only service with a very high "MemoryHigh" value. The service is allowed to go beyond that memory usage just fine as long as the kernel has no need for other memory. This is also a problem in itself if mixing non-memory constrained services with ones that have this setting. The system becomes very unbalanced unless you adjust it for your very own needs. Leaving `MemoryHigh` empty instructs cgroups to balance memory usage in a fair way. > I > tried the same with MemoryMax but this seemed to be a hard limit. Yes, it is a hard limit. Allocations beyond `MemoryMax` will force the process group to swap out inactive memory of itself. > I tried > setting a MemoryHigh with a slightly higher MemoryMax but it didn't seem to > bring any benefits, the MemoryHigh on its own seemed to be quite effective > at limiting Baloo's memory use. Cannot work. `MemoryHigh` is not a limit, it's a hint for the memory management when to consider a service to use "too much" memory, so services beyond that allocation will be considered for reclaim first. Or viewed from the other side: `MemoryHigh` is a type of resident memory protection which the kernel _tries_ to guarantee to the service (`MemoryMin` will force the guarantee). > I'm also pretty sure that even with a defined MemoryHigh, Baloo releases > memory when other processes require it. Yes, because it's a "soft guarantee", not a "soft limit". If the kernel has no more other processes to reclaim memory from, it will start reclaiming memory from `MemoryHigh` services below their setting, in order of priority that makes sense in that context. Baloo itself surely will free memory, too, by itself, and that's reflected here. Those memory allocations also include cache which baloo cannot directly control. The kernel tracks page cache ownership per cgroup, and accounts that to memory usage, too. I'm pretty sure `MemoryHigh` has been set so low (512M) because someone considered it a soft limit, but it's a soft guarantee. And setting it too low will hint the kernel to reclaim memory from such processes first - and that's usually cache before swapping memory out (depends on vm.swappiness). Thus, `MemoryHigh` should be set to a proper value that includes the active working set of memory pages for the process + a good value for cache to let it do it's job without stuttering the desktop. That settles around 1.5G of memory for me. But OTOH, that means, we will also protect its memory even if baloo is idle (and may be fine with using less than 1.5G RAM including caches). Thus I think, it may be a better idea to completely leave that value empty, maybe only include it as a comment with explanation so users can tune it easily with `systemctl --user edit kde-baloo.service`. > Certainly, there was dropping and rereading of clean pages when Baloo was > closing on the limit. That was visible in iotop. I noticed in "pathological > cases", indexing large quantities of data and having to manage very many > dirty pages, pushed Baloo to swap and performance very clearly suffered > (even when the rest of the system has sufficient space). I think it's > (likely) worthwhile adding the MemorySwapMax=0 for Baloo to stop it reaching > that point (although only if MemoryHigh is reasonable). The argument being > an OOM for Baloo is (likely) better than it swapping. This is a value > judgement through... `MemoryHigh` is a two-edged sword... You can stop the observed behavior by using a high valu
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) writing a *ton* of data while re-indexing unchanged files
https://bugs.kde.org/show_bug.cgi?id=404057 --- Comment #51 from Kai Krakow --- (In reply to tagwerk19 from comment #50) > (In reply to Kai Krakow from comment #49) > > Thank you for the insights. That's a lot more to think about... You're welcome. > What we had previously, of BTRFS presenting "another different" device > number on reboot and Baloo's initial scan for changes not committing at > intervals, that was a catastrophic combination. I initiated the idea to fold the uuid into the dev/inode feels somehow, I just hadn't time exploring the source code. Luckily, someone finally implemented that idea. \o/ > I think, in *general*, > nowadays Baloo does not demand so much memory. Maybe though I should check > when a lot of files have been deleted and Baloo has to catch up. How Baloo > might behave when it is squeezed for memory (rather than being the culprit), > that's something new to think about... Yeah exactly. I think one remaining issue is when system performance suffers not because baloo uses too much memory but because it becomes squeezed into too little memory. Thanks for testing it. I'm currently running fine with `MemoryLow=512M` and no high limit, seems to work great so far even with games running and while streaming, using btrfs on bcache with hdds. With that configuration, more baloo memory has been pushed into swap - but it was never reclaimed so its probably inactive memory anyways and should be in swap. I'd recommend to look into the "below" tool (an alternative implementation to "atop"), it tracks memory usage via cgroups and thus can tell you also the accounted cache memory of a process group where "htop" or "top" only show resident process memory without caches accounted. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 457894] DKIM plugin treats ed25119 signed messages as invalid
https://bugs.kde.org/show_bug.cgi?id=457894 Kai Bojens changed: What|Removed |Added CC||k...@kbojens.de -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 453554] New: turning one monitor off kills the panel configuration of the second monitor
https://bugs.kde.org/show_bug.cgi?id=453554 Bug ID: 453554 Summary: turning one monitor off kills the panel configuration of the second monitor Product: plasmashell Version: 5.24.5 Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Multi-screen support Assignee: plasma-b...@kde.org Reporter: k...@kaishome.de CC: aleix...@kde.org, notm...@gmail.com Target Milestone: 1.0 SUMMARY Monitor setup (xrandr dump at the end): Left main monitor: 4k displayport * top plasma panel with activity switcher, global menu, date and time, systray * bottom plasma panel with launch menu, icon window list, desktop switcher Right small monitor: full HD HDMI connected via DP * top plasma panel with window list, time, bluetooth applet, volume applet TV: 4k, HDMI * clone of left monitor (for couch gaming) Graphics: NVIDIA GTX 1660 Ti 6GB with Xorg Whenever I turn off my main monitor, all its panels move over to the right monitor. The same happens if the TV turns off or goes to sleep. Sometimes (probably before 5.24.5), I can see two overlapping panels at the top (my main top panel plus the simple side monitor panel) but since 5.24.5 the panel moves consistently, replacing the configuration of the right monitor. This was fine most of the time before 5.24.5 and consistently fine before 5.24.4: The panels were restored when I turned the main monitor back on, only messing up if plasma crashed or shut down before turning the monitor back on. But now it consistently throws away the plasma configuration of the right monitor: After turning the main monitor back on, I'm left with an empty default desktop on the right monitor, no custom background image, no panels, but all open windows moved to this monitor. Looking at the output of `qdbus org.kde.plasmashell /PlasmaShell org.kde.PlasmaShell.dumpCurrentLayoutJS` I can see that each incident adds another panel configuration in `layout.panels` but I have no way of getting it back. `plasmashellrc` has these lines: ``` [ScreenConnectors] 0=DP-4 1=HDMI-0 2=DP-1 ``` It also had `2=:0.0` followed by `3=DP-1` but I removed that out of desperation. It wasn't present in older backups of my system. It didn't change anything about the behavior, tho. STEPS TO REPRODUCE 1. Use a setup like I described above 2. Turn the displayport monitor off which seems to disconnect it from the system (my DP monitor and HDMI TV do that when turning them off, my HDMI monitor doesn't do it and seemingly stays connected/detected) 3. Observe the panels move over to the second screen 4. Turn first monitor back on OBSERVED RESULT After step 4, the panels move back to the monitor just turned back on but step 2/3 seem to have displaced the panel/desktop configuration of the second monitor, and after step 4, plasma will replace it with an empty default configuration. EXPECTED RESULT The panels should be properly restored to their respective original monitors. I guess it's fine and wanted that disconnecting the primary monitor would move panels over to remaining monitors, e.g. for laptop usage. But when I restore the original monitor connection for which I configured the panels, that configuration should be restored, or at least I should have an easy way to choose which panel configuration I want to restore. But in my case, it's gone for good although it still seems to live in the qdbus layout dump (and it's piling up there because I need to recreate the layout multiple times per day). I think Plasma should store and apply layouts like this: Store a layout of each monitor, also store a flag if this was made on the primary monitor. If the current monitor is the primary monitor, use the panel layout of the original primary monitor. Otherwise fall back to the layout originally defined for this monitor. Do not remove but swap layouts when the primary layout flag is involved. Move the primary layout flag only when the layout is actively edited. SOFTWARE/OS VERSIONS Operating System: Gentoo Linux KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.93.0 Qt Version: 5.15.3 Kernel Version: 5.15.37-gentoo (64-bit) Graphics Platform: X11 Processors: 20 × 12th Gen Intel® Core™ i7-12700K Memory: 31.1 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 1660 Ti/PCIe/SSE2 ADDITIONAL INFORMATION This behavior was triggered very rarely before 5.24.4, easily triggered with 5.24.4, and consistently triggers with 5.24.5. Given that history of behavior, it's probably some race condition and is not intentional. My clone monitor layout may play a role in this because I found in older versions some months back, that sometimes plasma panels would be defined for my TV instead of my main monitor (when I disabled the TV, all panels were gone). I had situations when the panels actually moved to a "third" monitor right of my seco
[plasmashell] [Bug 453554] turning one monitor off kills the panel configuration of the second monitor
https://bugs.kde.org/show_bug.cgi?id=453554 --- Comment #3 from Kai Krakow --- (In reply to Marco Martin from comment #1) > are all outputs connected to the internal videocard or there are external DP > dongles involved? No dongles but there is one DP-to-HDMI cable. Not sure if that counts as a dongle. The iGPU card is not active, I'm only using the PCI-e card. > in plasmashell itself it doesn't seem that anything have happened between > 5.23 and 5.25, wonder in what part the breaking change was. This morning when I turned the monitors back on, all was fine. So it may be some timing issue or something is racing. Or it just created "enough" panels in the qbus javascript dump that it no longer creates new configurations but just chooses from the existing ones. I'll observe it for some time and report back. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 453554] turning one monitor off kills the panel configuration of the second monitor
https://bugs.kde.org/show_bug.cgi?id=453554 --- Comment #4 from Kai Krakow --- Also, Plasma version is probably not the only thing that changed. The nvidia driver was also updated at least once, and Xorg components were also updated at least once. But I cannot really pin-point that to one of those changes, Plasma version seems to be the strongest indicator. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 453554] turning one monitor off kills the panel configuration of the second monitor
https://bugs.kde.org/show_bug.cgi?id=453554 --- Comment #5 from Kai Krakow --- It worked for a few days in a row. But yesterday evening and today morning, this happened again and the behavior is quite random: This time, only the top panel moved to the wrong screen while the bottom panel stood in place. Or maybe it's rather the other way around: Turning my main monitor off probably moves the panels to the other monitor, and when turning it back on, the panels do not properly move back. The interesting part this time is that the bottom panel behaved properly while the top panel behaved wrong. Latest 5.24 doesn't fix anything. Let's see if 5.25 solves something. -- You are receiving this mail because: You are watching all bug changes.
[Elisa] [Bug 436780] Elisa crashes after opening a directory from Files menu.
https://bugs.kde.org/show_bug.cgi?id=436780 --- Comment #2 from Kai Bojens --- Created attachment 148148 --> https://bugs.kde.org/attachment.cgi?id=148148&action=edit New crash information added by DrKonqi elisa (21.12.2) using Qt 5.15.2 - What I was doing when the application crashed: I opened the "Files" menue and changed into my DropBox Folder. After scrolling some lines down elisa crashes. -- Backtrace (Reduced): #4 0x7fce56049c79 in QHash::isEmpty() const (this=, this=) at /usr/include/qt5/QtCore/qhash.h:285 #5 QHash::empty() const (this=, this=) at /usr/include/qt5/QtCore/qhash.h:544 #6 QQmlIncubatorPrivate::incubate(QQmlInstantiationInterrupt&) (this=0x7fce38010fc0, i=) at qml/qqmlincubator.cpp:333 #7 0x7fce5604a362 in QQmlIncubationController::incubateFor(int) (msecs=, this=0x7fcde8070310) at qml/qqmlincubator.cpp:409 #8 QQmlIncubationController::incubateFor(int) (this=this@entry=0x7fcde8070310, msecs=) at qml/qqmlincubator.cpp:401 -- You are receiving this mail because: You are watching all bug changes.
[Elisa] [Bug 436780] Elisa crashes after opening a directory from Files menu.
https://bugs.kde.org/show_bug.cgi?id=436780 Kai Bojens changed: What|Removed |Added CC||k...@kbojens.de -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 453554] turning one monitor off kills the panel configuration of the second monitor
https://bugs.kde.org/show_bug.cgi?id=453554 Kai Krakow changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- Ever confirmed|0 |1 --- Comment #8 from Kai Krakow --- (In reply to Nate Graham from comment #7) > Cool, thanks! Can you file a new bug report for the new issue? > > Out of curiosity, does the wallpaper show up after 10 seconds or so? Re-opened, because unfortunately, the bug is still there: With the new panel management tool (available from the edit mode), I can now clearly see how panels move to the wrong screen. This usually happens when connected monitors swap positions: The last few days, I'm pretty sure I had the following order in the "Drag panels and desktops around" dialog: DP-4, DP-1, HDMI-0 (deactivated). Today, when I turned my monitors on, the order changed to "DP-4, HDMI-0 (deactivated), DP-1", and the panels have moved to the deactivated screen (but not the background image, that moved to a different screen a few days before already). Please take note that the background image shows the same bug but moves independently of the panels, so there are probably race conditions. I've set different wallpapers to track this: Both the wallpapers and the panels move to different screens, and they do NOT move the same way: Sometimes only the wallpaper moves to a different screen, sometimes only one panel of a screen moves, sometimes two panels of the same screen move. At least the panel management tools allows me to simply move panels and wallpapers back to their correct screen. The system hasn't been rebooted. All I do is turning off the monitors, and one monitor completely disconnects from the graphics card when turned off. So to reproduce it, in the worst case you'll have to physically disconnect the monitor because many monitors keep their connector online when turned off - but one of my monitors doesn't. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 453554] turning one monitor off kills the panel configuration of the second monitor
https://bugs.kde.org/show_bug.cgi?id=453554 --- Comment #9 from Kai Krakow --- Created attachment 150180 --> https://bugs.kde.org/attachment.cgi?id=150180&action=edit configuration completely doesn't match the output Here's an example of messed up content: As you can see, the panels overlap on the right screen although two of them are supposed to be on the left screen. Also, the left screen shows the background image of the deactivated screen. Dragging the panels back and forth in the editor fixes the panel placement. But dragging the background image will simply leave a black background that is not clickable or interactable anymore until I restart the plasmashell service. So, no - it's not fixed. I'd even say it shows the exact same behavior in 5.25 as it did in 5.24. Configuration and outputs do not match, panels are in very different locations than what Plasma thinks they should be. Rarely, I see how all panels disappear when I turn a monitor back on, and then re-appear around 5-10s later if that is what you were asking for. This seems to have the effect that plasma doesn't become confused about the monitor layout. I've last seen that in 5.24 but not yet in 5.25. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 453554] turning one monitor off kills the panel configuration of the second monitor
https://bugs.kde.org/show_bug.cgi?id=453554 Kai Krakow changed: What|Removed |Added Version Fixed In|5.25| -- You are receiving this mail because: You are watching all bug changes.
[clazy] [Bug 442769] New: qt6-qlatin1stringchar-to-u creates invalid code
https://bugs.kde.org/show_bug.cgi?id=442769
Bug ID: 442769
Summary: qt6-qlatin1stringchar-to-u creates invalid code
Product: clazy
Version: unspecified
Platform: Other
OS: Other
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: unassigned-b...@kde.org
Reporter: kai.koe...@qt.io
CC: smart...@kde.org
Target Milestone: ---
qt6-qlatin1stringchar-to-u creates code that doesn't compile
STEPS TO REPRODUCE
1. run clazy fix for e.g. QLatin1String("hello world");
OBSERVED RESULT
clazy will fix it to u"hello world", which cannot be assigned to QString
EXPECTED RESULT
clazy should fix it to u"hello world"_qs
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 356727] Panel sometimes disappears on hotplug/re-plug/sleep/wake
https://bugs.kde.org/show_bug.cgi?id=356727 --- Comment #76 from Kai Krakow --- (In reply to Nate Graham from comment #75) > As a result it would > probably be best if people who are still affected could file new bug > reports, and I will try my best to triage them accordingly. Thanks! I still have this open bug report which is similar but panels move to different screens (even disabled screens sometimes): https://bugs.kde.org/show_bug.cgi?id=453554 But the initial title doesn't exactly reflect the behavior under 5.25 because I can now recover the panels from the panel editor. Should I set a new title and set the new version number? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 441077] Plasmashell panels may freeze, usually unrelated but unresponsive NFS/SMB mounts are involved
https://bugs.kde.org/show_bug.cgi?id=441077 --- Comment #4 from Kai Krakow --- (In reply to Nate Graham from comment #2) > In general, this is why KIO exists: to provide asynchronous, non-blocking > access to flaky network resources. When you bypass KIO and mount them > directly, you're undoing that protection. > > What kinds of things have you manually mounted and why? The mount in question is a samba share mounted over VPN when I work remotely at home. The problem with KIO is that it is not transparently available to all software, i.e. when opening a document with LibreOffice, it will be copied to a temporary directory, then copied back on save/quit. This removes the ability of LibreOffice to lock the file and detect concurrent changes of the source file. And it also breaks relation between the original file path and the path opened in the application: This is not what I expect to be transparency. Also, non-KDE programs cannot even parse the paths: Sometimes, KIO paths become directly passed to the program instead of copying the file to a local path first. CLI utilities cannot even be used to navigate KIO mounts. KIO should probably become a fuse module - which would then probably just introduce this exact reported behavior which KIO tries to avoid. KIO is nice if you exclusively only use KDE software - but that's quite unrealistic in practice. Also, it falls apart once you drop to the CLI level, which is what a lot of my workflow consists of. I'm actually using KIO for things like managing files over sftp remotely via Dolphin - and it works great then. But its field of use is very limited to me. Maybe comment #3 solves it for me. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 441077] Plasmashell panels may freeze, usually unrelated but unresponsive NFS/SMB mounts are involved
https://bugs.kde.org/show_bug.cgi?id=441077 --- Comment #7 from Kai Krakow --- (In reply to Nate Graham from comment #5) > That's what kio-fuse was meant to solve. Do you have it installed? Ah ok, didn't know how it worked - and it was eventually kicked from the system previously by some conflict. I now reinstalled it and reloaded my systemd daemon. Observation: Opening files for non-KIO aware programs spawns a fuse mount. Looks like it doesn't do that for KIO-aware programs (at least I see no additional folders created in the mount directory). Let's see how I can use that for me. But I will still depend on NFS mounts from the local network, e.g. by backup repository will be mounted via an automounter (daily full system backup with borg). Usually, the NAS is available 24x7 but sometimes it will restart for updates - and that's when the plasmashell rarely but eventually blocks. Why does it look for network mounts that actually have no business with my user account, or does it? Any way to debug this when it happens? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 441077] Plasmashell panels may freeze, usually unrelated but unresponsive NFS/SMB mounts are involved
https://bugs.kde.org/show_bug.cgi?id=441077 --- Comment #9 from Kai Krakow --- I'm not sure how that could even work. (a) it runs from a different session context, it's running from systemd system service while kio-fuse is a user session dbus service (b) this would imply that I could use `ls nfs://serverip/` which I obviously cannot (I tried, spoiler: doesn't work) Maybe that could be solved if I knew how KDE/KIO decides whether to use KIO and when to fall back to KIO fuse. How does this heuristic work? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 441077] Plasmashell panels may freeze, usually unrelated but unresponsive NFS/SMB mounts are involved
https://bugs.kde.org/show_bug.cgi?id=441077 --- Comment #10 from Kai Krakow --- OTOH, I could try migrating to a borg client/server model instead of opening the repository via filesystem directly. This also decouples some security concerns as the borg service limits access patterns to those needed for repository access. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421131] Wayland: cursor lags under heavy CPU load
https://bugs.kde.org/show_bug.cgi?id=421131 --- Comment #14 from Kai Krakow --- I'd say that "loss of input events" should be actionable... (reported in comment #11) I don't care if mouse lags behind a little bit or jumps during CPU spikes, this also happens using X11. But it also loses input events (some keypresses are just discarded), and this particular problem seems very sensitive to even slight load spikes, and it was really distracting as texts I type had a lot of missing letters as if I couldn't type properly. I'm not sure if this has been fixed meanwhile because I switched back to kwin_x11 for that matter (and a lot of other quirks like context menus showing as windows etc). I'll give it another shot with 5.21: Seems at least a lot of quirks had been fixed. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 441077] New: Plasmashell panels may freeze, usually unrelated but unresponsive NFS/SMB mounts are involved
https://bugs.kde.org/show_bug.cgi?id=441077 Bug ID: 441077 Summary: Plasmashell panels may freeze, usually unrelated but unresponsive NFS/SMB mounts are involved Product: plasmashell Version: 5.21.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Panel Assignee: plasma-b...@kde.org Reporter: k...@kaishome.de Target Milestone: 1.0 Created attachment 140790 --> https://bugs.kde.org/attachment.cgi?id=140790&action=edit thread apply all bt SUMMARY Plasmashell tends to hang/completely freeze when a mounted network file system temporarily does not respond. Most of the times, the panels will recover after some minutes but sometimes they don't. I've now seen a freeze which didn't recover and I had to SIGKILL plasmashell to restart it, even `--replace` did not work. I'm not sure if a mounted file system was involved this time (see Additional Information below). Take note that the network mounts are completely unrelated, there's nothing on the panel that even loads data from it. In earlier versions this was also caused by plasma widgets loading data from network while the internet connection temporarily stalled. I've since removed all widgets that load data from network (like the weather widget). But I believe this incident may be caused by the disk usage warning plugin of plasma when it tries to access disk usage data from a non-responding mount. Conclusion: Plasma should not block and maybe wrap a timeout handler around queries that may potentially stall due to external reasons. However, this incident may be different. A plasma dev may have better insights. I'll attach a short and full gdb backtrace I was able to fetch from the hanging pid. Possible bug reports covering the mount-related issue but probably not a duplicate of this: #413110, #416972, #272361 STEPS TO REPRODUCE 0. The backtrace may not be about this particular hang: 1. Use network mounts somewhere below your home directory 2. Cut the network connection to stall access to these mounts 3. Observe plasmashell freezing and recovering minutes later OBSERVED RESULT Plasma panels stop responding to clicks and freeze with whatever content they did currently render. EXPECTED RESULT Plasma should detect timeouts and recover in one or another way, as a last resort it could kill itself and restart - which helped in this particular case: I SIGKILLed it and restarted it. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Gentoo Linux (available in About System) KDE Plasma Version: 5.21.5 KDE Frameworks Version: 5.82.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION This particular freeze may be related to this dmesg entry: [686470.331086] BUG: unable to handle page fault for address: 00020ee8 [686470.331091] #PF: supervisor write access in kernel mode [686470.331092] #PF: error_code(0x0002) - not-present page [686470.331093] PGD 0 P4D 0 [686470.331096] Oops: 0002 [#1] PREEMPT SMP [686470.331098] CPU: 1 PID: 1919 Comm: QSGRenderThread Not tainted 5.10.57-gentoo #1 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 441077] Plasmashell panels may freeze, usually unrelated but unresponsive NFS/SMB mounts are involved
https://bugs.kde.org/show_bug.cgi?id=441077 --- Comment #1 from Kai Krakow --- Created attachment 140791 --> https://bugs.kde.org/attachment.cgi?id=140791&action=edit thread apply all bt full -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 402154] Baloo reindexes everything after every reboot
https://bugs.kde.org/show_bug.cgi?id=402154 Kai Krakow changed: What|Removed |Added CC||k...@kaishome.de --- Comment #18 from Kai Krakow --- (In reply to tagwerk19 from comment #17) > Looks as if this is a long term issue... > Scroll down to the last posts in Bug 404057 Yep, this problem has already been deeply analyzed and is well understood. The referenced bug report includes a lot of thoughts, possible solutions, and also a few real improvements as patches - some of those were merged. There are also links to phabricator with extended discussion. I suggest to read that entirely to understand the problem (some later comments re-decide on previous thoughts). Sadly, I mostly lost interest in this issue in favor of other more important or personal stuff. I simply ditched baloo since then as I wasn't really using it anyway that much. But if anyone wants to take the effort in crafting any patches, they might want to start with implementing the mapping table from volume/subvolume UUID to a virtual device number - and that virtual device number would than be used instead of the real one. This way, a distinct file system would always show up as the same device number in baloo - no matter on which device node it appeared. It solves almost all of the problems mentioned here. I volunteer to mentor/help with such an implementation, I'm just too bad with Qt/KDE APIs to kickstart that myself. Later improvements should look at access patterns and how to optimize that, maybe LMDB can be used in a better way to optimize it for background desktop access patterns, otherwise it may need to be replaced with some other backend that's better at writing data to the database (aka, less scattering of data over time): LMDB is optimized for reads and appends, much less for random writes (but the latter is the most prominent access pattern for a desktop search index). So if we stay with LMDB, baloo needs to be optimized to prevent rewrites in favor of appends - without blowing up the DB size too much. It may mean to purge still existing data from the LMDB mmap in favor of a bigger continuous block of free DB memory. Also, aggressive write coalescing is needed to avoid fragmentation access patterns in filesystems. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 402154] Baloo reindexes everything after every reboot
https://bugs.kde.org/show_bug.cgi?id=402154 --- Comment #19 from Kai Krakow --- BTW: Such a UUID-to-deviceId mapping table would allow baloo to properly support most yet unsupported filesystems, probably also zfs. With such an idea implemented, the only requirement left to a supported filesystem would be that it has stable inodes across re-mounts/re-boots (most have, some don't) and supports reverse lookups (inode to path). The problematic design decision is how baloo identifies files: each file is assigned a devId/inodeId number (each lower 32-bit only, combined into a 64-bit fileId). If this magic number changes (that happens in zfs, btrfs, nfs...), the file appears as new. But neither Linux nor POSIX state anywhere that this can be used as an id to uniquely identify files - unless you never remount or reboot. Also, re-used inode numbers (especially after clipping at 32 bit) will completely mess up and confuse baloo. So this needs are multi-step fix: First (and most importantly) introduce virtual deviceIds by implementing a mapping table "volume/subvolId <-> virtualDeviceId" where virtualDeviceId would be a monotonically increasing number used uniquely throughout the index as a device id. Next step: Enlarge fileIds from 64 to 128 bit, so it can be crafted from 64-bit devid/inode without clipping/wraparound. On the pro side, such a mapping table would also allow to properly clean up index data from the DB for file systems no longer needed. Currently, baloo never knows if a file system would appear or doesn't. This could be implemented in one of the later steps as some sort of housekeeping optimizations. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 402154] Baloo reindexes everything after every reboot
https://bugs.kde.org/show_bug.cgi?id=402154 --- Comment #22 from Kai Krakow --- (In reply to tagwerk19 from comment #20) > (In reply to Kai Krakow from comment #18) > > ... I suggest to > > read that entirely to understand the problem ... > I've done my best :-) Thank you for the info! > > In: > > https://bugs.kde.org/show_bug.cgi?id=404057#c35 > > You have the the idea of an "Index per Filesystem" but then the idea seems I didn't... I explained why that would not work. > to have been put to the side. You mention "storage path" as a problem? Would > the way "local wastebaskets" are managed on mounted filesystems be a model? > They have to deal with the same issues as you've listed. The problem is that you would have do deal with proper synchronization when multiple databases are used. That is not just "find a writeable storage location and register this location somewhere". Also, you would need to have all these different DBs opened at the same time, and LMDB is a memory mapped database with random access patterns. So you'd multiply the memory pressure with each location, and that will dominate the filesystem cache. > https://phabricator.kde.org/T9805 This mentions "store an identifier per tracked device, e.g the filesystem UUID" which is probably my idea. Instead of using dev_id directly, the database should have a lookup table where filesystem UUIDs are stored as a simple list. The index of this list can be used as the new dev_id for the other tables. > Has a mention of "... inside encrypted containers", see this also in Bug > 390830. Encrypted containers should never be indexed in a global database as that would leak information from the encrypted container. The easiest solution would be to just not index encrypted containers unless the database itself is stored in an encrypted container - but that's also just an bandaid. Maybe encrypted containers should not be stored at all. Putting LMDB on an encrypted containers may have very bad side-effects on the performance side. > As background thoughts... > > Things like "Tags:" folders in Dolphin and incremental searches > when you type into Krunner depend on baloosearch being lightning fast. Having multiple databases per filesystem can only make this slower by definition because you'd need to query multiple databases. From my personal experience with fulltext search engines (ElasticSearch) I can only tell you that querying indexes and recombining results properly is a huge pita, and it's going to slow things way down. So the multiple database idea is probably a dead end. > It would be a shame to lose the ability to search for phrases as in > baloosearch Hello_Penguin > as opposed to > baloosearch "Hello Penguin" > > I'm guessing BTRFS usage is going to grow. The point is: Neither Linux nor POSIX state anywhere that a dev_id from stat() is unique across reboots or remounts. This is even less true for inode numbers with some remote filesystems or non-inode filesystems (where inode numbers are virtual and may be allocated from some runtime state). Those are not stable ids. At least for native Linux-filesystems we can expect inode numbers to be stable as those are stored inside the FS itself (the dev_id isn't but UUID is). On a side-note: In this context it would make sense to provide baloo as a system-wide storage and query service shared by multiple users, with an indexer running per user (to index encrypted containers). It's the only way to support these ideas: - safe access to encrypted containers - the database can be isolated from being readable by users (prevents information leakage) - solves the problem of multiple users indexing the same data multiple times - has capabilities to properly read UUIDs from filesystems/subvolumes (some FS only allow this for root) - can guard/filter which results are returned to users (by respecting FS ACLs and permission bits) - shared index location (e.g. /usr/share/docs) would be indexed just once On the contra side: - needs some sort of synchronization between multiple indexers (should work around race conditions that multiple indexers do not read and index the same files twice), could be solved by running the indexer within the system-wide service, too, but access to encrypted containers needs to be evaluated -- You are receiving this mail because: You are watching all bug changes.
