[kwin] [Bug 488060] Focus stealing prevention window rules are not enforced for the native Wayland apps
https://bugs.kde.org/show_bug.cgi?id=488060 --- Comment #7 from Pedro V --- Just mentioned the clipboard problem as focus stealing prevention is an important requirement for that to be well-working, but even though I'm also looking forward to that, as you mentioned it would be best not to hijack the topic here with that. Do note though that some users are already upset with Wayland limitations so the default might never change, but part of what makes KDE so great is the possibility of customization, so the current overly permissive approach could be kept as the default option, while business / privacy oriented setups should be able to opt into the requirement you described. User initiation alone is not a good enough requirement though, but it would be a good start. The earlier described problem of a call popping up while typing just really shouldn't happen, but the focus on launch problem satisfies the user initiation requirement while still being an annoyance. The worst case I tend to see is with Krusader as I tend to work over the network with large files using it. Not sure right now which part likes to pop up, maybe the "Synchronize Folders..." part which tends to open windows (especially in case of errors), but occasionally I run into the oddity of starting an operation (satisfying user initiation), then possibly hours later Krusader pops up either just indicating it's finished, or wanting attention for some other reason. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 485096] When default screenshot format is JPEG, screenshots copied to the clipboard cannot be pasted until Spectacle quits
https://bugs.kde.org/show_bug.cgi?id=485096 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com --- Comment #6 from Pedro V --- Possible regression? Can't reproduce with: KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.10 The format issue is really interesting, the clipboard really shouldn't be affected by whether the file is even saved or not, and it doesn't look like that the image format in the clipboard is affected by the format chosen for files. There's an interesting transformation though when Klipper takes over. Checked: - `wl-paste > testA.png` - Exit Spectacle - `wl-paste > testB.png` And while the two files look identical as pictures, the sizes and file contents are quite different. Looking with `qdbus org.kde.KWin /KWin org.kde.KWin.showDebugConsole` at the clipboard, the only obvious difference is the `x-kde-force-image-copy` mime type getting replaced with `application/x-kde-onlyReplaceEmpty`. Nothing I'm doing is breaking copying from Spectacle on the "old" system I'm using. Worst I get is Klipper sometimes not feeling like picking up new content, setting clipboard back to the previous content after Spectacle exits. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 487167] spectacle copy clipboard not compatible with whatsapp for linux, gwenview ok instead
https://bugs.kde.org/show_bug.cgi?id=487167 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com --- Comment #1 from Pedro V --- May be a duplicate of Bug 485096 , advising checking out the workarounds mentioned there. -- You are receiving this mail because: You are watching all bug changes.
[kio] [Bug 185030] Revival of kio_rar and kio_p7zip
https://bugs.kde.org/show_bug.cgi?id=185030 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 416848] Add 'paste from clipboard' to import image to view
https://bugs.kde.org/show_bug.cgi?id=416848 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 453599] Trying to connect to a wifi 6 WPA3-SAE ONLY access point, KDE attempts to use PSK to connect even though that's not possible.
https://bugs.kde.org/show_bug.cgi?id=453599 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 488060] Focus stealing prevention window rules are not enforced for the native Wayland apps
https://bugs.kde.org/show_bug.cgi?id=488060 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com --- Comment #4 from Pedro V --- (In reply to Vaclav Fiala from comment #3) > Here are a few use cases: > 1) "Cautious / security conscious user" - no new windows should get focus > initially, except for a few well defined ones (like a terminal app or > KRunner) > 2) "Long startup time apps" - define a rule that a specific application that > has a very long startup time should not get the initial focus (breaks > workflow) Can confirm these problems/desires, although I'm not sure the proposed approaches are the right ones: 1) User interaction is what should matter, a whitelist would be just a flawed workaround. If I press Ctrl-Alt-T I surely want Konsole right in my face, but if a background program would start it for some odd reason, I definitely wouldn't want it to steal focus. 2) Would have to test to get a feel, but I'm not sure I'd want a timeout in that case. If I wait for the launch then it should get focus anyway, but if I focus on another window while the program is starting, then I'd be okay with it not getting focus, no matter how fast it starts. The potentially tricky problem is starting from KRunner or the the Application Launcher as focus goes back to the previous window on those cases, and it's not obvious if the user wants to keep it that way which is the case where I could see the timeout making sense, although I still wouldn't be a fan of the resulting inconsistency. I'm not on Plasma 6 yet, so can't test current behavior, but so far I just gave up on the focus stealing prevention setting. Too low and silly programs pop up windows while I'm typing, potentially accepting a call almost instantly when hitting enter for what should be a new line in a text editor, or too extreme and even child windows appear behind the parent window. Speaking of security though, there's another important aspect other than accidental actions taken as mentioned. Ideally one day we are going to get the "promised" Wayland clipboard security feature which prevents programs just reading the clipboard whenever they feel like, even if that's an optional setting for more secure environments. This requires focus stealing prevention to work properly, so there's no unavoidable accidental user interaction which would allow clipboard reading (although I would opt into a strict Ctrl+(Shift)+V only pasting security level if ever available). GNOME had something relevant, and wl-paste worked around it with focus stealing: https://github.com/bugaevc/wl-clipboard/issues/31#issuecomment-462023847 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 429857] Allow to whitelist apps that can stay ontop of the screen lock
https://bugs.kde.org/show_bug.cgi?id=429857 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com --- Comment #2 from Pedro V --- Now this is what could be an XY problem, at least I believe I see what's the basic desire which is quite reasonable, but instead of that being described, a not really great potential solution was pitched instead. There are multiple forms of the generic idea, but it's all based on the problem of locking being all or nothing. There are some program-specific "layers" like password managers having separate locking, but there's no generic solution for allowing partial access to the system with seamless switching to full/different access. I'm not up to date on the topic, but consider some already existing solutions: - Android offers "app pinning" which is possibly the closest to what the user desires. A program can be "pinned" which makes it usable while the system itself is locked, so the device can be handed over to others, giving access to just a single program. - Android offers various forms of "secure containers" which is somewhat all over the place, but the general idea is having another layer of security to access specific programs. The implementations tend to be quite odd, but this tends to have the seamless desire as "secure" programs appear just like others once unlocked. - Multiple different operating systems are multi-user to some degree, so there's typically some kind of user switching. Currently on Linux at least sound is handled weirdly as PipeWire is user-level so audio setup is torn down during switching which is not handled by all programs too well, and it's generally not really a seamless process. It's likely still early to have related desires, but back when I've seen early multi-seat discussions about Wayland, one of the possible use cases I envisioned is quite relevant. The privilege separation part is tricky so I'll leave parts up to imagination, but it would be great if a single Wayland session could contain multiple different security contexts. Going with the reporter's simple desire, if mpv was started with a separate not really privileged user, then it would be great if the privileged user's session could be locked making its windows disappear, but the mpv window from the unlocked user would be still around. One user per monitor is a lower bar that used to be possible, and it could be a good enough solution given enough flexibility like "roaming" mouse and the ability to easily move a session from one monitor to another, but given that this direction mostly regressed, I'm not expecting such features any soon. Some relevant links: Bug 416720 Bug 256242 https://wiki.archlinux.org/title/xorg_multiseat -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 487634] Option to unlock by Fingerprint and Smartcard shown despite not having either one
https://bugs.kde.org/show_bug.cgi?id=487634 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[KRdp] [Bug 488372] Consider suppressing the portal confirmation dialog on connection
https://bugs.kde.org/show_bug.cgi?id=488372 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 488485] Security issues with auto enabled clipboard history.
https://bugs.kde.org/show_bug.cgi?id=488485 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 468691] Keyboard shortcut to share clipboard contents
https://bugs.kde.org/show_bug.cgi?id=468691 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com --- Comment #1 from Pedro V --- Potential duplicate of Bug 392164 , at least the desire is rather similar, and given a button, a keyboard shortcut assignable to that would be a logical next step. One possible tricky problem compared to the button desire is that there would be actually possibly multiple buttons as KDE Connect is not limited to a single device, so there can't be a simple universal shortcut, but instead a device-specific shortcut would be required which definitely adds complexity. -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 484363] Sometimes, on a multimonitor setup, screen locker fails to unlock screen and shows "Unlock" button that does nothing
https://bugs.kde.org/show_bug.cgi?id=484363 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 486352] Security issue: Lockscreen unlocked without a password with mysterious "Unlock" button, NoPasswordUnlock.qml in logs
https://bugs.kde.org/show_bug.cgi?id=486352 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 410360] Add a "soft upair" (disconnect) option to the interface and put a warning on the permanent unpair action.
https://bugs.kde.org/show_bug.cgi?id=410360 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com --- Comment #2 from Pedro V --- (In reply to René from comment #1) > 2. members don't want to be permanently connected to avoid clipboard paste > conflicts > 3. privacy issues in Android Part of this is covered by Bug 392164 . It's not really a small office or household specific issue though. Android is no longer really open source, phones are more of magical blackboxes nowadays instead of portable personal computers they were a decade or so ago. The "soft unpair" (I'd rather say pause) approach would be okay as a quick workaround, but I believe that finer-grained control is what's more desired here. For example the Run commands plugin gets it right, the user needs to whitelist commands first. Some examples of what's way too coarse-grained: - Clipboard: The lack of "single shot" sends just makes it too much of a security risk. Generally I'd also expect the automatic synchronization to drain phone battery quite a bit. - MprisRemote + Multimedia control receiver: Would be great to start/stop/pause music and maybe some videos, and also adjust the volume, but that comes hand in hand with sending info on every piece of multimedia playing with no exceptions. There's no way to disable metadata sending even though the multimedia buttons on some keyboards already work quite well without knowing what's playing, and there's also no whitelist to limit to just some specific programs as metadata can be useful after all. - LockDevice: Just recently found out that this isn't just for locking, it's also for no questions asked unlocking, going both ways. The "Locks your systems" made it look like a security feature I figured I'd use one day as it sounds great to be able to lock a remote host, but there aren't any settings so I ended up with a huge security hole of connected devices being able to unlock each-other. Generally KDE Connect is way too trusting, and the default settings are really not secure. I really appreciate the handful of features I use, but I just keep most of the plugins disabled as it's too risky to have them enabled. Speaking of which, relevant heads up: With LockDevice I got to know the hard way that disabling plugins don't actually unload them, so highly likely it's not enough to just temporary disable Clipboard either to achieve what's desired here. Also, there's a potential clipboard-specific solution Wayland "promised", but unfortunately it's not here (yet?). If clipboard reading would need user interaction, then clipboard contents simply just couldn't spread unintentionally. While this would break interaction-free automatic clipboard synchronization, I'd enable such a secure clipboard option in KWin without a second thought, and the KDE Connect Clipboard plugin would also become more useful by not sending everything. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 410149] Make & receive call from PC
https://bugs.kde.org/show_bug.cgi?id=410149 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kinfocenter] [Bug 488289] Window contents/text flicker when resizing when scrollbar is about to change visibility
https://bugs.kde.org/show_bug.cgi?id=488289 Rajeesh K V changed: What|Removed |Added CC||rajeeshknamb...@gmail.com --- Comment #3 from Rajeesh K V --- (In reply to David Edmundson from comment #1) > Does this happen with dolphin? Checked, Dolphin doesn't exhibit this problem. So it is probably just the energy info page, not KWin. -- You are receiving this mail because: You are watching all bug changes.
[kcalc] [Bug 487566] Kcalc doesn't chain result into next calculation anymore
https://bugs.kde.org/show_bug.cgi?id=487566 Gerd v. Egidy changed: What|Removed |Added CC||g...@egidy.de --- Comment #34 from Gerd v. Egidy --- I recently upgraded to 24.05.0 and was also puzzled by the new behavior of not reusing previous results. This is a feature I used very often. Very good that this will be addressed. But there is another, probably related issue: I usually have the "Numeral System Mode" activated with the bit editor enabled. I often need to set individual bits, for example from a register datasheet I read that I have to enable bit 7, bit 9, bit 14. Then I click these bits in the bit editor to enable them and get a number shown as decimal or hex in the result display. I then want to be able to use that number as part of a calculation, for example by shifting the bits by a given amount. I want to directly hit the "Lsh" button and continue my calculation. So basically using the bit editor as input method for a calculation. Will the proposed patch also allow this? On a first glance it looks to me like it currently only works after pressing = and not when bit-editing. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 488289] New: Window contents/text flicker when resizing when scrollbar is about to change visibility
https://bugs.kde.org/show_bug.cgi?id=488289 Bug ID: 488289 Summary: Window contents/text flicker when resizing when scrollbar is about to change visibility Classification: Plasma Product: kwin Version: 6.0.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: rajeeshknamb...@gmail.com Target Milestone: --- Created attachment 170315 --> https://bugs.kde.org/attachment.cgi?id=170315=edit KWin window text flickering on resize SUMMARY Window contents/text flickers when a window is resized. It does so (probably) only at the verge of changing the visibility of scrollbars. See attached screen recording. STEPS TO REPRODUCE 1. Open Energy Consumption Statistics (standalone, not from System Settings) 2. Enlarge the window size using mouse to the point where scrollbar is hidden and increase/decrease the window height in small units. OBSERVED RESULT Window contents and text flicker EXPECTED RESULT Window contents and text do not flicker SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora 40/Plasma 6.0.5/Wayland KDE Plasma Version: 6.0.5 KDE Frameworks Version: 5.115.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION GPU is Intel (HD Graphics 620), display server is Wayland. No KWin effects (other than default) enabled. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 402857] Touchpad gestures should be configurable
https://bugs.kde.org/show_bug.cgi?id=402857 Frans-Jan v. Steenbeek changed: What|Removed |Added CC||frans-...@van-steenbeek.net -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 487759] Vulkan wayland native windows go crazy when in fullscreen at random.
https://bugs.kde.org/show_bug.cgi?id=487759 V changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #6 from V --- (In reply to Zamundaaa from comment #3) > Okay. If you put > KWIN_DRM_NO_DIRECT_SCANOUT=1 > into /etc/environment and reboot, does the issue go away? Apparently it was already reported, or at least, something similar was, i added my comment to try and help... I think we can close this thread now. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/3402#note_2438198 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 487759] Vulkan wayland native windows go crazy when in fullscreen at random.
https://bugs.kde.org/show_bug.cgi?id=487759 --- Comment #4 from V --- (In reply to Zamundaaa from comment #3) > Okay. If you put > KWIN_DRM_NO_DIRECT_SCANOUT=1 > into /etc/environment and reboot, does the issue go away? I'm not sure, but it seems like it works... What does this do ? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 487815] New: After changing the CPU bar chart to application list, the entire shell freezes due to a binding loop
https://bugs.kde.org/show_bug.cgi?id=487815 Bug ID: 487815 Summary: After changing the CPU bar chart to application list, the entire shell freezes due to a binding loop Classification: Plasma Product: plasmashell Version: 6.0.5 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: System Monitor Assignee: plasma-b...@kde.org Reporter: fifis.hi...@gmail.com CC: ahiems...@heimr.nl, notm...@gmail.com Target Milestone: 1.0 SUMMARY After I accidentally changed the display style of the CPU usage tray sensor to ‘Application list’, the entire shell froze; Alt+Tab and shortcuts (e.g. Terminal, Ctrl+Alt+T) still work. Rebooting changes nothing – it still freezes. STEPS TO REPRODUCE 1. In the CPU usage monitor in the system tray, change ‘Bar chart’ to ‘Application list’ 2. The system tray and desktop freeze and become unresponsive. OBSERVED RESULT After `kquitapp5 plasmashell` and `kstart5 plasmashell`, here is the console log: ``` (base) [avk@UL0012159 ~]$ kstart5 plasmashell (base) [avk@UL0012159 ~]$ kf.plasma.quick: Applet preload policy set to 1 file:///usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/main.qml:196:25: QML FolderViewDropArea (parent or ancestor of QQuickLayoutAttached): Binding loop detected for property "minimumWidth" file:///usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/main.qml:196:25: QML FolderViewDropArea (parent or ancestor of QQuickLayoutAttached): Binding loop detected for property "minimumWidth" qml: The backend got an unknown wallpaper provider type. The wallpaper will now fall back to the default. Please check your wallpaper configuration! file:///usr/share/plasma/plasmoids/org.kde.plasma.private.systemtray/contents/ui/main.qml:162:21: QML KSortFilterProxyModel: Binding loop detected for property "sourceModel" file:///usr/share/plasma/plasmoids/org.kde.plasma.private.systemtray/contents/ui/main.qml:162:21: QML KSortFilterProxyModel: Binding loop detected for property "sourceModel" qml: SystemTray ItemLoader: Invalid state, cannot determine source! qt.gui.imageio: libpng warning: iCCP: known incorrect sRGB profile qt.gui.imageio: libpng warning: iCCP: known incorrect sRGB profile qt.gui.imageio: libpng warning: iCCP: known incorrect sRGB profile QFont::setPointSizeF: Point size <= 0 (0.00), must be greater than 0 QFont::setPointSizeF: Point size <= 0 (0.00), must be greater than 0 file:///usr/lib/qt6/qml/org/kde/kirigami/Dialog.qml:334:18: QML ScrollView: Binding loop detected for property "calculatedImplicitWidth" file:///usr/lib/qt6/qml/org/kde/kirigami/Dialog.qml:386:33: QML Binding: Binding loop detected for property "target" file:///usr/share/plasma/plasmoids/org.kde.plasma.systemmonitor/contents/ui/main.qml:38:25: QML FullRepresentation: Binding loop detected for property "contentItem" file:///usr/share/plasma/plasmoids/org.kde.plasma.systemmonitor/contents/ui/main.qml:38:25: QML FullRepresentation: Binding loop detected for property "contentItem" file:///usr/share/plasma/plasmoids/org.kde.plasma.systemmonitor/contents/ui/main.qml:38:25: QML FullRepresentation: Binding loop detected for property "contentItem" ... ``` EXPECTED RESULT Expected responsive shell and working widget that would show the CPU usage. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux KDE Plasma Version: 6.0.5 KDE Frameworks Version: 6.0.5 Qt Version: qt6-base 6.7.1-3, qt5-base 5.15.14+kde+r140-1 -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 487812] I changed my brightness by mistake, the second screen is stuck on a wrong brightness value
https://bugs.kde.org/show_bug.cgi?id=487812 --- Comment #1 from V --- Also specs: CPU: R7 7800X3D RAM: 32Gb GPU: RX 7900 XTX Driver: Mesa 24.0.7 and i run wayland. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 487812] New: I changed my brightness by mistake, the second screen is stuck on a wrong brightness value
https://bugs.kde.org/show_bug.cgi?id=487812 Bug ID: 487812 Summary: I changed my brightness by mistake, the second screen is stuck on a wrong brightness value Classification: Plasma Product: Powerdevil Version: 6.0.4 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: c9lyw0...@mozmail.com CC: m...@ratijas.tk, natalie_clar...@yahoo.de Target Milestone: --- SUMMARY I scrolled by mistake on the brightness tray icon, messing up the brightness of my screens. Now one of my 2 screens is stuck in an insanely bright mode, despite controlling the brightness cursor on the tray (apparently the only place where i can change that value), one screen changes, but not the other. STEPS TO REPRODUCE 1. scroll by mistake like a moron on the tray icon 2. Brightness messed up 3. Enjoy the flashbang on the second screen for the rest of your life. :) OBSERVED RESULT Brightness not changing on the second screen. EXPECTED RESULT Brightness should change as it sometimes does on the second screen. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Void-Linux 6.9.2 KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.6.0 ADDITIONAL INFORMATION Nothing. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 487759] Vulkan wayland native windows go crazy when in fullscreen at random.
https://bugs.kde.org/show_bug.cgi?id=487759 --- Comment #2 from V --- (In reply to Zamundaaa from comment #1) > What GPU are you using? Hello, thank you for your answer. My main configuration (which has this issue) runs with: CPU: R7 7800X3D RAM: 32Gb GPU: RX 7900 XTX Driver: Mesa 24.0.7 -- You are receiving this mail because: You are watching all bug changes.
[bugs.kde.org] [Bug 487757] New: Please delete my account
https://bugs.kde.org/show_bug.cgi?id=487757 Bug ID: 487757 Summary: Please delete my account Classification: Websites Product: bugs.kde.org Version: unspecified Platform: Other OS: Other Status: REPORTED Severity: normal Priority: NOR Component: database Assignee: sysad...@kde.org Reporter: vincent.bar...@outlook.fr CC: she...@kde.org Target Milestone: --- Hello. Could you please delete my account ? Thank you. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 482987] With fractional scale, bottom edge of screen has pixels that are held to the color of previously opened windows after closing those windows
https://bugs.kde.org/show_bug.cgi?id=482987 Lamarque V. Souza changed: What|Removed |Added CC|lamar...@kde.org| -- You are receiving this mail because: You are watching all bug changes.
[kontact] [Bug 487725] New: kontact crash
https://bugs.kde.org/show_bug.cgi?id=487725
Bug ID: 487725
Summary: kontact crash
Classification: Applications
Product: kontact
Version: unspecified
Platform: unspecified
OS: Linux
Status: REPORTED
Keywords: drkonqi
Severity: crash
Priority: NOR
Component: general
Assignee: kdepim-b...@kde.org
Reporter: ya-ruste...@ya.ru
Target Milestone: ---
Application: kontact (5.24.5 (23.08.5))
Qt Version: 5.15.13
Frameworks Version: 5.115.0
Operating System: Linux 6.1.85-un-def-alt1 x86_64
Windowing System: Wayland
Distribution: ALT Workstation K 10.3 (Sorbaronia Mitschurinii)
DrKonqi: 5.27.11 [KCrashBackend]
-- Information about the crash:
The application crashes with an error immediately after clicking on the account
settings button on the main page
The reporter is unsure if this crash is reproducible.
-- Backtrace:
Application: Kontact (kontact), signal: Segmentation fault
Content of s_kcrashErrorMessage: std::unique_ptr = {get() = 0x0}
[KCrash Handler]
#6 0x7f729db56524 in KCModuleProxy::isChanged() const () from
/usr/lib64/libKF5KCMUtils.so.5
#7 0x7f729de85967 in KontactKCMultiDialogPrivate::resolveChanges
(this=this@entry=0x55d59601e470,
currentProxy=currentProxy@entry=0x55d596153b70) at
/usr/src/debug/kontact-23.08.5/src/ksettingsdialog/kontactkcmultidialog.cpp:47
#8 0x7f729de86ca8 in
KontactKCMultiDialogPrivate::_k_slotCurrentPageChanged (this=0x55d59601e470,
current=0x55d5961e1750, previous=0x55d596154550) at
/usr/src/debug/kontact-23.08.5/src/ksettingsdialog/kontactkcmultidialog.cpp:118
#9 0x7f729c9071f2 in ?? () from /usr/lib64/libQt5Core.so.5
#10 0x7f729bf5487b in KPageDialog::currentPageChanged(KPageWidgetItem*,
KPageWidgetItem*) () from /usr/lib64/libKF5WidgetsAddons.so.5
#11 0x7f729c9071f2 in ?? () from /usr/lib64/libQt5Core.so.5
#12 0x7f729bf5cabb in KPageWidget::currentPageChanged(KPageWidgetItem*,
KPageWidgetItem*) () from /usr/lib64/libKF5WidgetsAddons.so.5
#13 0x7f729c9071f2 in ?? () from /usr/lib64/libQt5Core.so.5
#14 0x7f729bf55807 in KPageView::currentPageChanged(QModelIndex const&,
QModelIndex const&) () from /usr/lib64/libKF5WidgetsAddons.so.5
#15 0x7f729bf576c1 in ?? () from /usr/lib64/libKF5WidgetsAddons.so.5
#16 0x7f729c9071f2 in ?? () from /usr/lib64/libQt5Core.so.5
#17 0x7f729c87b140 in QItemSelectionModel::selectionChanged(QItemSelection
const&, QItemSelection const&) () from /usr/lib64/libQt5Core.so.5
#18 0x7f729c881c4c in
QItemSelectionModel::emitSelectionChanged(QItemSelection const&, QItemSelection
const&) () from /usr/lib64/libQt5Core.so.5
#19 0x7f729c883c9e in QItemSelectionModel::select(QItemSelection const&,
QFlags) () from /usr/lib64/libQt5Core.so.5
#20 0x7f729d87a8c2 in QTreeViewPrivate::select
(this=this@entry=0x55d59602d730, topIndex=..., bottomIndex=..., command=...,
command@entry=...) at itemviews/qtreeview.cpp:3927
#21 0x7f729d87b09e in QTreeView::setSelection (this=,
rect=..., command=...) at itemviews/qtreeview.cpp:2325
#22 0x7f729d806750 in QAbstractItemView::mousePressEvent
(this=0x55d5960141c0, event=) at
itemviews/qabstractitemview.cpp:1806
#23 0x7f729d5d011e in QWidget::event (this=0x55d5960141c0,
event=0x7ffd13589060) at kernel/qwidget.cpp:9045
#24 0x7f729d67da2e in QFrame::event (this=0x55d5960141c0, e=0x7ffd13589060)
at widgets/qframe.cpp:550
#25 0x7f729c8d0373 in
QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) ()
from /usr/lib64/libQt5Core.so.5
#26 0x7f729d58dc1e in QApplicationPrivate::notify_helper
(this=this@entry=0x55d5942c0b50, receiver=receiver@entry=0x55d59601fb10,
e=e@entry=0x7ffd13589060) at kernel/qapplication.cpp:3634
#27 0x7f729d59522b in QApplication::notify (this=0x7ffd13588da0,
receiver=0x55d59601fb10, e=0x7ffd13589060) at kernel/qapplication.cpp:3084
#28 0x7f729c8d060a in QCoreApplication::notifyInternal2(QObject*, QEvent*)
() from /usr/lib64/libQt5Core.so.5
#29 0x7f729d594263 in QApplicationPrivate::sendMouseEvent
(receiver=receiver@entry=0x55d59601fb10, event=event@entry=0x7ffd13589060,
alienWidget=alienWidget@entry=0x55d59601fb10, nativeWidget=0x55d595f9b1f0,
buttonDown=, lastMouseReceiver=..., spontaneous=true,
onlyDispatchEnterLeave=false) at kernel/qapplication.cpp:2622
#30 0x7f729d5e9607 in QWidgetWindow::handleMouseEvent (this=0x55d596086050,
event=0x7ffd13589320) at kernel/qwidgetwindow.cpp:684
#31 0x7f729d5ec935 in QWidgetWindow::event (this=0x55d596086050,
event=0x7ffd13589320) at kernel/qwidgetwindow.cpp:300
#32 0x7f729d58dc2f in QApplicationPrivate::notify_helper (this=, receiver=0x55d596086050, e=0x7ffd13589320) at
kernel/qapplication.cpp:3640
#33 0x7f729c8d060a in QCoreApplication::notifyInternal2(QObject*, QEvent*)
() from /usr/lib64/libQt5Core.so.5
#34 0x7f729cd66e53 in QGuiApplicationPrivate::processMouseEvent
(e=0x55d596800790) at
[frameworks-kio] [Bug 475235] [Data loss] Moving files to trash might silently delete them instead
https://bugs.kde.org/show_bug.cgi?id=475235 Pedro V changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 Product|dolphin |frameworks-kio Component|general |Trash CC||kdelibs-b...@kde.org Assignee|dolphin-bugs-n...@kde.org |kio-bugs-n...@kde.org Version|23.08.1 |unspecified --- Comment #3 from Pedro V --- Recommending using the "Permalink" button when linking source code files as the links containing "master" will just point to whatever is the latest, so they will become stale over time as files are changed and lines are drifting around if not completely changed or removed. Looking at the code, the key will be the "Configure Dolphin to skip the confirmation when deleting files" step, and the logical problem can be mostly understood here: https://invent.kde.org/frameworks/kio/-/blob/a360462d5290200b27d874d1cb3895336942d55b/src/widgets/widgetsaskuseractionhandler.cpp#L304 Apparently I made the mistake of understanding deleting as something like pressing the Delete button which should trash by default, but it's actually file delete in this case. The "Reduce the size of the trash" step breaks reproduction though, however I can't really see why isn't `(util.usage(partitionSize + additionalSize)) >= percent` evaluating to true in that case. With that, I can confirm this to be an undesired data loss problem, even though I personally consider only trashing to be safe without confirmation, and even that is annoying to do accidentally as there isn't an interface for reverting recent trashing operations, the user has to dig. Reproducer: 1. Uncheck the "Deleting files or folders" confirmation setting. 2. Ensure the trash isn't full already (Beware: Just setting trash limit to 0.01% to make it full already doesn't work here) 3. Create a large test file: `truncate -s 32G test.file` (modify size as needed to make sure it doesn't fit into the configured trash size limit) 4. Attempt to trash the test file 5. Observe the trashing operation being promoted to deletion which then gets automatically confirmed Issue is CONFIRMED, and it seems to be a problem in KIO, not in Dolphin, should affect other products too. Can't reproduce in Krusader though, this time trashing is just hanging, but that's a matter belonging to Bug 486299 . Suggesting bumping up Importance as this is a data loss concern. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 485258] Dolphin crashed after dragging a file to the path breadcrumb
https://bugs.kde.org/show_bug.cgi?id=485258 V changed: What|Removed |Added CC|fresh.frog5...@fastmail.com | -- You are receiving this mail because: You are watching all bug changes.
[ktorrent] [Bug 283335] UPNP gives 'internal server error' in 'port forwarded' column since upgrade to 4.7.x
https://bugs.kde.org/show_bug.cgi?id=283335 Steven V. Wilson changed: What|Removed |Added CC||funmaker...@yahoo.com --- Comment #5 from Steven V. Wilson --- This bug appears to have returned. Please reopen it. Kubuntu 23.04 Ktorrent version 23.08.1 Thanks. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 272361] Unavailable mounts mounts with Places entries make clients (e.g. Dolphin, Gwenview, file open or save dialogs) hang or become extremely slow
https://bugs.kde.org/show_bug.cgi?id=272361 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 486479] New: Dolphin crashed after dragging a file over the breadcrumbs
https://bugs.kde.org/show_bug.cgi?id=486479
Bug ID: 486479
Summary: Dolphin crashed after dragging a file over the
breadcrumbs
Classification: I don't know
Product: kde
Version: unspecified
Platform: NixOS
OS: Linux
Status: REPORTED
Keywords: drkonqi
Severity: crash
Priority: NOR
Component: general
Assignee: unassigned-b...@kde.org
Reporter: fresh.frog5...@fastmail.com
Target Milestone: ---
Application: (24.02.2)
Qt Version: 6.7.0
Frameworks Version: 6.1.0
Operating System: Linux 6.6.27-xanmod1 x86_64
Windowing System: Wayland
Distribution: NixOS 24.05 (Uakari)
DrKonqi: 6.0.4 [CoredumpBackend]
-- Information about the crash:
After dragging a file into IntelliJ IDEA (Community Edition), Dolphin crashed.
I was able to reproduce this reliably, and after experimenting a bit, found
that this appeared to depend on how deeply nested the file was. For instance,
`/home/v/a/a/a/a/b` would crash Dolphin, whereas `/home/v/a/a/a/b` would not.
Only dragging the file into the editor section of IDEA would induce a crash;
dragging into the Project file listing would open a modal as expected.
While trying to reproduce this, I discovered what appeared to be another bug:
Dolphin would crash when dragging a file onto the directory path/breadcrumbs at
the top. I eventually realized that this and the initial bug were one and the
same, and that these had nothing to do with the directory depth, since any time
I dragged the file *over* the breadcrumbs it would crash a moment later as
well. Naturally, longer paths were more likely to result in me moving the
cursor over the breadcrumbs, leading to a crash in only those cases when
initially debugging this.
The crash can be reproduced every time.
-- Backtrace:
Application: Dolphin (), signal: Segmentation fault
Content of s_kcrashErrorMessage: std::unique_ptr = {get() = 0x0}
[New LWP 575904]
[New LWP 575905]
[New LWP 575909]
[New LWP 575906]
[New LWP 575908]
[New LWP 575923]
[New LWP 575907]
[New LWP 575940]
[New LWP 575925]
[New LWP 575924]
[New LWP 575926]
[New LWP 575942]
[New LWP 575932]
[New LWP 575941]
[New LWP 575939]
[New LWP 575943]
[New LWP 575944]
[New LWP 576016]
[New LWP 576242]
[New LWP 575948]
[New LWP 575945]
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/nix/store/35pq4hr29c3sl79lgfwgsvd9nwzyp4am-glibc-2.39-5/lib/libthread_db.so.1".
Core was generated by `/run/current-system/sw/bin/dolphin'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 __pthread_kill_implementation (threadid=,
signo=signo@entry=11, no_tid=no_tid@entry=0) at pthread_kill.c:44
44return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO
(ret) : 0;
[Current thread is 1 (Thread 0x7fae066a3fc0 (LWP 575904))]
Cannot QML trace cores :(
Unexpectedly stumbled over an objfile
(/nix/store/5zk3svqc96pnjkf9yxwx4vpb5bh0hqzj-libdeflate-1.20/lib/libdeflate.so.0)
without build_id. Not creating payload.
[Current thread is 1 (Thread 0x7fae066a3fc0 (LWP 575904))]
Thread 21 (Thread 0x7fadb37fe6c0 (LWP 575945)):
#0 0x7fae0b839c5e in __futex_abstimed_wait_common64 (private=0,
cancel=true, abstime=0x7fadb37fda10, op=137, expected=0, futex_word=0x14bd3a4)
at futex-internal.c:57
#1 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x14bd3a4,
expected=expected@entry=0, clockid=clockid@entry=1,
abstime=abstime@entry=0x7fadb37fda10, private=private@entry=0,
cancel=cancel@entry=true) at futex-internal.c:87
#2 0x7fae0b839cdf in __GI___futex_abstimed_wait_cancelable64
(futex_word=futex_word@entry=0x14bd3a4, expected=expected@entry=0,
clockid=clockid@entry=1, abstime=abstime@entry=0x7fadb37fda10,
private=private@entry=0) at futex-internal.c:139
#3 0x7fae0b83c7d5 in __pthread_cond_wait_common (abstime=0x7fadb37fda10,
clockid=1, mutex=0x14bd350, cond=0x14bd378) at pthread_cond_wait.c:503
#4 ___pthread_cond_timedwait64 (cond=0x14bd378, mutex=0x14bd350,
abstime=0x7fadb37fda10) at pthread_cond_wait.c:643
#5 0x7fae0c087393 in QWaitCondition::wait(QMutex*, QDeadlineTimer) () from
/nix/store/r8a6ss3xnc9j4yrgajbvy8wnn359cpkq-qtbase-6.7.0/lib/libQt6Core.so.6
#6 0x7fae0c08409c in QThreadPoolThread::run() () from
/nix/store/r8a6ss3xnc9j4yrgajbvy8wnn359cpkq-qtbase-6.7.0/lib/libQt6Core.so.6
#7 0x7fae0c07ade1 in QThreadPrivate::start(void*) () from
/nix/store/r8a6ss3xnc9j4yrgajbvy8wnn359cpkq-qtbase-6.7.0/lib/libQt6Core.so.6
#8 0x7fae0b83d272 in start_thread (arg=) at
pthread_create.c:447
#9 0x7fae0b8b8dcc in clone3 () at
../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
Thread 20 (Thread 0x7fade5d2a6c0 (LWP 575948)):
#0 0x7fae0b8abb66 in __GI_ppoll (fds=0x7fade5d29840, nfds=1,
timeout=, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:42
#1 0x7fae0c0777f9 in qt_safe_poll(pollfd*, unsigned long, QDeadlineTimer)
() from
[gwenview] [Bug 486423] New: Avoid unnecessary stat calls for recent files and directories
https://bugs.kde.org/show_bug.cgi?id=486423 Bug ID: 486423 Summary: Avoid unnecessary stat calls for recent files and directories Classification: Applications Product: gwenview Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: gwenview-bugs-n...@kde.org Reporter: voidpointertonull+bugskde...@gmail.com Target Milestone: --- Many KDE programs have an issue with doing a whole lot of I/O undesired by the user, and gwenview seems to be no exception. This is mostly a problem with network mounted drives not rarely having high latency, and occasionally not even responding, leading to programs trying to use them freezing for a while. In my case I've had an NFS mount pointing to a remote HDD which was getting quite hammered, so it was not responding for 10+ seconds at a time. A more usual example of something like this happening is an NFS mount not responding at all due to networking issues which tends to completely freeze quite a few misbehaving programs. Found it odd that gwenview is affected as I was trying to look at local pictures, but a quick strace run revealed what's going on: 1) Recently opened files are checked out with stat calls and even opened to do another stat with the file handle. 2) After entries from ~/.local/share/gwenview/recentfolders/ get loaded, the directories there get checked out with stat. 3) When closing the program, fstab gets read and mount points get checked out with stat. The last one is likely done by an external library providing info for the "Places" tab (although that isn't shown in my test run), so let's consider it out of the scope of the bug report, just included for the sake of completeness. Aside from that, there's the nuisance that recent file and directory info is not just loaded, but everything pointed to gets checked out even when there's no recent information is shown. I wasn't even aware of this feature as I was always opening pictures directly, and I've just recently discovered that there's the "Open Recent" menu item, and recent directories and files get shown when gwenview is started with no file specified. I'm not exactly sure why is the directory and file stat checking done when gwenview is launched to show a specific file. Initially I thought that maybe it checks recent entries to see if files were deleted, but a quick test of deleting a picture which then keeps showing up in the "Open Recent" menu item revealed that not to be the case. Given that, I believe the stat calls shouldn't happen when the "Recent Folders" and "Recent Files" tabs aren't shown which is the case when gwenview is used to view specific files. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 454231] 3-fingers touchpad gesture (to navigate between virtual desktops) should follow touchpad scrolling direction preference
https://bugs.kde.org/show_bug.cgi?id=454231 Frans-Jan v. Steenbeek changed: What|Removed |Added Version|5.24.90 |6.0.4 --- Comment #13 from Frans-Jan v. Steenbeek --- Same on Plasma 6.0.4. as well. Should we update the version tag of this bug now that we're on the next Megarelease? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 454231] 3-fingers touchpad gesture (to navigate between virtual desktops) should follow touchpad scrolling direction preference
https://bugs.kde.org/show_bug.cgi?id=454231 Frans-Jan v. Steenbeek changed: What|Removed |Added CC||frans-...@van-steenbeek.net -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 392376] Wayland socket buffer gets filled up and application terminates when GUI thread was blocked
https://bugs.kde.org/show_bug.cgi?id=392376 --- Comment #12 from Pedro V --- *** Bug 484495 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 484495] Wayland native apps close often when the computer is slower due to high i/o
https://bugs.kde.org/show_bug.cgi?id=484495 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com Resolution|UPSTREAM|DUPLICATE --- Comment #3 from Pedro V --- The Wayland-specific part is already covered by #392376 . The issue with background I/O being capable of slowing everything down to almost a halt is a Linux kernel problem with a long history, and it doesn't look like it's getting improvements any soon, but you can surely make it worse by using extra features added over time like Btrfs with really heavy compression. KDE overall is getting quite resilient to it, at least as long as the I/O queue is progressing, not a complete halt as an NFS mount not responding will unfortunately still get many KDE components unusable as there's a whole lot of mount point poking everywhere with questionable necessity. Apparently I can't set CLOSED, so setting DUPLICATE while keeping the RESOLVED status, even though the issue itself isn't resolved. *** This bug has been marked as a duplicate of bug 392376 *** -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 392376] Wayland socket buffer gets filled up and application terminates when GUI thread was blocked
https://bugs.kde.org/show_bug.cgi?id=392376 --- Comment #11 from Pedro V --- The problem is definitely not gone completely, but KDE programs got quite resilient over time, and various workarounds tamed most common programs even including Firefox which still tends to lock up globally with mostly malicious websites abusing whatever they can with JS. This merged change is quite relevant though: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/188 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 179678] KIO needs PolicyKit-kde integration
https://bugs.kde.org/show_bug.cgi?id=179678 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[krusader] [Bug 480894] Can't "Move to Trash" files
https://bugs.kde.org/show_bug.cgi?id=480894 Pedro V changed: What|Removed |Added Status|REPORTED|NEEDSINFO CC||voidpointertonull+bugskdeor ||g...@gmail.com Resolution|--- |WAITINGFORINFO --- Comment #1 from Pedro V --- That's not a whole lot of info. Does the operation appear to succeed without doing anything? Does it fail with visual indication? Can you run `QT_LOGGING_RULES="*kio*=true" krusader -d` and show the output? There are multiple relevant suspect issues, but just ran into a nasty problem I wondered about but didn't know (or remember) to be this silly. The just reported Bug #486299 is one potential candidate. Will be curious if that's what you encountered. -- You are receiving this mail because: You are watching all bug changes.
[krusader] [Bug 486299] New: Moving to trash pretends to succeed if there's not enough space
https://bugs.kde.org/show_bug.cgi?id=486299 Bug ID: 486299 Summary: Moving to trash pretends to succeed if there's not enough space Classification: Applications Product: krusader Version: 2.8.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: krusader-bugs-n...@kde.org Reporter: voidpointertonull+bugskde...@gmail.com CC: krusader-bugs-n...@kde.org Target Milestone: --- KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 1. Exceed 0.01% of storage capacity in the trash 2. Set trash limit to 0.01% 3. Attempt to trash a file 4. Observe fake success without the file disappearing As described in Bug #475235 , Dolphin seems to report the issue all right. Interrogating Krusader with `QT_LOGGING_RULES="*kio*=true" krusader -d` reveals: kf.kio.widgets unknown@0 # CommandRecorder::slotResult: "The trash is full. Empty it or remove items manually." - no undo command will be added Error propagation up to the UI would be great for better user experience. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 475235] [Data loss] Moving files to trash might silently delete them instead
https://bugs.kde.org/show_bug.cgi?id=475235 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com --- Comment #1 from Pedro V --- KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 My Dolphin is also 23.08.1 , so I guess behavior should be matching, but I get the following warning: "The trash is full. Empty it or remove items manually." Given the Dolphin version match, maybe there's a mismatch for KIO where thrash handling actually happens? I can confidently say though that I can't reproduce, and the behavior I'm seeing is safe. -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 436919] Cannot compress large directory as 7zip
https://bugs.kde.org/show_bug.cgi?id=436919 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com Resolution|--- |WORKSFORME Status|REPORTED|NEEDSINFO --- Comment #7 from Pedro V --- Was the supposed reproducer method in comment 3 actually work to recreate the problem, or was it just assumed to be good enough? Suspected the "> 2 000 000" condition as a potential time waster, not recommending targeting that, but for the sake of completeness I went for it. Optimally there would be multiple directories used for best performance, but went for just 2 in tmpfs for simplicity, running the following in /tmp/test/test2/: seq 0 200 | xargs -I% -P $(nproc) touch % "Double bagged" the files as I was using Krusader for compressing, and it would just "freeze" when right clicking on the directory containing the ton of files, and figured it's easier to just add an extra layer instead of waiting for not sure how long. Neither Krusader nor Ark will confirm in reasonable time whether the package is any good, but `7z l test.7z | wc -l` shows 224 which is close enough to what's expected without getting into the details of cutting out extra verbosity. Generally I feel like this will be a duplicate of Bug #453452 , not having to do anything with the count of files. If that's the case, then suspected issues are: - 7z being rather unfriendly, not handling all files properly, symbolic links being one common example - Ark swallowing the errors of the 7z tool instead of properly propagating them which is the more serious problem as there's a fake success -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 419009] Cann't create 7z archive for folder
https://bugs.kde.org/show_bug.cgi?id=419009 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com Status|REPORTED|RESOLVED Resolution|--- |DUPLICATE --- Comment #9 from Pedro V --- Duplicate of multiple of various reports around involving files 7z / p7zip can't handle. Typically the issue is with symbolic links, and comment 5 showing even just "com1 -> /dev/ttyS0" is a quite likely candidate for problems as /dev/ttyS0 would be attempted to be added to the archive which would fail and would get whined about in the output of 7z, but then Ark swallows that error output, leading to the mess. For anyone finding this by accident later, this is why 7z isn't used universally and tar is still being used despite its significant limitations. The 7-Zip project mostly focuses on Windows, and support for features not presented or not really used there is poor, so it either gets upset with some files, or worse case it makes an archive that unpacks into a mess different than what was intended to be archived, like symbolic links being replaced with the files they pointed to. The problem with Ark is not just the lack of error propagation, but even hiding the error. Reaping this as it went without additional info for long, and there are multiple similar enough bug reports anyway. *** This bug has been marked as a duplicate of bug 453452 *** -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 453452] creating 7zip archive of ~/.mozilla or ~/.thunderbird folder fails
https://bugs.kde.org/show_bug.cgi?id=453452 Pedro V changed: What|Removed |Added CC||hard-c...@yandex.ru --- Comment #3 from Pedro V --- *** Bug 419009 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[krusader] [Bug 281917] Cannot copy a file from one zip archive to another
https://bugs.kde.org/show_bug.cgi?id=281917 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com --- Comment #21 from Pedro V --- Making krarc to krarc copy working seems to be mostly a wishlist matter, but there's an actual bug here of not having graceful error handling. Running `krusader -d` (version 2.8.0) shows that an error is encountered internally: source: "/tmp/B.zip/README.txt" dest: "/tmp/A.zip/README.txt" ERROR: "/tmp/B.zip/README.txt" is not a local file. Optimally this error would be propagated, and the copy operation would be interrupted with failure instead of letting it hang forever. -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 464633] ark creates folders with 01/01/1970 timestamp
https://bugs.kde.org/show_bug.cgi?id=464633 Pedro V changed: What|Removed |Added Status|REPORTED|NEEDSINFO CC||voidpointertonull+bugskdeor ||g...@gmail.com Resolution|--- |WAITINGFORINFO --- Comment #3 from Pedro V --- The linked site was possibly changed already. Clicking on "Download all files" gets me an archive with timestamps set to the time the archive was made. Do you still have such an archive which can be used as a reproducer? The zip format is messy, wanted to check whether the timestamp is actually missing (I'm not sure that can actually happen) or it's just set to 0. Without seeing more, I'm leaning towards the possibility that this may not be a (significant?) bug, and Bug #467994 had more info, especially with Bug #185209 being linked there which may be the ultimate desire. The empty "Date" field is still useful information. Let's theorize that the unix timestamp addition is missing. In that case I believe the ancient DOS-based timestamp which is not optional should be used, and according to https://stackoverflow.com/questions/3725662/what-is-the-earliest-timestamp-value-that-is-supported-in-zip-file-format , 1980-01-01 00:00 should be the earlier possible date with that. At least that's what's likely to be the technically correct approach, although I can't fault anyone for being happy enough with just unix timestamps working, not extending the already crazy domain of date and time handling with ancient DOS issues. Regarding the relevance of Bug #185209 , there's generally the problem that there's no invalid timestamp, the minimum (zero) value is just as valid as the maximum, even if some programs either can't handle part of the range (32-bit limitations, signed integer silliness, repurposing "unused" bit) or uses magic values for validity or error (minimum/zero and maximum typically). The DOS minimum of 1980-01-01 00:00 would likely work in your case, but pointing out that as the presence of that ancient timestamp is not optional, technically there's always a timestamp to be used. -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 436915] Compressing errors doesn't show up
https://bugs.kde.org/show_bug.cgi?id=436915 Pedro V changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 CC||voidpointertonull+bugskdeor ||g...@gmail.com --- Comment #1 from Pedro V --- This is the most generic description of the issue of errors of the external 7z process being swallowed, that makes it desirable as the catch-all report, but more specific bug reports have more information already. Setting CONFIRMED, but some bug deduplication will be desired with a winner chosen as there are multiple reports with the same root cause. -- You are receiving this mail because: You are watching all bug changes.
[krusader] [Bug 486289] New: 7z encryption detection logic is inefficient and silly
https://bugs.kde.org/show_bug.cgi?id=486289
Bug ID: 486289
Summary: 7z encryption detection logic is inefficient and silly
Classification: Applications
Product: krusader
Version: unspecified
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: krarc
Assignee: krusader-bugs-n...@kde.org
Reporter: voidpointertonull+bugskde...@gmail.com
CC: krusader-bugs-n...@kde.org
Target Milestone: ---
I'll keep the performance issue mostly to Bug #457906 , but the explanation is
a useful setup here too.
`getType` in app/Archive/krarchandler.h has a sneaky `bool check7zEncrypted =
true` which appears to be left at the default value everywhere. This leads to
`kio_krarcProtocol::checkIf7zIsEncrypted` and therefore
`kio_krarcProtocol::check7zOutputForPassword` getting executed not even just
once, but apparently several times every time the archive or a directory in it
is entered. As the external 7z tool is executed by `checkIf7zIsEncrypted` to
get a full file list, the performance issue is quite obvious.
The explained check is what's leading to the "silly" part which can be
considered broken in some cases. I found this whole issue because Krusader was
persistently asking for a password, multiple times every time an archive or a
directory in it was opened, so between the performance issues and the dialog
popups, it was a chore to do anything.
Figured out the hard way that my non-encrypted archive was triggering the
`line.contains("password") && line.contains("enter")` check in
`check7zOutputForPassword`, making Krusader believe that it's encrypted.
Problem is that a file in the archive could be called `enter_password.html`,
and Krusader would be fooled as "enter" and "password" would be matched on the
same line in the output of 7z, leading to the password dialog torture.
7z handling in general isn't exactly great anywhere, but surprised to see that
Krusader makes the matter significantly worse. Ark doesn't have this oddity.
--
You are receiving this mail because:
You are watching all bug changes.
[ark] [Bug 464860] Risk of data loss due to notification indicating successful compression to 7zip format when in fact the compression failed
https://bugs.kde.org/show_bug.cgi?id=464860 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com Resolution|--- |WAITINGFORINFO Status|REPORTED|NEEDSINFO --- Comment #2 from Pedro V --- Bug #453452 could be related, there's generally a problem with the lack of error handling for issues related to the external 7z executable. The password passed in the command line is a whole another issue I'd highlight here as I was surprised to see that "-pmypassword" part which can be seen by all users on the host on most setups. Not really seeing an error message though, or a specific error. Quite a bit of time passed since the report, but do you have any more specific information? Were the files actually archived in that 7203 ms? I would expect no archive in that time, but then a file not even existing shouldn't take 213525 ms to verify. -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 470577] [feature request] 7z additional options
https://bugs.kde.org/show_bug.cgi?id=470577 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 482255] Incredibly Niche Bug Leading To Severe Decompression Errors And Appearence of Corrupted Archive With A .7z
https://bugs.kde.org/show_bug.cgi?id=482255 Pedro V changed: What|Removed |Added Resolution|--- |WAITINGFORINFO Status|REPORTED|NEEDSINFO CC||voidpointertonull+bugskdeor ||g...@gmail.com --- Comment #1 from Pedro V --- Can p7zip (typically what's the 7z executable in Linux distributions) correctly extract the files? I'd suspect that first at least partially because Ark uses that for 7z files, although the extraction may be done with the K7zip implementation. Do the affected files contain special characters? Sometimes it's sneaky like _﹘—- being 4 different characters with the middle 2 being "Unicode", and the 7-Zip project is quite Windows-specific, embracing UTF-16 and locale madness, making it possible that an archive made on one system isn't handled well on another: https://unix.stackexchange.com/questions/305886/how-to-specify-character-encoding-for-7z -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 482901] Hangs while trying to unpack 20k+ files from .7z archive
https://bugs.kde.org/show_bug.cgi?id=482901 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com Ever confirmed|0 |1 Status|REPORTED|CONFIRMED --- Comment #1 from Pedro V --- Bug #454268 is not necessarily related. Haven't checked rar specifically, but 7z is somewhat of a special beast, an external 7z executable is used to get information about the contents of the archive, and it's surely really slow. It's not really an endless hang, your setup is just likely not fast enough to deal with the matter in a reasonable amount of time. Surprisingly the file listing procedure is unusually CPU intensive as mentioned in Bug #457906 and Bug #422142 already. -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 484404] Fails to find plugin for 7z files
https://bugs.kde.org/show_bug.cgi?id=484404 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com Resolution|--- |WORKSFORME Status|REPORTED|NEEDSINFO --- Comment #2 from Pedro V --- Can't reproduce, but it suspiciously seems like you attempted to use it during a period of temporary breakage: https://github.com/flathub/org.kde.ark/pull/82 Please retry, theoretically it should work already. -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 453452] creating 7zip archive of ~/.mozilla or ~/.thunderbird folder fails
https://bugs.kde.org/show_bug.cgi?id=453452 Pedro V changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|CONFIRMED CC||voidpointertonull+bugskdeor ||g...@gmail.com --- Comment #2 from Pedro V --- Initially I thought it could be a problem with names starting with a dot, but that's not the case, other directories are compressed okay. Starting with the vanity issue, even if the compression is stopped, the directory which should contain the resulting archive is opened which is unexpected. There's likely the lack of error handling here. As it could be seen that the external 7z tool is used to make the archive, caught the exact command used and ran it manually to see what's up. After a quite telling `ERROR:` line, the "offending" file is revealed: `stat error for .mozilla/firefox/Profile.ProfileName/lock (No such file or directory)` Looking at the file, `ls -la` shows the following: `lock -> 127.0.1.1:+2`. This is likely a good showcase of why 7z is recommended to be avoided for "non-trivial" archival purposes, as it has poor or no support for filesystem features not present or rarely used on Windows. Haven't verified, but as I've read once, it doesn't handle symbolic links, but just tries to add the files they are pointing to, and in this case the symbolic link is apparently being "abused" to contain program specific information instead of pointing at an existing file, so it's considered broken. Even if the symbolic link would point at an existing file, the archive would likely contain a copy of that file instead of the symbolic link, possibly making what should be a backup defective as you wouldn't get the exact same contents back when unpacking it. I'll set the CONFIRMED status, but there are some considerations here: - Part of the issue surely belongs here as error handling in Ark is apparently lacking, likely as a result of an external program being executed instead of everything being done in KIO as more typical - 7z not being Linux friendly is not really a KDE problem, although it's surely a UX issue. It's an interesting problem how failure should be handled as it may be considered okay in some cases. Seems like there was a temporary push towards official Linux support in the 7-Zip project, but doesn't seem like it got far: https://sourceforge.net/p/sevenzip/discussion/45797/thread/cec5e63147/ -- You are receiving this mail because: You are watching all bug changes.
[krusader] [Bug 457906] krusader is very slow with 7-zip 7zip 7z archives
https://bugs.kde.org/show_bug.cgi?id=457906 Pedro V changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|CONFIRMED CC||voidpointertonull+bugskdeor ||g...@gmail.com --- Comment #2 from Pedro V --- Already dug into the issue somewhat in Bug #422142 , but I'll partially reiterate what's there with more focus on Krusader. Aside from the K7zip implementation not looking like it's suitable for fast browsing, I'm not even sure if that's being used, and if it is, then that means that the file list is processed multiple times. Apparently there's a sneaky `bool check7zEncrypted = true` default option for checking archives because someone figured that `// encryption check is expensive, check only if it's necessary`, but it doesn't look like this is ever avoided. The price comes from running the external 7z executable to get a full list of files with details included. I also had the suspicion that this keeps on being done when moving around within the archive, and running `KDE_FORK_SLAVES=true krusader -d` shows output that suggests it may be the case, but I haven't seen enough to be confident. While 7z handling doesn't seem to be great overall in KDE, Krusader seems to be special with its own odd problems added. -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 422142] kioslave5 process causes high cpu usage while Dolphin opens an archive as folder
https://bugs.kde.org/show_bug.cgi?id=422142 Pedro V changed: What|Removed |Added Status|REPORTED|CONFIRMED CC||voidpointertonull+bugskdeor ||g...@gmail.com Ever confirmed|0 |1 --- Comment #2 from Pedro V --- The report isn't exactly great as it's mixing together multiple issues, some not even really KDE related, but some could be surely improved. Skipping zip as I don't tend to encounter particularly large zip files and it seems to be left behind in the "compression race", so will address only the other two. Tar: Bad news here, this is unlikely to be ever the format you'll quickly browse as it doesn't have a file index, so the whole archive needs to be scanned AND in the case of tar.gz even uncompressed which is going to be a whole lot of work just to list files. This is unlikely to get any better, attempts to introduce a file index to the tar format didn't seem to succeed, so the mind boggling part for me is that we still didn't move on to a different format. 7z: Couldn't test with Dolphin specifically as it's not into opening the test file, and stuffing it into the URL gets me a "Could not open the file, probably due to an unsupported file format." message with "sevenz:" getting prepended to the URL. Krusader and Ark however shows something surprising, the external 7z executable is used to get the WHOLE file list. Apparently that's not just I/O intensive due to being a wasteful strategy, but it surely pegs a CPU core for a while. Not really sure why isn't the k7zip implementation of karchive being used, but looking at K7Zip::openArchive I'm not sure it would be faster. This could be definitely improved. In this case kioslave5 should only show up as the CPU hog if K7Zip would be used for listing which isn't the case for me, I'm seeing the 7z process which is used to list the contents. Looking at the bug being assigned to kio-extras, there may be a tricky problem here with 7z: - If K7Zip browsing is slow, then that should belong there. I'm not sure if the whole file list really needs to be processed initially, but even ignoring that the code is surely not optimized to be able to deal with a whole lot of files. Can't compare right now, but in line with the Bug #457906 mention I can say that Total Commander makes 7z browsing quite fast. - The external 7z execution may not belong to kio-extras, that's likely done by the file/archive managers individually, at least I've found Krusader doing that. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 483137] Screencast plugin fails if PipeWire is started after KWin
https://bugs.kde.org/show_bug.cgi?id=483137 --- Comment #9 from Lamarque V. Souza --- I have found another workaround: Screencast works if I launch pipewire through a script in $HOME/.config/plasma-workspace/env/. In Gentoo the script is as simple as: /usr/bin/gentoo-pipewire-launcher & PS: there is no need for the script to be executable since plasma-session sources it. I also had to disable pipewire autostart by removing the file /etc/xdg/autostart/pipewire.desktop to avoid pipewire being restarted during startup. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 485828] Bluetooth mouse freezing until i unplug-replug phone from wall power socket that is connected to pc via kdeconnect. unplug-replug fixes bt mouse.
https://bugs.kde.org/show_bug.cgi?id=485828 --- Comment #1 from V --- mouse is a logitech m570 trackball if that helps -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 485828] New: Bluetooth mouse freezing until i unplug-replug phone from wall power socket that is connected to pc via kdeconnect. unplug-replug fixes bt mouse.
https://bugs.kde.org/show_bug.cgi?id=485828 Bug ID: 485828 Summary: Bluetooth mouse freezing until i unplug-replug phone from wall power socket that is connected to pc via kdeconnect. unplug-replug fixes bt mouse. Classification: Applications Product: kdeconnect Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: common Assignee: albertv...@gmail.com Reporter: knotina...@vivaldi.net CC: andrew.g.r.hol...@gmail.com Target Milestone: --- *** If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** SUMMARY Bluetooth mouse freezing until i unplug-replug phone from wall power socket with phone that is connected to pc via kdeconnect only. unplug-replug fixes bluetooth mouse connected to pc. STEPS TO REPRODUCE 1. wait til mouse freezes on usb hub (this doesn't occur if BT dongle is plugged directly into laptop, only the hub) and happens randonly. 2. unplug-replug phone power charging cable from wall outlet. 3. OBSERVED RESULT problem fixed when power cable plugged (until next freeze) EXPECTED RESULT standard bt mouse function regardless of whether phone is connected via kdeconnect SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Artix Linux, kernel 6.8.6-Artix1 (available in About System) KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 483137] Screencast plugin fails if PipeWire is started after KWin
https://bugs.kde.org/show_bug.cgi?id=483137 --- Comment #6 from Lamarque V. Souza --- Created attachment 168354 --> https://bugs.kde.org/attachment.cgi?id=168354=edit Revert commit 37d2a7914329c65361eedfd995f25bd6867b68bc for kwin 6.0.3.1 I have updated the revert patch to apply to kwin 6.0.3.1 so we can use screencast until the problem is properly fixed. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 482987] Bottom edge of screen has pixels that are held to the color of previously opened windows after closing those windows
https://bugs.kde.org/show_bug.cgi?id=482987 Lamarque V. Souza changed: What|Removed |Added CC||lamar...@kde.org -- You are receiving this mail because: You are watching all bug changes.
[ksysguard] [Bug 473052] System monitor grid style widget doesn't apply configured update interval to sensors
https://bugs.kde.org/show_bug.cgi?id=473052 Lamarque V. Souza changed: What|Removed |Added CC||lamar...@kde.org --- Comment #2 from Lamarque V. Souza --- It happens for me too. Operating System: Gentoo Linux 2.14 KDE Plasma Version: 6.0.2 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.6.16-lvs (64-bit) Graphics Platform: Wayland -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 483137] Screencast plugin fails if PipeWire is started after KWin
https://bugs.kde.org/show_bug.cgi?id=483137 Lamarque V. Souza changed: What|Removed |Added CC||lamar...@kde.org -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 483277] New: ComfyUi integration: no docker / function working except controlnet
https://bugs.kde.org/show_bug.cgi?id=483277
Bug ID: 483277
Summary: ComfyUi integration: no docker / function working
except controlnet
Classification: Applications
Product: krita
Version: 5.2.2
Platform: Microsoft Windows
OS: Microsoft Windows
Status: REPORTED
Severity: grave
Priority: NOR
Component: Dockers
Assignee: krita-bugs-n...@kde.org
Reporter: diego.vu...@gmail.com
Target Milestone: ---
SUMMARY
***
I've follow all the installation guidelines, enabled the ComfyUi plugin and all
the relevant dockers.
If I try to run any of the available feature (no matter if upscale, generate
etc) I always get an error.
Controlnet instead is working fine.
***
UPSCALE ERROR LOG:
JSONDecodeError
Python 3.10.7: C:\Program Files\Krita (x64)\bin\krita.exe
Mon Mar 11 19:29:36 2024
A problem occurred in a Python script. Here is the sequence of
function calls leading up to the error, in the order they occurred.
C:\Users\User\AppData\Roaming\krita\pykrita\krita_comfy\pages\upscale.py in
()
65 self.upscaler_layout.cfg_connect()
66 self.upscale_by.cfg_connect()
67 self.btn.released.connect(lambda: script.action_simple_upscale())
68 self.get_workflow_btn.released.connect(
69 lambda: get_workflow(script.cfg, script.action_get_workflow,
"upscale")
self undefined
global script =
script.action_simple_upscale = >
C:\Users\User\AppData\Roaming\krita\pykrita\krita_comfy\script.py in
action_simple_upscale(self=)
612 if not self.doc:
613 return
614 self.apply_simple_upscale()
615
616 def action_update_config(self):
self =
self.apply_simple_upscale = >
C:\Users\User\AppData\Roaming\krita\pykrita\krita_comfy\script.py in
apply_simple_upscale(self=)
461 self.client.images_received.disconnect(cb)
462
463 self.client.post_upscale(cb, sel_image)
464
465 def apply_get_workflow(self, mode):
self =
self.client =
self.client.post_upscale = >
cb = .cb>
sel_image =
C:\Users\User\AppData\Roaming\krita\pykrita\krita_comfy\client.py in
post_upscale(self=, cb=.cb>, src_img=)
1739 upscale_latent()
1740 else:
1741 params, _ =
self.run_injected_custom_workflow(self.cfg("upscale_workflow", str), 0,
"upscale", src_img)
1742
1743 if cb is None:
params = {}
_ undefined
self =
self.run_injected_custom_workflow = >
self.cfg =
builtinstr =
src_img =
C:\Users\User\AppData\Roaming\krita\pykrita\krita_comfy\client.py in
run_injected_custom_workflow(self=,
workflow='', seed=0, mode='upscale', src_img=,
mask_img=None, controlnet_src_imgs={}, resized_width=None, resized_height=None,
original_width=None, original_height=None)
1211 def run_injected_custom_workflow(self, workflow, seed, mode, src_img,
mask_img = None, controlnet_src_imgs = {},
1212 resized_width = None, resized_height
= None, original_width = None, original_height = None):
1213 params = self.restore_params(json.loads(workflow), src_img,
mask_img)
1214 ksampler_id = DEFAULT_NODE_IDS["KSampler"]
1215 positive_prompt_id = DEFAULT_NODE_IDS["ClipTextEncode_pos"]
params undefined
self =
self.restore_params = >
global json =
json.loads =
workflow = ''
src_img =
mask_img = None
C:\Program Files\Krita (x64)\json\__init__.py in loads(s='', cls=None,
object_hook=None, parse_float=None, parse_int=None, parse_constant=None,
object_pairs_hook=None, **kw={})
C:\Program Files\Krita (x64)\json\decoder.py in
decode(self=, s='', _w=)
C:\Program Files\Krita (x64)\json\decoder.py in
raw_decode(self=, s='', idx=0)
JSONDecodeError: Expecting value: line 1 column 1 (char 0)
__cause__ = None
__class__ =
__context__ = StopIteration(0)
__delattr__ =
__dict__ = {'colno': 1, 'doc': '', 'lineno': 1, 'msg': 'Expecting value',
'pos': 0}
__dir__ =
__doc__ = None
__eq__ =
__format__ =
__ge__ =
__getattribute__ =
__gt__ =
__hash__ =
__init__ =
__init_subclass__ =
__le__ =
__lt__ =
__module__ = 'json.decoder'
__ne__ =
__new__ =
__reduce__ =
__reduce_ex__ =
__repr__ =
__setattr__ =
__setstate__ =
__sizeof__ =
__str__ =
__subclasshook__ =
__suppress_context__ = True
__traceback__ =
__weakref__ = None
args = ('Expecting value: line 1 column 1 (char 0)',)
colno = 1
doc = ''
lineno = 1
msg = 'Expecting value'
pos = 0
with_traceback =
The above is a description of an error in a Python program. Here is
the original traceback:
Traceback (most recent call last):
File
"C:\Users\User\AppData\Roaming\krita\pykrita\krita_comfy\pages\upscale.py",
line 67, in
self.btn.released.connect(lambda:
[plasmashell] [Bug 482828] Task Manager icons disappear/move to the left when mouse is moved over them
https://bugs.kde.org/show_bug.cgi?id=482828 --- Comment #4 from Lamarque V. Souza --- I use Intel gpu for Plasma 5 and 6. I had tried to make Plasma 5 (kwin_wayland) use the nvidia gpu in the past with no success. However, I have tested with a new user and it does not have this problem. So I did a backup of my entire $HOME/.config folder, copied that user's configuration files over my configuration files and that solved that particular problem. After that I restored some configuration files from the backup, redid some other configurations and that is it: Plasma 6 is working better than Plasma 5 now. I does not know which configuration fixed the problem for me though. I guess everybody should test with a new user to make sure it is not just a configuration problem. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 482828] Task bar/panel icons disappear when mouse is moved over them
https://bugs.kde.org/show_bug.cgi?id=482828 Lamarque V. Souza changed: What|Removed |Added CC||lamar...@kde.org --- Comment #2 from Lamarque V. Souza --- Same here with Gentoo. I own a dual gpu notebook (intel + nvidia). I have removed all offloading to nvidia configuration and still the same problem. The glitches looks like kwin_wayland 6 is using software rendering. Everything used to work with kwin_wayland 5. Version === KWin version: 6.0.1 Qt Version: 6.6.2 Qt compile version: 6.6.2 XCB compile version: 1.16 Operation Mode: Xwayland Build Options = KWIN_BUILD_DECORATIONS: yes KWIN_BUILD_TABBOX: yes KWIN_BUILD_ACTIVITIES: yes HAVE_X11_XCB: yes HAVE_GLX: yes X11 === Vendor: The X.Org Foundation Vendor Release: 12302004 Protocol Version/Revision: 11/0 SHAPE: yes; Version: 0x11 RANDR: yes; Version: 0x14 DAMAGE: yes; Version: 0x11 Composite: yes; Version: 0x4 RENDER: yes; Version: 0xb XFIXES: yes; Version: 0x50 SYNC: yes; Version: 0x31 GLX: yes; Version: 0x0 Decoration == Plugin: org.kde.breeze Theme: Plugin recommends border size: None onAllDesktopsAvailable: false alphaChannelSupported: true closeOnDoubleClickOnMenu: false decorationButtonsLeft: 5, 1 decorationButtonsRight: 3, 4 borderSize: 2 gridUnit: 10 font: Noto Sans,9,-1,5,400,0,0,0,0,0,0,0,0,0,0,1 smallSpacing: 2 largeSpacing: 10 Output backend == Name: DRM Atomic Mode Setting on GPU 0: true Cursor == themeName: ComixCursors-custom themeSize: 24 Options === focusPolicy: FocusFollowsMouse xwaylandCrashPolicy: 1 xwaylandMaxCrashCount: 3 nextFocusPrefersMouse: true clickRaise: true autoRaise: false autoRaiseInterval: 750 delayFocusInterval: 100 shadeHover: false shadeHoverInterval: 250 separateScreenFocus: false activeMouseScreen: true placement: 4 activationDesktopPolicy: SwitchToOtherDesktop focusPolicyIsReasonable: true borderSnapZone: 10 windowSnapZone: 10 centerSnapZone: 0 snapOnlyWhenOverlapping: false rollOverDesktops: false focusStealingPreventionLevel: 0 operationTitlebarDblClick: 5000 operationMaxButtonLeftClick: 5000 operationMaxButtonMiddleClick: 5015 operationMaxButtonRightClick: 5014 commandActiveTitlebar1: MouseRaise commandActiveTitlebar2: MouseNothing commandActiveTitlebar3: MouseOperationsMenu commandInactiveTitlebar1: MouseActivateAndRaise commandInactiveTitlebar2: MouseNothing commandInactiveTitlebar3: MouseOperationsMenu commandWindow1: MouseActivateRaiseAndPassClick commandWindow2: MouseActivateAndPassClick commandWindow3: MouseActivateAndPassClick commandWindowWheel: MouseNothing commandAll1: MouseUnrestrictedMove commandAll2: MouseToggleRaiseAndLower commandAll3: MouseUnrestrictedResize keyCmdAllModKey: 16777251 condensedTitle: false electricBorderMaximize: true electricBorderTiling: true electricBorderCornerRatio: 0.25 borderlessMaximizedWindows: false killPingTimeout: 5000 hideUtilityWindowsForInactive: true compositingMode: 1 useCompositing: true hiddenPreviews: 1 glSmoothScale: 1 glStrictBinding: true glStrictBindingFollowsDriver: true glPreferBufferSwap: AutoSwapStrategy glPlatformInterface: 2 windowsBlockCompositing: true allowTearing: true Screen Edges desktopSwitching: false desktopSwitchingMovingClients: false cursorPushBackDistance: 1x1 timeThreshold: 100 reActivateThreshold: 200 actionTopLeft: 0 actionTop: 0 actionTopRight: 0 actionRight: 0 actionBottomRight: 0 actionBottom: 0 actionBottomLeft: 0 actionLeft: 0 Screens === Active screen follows mouse: yes Number of Screens: 3 Screen 0: - Name: eDP-1 Enabled: 1 Geometry: 3840,0,1920x1080 Scale: 1 Refresh Rate: 60020 Adaptive Sync: incapable Screen 1: - Name: DP-1 Enabled: 1 Geometry: 1920,0,1920x1080 Scale: 1 Refresh Rate: 6 Adaptive Sync: incapable Screen 2: - Name: DP-2 Enabled: 1 Geometry: 0,0,1920x1080 Scale: 1 Refresh Rate: 6 Adaptive Sync: incapable Compositing === Compositing is active Compositing Type: OpenGL OpenGL vendor string: Intel OpenGL renderer string: Mesa Intel(R) HD Graphics 530 (SKL GT2) OpenGL version string: 4.6 (Core Profile) Mesa 23.3.6 OpenGL platform interface: EGL OpenGL shading language version string: 4.60 Driver: Intel GPU class: Skylake OpenGL version: 4.6 GLSL version: 4.60 Mesa version: 23.3.6 X server version: 1.23.2 Linux kernel version: 6.6.16 Direct rendering: Requires strict binding: no Virtual Machine: no OpenGL 2 Shaders are used Loaded Effects: --- thumbnailaside screenshot outputlocator colorpicker zoom screenedge mousemark blur contrast sessionquit logout login slidingpopups windowaperture slide morphingpopups frozenapp fullscreen maximize squash scale fadingpopups dialogparent windowview tileseditor overview highlightwindow blendchanges startupfeedback screentransform kscreen Currently Active Effects: - blur
[skrooge] [Bug 476591] Part of the skrooge flatpak's user interface is not translated and remains in English
https://bugs.kde.org/show_bug.cgi?id=476591 --- Comment #8 from Jean-Pierre V --- Hi Skierpage, I confirm your point : adding this symlink to org.kde.skrooge makes skrooge works perfectly in French. So there is a weird thing in the process of building this package. To me it is not only for the french language, in the skrooge gitlab/po repository you have about 43 languages available. However only 19 symlinks available in the ./files/share/locale/ directory... strange. I am not skilled enough to help ... hope some experts can help. Thanks for the fix JP -- You are receiving this mail because: You are watching all bug changes.
[skrooge] [Bug 476591] Part of the skrooge flatpak's user interface is not translated and remains in English
https://bugs.kde.org/show_bug.cgi?id=476591 --- Comment #6 from Jean-Pierre V --- May be it can help : If I type the below commands , I cannot see any link to the french locale, would it be a reason ? flatpak run --command=bash org.kde.skrooge Then [ org.kde.skrooge locale] cd /app/share/locale [ org.kde.skrooge locale]$ ls -l total 8 lrwxrwxrwx 1 nfsnobody nfsnobody 47 24 févr. 15:06 ca@valencia -> ../../share/runtime/locale/ca/share/ca@valencia lrwxrwxrwx 1 nfsnobody nfsnobody 38 24 févr. 15:06 da -> ../../share/runtime/locale/da/share/da drwxr-xr-x 3 nfsnobody nfsnobody 4096 1 janv. 1970 en_GB drwxr-xr-x 3 nfsnobody nfsnobody 4096 1 janv. 1970 en_US lrwxrwxrwx 1 nfsnobody nfsnobody 38 24 févr. 15:06 eu -> ../../share/runtime/locale/eu/share/eu lrwxrwxrwx 1 nfsnobody nfsnobody 38 24 févr. 15:06 fi -> ../../share/runtime/locale/fi/share/fi lrwxrwxrwx 1 nfsnobody nfsnobody 38 24 févr. 15:06 ga -> ../../share/runtime/locale/ga/share/ga lrwxrwxrwx 1 nfsnobody nfsnobody 38 24 févr. 15:06 gl -> ../../share/runtime/locale/gl/share/gl lrwxrwxrwx 1 nfsnobody nfsnobody 38 24 févr. 15:06 ia -> ../../share/runtime/locale/ia/share/ia lrwxrwxrwx 1 nfsnobody nfsnobody 38 24 févr. 15:06 ja -> ../../share/runtime/locale/ja/share/ja lrwxrwxrwx 1 nfsnobody nfsnobody 38 24 févr. 15:06 ko -> ../../share/runtime/locale/ko/share/ko lrwxrwxrwx 1 nfsnobody nfsnobody 38 24 févr. 15:06 mr -> ../../share/runtime/locale/mr/share/mr lrwxrwxrwx 1 nfsnobody nfsnobody 38 24 févr. 15:06 ms -> ../../share/runtime/locale/ms/share/ms lrwxrwxrwx 1 nfsnobody nfsnobody 40 24 févr. 15:06 nds -> ../../share/runtime/locale/nds/share/nds lrwxrwxrwx 1 nfsnobody nfsnobody 41 24 févr. 15:06 pt_BR -> ../../share/runtime/locale/pt/share/pt_BR lrwxrwxrwx 1 nfsnobody nfsnobody 38 24 févr. 15:06 ug -> ../../share/runtime/locale/ug/share/ug lrwxrwxrwx 1 nfsnobody nfsnobody 41 24 févr. 15:06 zh_CN -> ../../share/runtime/locale/zh/share/zh_CN lrwxrwxrwx 1 nfsnobody nfsnobody 41 24 févr. 15:06 zh_TW -> ../../share/runtime/locale/zh/share/zh_TW -- You are receiving this mail because: You are watching all bug changes.
[skrooge] [Bug 476591] Part of the skrooge flatpak's user interface is not translated and remains in English
https://bugs.kde.org/show_bug.cgi?id=476591 --- Comment #5 from Jean-Pierre V --- Created attachment 166126 --> https://bugs.kde.org/attachment.cgi?id=166126=edit Skrooge screenshot with a native installation (via pacman) To show what it should be -- You are receiving this mail because: You are watching all bug changes.
[skrooge] [Bug 476591] Part of the skrooge flatpak's user interface is not translated and remains in English
https://bugs.kde.org/show_bug.cgi?id=476591 --- Comment #4 from Jean-Pierre V --- (In reply to skierpage from comment #3) > Created attachment 166122 [details] > incomplete localization of the Skrooge flatpak from flathub Yes exactly ! confirm , same screenshot you sent ! The menu items "configuration" and "aide" are in French as well as the second line (Nouveau/ouvrir) whereas the others menu items remain in English. As we can see in your screenshot the items (DashBoard, Accounts, ) remains also in English. I will send a screenshot of a native installation of skrooge (pacman -Syu skrooge on Arch Linux) where everything is translated to compare. Thanks JP -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 456515] Ring my phone not working
https://bugs.kde.org/show_bug.cgi?id=456515 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[frameworks-networkmanager-qt] [Bug 464615] Support Enhanced Open (OWE) Wi-Fi security option
https://bugs.kde.org/show_bug.cgi?id=464615 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 469819] kbd_backlight restored to wrong value after lid close-open
https://bugs.kde.org/show_bug.cgi?id=469819 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 476600] Selecting files in klipper does not make them available to xdg-desktop-portal
https://bugs.kde.org/show_bug.cgi?id=476600 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 432143] ssh config file with "includes" not taken into account
https://bugs.kde.org/show_bug.cgi?id=432143 Pedro V changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #7 from Pedro V --- While the recently described issue can be considered a subset of the original problem, it's already being tracked by Bug 475638 . The other bug report is specifically about the problem that still exists which helps with keeping noise down, therefore I recommend tracking that, and I believe this report should be closed instead of being turned into a duplicate report. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 453756] Location bar resets after several seconds when typing
https://bugs.kde.org/show_bug.cgi?id=453756 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com --- Comment #29 from Pedro V --- Does the location bar seem to track changes in the directory? Suspected a TOCTOU problem, but in my case autocompletion seems to read the contents of the directory once, then it doesn't care about any changes at all, new directories don't appear in /tmp while at least "/t" is in the URL, have to get to just "/" so it starts autocompleting there, then getting back to "/tmp/" refreshes the cache. KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Attempted to reproduce with the following ran as root which should be similar to what Docker (actually runc) appears to be doing: rm -rf /tmp/dolphintest; while :; do mkdir /tmp/dolphintest; chmod 2700 /tmp/dolphintest; sleep 1; rm -rf /tmp/dolphintest; sleep 1; done Directory content tracking tends to break though after heavy I/O, so checked on another system too which was only likely used, but autocompletion seems to be "sticky" there too, so I'm really wondering if I'm going in the wrong direction, or autocompletion updates with changes for others. -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 475638] using include in ssh config doesn't traverse all includes, only the first
https://bugs.kde.org/show_bug.cgi?id=475638
Pedro V changed:
What|Removed |Added
Status|REPORTED|CONFIRMED
CC||voidpointertonull+bugskdeor
||g...@gmail.com
Ever confirmed|0 |1
--- Comment #1 from Pedro V ---
Can confirm, likely an upstream (libssh) issue, although it seems to be capable
of processing multiple includes, and I'm really not seeing what's the logical
problem preventing it.
Suspecting a corrupt state returning from include directive processing and
looking for some extra noise between the 2 includes, ended up with the
following config:
```
Include ~/.ssh/config0
Host test
HostKeyAlias test
Include ~/.ssh/config1
```
Running `KIO_SFTP_LOG_VERBOSITY=10 KDE_FORK_SLAVES=1
QT_LOGGING_RULES="log_kio_sftp=true;kf.kio.workers.sftp=true;" krusader` , got
the following output:
```
kf.kio.workers.sftp: list directory: QUrl("sftp://test1;)
kf.kio.workers.sftp: checking cache: info.username = "" , info.url =
"sftp://test1;
kf.kio.workers.sftp:
kf.kio.workers.sftp: Creating the SSH session and setting options
kf.kio.workers.sftp: [ ssh_config_parse_file ] ( 3 ) ssh_config_parse_file:
Reading configuration data from /home/user/.ssh/config
kf.kio.workers.sftp: [ local_parse_file ] ( 3 ) local_parse_file: Reading
additional configuration data from /home/user/.ssh/config0
kf.kio.workers.sftp: [ ssh_config_parse_line ] ( 2 ) ssh_config_parse_line:
Unsupported option: HostKeyAlias, line: 3
```
SOC_INCLUDE appears to be correctly excluded from the seen[opcode] check,
suspecting the parsing variable to be handled silly.
Looking for a way to reset it, I cooked up:
```
Include ~/.ssh/config0
Match user user
HostKeyAlias test
Include ~/.ssh/config1
```
With that, connecting to sftp://user@test1 (note the inclusion of the
username!) succeeds as the parsing of the second inclusion isn't skipped
anymore:
```
kf.kio.workers.sftp: [ ssh_config_parse_file ] ( 3 ) ssh_config_parse_file:
Reading configuration data from /home/user/.ssh/config
kf.kio.workers.sftp: [ local_parse_file ] ( 3 ) local_parse_file: Reading
additional configuration data from /home/user/.ssh/config0
kf.kio.workers.sftp: [ ssh_config_parse_line ] ( 4 ) ssh_config_parse_line:
line 2: Processing Match keyword 'user'
kf.kio.workers.sftp: [ ssh_config_match ] ( 4 ) ssh_config_match: Matched
'user' against pattern 'user' (ok=1)
kf.kio.workers.sftp: [ ssh_config_parse_line ] ( 2 ) ssh_config_parse_line:
Unsupported option: HostKeyAlias, line: 3
kf.kio.workers.sftp: [ local_parse_file ] ( 3 ) local_parse_file: Reading
additional configuration data from /home/user/.ssh/config1
```
--
You are receiving this mail because:
You are watching all bug changes.
[kio-extras] [Bug 480547] Cannot connect to remote servers from .ssh/config/ that don't use a resolvable hostname as an identifier
https://bugs.kde.org/show_bug.cgi?id=480547 Pedro V changed: What|Removed |Added Component|net-connection |SFTP Status|REPORTED|CONFIRMED Ever confirmed|0 |1 Version|2.7.2 |unspecified Assignee|krusader-bugs-n...@kde.org |plasma-b...@kde.org CC||voidpointertonull+bugskdeor ||g...@gmail.com Product|krusader|kio-extras --- Comment #1 from Pedro V --- Initially I wanted to just conclude that it's a works for me kind of matter, but although the IP address you provided is not valid, I figured the friendly hostname pattern was deliberate, so I gave that a try. It turns out that the problem is with the underscore, can reproduce seeing the 3 line error message that way. The issue doesn't appear without special characters or for example dash being used as a separator. Can also reproduce the issue with Dolphin, so not likely to be specific to Krusader, it's more likely to be a KIO (slave) problem. KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 -- You are receiving this mail because: You are watching all bug changes.
[krusader] [Bug 451343] Krusader does not show copy progress unless run as su
https://bugs.kde.org/show_bug.cgi?id=451343 Pedro V changed: What|Removed |Added Status|NEEDSINFO |RESOLVED --- Comment #4 from Pedro V --- Wishing you luck in getting it going again, it's one of the major reasons why I could conveniently switch from Windows, even though Total Commander had more features, but Krusader is still decent at file management. Recently (unfortunately) I got to see that Krusader is still persistent at showing notifications as the infamous RDNA2 VCN hanging bug brought down most of my desktop environment, so Krusader started opening progress windows without being able to show native notifications, so I think the feature is all right. I don't think I can close bugs, possibly you as the bug opener can do it though. Setting RESOLVED to get it out of the way, expecting someone with the right privilege to set CLOSED status eventually. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 211416] Optimise kde performance on nfs
https://bugs.kde.org/show_bug.cgi?id=211416 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com --- Comment #26 from Pedro V --- I feel like this can be merged into the more generic Bug #293888 and/or Bug #178678 as the mentioned issues are not NFS specific. A lot of mentioned problems should be already long gone already. The only part that's still around is KDE components getting bottlenecked by latency which is usually experienced with either high network latency, or an overloaded server (high CPU usage, HDD, heavy I/O usage). NFS with a nearby server is pretty decent nowadays as long as the server remains responsive, at least I have no complaints even with an HDD share as long as I don't start an I/O heavy workload. I mostly use Krusader though which is lighter than for example Dolphin which by default even digs into subdirectories. -- You are receiving this mail because: You are watching all bug changes.
[krusader] [Bug 462922] List of available media needs improvements
https://bugs.kde.org/show_bug.cgi?id=462922 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com --- Comment #1 from Pedro V --- This should have a wishlist priority as it's not exactly a bug. Please adjust the "Importance" part (if you can). Just ran into a relevant option while exploring settings and I remembered bug report(s?) desiring such features. At least a SquashFS filter was already available at the time of report: https://invent.kde.org/utilities/krusader/-/commit/9d80bd9f4d8251550a1311c4851de7fa919a104e The reproducer is insufficient though, it's important to mention the use of Snap and Docker. The former is unwelcome on a lot of systems so I wouldn't take it granted to see it somewhere, and the later is less noisy and not everyone uses it. For example I don't have Snap, and I'm using Podman instead of Docker with multiple containers running even right now, and the list isn't that horrifying, even though it's surely strange for me too: - NFS mounts are shown 3 times each with each entry having a different icon, but only 1 working, the other 2 just showing errors when selected - LUKS entries, 1 showing an error on selection, the other one working, but being redundant Aside from the oddities I've mentioned which don't really make much sense as they are not even usable, generally the concern is not breaking others' workflow which is likely why the SquashFS filtering isn't enabled by default either. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 293888] Poor performance with mounted network locations
https://bugs.kde.org/show_bug.cgi?id=293888 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com --- Comment #40 from Pedro V --- Isn't this supposed to be part of the more generic Bug #178678 ? Although the title makes it seem like it's Dolphin-specific, that's just the worst offender and the bug report was turned into a general KIO issue. (In reply to flan_suse from comment #39) > KDialog is hilariously slow, even for local filesystems. (Slow for network > locations *and* local. It's just more noticeable for network shares.) The issue is with latency-bound I/O strategies. It should be really uncommon locally unless you are looking at an HDD which happens to get quite a bit of usage elsewhere too. The file picker appears to show mounts, so it should be still affected by the problems of mounted network locations. Not sure how often does that info get refreshed, but just a single mount not responding or being too slow can negatively effect user experience as discussed in Bug #454722 . -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 178678] Navigating mounted network locations is extremely slow in Dolphin compared to command line
https://bugs.kde.org/show_bug.cgi?id=178678 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com Status|REPORTED|CONFIRMED Ever confirmed|0 |1 --- Comment #103 from Pedro V --- (In reply to Germano Massullo from comment #101) > I think it's the client system triggering too much I/O on the server because > it tries to retrieve as much data as possible from the remote folders. This > is not happening when using Krusader Krusader is still not immune to such issues as others mentioned earlier already, it just gets significantly less information compared to Dolphin with default configuration which even goes into subdirectories, so it can be really excessive. (In reply to Harald Sitter from comment #70) > Alas, can't reproduce. The key which was mentioned here already is high latency, that's a significant problem elsewhere too in KDE, mostly because: - A whole lot of I/O operations are done one by one and with high latency that becomes really obvious. A simple example of that problem is observing the SFTP KIO slaving dealing with a directory with symbolic links over a high latency connection where an strace on sshd can show the stat(x) calls being issued rather slowly with the latency penalty. - Apparently there's no progressive file listing, and getting information does block the GUI Theoretically this doesn't even really need networking to reproduce, it's just easier with that as it adds more latency and I suspect that no helpful I/O scheduler can get in the way of getting high latency. Currently I can experience this with high latency not caused by the network, but by accessing an HDD over NFS which is under heavy load not by just the test host which definitely makes it worse, but hammering it just with one host already makes the experience bad. Do note that caching definitely gets in the way of reproducing the issue, so I'll address that. Given the previously mentioned conditions, looking at a directory with 30k+ files where new files are slowly being created. Didn't measure first listing attempt, but likely that's not the best anyway, so let's assume a hot cache which gets the following experiences: - `ls -la`: <1 s, reasonably fast - Krusader: <2 s, still pretty decent although with the files on the top not changing, and starting scrolling starts to make the UI unresponsive. One large scroll with the mouse, and it's just gone for some time, although still just for seconds. - Dolphin: ? s. At one point it starts showing the files, but due to the occasional creation of new files it never becomes usable, although it does show changes occasionally There should be quite a few ways of reproducing even with let's say a local HDD being scrubbed, or worse, defragmented while testing. The tricky part is that without file changes various caching strategies and even the I/O scheduler is likely to get in the way, but with file changes other bugs may be at play too: - At least with Krusader the tracking of directory contents tend to fall apart mostly after heavy I/O until reboot. This most commonly affects NFS mounts for me, but happened multiple times already after handling directories with a ton of files. What I tend to notice is not all deleted files disappearing from the list. Not sure how it is to this issue, but mentioning as it may matter. - Quite rare, but I just recently happened to have gam_server pegging a core, Krusader staying unresponsive until gam_server got killed. I'm not really familiar with Gamin, I'm not even sure if it's actually needed or I'd be better off removing it as it's apparently optional, but reading around, it seems to be a troublemaker for others too which could mess with testing. -- You are receiving this mail because: You are watching all bug changes.
[baloo-widgets] [Bug 423502] FileFetchJob::doStart causes intermittent gui blocks
https://bugs.kde.org/show_bug.cgi?id=423502 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 454722] Dolphin Not Responding When NFS Mounted Shares OffLine
https://bugs.kde.org/show_bug.cgi?id=454722 Pedro V changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|CONFIRMED CC||voidpointertonull+bugskdeor ||g...@gmail.com --- Comment #4 from Pedro V --- (In reply to battyanyi.dani from comment #1) > I have the same issue. It looks like dolphin tries to mount the unavailable > network share each time it loads a new directory. As a Krusader fan I can say that the issue is not limited to just Dolphin, and I don't think the issue is with mounting as an already mounted share becoming unresponsive is also causing such issues. It's likely to be a matter of either both Dolphin and Krusader trying to get info on mounts in the background for something like disk usage measurement, or KIO is serving too much information somewhere, poking all mounts even when not desired. (In reply to SoftExpert from comment #3) > I don't understand why this is getting so little attention - wouldn't this > impacting everyone ? Unlikely to be common at least on the local network. My rather weak server sharing a slow HDD is not affected in normal circumstances, it only gets slow when I'm well aware I'm abusing it with I/O. Other than that I use the SFTP KIO slave for high latency targets which is surely slow, but by not being a mount it doesn't exhibit this issue. The issue possibly got better over time with the addition of some timeout, or I just happened to be "lucky" because the share wasn't in use so the symptoms weren't severe last time I've seen it. It would be interesting to confirm though whether my Krusader usage mattered there and Dolphin still freezes. Although I haven't used Dolphin last time, confirming the issue because it's a known problem, and I happened to "enjoy" waiting for timeouts quite recently with Krusader as I was messing with the network making the mounted NFS share's server unavailable. Operating System: Kubuntu 23.10 KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.10 Kernel Version: 6.5.0-15-generic (64-bit) -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 396335] Gaming mouse loses configuration after booting windows, is restored by reconnecting it again
https://bugs.kde.org/show_bug.cgi?id=396335 Pedro V changed: What|Removed |Added Resolution|--- |WAITINGFORINFO CC||voidpointertonull+bugskdeor ||g...@gmail.com Status|REPORTED|NEEDSINFO --- Comment #1 from Pedro V --- I don't think this is relevant to KDE and likely that's why it didn't get attention at all. Is this still a problem to begin with? You skipped describing the behavior of booting straight into Linux, but I suspect it's the same as what happens when the mouse gets plugged in while Linux is running. If that's the case, then the problem is not even with Linux, you should encounter the same problem even by just booting into a different Windows setup without the mouse specific driver Generally it sounds like that the Windows driver leaves the hardware in a dirty state or it intentionally does some kind of reset when exiting which is surprisingly common mostly with "gaming" devices and lighting control. In that case there are the following possible cases: - Most desirably the faulty Windows driver logic would get fixed because that's the source of the problem after all - If there's a hardware specific driver in Linux for the device, then a workaround can be added there, although it likely won't be desired if the problem is really caused by just software The reproducer description is likely insufficient though. I happen to have a Logitech "gaming" mouse, and taking advantage of it storing configuration on the hardware, I made sure to only use the manufacturer bloatware in a Windows VM but not anywhere else, and although I mostly used virtualization instead of dual booting, I haven't experienced the described issue, so I suspect it doesn't happen when there's no manufacturer software running anywhere and the mouse is just merely treated as a USB HID device. -- You are receiving this mail because: You are watching all bug changes.
[krusader] [Bug 434538] Add options to "Copy" dialog window: overwrite rules and other possible options
https://bugs.kde.org/show_bug.cgi?id=434538 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com --- Comment #5 from Pedro V --- This could be potentially turned into a more generic problem of operations stalling waiting for user interaction. My occasional issue is similar, but I tend to encounter it with the Synchronize Folders function as it whines about not being able to access files rsync had no problem making. It's not just quite tiresome to keep on dismissing the error popup that can be only dismissed anyway, but the process also tends to be quite slow with a lot of small files due to the likely sequential processing with synchronous I/O, so it's not uncommon that the host is left on its own while it's working, but it gets stuck on such a prompt. I used to use Total Commander which had a kind of a fix for at least the reported problem. Wasn't optimal, but the first time it wanted to overwrite a file, it had an option to automatically overwrite all the following files too, basically what's mentioned in Comment 1. It didn't have a solution for error popups though, likely the assumption was that they were rare, and it was also faster to enumerate smaller files despite the infamously slow Windows I/O, so it likely used a more efficient I/O strategy, therefore the error popups were less of a problem especially on HDDs. The lowest hanging fruits are the already mentioned ones, but this could be also solved by moving file entries into a user interactivity queue when they need attention while continuing to process other files, and as the user would process prompts, the entries would be either discarded or moved back depending on what the user desires. -- You are receiving this mail because: You are watching all bug changes.
[krusader] [Bug 423451] Exclude state (dynamic) config info from krusaderrc to separate file, for allow sync Krusader settings via file between computers
https://bugs.kde.org/show_bug.cgi?id=423451 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[krusader] [Bug 451343] Krusader does not show copy progress unless run as su
https://bugs.kde.org/show_bug.cgi?id=451343 Pedro V changed: What|Removed |Added Resolution|--- |WORKSFORME Status|REPORTED|NEEDSINFO CC||voidpointertonull+bugskdeor ||g...@gmail.com --- Comment #1 from Pedro V --- Can you confirm that this is still an issue? That 4.14.8 Plasma version is suspiciously way too old for even 2022, and with the more appropriate 5.x versions I haven't seen such issues even back in 2022 on multiple hosts. Even when plasmashell crashed, Krusader just started opening its own windows to show progress. -- You are receiving this mail because: You are watching all bug changes.
[krusader] [Bug 452682] KRUSADER: Copying to drives or network shares that report wrong free space should have a override option (force copy)
https://bugs.kde.org/show_bug.cgi?id=452682 Pedro V changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|CONFIRMED CC||voidpointertonull+bugskdeor ||g...@gmail.com --- Comment #1 from Pedro V --- There isn't even a need for wrong free space reporting, I ran into the frustrating lack of this feature in a different context. Wanted to update a large directory with rsync, but desired to have a backup first both for safety and for checking differences later. Given that I'm using Btrfs, I opted to (ab)use CoW by doing a "ghetto backup" by just simply copying the whole directory as reflinks are quite cheap. Problem was that Krusader figured that I don't have the hundreds of GiBs of free space it would take to make a copy without reflinks, so it just didn't let me do that. Bonus: It's sometimes undesired to go through the files to begin with as that could introduce a large delay before starting to do the desired copy operation, and if that's not done, then there's obviously no checking for space. If I remember well I observed these solutions in Total Commander: - The free space problem could be just ignored as it's requested here - The initial enumeration of files could be interrupted so the user could get rid of the extra feature conveniently - The initial enumeration of files could be completely disabled -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 432143] ssh config file with "includes" not taken into account
https://bugs.kde.org/show_bug.cgi?id=432143 Pedro V changed: What|Removed |Added Status|REPORTED|NEEDSINFO Resolution|--- |WORKSFORME --- Comment #3 from Pedro V --- Seems to be working with KDE Frameworks 5.110.0 . It wasn't likely to be a Krusader problem to begin with as that just uses KIO (and extras) where the SFTP slave is a wrapper for libssh. Figured that this would be yet another libssh problem as its options support is quite spotty, but apparently it supported Include well before the bug report, so theoretically it should have worked already. Not sure why did the issue happened back then, but I can't reproduce it, so assuming that something was fixed after all. -- You are receiving this mail because: You are watching all bug changes.
[krusader] [Bug 471363] Mkdir FN bar button does not do tilde expansion
https://bugs.kde.org/show_bug.cgi?id=471363 Pedro V changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 CC||voidpointertonull+bugskdeor ||g...@gmail.com --- Comment #1 from Pedro V --- Interesting, didn't even know that Mkdir could do more than just creating a directory in the current directory, but `test/test` works creating a nested directory, and even `../test` works creating a directory outside the current one. Even absolute paths work like `/home/username/test` , therefore I'd conclude that the user is right to expect tilde expansion to also work, but I can confirm in the following environment that it doesn't: Operating System: Kubuntu 23.10 KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.10 It's still not necessarily a bug as tilde expansion is a feature which is definitely not universally supported, therefore I believe that importance should be set to wishlist. -- You are receiving this mail because: You are watching all bug changes.
[krusader] [Bug 470866] Krusader opens terminal application in wrong language
https://bugs.kde.org/show_bug.cgi?id=470866 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com --- Comment #1 from Pedro V --- I don't even dare to try to reproduce it the problem, but the wanting English but no US-specific silly baggage is a familiar problem, and I ended up with /etc/default/locale containing: ``` # File generated by update-locale LANG=C.UTF-8 LC_NUMERIC="C.UTF-8" LC_TIME="C.UTF-8" LC_MONETARY="C.UTF-8" LC_PAPER="C.UTF-8" LC_NAME="C.UTF-8" LC_ADDRESS="C.UTF-8" LC_TELEPHONE="C.UTF-8" LC_MEASUREMENT="C.UTF-8" LC_IDENTIFICATION="C.UTF-8" ``` Not sure where else are locale options could be hiding, maybe there was something user-specific I nuked trying to solve these kind of problems, but I ended up with the locale command showing: ``` LANG=en_US.UTF-8 LANGUAGE=en_US LC_CTYPE="en_US.UTF-8" LC_NUMERIC=C.UTF-8 LC_TIME=C LC_COLLATE="en_US.UTF-8" LC_MONETARY=C.UTF-8 LC_MESSAGES="en_US.UTF-8" LC_PAPER=C.UTF-8 LC_NAME=C.UTF-8 LC_ADDRESS=C.UTF-8 LC_TELEPHONE=C.UTF-8 LC_MEASUREMENT=C LC_IDENTIFICATION=C.UTF-8 LC_ALL= ``` This isn't really what we'd want, but as the Digital Clock residing on the Task Manager can be set to use a date format, it ended up being good enough for me. Lock screen clock still doesn't have the preferred ISO format and there are other similar issues here and there, but that's what we get with silly locales. I've also tried using de_DE.UTF-8 before, but then I got to enjoy German day names too which wasn't exactly what I desired. While it's definitely odd that you get this specific problem with Krusader, the root of the issue is the spreading localization spaghetti which surely wasn't this bad earlier, at least I used to have an older setup which was easier to set to be English with non-US formats, but then last year as I made a fresh setup with the most recent Kubuntu, I ended up with localization being forced more on the user instead of just language with separate format preferences. -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 476081] ip wildcard in known_hosts not functional
https://bugs.kde.org/show_bug.cgi?id=476081 Pedro V changed: What|Removed |Added CC||voidpointertonull+bugskdeor ||g...@gmail.com --- Comment #1 from Pedro V --- It's quite likely an upstream shortcoming as the SFTP KIO slave uses libssh which seems to neglect a lot of "convenience" features. For example what you want to achieve here could be also done with HostKeyAlias, but that isn't supported either. Apparently it doesn't use known_hosts2 by default, but surprisingly it supports the UserKnownHostsFile option, so you can request that to be also used in your SSH config file. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 471375] Firefox copy failure with middle-click-to-paste disabled
https://bugs.kde.org/show_bug.cgi?id=471375 --- Comment #13 from Pedro V --- The recently released Firefox 122.0 stopped using primary selection when support for it isn't advertised, therefore the issue is fixed there. Unfortunately the recently released Thunderbird 115.7.0 didn't get this fix, therefore that's still affected. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 479814] Desktop Cube Not Working for RC1
https://bugs.kde.org/show_bug.cgi?id=479814 v...@v0.vc changed: What|Removed |Added CC||v...@v0.vc -- You are receiving this mail because: You are watching all bug changes.
