[frameworks-baloo] [Bug 460509] Baloo indexes files temporarily mounted from other file systems
https://bugs.kde.org/show_bug.cgi?id=460509 --- Comment #6 from Adam Fontenot --- (In reply to tagwerk19 from comment #5) > (In reply to Adam Fontenot from comment #3) > > ... Maybe an option could be provided, but the ability to > > manually "opt-in" specific directories by adding them to the indexing list > > is probably good enough ... > Wandering off into the territory of "personal preferences" here, but I trust > the idea of fewest surprises... Right - I think the one case where we can say indexing definitely *shouldn't* happen is when something is mounted "temporarily" - although maybe that isn't clearly defined yet. Basically, if there's any reason to think the path might be expected to change? I agree with you that something's being in fstab is a good sign it's "permanent" and should be indexed. However, I think if Baloo is going to do that, several footguns need to be avoided: * The heuristics for determining which filesystems are permanent need to be pretty much flawless. You could have an fstab set up so that multiple USB drives are all mounted on demand to ~/usb. That's pretty much a worst case scenario. Files suddenly appear and disappear, Baloo trashes the database trying to delete everything, etc. * Some method for determining that a given file system is network-based is probably needed; I think content indexing should probably be turned off for these file systems by default. The user could always opt in for individual directories as needed. * Baloo needs to have a mechanism where downstream search tools don't see files on unmounted file systems in their searches. In the mean time, I think the right move is to fix issues like this one (Baloo indexing huge file systems - multiple terabytes in my case - over the network) by changing the defaults so that Baloo never crosses file systems unless the user manually opts a folder in. We can make this work better when the issues above are solved. Users with permanent file systems they want indexed are in a better position anyway. Because their paths are static, they can manually include things in the indexing list easily. I think that's one good reason to lean in the direction of not trying to do too much magic in Baloo by default. When Baloo is including stuff in directories that don't have static locations and you want it to stop, there's not much you can do about that. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 460840] New: KWin doesn't respect sub-pixel rendering setting for window titles
https://bugs.kde.org/show_bug.cgi?id=460840 Bug ID: 460840 Summary: KWin doesn't respect sub-pixel rendering setting for window titles Classification: Plasma Product: kwin Version: 5.26.0 Platform: Archlinux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: decorations Assignee: kwin-bugs-n...@kde.org Reporter: adam.m.fontenot+...@gmail.com Target Milestone: --- SUMMARY I have RGB sub-pixel rendering enabled. It works as expected everywhere inside KDE / QT applications, but window titles are rendered with only grayscale anti-aliasing. >From what I can tell looking at some old screenshots, the issue first appeared sometime in 2018 or 2019. I think this probably affects anywhere that KWin draws text, but I'm not sure where that is besides the window title, so I can't verify. Text drawn as part in Plasma (e.g. in the task bar) respects the rendering settings. STEPS TO REPRODUCE 1. Enable RGB sub-pixel rendering for fonts in your system settings. (I also have anti-aliasing enabled and hinting disabled, although this shouldn't matter.) 2. Restart KWin and see if window titles are subpixel rendered. (If you take a screenshot and zoom in close, you should see color fringing around the glyphs.) OBSERVED RESULT Window titles are not subpixel rendered. EXPECTED RESULT They should be. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.26.0 KDE Frameworks Version: 5.99.0 Qt Version: 5.15.6 Kernel Version: 6.0.1-arch1-1 (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 429742] Many emoji display broken representations or do not display at all in QT widgets
https://bugs.kde.org/show_bug.cgi?id=429742 Adam Fontenot changed: What|Removed |Added Status|RESOLVED|REOPENED Ever confirmed|0 |1 Summary|the transgender flag emoji |Many emoji display broken |doesn't display correctly |representations or do not |in any KDE app, but it's|display at all in QT |there in the emoji |widgets |selector. | Resolution|UPSTREAM|--- --- Comment #10 from Adam Fontenot --- I'm reopening this in the hope of further discussion. I filed the upstream bugs over a year ago now: * https://bugreports.qt.io/browse/QTBUG-97401 * https://bugreports.qt.io/browse/QTBUG-97400 I think they were extremely clear about what the problem was on a technical level, and if I'm not wrong, they're probably not that hard to fix in QT. Unfortunately, neither bug has received a single comment from a QT developer or even marked confirmed. Because the reported issue also affects QT 6, I can only assume this problem is not going away for us in the near future. I think we have to have some sort of plan here. KDE is a desktop environment! Having broken emojis should be considered unacceptable. My understanding is that we patch QT on many of the platforms QT ships on. (My operating system, Arch Linux, packages QT with patches by KDE.) Is this something we can fix on our end and move on? Are there other possible workarounds? To quickly summarize the issues for anyone new to this bug report, * QT ignores the emoji presentation selector (QTBUG-85744) and in fact emoji representation breaks if an emoji contains a presentation selector in the middle of the emoji (QTBUG-97401). Presentation selectors are used in the normal (or "fully qualified") form of many emojis. * When an emoji combines two other code points with a zero-width join (like "man kneeling" = "person kneeling" + "male sign"), the resulting emoji will not be displayed correctly if one of those two symbols exists in the user's primary font. (QTBUG-97400) I have a more detailed discussion in the thread above. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 460509] Baloo indexes files temporarily mounted from other file systems
https://bugs.kde.org/show_bug.cgi?id=460509 --- Comment #3 from Adam Fontenot --- (In reply to tagwerk19 from comment #2) > (In reply to Adam Fontenot from comment #0) > > ... Baloo was intelligently skipping other file systems in its indexing ... > That had apparently been implemented a while back - Bug 333433 > > Although don't have a feeling for what "people would expect (or want) to > happen" I'm thinking given Bug 333433 that Baloo should not index mounted file systems by default. Maybe an option could be provided, but the ability to manually "opt-in" specific directories by adding them to the indexing list is probably good enough. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 437754] "balooctl status" can trigger high memory use
https://bugs.kde.org/show_bug.cgi?id=437754 Adam Fontenot changed: What|Removed |Added CC||adam.m.fontenot+kde@gmail.c ||om -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 460460] Baloo lies about its status when writing to its database
https://bugs.kde.org/show_bug.cgi?id=460460 --- Comment #6 from Adam Fontenot --- (In reply to tagwerk19 from comment #5) > (In reply to Adam Fontenot from comment #4) > > (In reply to tagwerk19 from comment #3) > > ... there are a million Baloo bugs for i/o thrashing, memory > > use, hanging on specific files, incorrect indexing, etc... > OK :-/ > > I'd say though that my experience triaging reports is that the number > reported has settled down *remarkably* over the last two years. Older > versions of baloo that are disappearing as people update their distro's. > Maybe also that I/O load is not so visible with SSD's. Sorry, I didn't mean to be saucy about it. I certainly appreciate the amount of effort that's gone into improving Baloo and understand that it's not easy work. "Millions" was obviously an exaggeration. It's just that Baloo is the one component of KDE in which I encounter show-stopping bugs, over and over again. Other components are at least working well enough that I can "dogfood" and improve them. Baloo I'm forced to keep disabled; once a year or so I give it a try to see if things are better. Judging by user reports on places like the KDE subreddit, I don't think my experience is too far from the norm: https://old.reddit.com/r/kde/search?q=baloo_sr=on You'll find reports here that are hair-raising to say the least. I do think file name search (Baloo with content indexing disabled) has gotten better; I managed to have it enabled the last few months with not too much trouble... before the combination of Bug 460509 and Bug 437754 forced me to disable it again. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 460460] Baloo lies about its status when writing to its database
https://bugs.kde.org/show_bug.cgi?id=460460 --- Comment #4 from Adam Fontenot --- (In reply to tagwerk19 from comment #3) > Does it make sense to close this as a duplicate of Bug 437754? Probably not? I tried to keep this bug report focused on the user-facing issue in Baloo. I think you're probably right that the cause of my specific issue was Bug 437754. However, there are a million Baloo bugs for i/o thrashing, memory use, hanging on specific files, incorrect indexing, etc, and one thing that unites them is that the user is put in a situation where they will probably want to kill Baloo. The problem that users regularly encounter is that Baloo claims to be idle and can't be killed. (In my case it even hung the System Settings UI for 30 seconds as well.) Under the assumption that we probably won't have fixed all the issues with Baloo in a year (or five), I think making sure the user is given correct information when it's misbehaving and the ability to stop it is very important. > When it starts up "baloo_file" scans through the filesystem looking for > unindexed or updated files. At the moment it does that in memory, only > committing the results at the end of the process. That means "balooctl" > doesn't > see the work done when it is looking in the database file. It's hard to say for sure what Baloo was doing in my case, but from the `strace` it appeared to be seeking and writing a file. If that's the case then I assume it wasn't merely updating the list of changed files in memory, so that can't be the explanation for why it claimed to be idle. > If you are interested, have a look at: > > https://bugs.kde.org/show_bug.cgi?id=402154#c12 Fortunately I don't mount any subvolumes explicitly, I have separate real partitions (e.g. for root and home) each formatted with BTRFS, and only the default BTRFS subvolume on each file system is mounted in my fstab. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 460508] Dolphin search crosses file system boundary when Baloo is disabled
https://bugs.kde.org/show_bug.cgi?id=460508 --- Comment #2 from Adam Fontenot --- (In reply to tagwerk19 from comment #1) > I think if you are searching with Dolphin, and Dolphin sees that baloo is > disabled or the folder "it is in" is not indexed by baloo, it will start a > "there and then" search. That is via "filenamesearch" rather then > "baloosearch" (although it's a bit more difficult to see what Dolphin is > doing behind the scenes nowadays). Just to make sure it's clear - I'm not searching inside a mounted remote directory. I'm searching inside a directory (my home folder) that contains a mounted remote directory. If Dolphin is currently browsing inside the remote, I expect it to search the remote (because the search "starts in" the remote file system). When searching my home directory, I expect it to skip other filesystems. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 460509] New: Baloo indexes files temporarily mounted from other file systems
https://bugs.kde.org/show_bug.cgi?id=460509 Bug ID: 460509 Summary: Baloo indexes files temporarily mounted from other file systems Classification: Frameworks and Libraries Product: frameworks-baloo Version: 5.99.0 Platform: Archlinux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Baloo File Daemon Assignee: baloo-bugs-n...@kde.org Reporter: adam.m.fontenot+...@gmail.com Target Milestone: --- SUMMARY I was previously under the impression that Baloo was intelligently skipping other file systems in its indexing, because even when it indexes them Dolphin (for whatever reason) doesn't seem to show them. However, I have found using the `baloosearch` CLI that it is, in fact, indexing files on remote (network based) file systems. STEPS TO REPRODUCE 1. Make sure file indexing is enabled and content indexing is disabled. (I'm not sure what would happen if content indexing were enabled and I'm afraid to find out.) 2. Mount a remote directory via sshfs to a part of your home directory that Baloo is set to index. 3. Activate Baloo and/or force a rescan. 4. Search for files known to be on the remote file system (e.g. via Dolphin and via baloosearch). OBSERVED RESULT The files appear in `baloosearch` and can therefore be assumed to be in the index. Actually, this is probably responsible for the unusually large index size I was experiencing (which tagwerk19 commented on here: https://bugs.kde.org/show_bug.cgi?id=460460#c1). The files do not appear in the Dolphin search tool - despite the fact that Dolphin *does* cross file system boundaries if Baloo is disabled. See here for that bug: https://bugs.kde.org/show_bug.cgi?id=460508 EXPECTED RESULT Baloo does not index files on remote file systems. These are often temporarily mounted and can change location. E.g. the same files may be on ~/remote one day, ~/remote2 another day, and so on. I'm not sure if Baloo regards these files as deleted when the remote is unmounted, but if it does the result is probably disk thrashing as it has to update its index. (I also expect Dolphin to show the same results as baloosearch, but that's a secondary issue here.) SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.26.0 KDE Frameworks Version: 5.99.0 Qt Version: 5.15.6 Kernel Version: 6.0.1-arch1-1 (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 460508] New: Dolphin search crosses file system boundary when Baloo is disabled
https://bugs.kde.org/show_bug.cgi?id=460508 Bug ID: 460508 Summary: Dolphin search crosses file system boundary when Baloo is disabled Classification: Applications Product: dolphin Version: 22.08.2 Platform: Archlinux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: search Assignee: dolphin-bugs-n...@kde.org Reporter: adam.m.fontenot+...@gmail.com CC: kfm-de...@kde.org Target Milestone: --- SUMMARY I occasionally have remote file systems (like sshfs) mounted locally under my home directory. Baloo, sensibly enough, does not index under these directories, and Dolphin does not attempt to search them when Baloo is enabled. However, having recently been forced to disable Baloo, I discovered that Dolphin crosses file system boundaries when Baloo is disabled. STEPS TO REPRODUCE 1. Disable Baloo 2. Mount a large remote directory via sshfs in your home directory 3. Try to search your home directory in Dolphin OBSERVED RESULT The search is extremely slow (assuming that the remote directory is slow and large enough). With the right search terms you can verify that some of the results are from the remote file system. I killed a search after five minutes. Searching my 500k file home directory with `find -xdev` takes 5 seconds, even after dropping caches. EXPECTED RESULT Dolphin should mirror the behavior of Baloo and not cross file system boundaries when searching by default. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.26.0 KDE Frameworks Version: 5.99.0 Qt Version: 5.15.6 Kernel Version: 6.0.1-arch1-1 (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 460460] Baloo lies about its status when writing to its database
https://bugs.kde.org/show_bug.cgi?id=460460 --- Comment #2 from Adam Fontenot --- (In reply to tagwerk19 from comment #1) > (In reply to Adam Fontenot from comment #0) > > 2... probably resulting in the deletion of some > > temporary files. (See the linked bug above describing heavy disk write > > caused by file deletion.) > > 3. Try to check on Baloo's status... > Maybe Bug 437754. So in this bug, the act of checking on Baloo's status is what triggers both memory use and i/o thrashing followed by bloating the database? That's ... insidious. Lines up pretty well with my experience, given that I was sitting at around 0.5 GB used for months before I had this problem. > I'm guessing you had been doing content indexing previously and had disabled > it - otherwise 0.5 Gbyte seems a little large. I'd need to check to see > whether baloo "cleans up" content records in this situation or just leaves > them "orphaned". No, I've had content indexing disabled for a while (due to the innumerable bugs I've encountered with it) and previously deleted the database. So that 0.5 GB was whatever it was previously using. Unfortunately no way to check that now, as I was forced to kill the process and delete the database because of this issue. For reference, my home folder has about 500k items, of which about 180k are supposedly excluded (being in cache or source code directories I have marked as "not indexed" in the settings). > Second thought is that if baloo_file sees a large number of unindexed files, > it first collects the metadata for all of them, then writes the all results > to disc. This can give a sharp peak in memory usage and, in extreme cases, > bog down the system. > > Note in this case, the work that baloo_index is doing is invisible to > "balooctl status". This is part of what I'm advocating here; there should be no work done by Baloo that is invisible to `balooctl` or is unkillable by the user. (There may be work that we strongly prefer the user not interrupt, but ultimately if we don't provide a way for them to do it nicely they're just going to `kill -9` the Baloo processes.) > Off-chance thought... > > Can you see out what temporary files Audacity creates? Might baloo want to > index them? (Are they hidden or not? what does kmimetypefinder say about > them?). It is an off-chance as if you are not content indexing, this > shouldn't affect you. Checked on this, the files are actually created in /var/tmp, so not relevant here. Most likely what happened is that just before opening Audacity I decided to clear up some free space in order to be able to export files. These were mostly a bunch of large source code directories that I had extracted in my downloads folder (which is indexed) while I was debugging something. It's entirely possible that Baloo was still hung on those by the time I closed Audacity. > What filesystem are you using? If you are using BTRFS, there'll be a > follow-on set of questions I am indeed using BTRFS. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 431396] Window decoration buttons are mis-rendered
https://bugs.kde.org/show_bug.cgi?id=431396 Adam Fontenot changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #21 from Adam Fontenot --- Can't currently repro this with Plasma 5.26, testing eog 42.3. Assuming it was fixed. Going to close this issue. If there are issues that appear without theme changes (e.g. you see the problem after a reboot), please re-open the bug. If you see an issue where GTK applications don't update after making changes to your theme, please file a new bug. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 460460] New: Baloo lies about its status when writing to its database
https://bugs.kde.org/show_bug.cgi?id=460460 Bug ID: 460460 Summary: Baloo lies about its status when writing to its database Classification: Frameworks and Libraries Product: frameworks-baloo Version: 5.99.0 Platform: Archlinux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Baloo File Daemon Assignee: baloo-bugs-n...@kde.org Reporter: adam.m.fontenot+...@gmail.com Target Milestone: --- SUMMARY I was encountering a separate issue with Baloo, probably https://bugs.kde.org/show_bug.cgi?id=442453 I tried to check on Baloo's status - both in the System Setting UI and with `balooctl status` - and it claimed to be idle. But it was clearly not idle, see below. STEPS TO REPRODUCE 1. Disable content indexing - only file indexing is relevant here. 2. Get into a situation where Baloo will choke on some files and start thrashing the disk. In this case I had opened a large file with Audacity and then closed the program, probably resulting in the deletion of some temporary files. (See the linked bug above describing heavy disk write caused by file deletion.) 3. Try to check on Baloo's status. OBSERVED RESULT `balooctl` takes a very long time (30 seconds or so) to respond (as does the System Setting UI)... this System Settings freeze probably deserves a separate bug report... Eventually it responds and claims to be idle: Baloo File Indexer is running Indexer state: Idle Total files indexed: 788,267 Files waiting for content indexing: 0 Files failed to index: 0 Current size of index is 3.01 GiB According to htop, however, `baloo_file` was using quite a lot of memory and an increasing amount of CPU. I remembered to try `strace` on the `baloo_file` process while this was happening, and it was an endless stream of seeking and writing on a single file descriptor. Almost certainly this file was the Baloo database, given the concurrent index bloating. EXPECTED RESULT 1. Baloo should respond quickly to status requests. The controller application should never (?) be deadlocked. 2. Baloo should describe itself as "writing to database" or something similar when it is performing these heavy database writes. 3. Baloo should allow the user to kill it from the System UI when it is in *any* running state, even if it is not actively indexing. In the situation in question, Baloo had bloated its database from 0.5 GB to over 3 GB in the space of about 2 minutes, so being able to kill it quickly is critically important in this kind of situation. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.26.0 KDE Frameworks Version: 5.99.0 Qt Version: 5.15.6 Kernel Version: 6.0.1-arch1-1 (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[akregator] [Bug 458116] Articles spilling from one feed to another
https://bugs.kde.org/show_bug.cgi?id=458116 --- Comment #24 from Adam Brightmore --- (In reply to Philippe ROUBACH from comment #23) > (In reply to Adam Brightmore from comment #22) > > Yep can confirm it has started happening again after updating, back to the > > flatpak version once more. :( > > Hello > > Is flatpack version well included in Kontact or separated ? > > thanks I assume you would need to install the flatpak version of Kontact, but I don't use that so I don't know. Also of note I encountered this issue in the latest version of the flatpak so I've downgraded to the version I was using last time via this command: sudo flatpak update --commit=9f6169096fcc17ed167fcf8da15e4675438d204ef9035c9f8fb24958be28f02f org.kde.akregator -- You are receiving this mail because: You are watching all bug changes.
[akregator] [Bug 458116] Articles spilling from one feed to another
https://bugs.kde.org/show_bug.cgi?id=458116 Adam Brightmore changed: What|Removed |Added CC||sinister@gmail.com --- Comment #22 from Adam Brightmore --- Yep can confirm it has started happening again after updating, back to the flatpak version once more. :( -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 458865] After an update to qt5-base the dolphin file picker dialog used in GTK applications via GTK_USE_PORTAL=1 ignores theming
https://bugs.kde.org/show_bug.cgi?id=458865 --- Comment #49 from Adam Williamson --- oof, and I just realized...we do actually run SDDM on X on Fedora (because it has bugs running on Wayland). So the patch from this issue is probably relevant to that case after all... -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 458865] After an update to qt5-base the dolphin file picker dialog used in GTK applications via GTK_USE_PORTAL=1 ignores theming
https://bugs.kde.org/show_bug.cgi?id=458865 --- Comment #47 from Adam Williamson --- (In reply to Antonio Rojas from comment #46) > (In reply to Adam Williamson from comment #45) > > So we have folks running into this on Fedora: > > https://bugzilla.redhat.com/show_bug.cgi?id=2133795 > > > > It looks like we don't have the change from this bug report yet. However, > > Fedora users will generally be on Wayland, and the change from this bug > > report is only to startplasma-x11.cpp. I notice that in > > startplasma-wayland.cpp , `setupCursor` still happens very early - in fact > > it's nearly the *first* thing that happens. Does it need to be delayed on > > Wayland too? > > For the Wayland session, when setupCursor is called is irrelevant for this > issue, because on Wayland setupCursor does not launch kapplymousetheme (or > any other QApplication) [1], so it doesn't activate xdg-desktop-portal > > [1] > https://invent.kde.org/plasma/plasma-workspace/-/blob/v5.26.0/startkde/ > startplasma.cpp#L208 > > Is anybody actually reporting wrong cursors on Wayland on Fedora? AFAICS the > downstream bug report is about xdg-desktop-portal-kde crashes for the sddm > user, which is also caused by the Qt change, but is unrelated to the wrong > cursors issue. Well, I was following on from your comment 34, but now I see that yeah, it doesn't run `kapplymousetheme` on Wayland. Yes, the downstream report is just about the crash under SDDM. I got here via the Arch report, and both do seem to discuss that crash. Is there a different bug report for that? Do we know what's causing it / have a fix? I don't think we know yet if there are any practical consequences of it, it's more just that people are noticing the crash report. Thanks! -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 458865] After an update to qt5-base the dolphin file picker dialog used in GTK applications via GTK_USE_PORTAL=1 ignores theming
https://bugs.kde.org/show_bug.cgi?id=458865 Adam Williamson changed: What|Removed |Added CC||ad...@happyassassin.net --- Comment #45 from Adam Williamson --- So we have folks running into this on Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=2133795 It looks like we don't have the change from this bug report yet. However, Fedora users will generally be on Wayland, and the change from this bug report is only to startplasma-x11.cpp. I notice that in startplasma-wayland.cpp , `setupCursor` still happens very early - in fact it's nearly the *first* thing that happens. Does it need to be delayed on Wayland too? I'll poke around at this a bit myself if I have time. -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 456612] random crash, plasmashell restarted
https://bugs.kde.org/show_bug.cgi?id=456612 Adam Tazul changed: What|Removed |Added CC||adam_ta...@outlook.com -- You are receiving this mail because: You are watching all bug changes.
[akregator] [Bug 459479] New: Communicate with the Facebook Support service team to ask for the solution at once:
https://bugs.kde.org/show_bug.cgi?id=459479 Bug ID: 459479 Summary: Communicate with the Facebook Support service team to ask for the solution at once: Classification: Applications Product: akregator Version: unspecified Platform: Other OS: Other Status: REPORTED Severity: normal Priority: NOR Component: akregator konqueror plugin Assignee: kdepim-b...@kde.org Reporter: adamsmith908...@gmail.com Target Milestone: --- You may easily communicate with the Facebook Support service team to ask for solution service at once as the unusual tech problems have worsened the condition. It is always essential to take the initiatives in a positive direction so that Facebook customers may keep on using the Facebook account according to the requirement to shop online from anywhere and anytime using their mobile. They like such an aspect a lot and thus they should be familiar with the solution options. https://www.primotechy.com/blog/how-do-i-contact-facebook-support/ -- You are receiving this mail because: You are watching all bug changes.
[akregator] [Bug 458116] Articles spilling from one feed to another
https://bugs.kde.org/show_bug.cgi?id=458116 Adam Brightmore changed: What|Removed |Added CC|sinister@gmail.com | -- You are receiving this mail because: You are watching all bug changes.
[akregator] [Bug 458116] Articles spilling from one feed to another
https://bugs.kde.org/show_bug.cgi?id=458116 --- Comment #16 from Adam Brightmore --- (In reply to Andreas Hencke from comment #15) > (In reply to Colin J Thomson from comment #14) > > I'll tentatively say with today's update of Frameworks to 5.98 from > > zawertun's COPR this has fixed it for me on this Fedora 36 box. > > Seemed to be fixed with the Frameworks update on my arch machine. Can also confirm seems to be fixed. I'd been using the flatpak version till this morning when I updated Arch and switched back (exported/imported feeds and copied my archive .mk4 files), haven't had any issues all day now. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 458622] Window order gets briefly switched when changing workspaces, when a window is set to appear on all desktops
https://bugs.kde.org/show_bug.cgi?id=458622 --- Comment #1 from Adam Fontenot --- A friend also using KDE on Arch Linux was able to reproduce this. It's likely the bug affects all users of 5.25. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 458622] New: Window order gets briefly switched when changing workspaces, when a window is set to appear on all desktops
https://bugs.kde.org/show_bug.cgi?id=458622 Bug ID: 458622 Summary: Window order gets briefly switched when changing workspaces, when a window is set to appear on all desktops Product: kwin Version: 5.25.4 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: compositing Assignee: kwin-bugs-n...@kde.org Reporter: adam.m.fontenot+...@gmail.com Target Milestone: --- Created attachment 151775 --> https://bugs.kde.org/attachment.cgi?id=151775=edit screen recording of the problem SUMMARY When you have a window open on workspace 1, and another window open on workspace 2, a third window that is set to show up on all desktops will briefly pop up above the other windows, before (spontaneously) finding its correct order a second or so later, every time you change workspaces. This is *extremely* irritating and should be easy to reproduce. The bug is probably somehow related to https://bugs.kde.org/show_bug.cgi?id=455429 but it's not the same issue. I don't have "slide back" enabled. Note: I'm using "workspace" and "desktop" synonymously in what follows. KDE is not consistent in how it describes this concept. STEPS TO REPRODUCE 1. Open a window on workspace 1 and another window on workspace 2. 2. Open a third window and use the window actions to put the window "On All Desktops". 3. Toggle between the workspaces and raise the windows you created in step 1 so that they're above the third window in the order. 4. Toggle between the workspaces. OBSERVED RESULT The third window (created in step 2) that is set to open on all desktops will briefly "flash" above the other windows when you change workspaces, even though it should be at the bottom of the stack on both workspaces. After a brief (~1s) period, it will then drop down below the other windows to its correct order. Windows set to appear on all desktops will briefly flash above even windows that have "keep above" set. Changing the Virtual Desktop Switching Animation to "Fade Desktop" instead of "Slide" does not fix the problem. It's a little harder to detect because the animation is faster, but definitely still happening. EXPECTED RESULT Windows should stay at the correct order when switching workspaces. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.25.4 KDE Frameworks Version: 5.97.0 Qt Version: 5.15.5 Kernel Version: 5.19.5-arch1-1 (64-bit) Graphics Platform: X11 Graphics Processor: Mesa Intel® HD Graphics 3000 ADDITIONAL INFORMATION I'm about 90% sure I saw someone report this issue on the KDE subreddit around the time 5.25 was released, but I can't seem to find it now. I think this is a regression in 5.25 but I'm not certain about that. At the very least it's a regression over ~6 months ago. -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 454765] Unable to save persistent module data if ~/.local/state folder does not exist
https://bugs.kde.org/show_bug.cgi?id=454765 P. Adam Sowa changed: What|Removed |Added CC||pa.sowa@gmail.com --- Comment #1 from P. Adam Sowa --- There is a MR that fixes this bug: https://invent.kde.org/sdk/kdesrc-build/-/merge_requests/151 -- You are receiving this mail because: You are watching all bug changes.
[libkgapi] [Bug 439285] Bad request, Google replied "Contacts API is being deprecated"
https://bugs.kde.org/show_bug.cgi?id=439285 Adam Tazul changed: What|Removed |Added CC||adam_ta...@outlook.com -- You are receiving this mail because: You are watching all bug changes.
[akregator] [Bug 458116] Articles spilling from one feed to another
https://bugs.kde.org/show_bug.cgi?id=458116 --- Comment #3 from Adam Brightmore --- Okay the oldest version that would work without downgrading other packages was 5.20.0 (22.04.0) which is still KDE Frameworks 5.97.0 based. The issue still persisted in that version so now I'm trying the flatpak version which is Version 5.21.0 (22.08.0) and also uses KDE Frameworks Version 5.97.0 & Qt Version 5.15.5 (built against 5.15.5). After using the flatpak version for about 2h40m the bug hasn't happened yet so this could be a temporary workaround for those affected till this is fixed -- You are receiving this mail because: You are watching all bug changes.
[akregator] [Bug 458116] Articles spilling from one feed to another
https://bugs.kde.org/show_bug.cgi?id=458116 Adam Brightmore changed: What|Removed |Added CC||sinister@gmail.com --- Comment #1 from Adam Brightmore --- Also experiencing this with version 22.04.3, tried downgrading to 22.04.2 still happened. Exported all my feeds, moved akregator configs & files in .config and .local/share. Started akregator and it seemed like a clean slate so I deleted the default feeds and re-imported my old feeds. Seemed okay for awhile, but eventually it started happening again. And it's not just youtube feeds, random blogs and podcast feeds also show up in youtube feeds and vice versa. Gonna try downgrading further (to oldest one that will still run) and see if that fixes it, will report back. Operating System: Arch Linux KDE Plasma Version: 5.25.4 KDE Frameworks Version: 5.97.0 Qt Version: 5.15.5 Kernel Version: 5.19.2-zen1-1-zen (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 457817] New: window preview quality is very low due to cheap / fast scaling algorithm
https://bugs.kde.org/show_bug.cgi?id=457817 Bug ID: 457817 Summary: window preview quality is very low due to cheap / fast scaling algorithm Product: kwin Version: 5.24.4 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: adam.m.fontenot+...@gmail.com Target Milestone: --- Created attachment 151292 --> https://bugs.kde.org/attachment.cgi?id=151292=edit screenshot of the problem and proposed resolution Everywhere a window preview is shown (e.g. in present-windows, in the window previews of Plasma's icons-only task manager, etc), it is low quality - meaning "pixelated" looking, with strong color fringing around text (when sub-pixel anti-aliasing is enabled for font rendering on the system). I am assuming that different tools utilizing window previews under KWin rely on the same scaling code, since the issue is the same in each case, so I'm reporting this as a general bug. STEPS TO REPRODUCE 1. Make sure the compositor's scale method is set to "accurate" instead of smooth - just in case it might have an effect. 2. Open a bunch of windows and then activate the "present windows" effect. (Opening a bunch of windows will make the resulting preview size smaller, which will make the problem easier to see on high resolution screens.) OBSERVED RESULT Quality is poor (see attached screenshot). Strong color fringing around text is probably caused by using a nearest neighbor / point algorithm to rescale the window preview. EXPECTED RESULT Quality is acceptable (see attached screenshot). For the sample shown in the screenshot, I captured the window at full resolution and used a (still very cheap and fast) bilinear filter to create a preview of the same size as the one created by KWin. Window rescaling is probably GPU accelerated anyway (?) so I don't think using a slightly more expensive algorithm like bilinear should be a problem. If it might be on some systems, perhaps a setting to enable or disable it could be added. SOFTWARE/OS VERSIONS Linux: Arch Linux x86_64 (kernel 5.18.16-arch1-1) KDE Plasma Version: 5.25.4 (x11) KDE Frameworks Version: 5.96.0 Qt Version: 5.15.5 ADDITIONAL INFORMATION I've always thought it would be nice if window previews also showed the window decorations. -- You are receiving this mail because: You are watching all bug changes.
[krusader] [Bug 456348] KrArc freezes, both in Krusader and Dolphin
https://bugs.kde.org/show_bug.cgi?id=456348 Adam changed: What|Removed |Added CC||adam.neum...@pm.me --- Comment #7 from Adam --- I have same issue in Krusader, only ZIP archives are affected. Krusader: 2.7.2 Operating System: Arch Linux KDE Plasma Version: 5.25.3 KDE Frameworks Version: 5.96.0 Qt Version: 5.15.5 Kernel Version: 5.18.14-arch1-1 Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[krusader] [Bug 456348] KrArc freezes, both in Krusader and Dolphin
https://bugs.kde.org/show_bug.cgi?id=456348 Adam changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 --- Comment #6 from Adam --- *** This bug has been confirmed by popular vote. *** -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 442571] kdeconnect-cli -a lists not paired devices
https://bugs.kde.org/show_bug.cgi?id=442571 Adam Fontenot changed: What|Removed |Added Resolution|--- |FIXED Version Fixed In||22.08 Status|ASSIGNED|RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[print-manager] [Bug 455798] Network printer missing in the print dialog of KDE apps, while available and working in the system settings and all non-KDE apps
https://bugs.kde.org/show_bug.cgi?id=455798 Adam Pigg changed: What|Removed |Added CC||a...@piggz.co.uk --- Comment #10 from Adam Pigg --- Also confirmed on opensuse tumbleweed, and a canon mg5700. I never had to add this printer locally as it just worked, but since an update, it hasnt worked in the last month. I added it to the local cups system, and its still not listed in kde apps. Listed fine in firefox. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 455846] zoom rotate move does not work (with touchpad and touch)
https://bugs.kde.org/show_bug.cgi?id=455846 --- Comment #3 from Adam Belis --- Sombody suggested that i play with new canvas settings. After cahngeing presetrs few times and resetting them it started working so it seems like shorcut migrating was not done correctly for users who update -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 455846] zoom rotate move does not work (with touchpad and touch)
https://bugs.kde.org/show_bug.cgi?id=455846 --- Comment #1 from Adam Belis --- bug is stil therre in beta2 -- You are receiving this mail because: You are watching all bug changes.
[korganizer] [Bug 456717] New: Doesn't remember which calendars should be enabled
https://bugs.kde.org/show_bug.cgi?id=456717 Bug ID: 456717 Summary: Doesn't remember which calendars should be enabled Product: korganizer Version: 5.20.3 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kdepim-b...@kde.org Reporter: vend...@gmail.com Target Milestone: --- STEPS TO REPRODUCE 1. Add a mix of local calendars (default Birthday & Anniversaries works) and remote (Google calendar) 2. Set calendars to be enabled 3. Restart KOrganizer OBSERVED RESULT When KOrganizer starts up all calendars are disabled regardless of if they were enabled or not last time KOrganizer ran. EXPECTED RESULT It should remember which calendars are enabled and which are disabled. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.25.3 KDE Frameworks Version: 5.96.0 Qt Version: 5.15.5 Kernel Version: 5.18.11-arch1-1 (64-bit) Graphics Platform: Wayland -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 442571] kdeconnect-cli -a lists not paired devices
https://bugs.kde.org/show_bug.cgi?id=442571 Adam Fontenot changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 CC||adam.m.fontenot+kde@gmail.c ||om --- Comment #1 from Adam Fontenot --- I encountered this as well, pretty easy to verify that this is what the code does. I'll try to submit a patch for this soon. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 456100] When taking a second screenshot after saving a first one, Spectacle sometimes falsely claims to have saved the file
https://bugs.kde.org/show_bug.cgi?id=456100 --- Comment #4 from Adam Fontenot --- (In reply to Antonio Prcela from comment #3) > That's the point, the message never disappears. With this change, it works > as you have described in "expected". Maybe I misunderstood what the change is doing. It appears to make the message disappear after 10 seconds. That's not what I'm looking for, notwithstanding anything I said about the expected results. Right now, the "file saved" notification stays active indefinitely. That seems fine to me. When you click the "Take a New Screenshot" button, the notification disappears immediately, which also seems right. (If you take a new screenshot, then it won't have been saved, so the message would be misleading if it remained.) The problem is that when you activate Spectacle by clicking an activation key, a new screenshot is taken but the message doesn't go away. Making it so that the message went away after 10 seconds unconditionally would be a bad idea in my estimation. It would make it less clear in some cases that an image had been saved, and if you took a new screenshot quickly enough after saving the previous one, the "saved" message would still be visible for a few seconds until it disappeared. In that case it wouldn't even solve the problem of Spectacle falsely claiming to have saved the file. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 456100] When taking a second screenshot after saving a first one, Spectacle sometimes falsely claims to have saved the file
https://bugs.kde.org/show_bug.cgi?id=456100 --- Comment #2 from Adam Fontenot --- (In reply to Bug Janitor Service from comment #1) > A possibly relevant merge request was started @ > https://invent.kde.org/graphics/spectacle/-/merge_requests/145 I had a quick look at the merge request and it seems like it's supposed to hide the message on a timer? That would help but it's not the core issue here. When I click the "take a new screenshot" button, the message disappears immediately. There's presumably some bit of code hooked up to the button to do that, and I think it would make sense to have it fire every time a new screenshot is taken, including when that happens because of an activation key. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 456100] New: When taking a second screenshot after saving a first one, Spectacle sometimes falsely claims to have saved the file
https://bugs.kde.org/show_bug.cgi?id=456100 Bug ID: 456100 Summary: When taking a second screenshot after saving a first one, Spectacle sometimes falsely claims to have saved the file Product: Spectacle Version: 22.04.2 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: General Assignee: m...@baloneygeek.com Reporter: adam.m.fontenot+...@gmail.com CC: k...@david-redondo.de Target Milestone: --- SUMMARY Saving a screenshot in Spectacle results in a confirmation message that says something like "The screenshot was saved as Screenshot_date_time.png". This message remains visible even if you take a new screenshot, which misleadingly suggests that the new screenshot has also been saved. I have accidentally lost work while taking a series of screenshots because I thought that a screenshot was saved when it was not. This seems to happen when Spectacle is activated with a shortcut, but not when clicking the "Take a New Screenshot" button in the Spectacle window. In the example below, I have the Print Screen key bound to "launch Spectacle" under Shortcuts in System Settings. When pressed, this key launches spectacle (if it is not launched already) and immediately takes a screenshot. STEPS TO REPRODUCE 1. Activate Spectacle with an activation key (e.g. Print Screen). Take a screenshot and save it to disk with the Save As button. 2. Activate Spectacle with an activation key again. 3. Close Spectacle by clicking the button on the window frame. OBSERVED RESULT After saving the screenshot to disk in step 1, a message appears in the spectacle window indicating that the file has been saved. When activating Spectacle again, because the window is already open a new screenshot is taken immediately. When this happens, the message indicating that the (previous) file was saved does not go away from the window. When closing Spectacle immediately, there is no warning that the file is unsaved, making it more likely that the user will lose work if they trust the message. EXPECTED RESULT When activating Spectacle when the window is already open, I expect the behavior to be the same as when clicking "Take a New Screenshot". In other words, Spectacle should remove the message stating that the file is saved when a new screenshot is taken. SOFTWARE/OS VERSIONS Linux: Arch Linux x86_64 (kernel version 5.18.5) KDE Plasma Version: 5.25.0 KDE Frameworks Version: 5.95.0 Qt Version: 5.15.4 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 455370] Unable to use alternative Window Managers
https://bugs.kde.org/show_bug.cgi?id=455370 Adam Tazul changed: What|Removed |Added Status|RESOLVED|REPORTED Resolution|DUPLICATE |--- --- Comment #7 from Adam Tazul --- (In reply to Antonio Rojas from comment #6) > It's not. You are using systemd boot because that's the default in 5.25. Shouldn't the KDEWM environment variable be read when using systemd boot? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 455846] New: zoom rotate move does not work (with touchpad and tocuh)
https://bugs.kde.org/show_bug.cgi?id=455846 Bug ID: 455846 Summary: zoom rotate move does not work (with touchpad and tocuh) Product: krita Version: 5.1.0-beta1 Platform: Other OS: Microsoft Windows Status: REPORTED Severity: major Priority: NOR Component: * Unknown Assignee: krita-bugs-n...@kde.org Reporter: adam.be...@gmail.com Target Milestone: --- SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. opem krita and empty file 2. put two fingers together and spread them on touchpad or screen 3. OBSERVED RESULT nothing EXPECTED RESULT zoom rotate move SOFTWARE/OS VERSIONS Windows: win 10 surface pro 4 macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 443693] Clicking pause indexer should pause the Baloo indexer, but it doesn't
https://bugs.kde.org/show_bug.cgi?id=443693 Adam Fontenot changed: What|Removed |Added Status|NEEDSINFO |REOPENED Resolution|WAITINGFORINFO |--- --- Comment #5 from Adam Fontenot --- (In reply to Nate Graham from comment #4) > When you click "Pause Indexer", can you run `balooctl status` in a terminal > window and paste the output? I suspect what might be going on is that the > indexer itself does in fact get paused, but its running indexing processes > don't. I was able to reproduce the exact conditions. Here's a timeline. 1. Start `balooctl monitor` and `htop`. 2. Run `balooctl status`. See Output 1 below. 3. Start compiling a large piece of software that will create many new files in a directory that is indexed by Baloo. For this test, I was compiling the Arch Linux package `libreoffice-fresh`. 4. Observe that `baloo_file` becomes active in htop. In the monitor, note that the status changes to "Indexing new files" or "Indexing modified files". High CPU use by baloo is observed despite near-100% CPU demand from the compiler. 5. Open System Settings. Baloo settings page is oddly slow to load, but when it loads it says "Idle". I have noticed that running `balooctl status` will *hang* for a long time if the indexer is running. Presumably the indexer has briefly caught up with the compiler? 6. Click "Pause Indexer". Baloo seems indecisive, but after 20 seconds or so "Suspended" appears in the monitor window. 7. Observe that `baloo_file` continues to run in `htop`, using a large amount of CPU. 8. Run `balooctl status`. See Output 2 below. 9. Start writing this bug report. As I type this, `baloo_file` has continued to run. It has grown to over 1.7 GB of resident memory use, and continues to eat a lot of CPU. For good measure, I am running `balooctl status` again now. It takes over 50 seconds to complete. The monitor window continues to show "Suspended" as its last status message. See Output 3 below. Something that sticks out to me about this last state is that the number of indexed files is actually *dropping* over time, and despite this, the index size has ballooned (pun not intended) to an enormous size given the relatively moderate number of files indexed. I know for sure that this dramatic increase was the result of this testing, because I was recently forced to delete the Baloo data directory after seeing this issue. Nothing I have been able to do (including deleting the build directory entirely and trying to force baloo to recheck it) has been able to reduce this increased disk space usage. Every time it happens I am forced to delete Baloo's index and start over. I'm including the result of `balooctl indexSize` below, as Output 4. I'm in the process of trying to write a bug report to cover disk usage problems with Baloo, as there isn't one at present I don't think. (There's one for i/o utilization, cpu use, memory consumption, etc.) If there is anything I can provide to make that bug report better, please let me know. I'd like to avoid side-tracking this bug with the disk usage problem as it isn't the central issue here. Content indexing has been completely disabled throughout this entire process. Output 1 (status before compiling begins): Baloo File Indexer is running Indexer state: Idle Total files indexed: 270,102 Files waiting for content indexing: 0 Files failed to index: 0 Current size of index is 134.10 MiB Output 2 (status while compiling continues, and after Baloo is suspended): Baloo File Indexer is running Indexer state: Suspended Total files indexed: 295,546 Files waiting for content indexing: 0 Files failed to index: 0 Current size of index is 182.13 MiB Output 3 (status after writing this comment, after previously stopping the build): Baloo File Indexer is running Indexer state: Idle Total files indexed: 283,689 Files waiting for content indexing: 0 Files failed to index: 0 Current size of index is 2.37 GiB Output 4 (current indexSize): File Size: 2.37 GiB Used: 114.48 MiB PostingDB: 18.00 MiB15.723 % PositionDB: 18.85 MiB16.467 % DocTerms: 19.36 MiB16.907 % DocFilenameTerms: 17.24 MiB15.061 % DocXattrTerms: 4.00 KiB 0.003 % IdTree: 7.27 MiB 6.350 % IdFileName: 19.51 MiB17.040 % DocTime: 12.43 MiB10.861 % DocData:0 B 0.000 % ContentIndexingDB:0 B 0.000 % FailedIdsDB:0 B 0.000 % MTimeDB: 1.82 MiB 1.587 % -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 443693] Clicking pause indexer should pause the Baloo indexer, but it doesn't
https://bugs.kde.org/show_bug.cgi?id=443693 Adam Fontenot changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #3 from Adam Fontenot --- This isn't fixed for me. Perhaps it's fixed in some situations but not others? Let me know if you want me to open a new bug. Specific situation in which I saw this bug: I was compiling some software. All eight (virtual) cores on my system were in use. I had htop open and noticed that despite all cores being at 100%, baloo_file was using about 60% CPU (of one core) consistently, and more than 10% of my RAM. This despite being nice 19! (Perhaps something wrong with the scheduler, but I haven't looked into it further.) I opened the system settings, and Baloo's status said "Idle, 100% complete". Clicking "Pause Indexer" did nothing. baloo_file continued to run with a pretty aggressive amount of CPU use given that I was trying to compile some software. Speculation: * Baloo can be wrong about whether its indexer is running or not * When Baloo thinks its indexer is not running, and it is, clicking "Pause Indexer" will fail to stop the indexer. SIGTERM sent to baloo_file stopped it successfully. SOFTWARE/OS VERSIONS (updated) Linux: Arch Linux x86_64 (kernel 5.18.5) KDE Plasma Version: 5.25.0 KDE Frameworks Version: 5.95.0 Qt Version: 5.15.4 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 455370] Unable to use alternative Window Managers
https://bugs.kde.org/show_bug.cgi?id=455370 --- Comment #2 from Adam Tazul --- Created attachment 149768 --> https://bugs.kde.org/attachment.cgi?id=149768=edit Example .desktop file from /usr/share/xsessions/, launching XMonad as the Window Manager -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 455370] Unable to use alternative Window Managers
https://bugs.kde.org/show_bug.cgi?id=455370 --- Comment #1 from Adam Tazul --- (In reply to Adam Tazul from comment #0) > Since 5.25, no matter what method is used to set the environment variable. No matter what is set as KDEWM, it spawn Kwin instead of your WIndow Manager of choice*** -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 455370] Unable to use alternative Window Managers
https://bugs.kde.org/show_bug.cgi?id=455370 Adam Tazul changed: What|Removed |Added Flags||X11+ -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 455370] Unable to use alternative Window Managers
https://bugs.kde.org/show_bug.cgi?id=455370 Adam Tazul changed: What|Removed |Added CC||adam_ta...@outlook.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 455370] New: Unable to use alternative Window Managers
https://bugs.kde.org/show_bug.cgi?id=455370 Bug ID: 455370 Summary: Unable to use alternative Window Managers Product: kwin Version: 5.25.0 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: adam_ta...@outlook.com Target Milestone: --- Created attachment 149767 --> https://bugs.kde.org/attachment.cgi?id=149767=edit Example script, launching XMonad as the Window Manager SUMMARY (Sorry if this is not in the right section, I'm not 100% sure where this bug falls) In previous versions of KDE Plasma, setting the KDEWM environment variable to another Window Manager on your system would force Plasma to spawn that as the Window Manager in place of Kwin. Since 5.25, no matter what method is used to set the environment variable. STEPS TO REPRODUCE 1. Install and set up an alternative Window Manager of choice for use with KDE Plasma (X11) 2. Set the KDEWM environment variable using a pre-startup script in ~/.config/plasma-workspace/env/ OBSERVED RESULT KDE Plasma spawns Kwin EXPECTED RESULT KDE Plasma spawns the specified Window Manager SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux Rolling, all testing and unstable repo's enabled Kernel version: 5.18.3-arch1-1 (available in About System) KDE Plasma Version: 5.25.0 KDE Frameworks Version: 5.95.0 Qt Version: 5.15.4 ADDITIONAL INFORMATION N/A -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 455170] New: "Maximization" visual effect briefly appears *above* window when moving window away from activation point at top of screen
https://bugs.kde.org/show_bug.cgi?id=455170 Bug ID: 455170 Summary: "Maximization" visual effect briefly appears *above* window when moving window away from activation point at top of screen Product: kwin Version: 5.24.5 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: adam.m.fontenot+...@gmail.com Target Milestone: --- Created attachment 149627 --> https://bugs.kde.org/attachment.cgi?id=149627=edit screen recording of the problem SUMMARY When using the top screen edge to maximize a window, an effect is used to indicate to the user that the window will be maximized if they release the mouse button. This looks like a kind of partially transparent dark rectangle that starts behind the window and expands to fill the screen. However, if the user decides not to maximize the window, and instead moves the cursor away from the top edge of the screen while continuing to keep the mouse button held, the transparent effect will quickly fade away - but while it is doing so, it will appear *on top* of the window, causing a brief undesirable "flash". on the window. A screen recording clearly showing the issue if you step frame by frame is attached. STEPS TO REPRODUCE 1. Make sure the top screen edge is set to maximize dragging windows (Workplace Behavior > Screen Edges in System Settings). 2. Drag a window to the top of the screen and hold it there. 3. While continuing to hold the window, move it away from the top edge. OBSERVED RESULT The moment that the maximization will no longer occur if the mouse button is released, the effect starts to fade. At that same moment, the effect (a dark transparent rectangle) appears *above* the window held by the mouse, whereas before it appeared below that window. EXPECTED RESULT The effect fades away, while remaining below the held window. SOFTWARE/OS VERSIONS Linux: Arch Linux x86_64 (kernel version 5.17.8) KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.4 ADDITIONAL INFORMATION Only tested on X11. Graphics processor is integrated Intel chip, on the Mesa driver. -- You are receiving this mail because: You are watching all bug changes.
[kwallet-pam] [Bug 453932] I never setup kdewallet, I just started getting prompts for password
https://bugs.kde.org/show_bug.cgi?id=453932 Adam Piggott changed: What|Removed |Added CC||kde-bugs@proactiveservices. ||co.uk --- Comment #5 from Adam Piggott --- This started happening on my system on 2022-05-25; I have also not set up or consciously used KWallet. I was initially prompted for my WiFi credentials after rebooting my system and logging on. I tried logging off and on again. No prompt for WiFi credentials, and WiFi was working, but I received the same KWallet prompt as OP. I also see a prompt if I try to open the desktop programs Skype or Element (both which use Electron). Operating System: Ubuntu 20.04 KDE Plasma Version: 5.18.8 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 Kernel Version: 5.4.0-113-generic OS Type: 64-bit Processors: 4 × Intel® Core™ i5-3320M CPU @ 2.60GHz Memory: 11.5 GiB of RAM -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 431396] Window decoration buttons are mis-rendered
https://bugs.kde.org/show_bug.cgi?id=431396 --- Comment #17 from Adam Fontenot --- (In reply to Jin Liu from comment #16) > How to fix it: > 1. trash ~/.config/gtk-3.0 > 2. in kde-gtk-config, set theme to Breeze > > So seems the problem is that kde-gtk doesn't regenerate gtk config files > when kde global theme changes. This didn't fix the issue for me, I think you might be seeing something else. Maybe you can provide a screenshot of what you see? I think if KDE is supposed to changing the gtk config when the global theme changes (maybe Nate can confirm?), if it is not doing that, it's probably a separate bug. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 453973] New: Deshake_opencl filter not working
https://bugs.kde.org/show_bug.cgi?id=453973 Bug ID: 453973 Summary: Deshake_opencl filter not working Product: kdenlive Version: 21.12.3 Platform: Ubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Effects & Transitions Assignee: vpi...@kde.org Reporter: adam.skoblin...@gmail.com Target Milestone: --- SUMMARY The following message appears after applying the "deshake_opencl" filter to a movie: "[filter avfilter.deshake_opencl filter5] Cannot configure the filter graph" STEPS TO REPRODUCE 1. Add a clip to the project, insert it to the timeline 2. Select the deshake_opencl effect 3. Apply it to the clip in the timeline OBSERVED RESULT [filter avfilter.deshake_opencl filter5] Cannot configure the filter graph SOFTWARE/OS VERSIONS DISTRIB_ID=Ubuntu DISTRIB_RELEASE=22.04 DISTRIB_CODENAME=jammy DISTRIB_DESCRIPTION="Ubuntu 22.04 LTS" -- You are receiving this mail because: You are watching all bug changes.
[Ruqola] [Bug 453732] New: crash on Mac when hitting backspace in the channel quicksearch while a search is running
https://bugs.kde.org/show_bug.cgi?id=453732 Bug ID: 453732 Summary: crash on Mac when hitting backspace in the channel quicksearch while a search is running Product: Ruqola Version: 1.7.1 Platform: Compiled Sources OS: Other Status: REPORTED Severity: crash Priority: NOR Component: frontend Assignee: mon...@kde.org Reporter: a...@kde.org Target Milestone: --- Created attachment 148789 --> https://bugs.kde.org/attachment.cgi?id=148789=edit backtrace I'm using nightly builds from KDE of ruqola on an M1 Mac. When I trigger a channel list quicksearch/filter, mistype and then hit backspace to correct my query I get the attached crash. Seems timing/state related as the crash is not 100% reproducible, but it happens fairly often to me. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 443538] Download New Stuff cannot be closed after closing Dolphin
https://bugs.kde.org/show_bug.cgi?id=443538 --- Comment #2 from Adam P --- Maybe related? https://bugs.kde.org/show_bug.cgi?id=450702 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 451150] Clicking the close button in the Present Windows effect frequently fails the first time
https://bugs.kde.org/show_bug.cgi?id=451150 --- Comment #3 from Adam Fontenot --- (In reply to Fushan Wen from comment #2) > My observation is the first click on the close button is always successful, > but the second click is always invalid. Same in the Window View effect. Interesting. Your report got me to investigate further, and it looks like we are experiencing the same issue. More precisely, what we are both seeing (I think) is that the close button click fails *every other* time, even if the present windows effect has been closed in between attempts to close windows. So in this report, I say it frequently fails the first time, but what is actually happening (it seems, based on testing) is that it's failing 50% of the time. Half the time it works the first time, but then it will fail the next time you use it, even if that's minutes or hours later. I noticed this aspect of the problem and reported it as this bug. In your bug report, you're noticing that it fails the *second* time, because you were testing trying to close multiple windows in one go. But actually, I think you will discover that if you successfully close a window, then it will fail the next time you try to use it. @Nate or other devs not experiencing this issue: I can record another screencast showing the problem if the above description isn't clear enough. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 452837] Automount mounts non-removable devices
https://bugs.kde.org/show_bug.cgi?id=452837 --- Comment #3 from Adam Williamson --- Yeah, that's the commit I thought had changed things too. I didn't know how much of the change was intentional, though. -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 452837] New: Automount mounts non-removable devices
https://bugs.kde.org/show_bug.cgi?id=452837 Bug ID: 452837 Summary: Automount mounts non-removable devices Product: kde Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: unassigned-b...@kde.org Reporter: ad...@happyassassin.net Target Milestone: --- SUMMARY With plasma-desktop 5.24.4, automounting of "known devices" on "Login" and "Attach" is enabled by default. These settings are shown under "Removable Devices" in System Settings. However, despite that name, it seems they affect non-removable devices. We found this out in a Fedora downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=2073708 . The problem happens if you try to install Fedora 36 over the top of an existing Fedora or RHEL installation which uses LVM. When the Fedora installer goes to delete the existing LVs, it activates them (this is "to be able to wipe the file system from them"), and KDE sees the device appear and automounts it (it's "known" because it was mounted earlier in the boot or install process, I think). It does this even if the LV is on an internal, non-removable hard disk. STEPS TO REPRODUCE This is the reproducer I know of: 1. Install Fedora or RHEL with an LVM layout, ideally with more than one LV (e.g. a /home and a root partition) - older Fedora releases on larger disks do this by default, otherwise you can do it in custom partitioning 2. Boot a current Fedora 36 KDE live image, e.g. https://kojipkgs.fedoraproject.org/compose/branched/Fedora-36-20220421.n.0/compose/Spins/x86_64/iso/Fedora-KDE-Live-x86_64-36-20220421.n.0.iso 3. Run through the installer, choosing to wipe the existing partitions to provide space for the install 4. Try and run the install; it will likely fail at the start, complaining that "device is active". This seems to be slightly racy, for me it happens about 1 in 2 tries. Snapshotting a VM after point 1 is a good idea There are likely much simpler ways to do it, though. Probably just creating some LVs on a non-removable disk, then playing with mounting/unmounting and activating/deactivating them will do the trick. OBSERVED RESULT Filesystem on the LV on a non-removable disk gets automounted EXPECTED RESULT Filesystems on non-removable disk should not be automounted, since the config settings refer specifically to "Removable Devices" SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.24.3 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION Filing against this component because there doesn't seem to be a match for plasma-desktop, which is where the code seems to be: https://github.com/KDE/plasma-desktop/blob/master/solid-device-automounter/kded/DeviceAutomounter.cpp . It doesn't look to me like anything there is actually doing any kind of check that a filesystem is on a removable drive. Maybe the assumption is that only filesystems on "removable" drives would suddenly appear or disappear, but that's an incorrect assumption as we see with LVs. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kservice] [Bug 452566] KDE offers to open mimetype with application twice when it inherits the association twice
https://bugs.kde.org/show_bug.cgi?id=452566 --- Comment #3 from Adam Fontenot --- (In reply to Ahmad Samir from comment #1) > First things first, could you verify you only have one okular .desktop file > in /usr/share/applications/ and ~/.local/share/applications/ ? Yes, I only have /usr/share/applications/org.kde.okular.desktop -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kservice] [Bug 452566] New: KDE offers to open mimetype with application twice when it inherits the association twice
https://bugs.kde.org/show_bug.cgi?id=452566 Bug ID: 452566 Summary: KDE offers to open mimetype with application twice when it inherits the association twice Product: frameworks-kservice Version: 5.93.0 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: fa...@kde.org Reporter: adam.m.fontenot+...@gmail.com CC: kdelibs-b...@kde.org Target Milestone: --- SUMMARY This is related to, but not quite the same as, Bug 425154 (see last comment), which describes a corner case that still needs to be addressed... Basically, if a mimetype inherits the same application twice (which can easily happen in multiple-inheritance cases), KDE will show the application twice in menus and the system settings module. STEPS TO REPRODUCE 1. Create a JSON file. 2. Set okular to open the mimetypes "application/x-executable" and "text/plain". Apply changes. 3. Right click on the JSON file in dolphin, and see what programs are made available to open the file. OBSERVED RESULT Okular appears twice in the results. EXPECTED RESULT Okular appears once in the results, at the position it inherits *first* in a breadth-first search of the inherited mimetypes of application/json. SOFTWARE/OS VERSIONS Linux: Arch Linux (kernel 5.17.1) KDE Plasma Version: 5.24.4 (X11) KDE Frameworks Version: 5.93.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION The positions Okular appears at in the results appear to suggest that kservice is searching the inherited mimetypes in depth-first order instead of breadth-first. This is incorrect and leads to the corner case issue described in the comments of Bug 425154. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 439614] Running commands in Konsole becomes slow / laggy when it has been open a long time
https://bugs.kde.org/show_bug.cgi?id=439614 Adam Fontenot changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |NOT A BUG --- Comment #3 from Adam Fontenot --- I believe I managed to track down the cause of this, and I don't think it's a Konsole bug. It's actually because I'm using ZSH as my shell. It has some complicated options that try to interweave the history for all active shells, and it looks like this history isn't getting finalized and flushed to the history file until all active ZSH shells are closed (or possibly until a logout happens?). The result of this is that the in-memory version of the history gets more and more complicated over time, and this results in extreme input lag. Closing this under the assumption that ZSH is to blame. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 451151] Hovering windows in the Present Windows effects creates a gap between the window title and window content
https://bugs.kde.org/show_bug.cgi?id=451151 --- Comment #3 from Adam Fontenot --- I tested and was able to reproduce this on different hardware with a separate KDE installation. It's not consistent, even on my hardware. The bug seems to appear when a resize operation occurs on the window preview bitmap of a particular size. Certain amounts of resizing cause the gap to appear, others do not. In the following screenshot, you can clearly see that it *is* a gap that appears, not just a line. You can see hints of the background image (one of the default KDE wallpapers) behind the window: https://i.imgur.com/yrZ3CXY.png -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 431396] Window decoration buttons are mis-rendered
https://bugs.kde.org/show_bug.cgi?id=431396 Adam Fontenot changed: What|Removed |Added Status|NEEDSINFO |REOPENED Resolution|WAITINGFORINFO |--- --- Comment #15 from Adam Fontenot --- (In reply to Nate Graham from comment #14) > we track those bugs here in systemsettings | kcm_style. So it's in the right > place. > > What Plasma version are you using, Adam? Reproduced it just now with 5.24.4, official Arch Linux package. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 431396] Window decoration buttons are mis-rendered
https://bugs.kde.org/show_bug.cgi?id=431396 --- Comment #13 from Adam Fontenot --- (In reply to Jan Blackquill from comment #12) > Cannot reproduce; if you can still reproduce, this is likely an issue with > kde-gtk-config and not Breeze GTK. Moving this there. I can still reproduce this. Here's a quick screenshot of the eye of gnome (image viewer) preferences window: https://i.imgur.com/9N4JNf6.png It doesn't look like this bug is filed against kde-gtk-config. Do you want me to file a new bug to follow up on this issue? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 451150] Clicking the close button in the Present Windows effect frequently fails the first time
https://bugs.kde.org/show_bug.cgi?id=451150 --- Comment #1 from Adam Fontenot --- Need to revise one point slightly: for some reason I was going off the video when I said the button didn't activate. This is not actually true. In Present Windows, I can hold the button down with the cursor over a close button for half a second or so, enough time to for the button animation to take effect, and it is clearly activating. Despite this, the window does not close when I release the button. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 451151] Hovering windows in the Present Windows effects creates a gap between the window title and window content
https://bugs.kde.org/show_bug.cgi?id=451151 --- Comment #2 from Adam Fontenot --- (In reply to Niklas Stephanblome from comment #1) > Can't reproduce, what do you mean by "a gap appears"? This is almost certainly some kind of graphics / openGL bug, so it's not too surprising if not everyone can reproduce it. Can you see my screenshot of the problem attached to the issue? When in Present Windows, if I hover over a window it changes the size of the window. The is just a static bitmap preview of the window contents, and it looks like the window titlebar and the window are rendered as separate bitmaps. Resizing them at the same time creates aliasing artifacts between them, creating a gap between them through which you can kind of see colors from the background flickering through. In my screenshot, this is happening on the top left, just under the window title bar. -- You are receiving this mail because: You are watching all bug changes.
[kalendar] [Bug 452288] Event deletion prompt is unnecessarily large on desktop
https://bugs.kde.org/show_bug.cgi?id=452288 --- Comment #1 from Adam P --- Created attachment 147978 --> https://bugs.kde.org/attachment.cgi?id=147978=edit A rough simulation of the expected appearance -- You are receiving this mail because: You are watching all bug changes.
[kalendar] [Bug 452288] New: Event deletion prompt is unnecessarily large on desktop
https://bugs.kde.org/show_bug.cgi?id=452288 Bug ID: 452288 Summary: Event deletion prompt is unnecessarily large on desktop Product: kalendar Version: 1.0.0 Platform: Manjaro OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: claudio.cam...@gmail.com Reporter: platke...@centrum.cz CC: c...@carlschwan.eu Target Milestone: --- Created attachment 147977 --> https://bugs.kde.org/attachment.cgi?id=147977=edit Screenshot of the deletion prompt SUMMARY The confirmation dialog asking if you are sure to delete an item shows a disproportionately large icon which makes the window layout look weird and inconsistent with the rest of the system. STEPS TO REPRODUCE 1. Right-click an event. 2. Select "Delete" from the context menu. OBSERVED RESULT The window that pops up has a very large icon. EXPECTED RESULT The windows layout is closer to regular KDialog. SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 5.24.3 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.3 Kernel Version: 5.16.14-1-MANJARO (64-bit) Graphics Platform: X11 Processors: 12 × Intel® Core™ i5-10400F CPU @ 2.90GHz Memory: 15,5 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 1660 SUPER/PCIe/SSE2 -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 451915] Feature request: Allow files to be dragged and dropped from dolphin into the file, documents and project section.
https://bugs.kde.org/show_bug.cgi?id=451915 Adam Dymitruk changed: What|Removed |Added CC||a...@dymitruk.com -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 451915] New: Feature request: Allow files to be dragged and dropped from dolphin into the file, documents and project section.
https://bugs.kde.org/show_bug.cgi?id=451915 Bug ID: 451915 Summary: Feature request: Allow files to be dragged and dropped from dolphin into the file, documents and project section. Product: kate Version: 22.03.80 Platform: unspecified OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: a...@dymitruk.com Target Milestone: --- When working with a project and gathering resources for images or other files, it would be a lot simpler to allow a drag and drop action from dolphin or other source to copy a file to a project. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 445681] Notifications keep being a spammed repeatedly
https://bugs.kde.org/show_bug.cgi?id=445681 Adam Dymitruk changed: What|Removed |Added CC||a...@dymitruk.com -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 400704] Baloo indexing I/O introduces serious noticable delays
https://bugs.kde.org/show_bug.cgi?id=400704 Adam Fontenot changed: What|Removed |Added CC||adam.m.fontenot+kde@gmail.c ||om --- Comment #43 from Adam Fontenot --- (In reply to tagwerk19 from comment #38) > It would make sense to have time/memory limits for such actions (and > flag the file as > "failed" if the extraction exceeds them). Was thinking about this and similar IO problems, and decided to have a look at how Gnome's "tracker" is handling things these days. Going to document my findings here in the hope it's useful as inspiration for how we might handle similar problems. I think it's an important point of comparison for Baloo. I have mostly positive things to say, although Tracker also has some flaws (it didn't pick up my XDG Documents folder by default, it didn't index the contents of files with text/plain mimetimes that don't have file extensions, and it uses a large amount of CPU while searching in Nautilus). * I enabled Tracker to index my home folder (with content indexing) and it uses 474 MB on my $HOME. I've completely disabled content indexing for Baloo, but it's somehow using 1.4 GB. Suffice it to say that Baloo is weirdly inefficient. (ContentIndexingDB is empty, so it's not old content indexes.) More research needed here, any suggestions appreciated. * Unlike Baloo, Tracker does not hang when given pathological files. (See the link in tagwerk19's comment for an example.) I get a very sensible "Crash/hang handling file" message in the log for this file and it's otherwise ignored. Among other checks, they appear to kill the process if the content indexer takes more than 30 seconds on a file, which seems quite reasonable: https://gitlab.gnome.org/GNOME/tracker-miners/-/blob/master/src/tracker-extract/tracker-extract.c * They have some cool features around full text search including unaccenting and case folding, and use SPARQL for queries: https://wiki.gnome.org/Projects/Tracker/Features I haven't seen enough documentation from Baloo to know how we stack up there. * Tracker and Baloo both blacklist source code files by default, among several other types. Baloo doesn't expose this to the user in the UI, which I think might surprise some users who expect more configurability from KDE. * Tracker seems not to be very configurable. There's a bit of under the hood adjustment possible, but mostly the focus seems to be on having good heuristics out of the box. I don't think we could trivially swap Tracker for Baloo and having everything we need work. We'll need to keep improving Baloo. :-) This comment might be better off on the Wiki somewhere, but it seems pretty underutilized and I'm not sure where I'd put it or if anyone would even read it there. -- You are receiving this mail because: You are watching all bug changes.
[Active Window Control] [Bug 451568] New: How Do I Activate Cash App Card Automatically Or Manually?
https://bugs.kde.org/show_bug.cgi?id=451568 Bug ID: 451568 Summary: How Do I Activate Cash App Card Automatically Or Manually? Product: Active Window Control Version: unspecified Platform: Other OS: Other Status: REPORTED Severity: normal Priority: NOR Component: General Assignee: zrenf...@gmail.com Reporter: adamkent2...@gmail.com CC: plasma-b...@kde.org Target Milestone: --- Once you receive your Cash App visa debit card, you have to first Activate Cash App Card if you are looking to leverage it at its best. There are two different modes of activating your Cash App card without any kind of hassle, either manually or automatically, in a couple of seconds. https://www.contactmail-support.com/blog/how-to-activate-cash-app-card/ -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 427060] Cursor "hit box" is offset under Wayland on VMs (VMWare, VirtualBox, ...)
https://bugs.kde.org/show_bug.cgi?id=427060 --- Comment #28 from Adam Williamson --- >From my perspective it seems like this got fixed, then came back. In Fedora 35 we were suffering from this; I backported https://github.com/KDE/kwin/commit/998bbf4eba724a9b94a5bae62182456b85b11383#diff-034885748897f413c645e3efd125d7c0db9a8454d580f6093e40c885d974c818 , and that fixed it. Now people are reporting in F36 Beta that it's back again. What changed upstream? Was that fix reverted or lost? -- You are receiving this mail because: You are watching all bug changes.
[Active Window Control] [Bug 451305] New: Is The Cash App ++ Real To Use To Send Or Receive Money?
https://bugs.kde.org/show_bug.cgi?id=451305 Bug ID: 451305 Summary: Is The Cash App ++ Real To Use To Send Or Receive Money? Product: Active Window Control Version: unspecified Platform: Other OS: Other Status: REPORTED Severity: normal Priority: NOR Component: General Assignee: zrenf...@gmail.com Reporter: adamkent2...@gmail.com CC: plasma-b...@kde.org Target Milestone: --- Is The Cash App ++ Real to send or receive money from your Cash App account? All you have to do is to have a word with the professionals and experts who will provide you with the right kind of assistance to get rid of hassles and hurdles permanently from the root, in every possible manner. https://www.emailsupport-contact.com/blog/how-do-i-get-cash-app-plus-plus/ -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 451156] New: Changes to shadows in Breeze window decoration options don't propagate to the gtk theme
https://bugs.kde.org/show_bug.cgi?id=451156 Bug ID: 451156 Summary: Changes to shadows in Breeze window decoration options don't propagate to the gtk theme Product: Breeze Version: 5.24.2 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: gtk theme Assignee: uhh...@gmail.com Reporter: adam.m.fontenot+...@gmail.com CC: plasma-b...@kde.org Target Milestone: --- SUMMARY I'm using the Breeze window decorations and the Breeze application style as well. Breeze-GTK is set as my GTK application style (using the System Settings module). I find the default window shadows for Breeze to be much too large and dark - actually they're strong enough that they create a small amount of banding on my screen, which I find intolerable - and so I make it much smaller and lighter. Unfortunately, even though KDE seems to control the appearance of most GTK applications pretty well, changing the shadow settings doesn't do anything at all. STEPS TO REPRODUCE 1. Make sure all instances of a Gnome application (the Image Viewer, eog, is my go-to for testing) are closed, and that you are using the Breeze window decorations and Breeze-GTK as your Gnome/GTK theme. This bug is reproduced under KDE, not in a Gnome session. 2. Change the shadow setting for your window decorations. System Settings > Appearance > Global Theme > Window Decorations; click the edit "pencil" icon on the Breeze theme in the main window; use the Shadow tab. Click OK and make sure the changes are properly applied in KDE applications. 3. Reopen a Gnome / GTK application. OBSERVED RESULT No change to the shadows of the GTK application. EXPECTED RESULT The GTK application window should have exactly the same shadows as other windows under KWin - at least when the matching themes Breeze and Breeze GTK are used. SOFTWARE/OS VERSIONS Linux: Arch Linux kernel 5.16.11 x86_64 KDE Plasma Version: 5.24.2 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION Graphics platform is X11. I was able to work around the issue by manually changing the window shadows in ~/.config/gtk-3.0/gtk.css. Since (I think?) KDE manages these files when the Settings module changes the options for GTK applications, it should be possible to add handling for changing the shadows automatically. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 414559] Running "sudo udevadm trigger -s input" resets touchpad configuration; can happen after system upgrade
https://bugs.kde.org/show_bug.cgi?id=414559 --- Comment #22 from Adam E --- Sorry, I didn't realize I can't edit my replies so adding some more information here: Using Xorg, not wayland (although the system does have some wayland packages installed) Using libinput not synaptics. I got here from Bug 435113 which seems more similar to my issue but that report says they did not have an issue with this udevadm command. Let me know if I can provide any additional information or assistance -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 414559] Running "sudo udevadm trigger -s input" resets touchpad configuration; can happen after system upgrade
https://bugs.kde.org/show_bug.cgi?id=414559 --- Comment #21 from Adam E --- Hi all, I'm on latest Arch Linux on a desktop and experiencing the same issue. Running the command resets mouse sensitivity settings - tested by lowering mouse sensitivity and then running that command. In my case I use a dock to switch inputs between two computers and so on every switch the mouse sensitivity is reset. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 414559] Running "sudo udevadm trigger -s input" resets touchpad configuration; can happen after system upgrade
https://bugs.kde.org/show_bug.cgi?id=414559 Adam E changed: What|Removed |Added CC||linuxad...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 435113] certain mouse settings resets after restart/resume from suspend/dock/undock
https://bugs.kde.org/show_bug.cgi?id=435113 Adam E changed: What|Removed |Added CC||linuxad...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 449276] kdeconnectd intermittent crash while in the background
https://bugs.kde.org/show_bug.cgi?id=449276 Adam Mizerski changed: What|Removed |Added CC||a...@mizerski.pl -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 438883] Re-implement Desktop Cube effect with modern effects API
https://bugs.kde.org/show_bug.cgi?id=438883 Adam Wenocur changed: What|Removed |Added CC||aweno...@gmail.com --- Comment #22 from Adam Wenocur --- long-time Plasma user here, since KDE 3.0. I created an account on this bugzilla, having never had complaints about KDE in the past twenty years. My first issue is to add my voice to this list requesting the cube transition be returned. I started running 5.23.5 last month, as it was declared stable in the Gentoo main portage tree. I appreciate the reason for it and look forward to better compositing, but the 3D animated transitions are not a niche feature. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 449273] Mouse clicks from openQA (automated test framework) in Fedora installer on KDE 5.23.90 stop working shortly after it starts
https://bugs.kde.org/show_bug.cgi?id=449273 --- Comment #24 from Adam Williamson --- Yeah, confirmed, clicking twice in the same place does not help at all. Neither with nor without the "mouse hide" operation in between clicks. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 449273] Mouse clicks from openQA (automated test framework) in Fedora installer on KDE 5.23.90 stop working shortly after it starts
https://bugs.kde.org/show_bug.cgi?id=449273 --- Comment #23 from Adam Williamson --- Oh well, that answers a question I was about to look into, which was "could this be to do with https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4123 ?" - it sounds like the answer is 'no'. I'm double-checking the answer to Vlad's question to me right now, I'm pretty sure the answer is "clicking twice doesn't help at all" but just double checking that. -- You are receiving this mail because: You are watching all bug changes.
[kontact] [Bug 449872] Kontact crashed while trying to reply to email
https://bugs.kde.org/show_bug.cgi?id=449872 --- Comment #8 from Adam Jimerson --- (In reply to lod from comment #7) > If you want to start kmail/kontact again, you have to remove > ~/.local/share/kmail2/autosave/ > > It saves the broken state and tries to restore it at start up. It's also not > related to all email accounts, some just work like usual. Confirmed, this does allow me to launch Kontact/Kmail again. Should there be a guard against this causing Kmail/Kontact from segfaulting if it is unable to restore from whatever is stored there? -- You are receiving this mail because: You are watching all bug changes.
[kontact] [Bug 449872] Kontact crashed while trying to reply to email
https://bugs.kde.org/show_bug.cgi?id=449872 --- Comment #6 from Adam Jimerson --- Created attachment 146532 --> https://bugs.kde.org/attachment.cgi?id=146532=edit Stacktrace from just launching Kmail This is the stacktrace I get when I just launch Kmail instead of Kontact. -- You are receiving this mail because: You are watching all bug changes.
[kontact] [Bug 449872] Kontact crashed while trying to reply to email
https://bugs.kde.org/show_bug.cgi?id=449872 --- Comment #5 from Adam Jimerson --- Oh boy I did not realize that reporting this crash via drkonqi would put the whole stacktrace in the body instead of an attachment... Either way I'll try and provide some additional information on top of the excellent work that Sven did. > When I start KMail only, it also crashes and consists of this in the stack > trace After giving up on launching Kontact yesterday, I also tried just launching Kmail2 as a standalone and it crash as well. Both Kontact and Kmail2 segfaults before any window appears but after the launch feedback animation is triggered. So it must be happening very ealier in the execution of Kontact (or maybe even Kmail2 and it is killing Kontact with it). Question for the devs: Between my testing and Sven's it sounds like I may have incorrectly reported this and the real issue is Kmail2 and Kontact is just an innocent by standard being brought down with Kmail? > However, when I restart akonadi, I get notifications about new E-Mails Interestingly, the new E-Mail notification continued to work for me without having to restart akonadi, and it is working today after a full system reboot. Note, I have not tried uninstalling Sonnet like Sven has. -- You are receiving this mail because: You are watching all bug changes.
[kontact] [Bug 449872] New: Kontact crashed while trying to reply to email
https://bugs.kde.org/show_bug.cgi?id=449872 Bug ID: 449872 Summary: Kontact crashed while trying to reply to email Product: kontact Version: unspecified Platform: Archlinux Packages OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: kdepim-b...@kde.org Reporter: vend...@gmail.com Target Milestone: --- Application: kontact (5.19.2 (21.12.2)) Qt Version: 5.15.2 Frameworks Version: 5.90.0 Operating System: Linux 5.16.7-arch1-1 x86_64 Windowing System: X11 Distribution: "Arch Linux" DrKonqi: 5.24.0 [KCrashBackend] -- Information about the crash: - What I was doing when the application crashed: When trying to reply to an email with the "a" keyboard shortcut Kontact crashed and continunally crashes when trying to restart the application. The crash can be reproduced every time. -- Backtrace: Application: Kontact (kontact), signal: Segmentation fault [KCrash Handler] #4 std::__atomic_base::load(std::memory_order) const (__m=std::memory_order_relaxed, this=0x8) at /usr/include/qt/QtCore/qrefcount.h:54 #5 QAtomicOps::loadRelaxed(std::atomic const&) (_q_value=...) at /usr/include/qt/QtCore/qatomic_cxx11.h:239 #6 QBasicAtomicInteger::loadRelaxed() const (this=0x8) at /usr/include/qt/QtCore/qbasicatomic.h:107 #7 QtPrivate::RefCount::ref() (this=0x8) at /usr/include/qt/QtCore/qrefcount.h:55 #8 QString::QString(QString const&) (this=0x7ffcc1136340, other=..., this=, other=) at /usr/include/qt/QtCore/qstring.h:1094 #9 0x7f7009c03b86 in std::_Head_base<3ul, QString, false>::_Head_base(QString const&) (__h=..., this=0x7ffcc1136340, this=, __h=) at /usr/include/c++/11.1.0/tuple:182 #10 std::_Tuple_impl<3ul, QString, QString>::_Tuple_impl(QString const&, QString const&) (__tail#0=, __head=..., this=0x7ffcc1136338) at /usr/include/c++/11.1.0/tuple:270 #11 std::_Tuple_impl<2ul, QString, QString, QString>::_Tuple_impl(QString const&, QString const&, QString const&) (__tail#1=, __tail#0=..., __head=..., this=0x7ffcc1136338) at /usr/include/c++/11.1.0/tuple:270 #12 std::_Tuple_impl<1ul, GpgME::Key, QString, QString, QString>::_Tuple_impl(GpgME::Key const&, QString const&, QString const&, QString const&) (__tail#2=, __tail#1=..., __tail#0=..., __head=..., this=0x7ffcc1136338) at /usr/include/c++/11.1.0/tuple:270 #13 std::_Tuple_impl<0ul, std::_Placeholder<1>, GpgME::Key, QString, QString, QString>::_Tuple_impl(std::_Placeholder<1> const&, GpgME::Key const&, QString const&, QString const&, QString const&) (__tail#3=, __tail#2=..., __tail#1=..., __tail#0=..., __head=, this=0x7ffcc1136338) at /usr/include/c++/11.1.0/tuple:270 #14 std::tuple, GpgME::Key, QString, QString, QString>::tuple(std::_Placeholder<1> const&, GpgME::Key const&, QString const&, QString const&, QString const&) (__elements#4=, __elements#3=..., __elements#2=..., __elements#1=..., __elements#0=, this=0x7ffcc1136338) at /usr/include/c++/11.1.0/tuple:719 #15 std::_Bind (*(std::_Placeholder<1>, GpgME::Key, QString, QString, QString))(GpgME::Context*, GpgME::Key const&, QString const&, QString const&, QString const&)>::_Bind const&, GpgME::Key const&, QString const&, QString const&, QString const&>(std::tuple (*&&)(GpgME::Context*, GpgME::Key const&, QString const&, QString const&, QString const&), std::_Placeholder<1> const&, GpgME::Key const&, QString const&, QString const&, QString const&) (__f=, this=) at /usr/include/c++/11.1.0/functional:490 #16 std::bind (*)(GpgME::Context*, GpgME::Key const&, QString const&, QString const&, QString const&), std::_Placeholder<1> const&, GpgME::Key const&, QString const&, QString const&, QString const&>(std::tuple (*&&)(GpgME::Context*, GpgME::Key const&, QString const&, QString const&, QString const&), std::_Placeholder<1> const&, GpgME::Key const&, QString const&, QString const&, QString const&) (__f=) at /usr/include/c++/11.1.0/functional:793 #17 QGpgME::QGpgMEAddUserIDJob::start(GpgME::Key const&, QString const&, QString const&, QString const&) (this=0x562d32e9f830, key=..., name=..., email=..., comment=) at /build/gpgme/src/gpgme-1.17.0/lang/qt/src/qgpgmeadduseridjob.cpp:82 #18 0x7f70098fe059 in KMComposerWin::slotRecipientAdded(MessageComposer::RecipientLineNG*) (this=0x562d31d2fe70, line=) at /usr/src/debug/kmail-21.12.2/src/editor/kmcomposerwin.cpp:3776 #19 0x7f707abfad93 in QtPrivate::QSlotObjectBase::call(QObject*, void**) (a=0x7ffcc11365a0, r=, this=0x562d32e41f50, this=, r=, a=) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398 #20 doActivate(QObject*, int, void**) (sender=0x562d32808940, signal_index=15, argv=0x7ffcc11365a0) at kernel/qobject.cpp:3886 #21 0x7f700927e364 in MessageComposer::RecipientLineNG::analyzeLine(QString const&) (this=0x562d32808940, text=) at /usr/src/debug/messagelib-21.12.2/messagecomposer/src/recipient/recipientline.cpp:120 #22 0x7f707abfad93
[kwin] [Bug 449273] Mouse clicks from openQA (automated test framework) in Fedora installer on KDE 5.23.90 stop working shortly after it starts
https://bugs.kde.org/show_bug.cgi?id=449273 --- Comment #20 from Adam Williamson --- I just checked, and it looks like we've had 5.24.0 in Rawhide for a few days. Unfortunately the bug is still present :( -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 449273] Mouse clicks from openQA (automated test framework) in Fedora installer on KDE 5.23.90 stop working shortly after it starts
https://bugs.kde.org/show_bug.cgi?id=449273 --- Comment #18 from Adam Williamson --- As mentioned above I tried a git snapshot on 2022-01-28. If the fix landed after that, though, it's a possibility. I'll try in the morning. -- You are receiving this mail because: You are watching all bug changes.
[knights] [Bug 449639] Segmentation fault while playing against the computer
https://bugs.kde.org/show_bug.cgi?id=449639 --- Comment #1 from Adam Jimerson --- Created attachment 146296 --> https://bugs.kde.org/attachment.cgi?id=146296=edit Game log Attaching the game log file as well just encase it is helpful. -- You are receiving this mail because: You are watching all bug changes.
[knights] [Bug 449639] New: Segmentation fault while playing against the computer
https://bugs.kde.org/show_bug.cgi?id=449639 Bug ID: 449639 Summary: Segmentation fault while playing against the computer Product: knights Version: 2.6.21122 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: alexander.se...@web.de Reporter: vend...@gmail.com CC: kde-games-b...@kde.org Target Milestone: --- Created attachment 146295 --> https://bugs.kde.org/attachment.cgi?id=146295=edit Backtrace from segfault. SUMMARY While playing a game against the computer using the gnuchess game engine and the xboard protocal Knights crashed with a segmentation fault. STEPS TO REPRODUCE 1. Start a new game with 1 human player and one computer playing (gnuchess & xboard) 2. Play the game for a little while 3. Game will crash while "Computer is thinking" OBSERVED RESULT The game hung at "computer is thinking" for several minutes before eventually crashing. EXPECTED RESULT Game shouldn't crash SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.23.5 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2 Kernel Version: 5.16.5-arch1-1 (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-6820HQ CPU @ 2.70GHz Memory: 31.2 GiB of RAM Graphics Processor: Quadro M1000M/PCIe/SSE2 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 447949] lsp-client: gopls results in constant errors when typing
https://bugs.kde.org/show_bug.cgi?id=447949 Adam Jimerson changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 449273] Mouse clicks from openQA (automated test framework) in Fedora installer on KDE 5.23.90 stop working shortly after it starts
https://bugs.kde.org/show_bug.cgi?id=449273 --- Comment #16 from Adam Williamson --- https://gitlab.gnome.org/GNOME/mutter/-/issues/2117 , and the fix was https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2257 . Definitely not the same bug as it's mutter and mutter isn't involved here, but it was an odd coincidence that they showed up around the same time. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 449273] Mouse clicks from openQA (automated test framework) in Fedora installer on KDE 5.23.90 stop working shortly after it starts
https://bugs.kde.org/show_bug.cgi?id=449273 --- Comment #13 from Adam Williamson --- Created attachment 146234 --> https://bugs.kde.org/attachment.cgi?id=146234=edit KWIN_XWAYLAND_DEBUG=1 messages from anaconda This is /var/log/messages from an openQA failure with KWIN_XWAYLAND_DEBUG=1 set via /etc/profile.d. The relevant messages should be around the 13:09:21 mark in the log - the messages from Anaconda about setting the locale to en_US.UTF-8 should come from the point where the test types 'english' into the entry box and clicks on "English (United States)", right before the point where it tries to click Continue and it doesn't work. The timestamps on the logs from the VM itself and the logs from the test runner don't always match precisely, but FWIW, here are the logs of the critical point from the test runner: [2022-02-03T18:09:27.871Z] [debug] tests/_boot_to_anaconda.pm:167 called testapi::assert_and_click [2022-02-03T18:09:27.871141Z] [debug] <<< testapi::assert_and_click(mustmatch="anaconda_select_install_lang_filtered", timeout=30) [2022-02-03T18:09:27.871998Z] [debug] clicking at 686/206 [2022-02-03T18:09:27.872119Z] [debug] tests/_boot_to_anaconda.pm:167 called testapi::assert_and_click [2022-02-03T18:09:27.872211Z] [debug] <<< testapi::mouse_set(x=686, y=206) [2022-02-03T18:09:27.872740Z] [debug] mouse_move 686, 206 [2022-02-03T18:09:27.872876Z] [debug] send_pointer_event 0, 686, 206, 1 [2022-02-03T18:09:27.873272Z] [debug] tests/_boot_to_anaconda.pm:167 called testapi::assert_and_click [2022-02-03T18:09:27.873381Z] [debug] <<< testapi::mouse_click(button="left", cursor_down="0.15") [2022-02-03T18:09:27.873867Z] [debug] pointer_event 1 686, 206 [2022-02-03T18:09:27.874004Z] [debug] send_pointer_event 1, 686, 206, 1 [2022-02-03T18:09:28.024935Z] [debug] pointer_event 0 686, 206 [2022-02-03T18:09:28.025082Z] [debug] send_pointer_event 0, 686, 206, 1 [2022-02-03T18:09:29.025684Z] [debug] tests/_boot_to_anaconda.pm:167 called testapi::assert_and_click [2022-02-03T18:09:29.025885Z] [debug] <<< testapi::mouse_set(x=1023, y=767) [2022-02-03T18:09:29.026785Z] [debug] mouse_move 1023, 767 [2022-02-03T18:09:29.026920Z] [debug] send_pointer_event 0, 1023, 767, 1 [2022-02-03T18:09:29.027420Z] [debug] tests/_boot_to_anaconda.pm:168 called testapi::assert_screen [2022-02-03T18:09:29.027602Z] [debug] <<< testapi::assert_screen(mustmatch="anaconda_select_install_lang_selected", timeout=10) [2022-02-03T18:09:29.038653Z] [debug] no match: 9.9s, best candidate: install_lang_english_selected-testonlycursor-20220128 (0.93) [2022-02-03T18:09:30.173707Z] [debug] >>> testapi::_handle_found_needle: found install_lang_english_selected-20200116, similarity 0.98 @ 605/197 [2022-02-03T18:09:30.173913Z] [debug] tests/_boot_to_anaconda.pm:175 called testapi::assert_and_click [2022-02-03T18:09:30.174063Z] [debug] <<< testapi::assert_screen(mustmatch="anaconda_select_install_lang_continue", timeout=30) [2022-02-03T18:09:31.196994Z] [debug] >>> testapi::_handle_found_needle: found install_lang_continue-20210714, similarity 0.99 @ 926/684 [2022-02-03T18:09:31.197187Z] [debug] tests/_boot_to_anaconda.pm:175 called testapi::assert_and_click [2022-02-03T18:09:31.197326Z] [debug] <<< testapi::assert_and_click(mustmatch="anaconda_select_install_lang_continue", timeout=30) [2022-02-03T18:09:31.198252Z] [debug] clicking at 970/696 [2022-02-03T18:09:31.198373Z] [debug] tests/_boot_to_anaconda.pm:175 called testapi::assert_and_click [2022-02-03T18:09:31.198478Z] [debug] <<< testapi::mouse_set(x=970, y=696) [2022-02-03T18:09:31.199030Z] [debug] mouse_move 970, 696 [2022-02-03T18:09:31.199168Z] [debug] send_pointer_event 0, 970, 696, 1 [2022-02-03T18:09:31.199546Z] [debug] tests/_boot_to_anaconda.pm:175 called testapi::assert_and_click [2022-02-03T18:09:31.199650Z] [debug] <<< testapi::mouse_click(button="left", cursor_down="0.15") [2022-02-03T18:09:31.200157Z] [debug] pointer_event 1 970, 696 [2022-02-03T18:09:31.200271Z] [debug] send_pointer_event 1, 970, 696, 1 [2022-02-03T18:09:31.351157Z] [debug] pointer_event 0 970, 696 [2022-02-03T18:09:31.351279Z] [debug] send_pointer_event 0, 970, 696, 1 [2022-02-03T18:09:32.351940Z] [debug] tests/_boot_to_anaconda.pm:175 called testapi::assert_and_click [2022-02-03T18:09:32.352249Z] [debug] <<< testapi::mouse_set(x=1023, y=767) [2022-02-03T18:09:32.354309Z] [debug] mouse_move 1023, 767 [2022-02-03T18:09:32.354443Z] [debug] send_pointer_event 0, 1023, 767, 1 That's clicking on "English (US)" (at 686/206), moving mouse to 1023/767, then clicking on the continue button (970/696), then moving mouse to 1023/767 again. -- You are receiving this mail because: You are watching all bug changes.
[Falkon] [Bug 449562] Missing or broken FIDO U2F support
https://bugs.kde.org/show_bug.cgi?id=449562 --- Comment #3 from Adam Jimerson --- Sorry just noticed I didn't fully complete the bug template, see below for the rest of the info: STEPS TO REPRODUCE 1. Setup a hardware security key FIDO U2F, or some other common standard on an account in a site that supports it 2. Attempt to login to said site with Falkon 3. Fail to do so as not able to answer the 2 factor auth challenge, and in the case of Google switching to another method is not possible. OBSERVED RESULT Not able to complete second factor auth challenge on sites with a hardware security key enabled. EXPECTED RESULT Either the site realize that using the security key is not possible, allowing use of fallback methods, or ideally for FIDO U2F keys to work. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.23.5 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2 Kernel Version: 5.16.5-arch1-1 (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-6820HQ CPU @ 2.70GHz Memory: 31.2 GiB of RAM Graphics Processor: Quadro M1000M/PCIe/SSE2 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[Falkon] [Bug 449562] Missing or broken FIDO U2F support
https://bugs.kde.org/show_bug.cgi?id=449562 --- Comment #2 from Adam Jimerson --- Created attachment 146229 --> https://bugs.kde.org/attachment.cgi?id=146229=edit GitHub FIDO U2F error -- You are receiving this mail because: You are watching all bug changes.
[Falkon] [Bug 449562] Missing or broken FIDO U2F support
https://bugs.kde.org/show_bug.cgi?id=449562 --- Comment #1 from Adam Jimerson --- Created attachment 146228 --> https://bugs.kde.org/attachment.cgi?id=146228=edit Screenshot from GitHub trying to access FIDO U2F key I was only able to upload one attachment when I created the ticket but for the case of GitHub it is a little different as there in actually errors out after an extended period of time. -- You are receiving this mail because: You are watching all bug changes.
[Falkon] [Bug 449562] New: Missing or broken FIDO U2F support
https://bugs.kde.org/show_bug.cgi?id=449562 Bug ID: 449562 Summary: Missing or broken FIDO U2F support Product: Falkon Version: 3.2.0 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: now...@gmail.com Reporter: vend...@gmail.com Target Milestone: --- Created attachment 146227 --> https://bugs.kde.org/attachment.cgi?id=146227=edit Screenshot of Google login process while trying to use FIDO U2F key for 2 factor authentication SUMMARY Falkon cannot seem to access my FIDO U2F security key, which is a Yubikey Neo. Instead when I get to the point in the login process where it the browser should prompt me to insert my key and press the button the site just hangs waiting to see/access/recognize my key. Using other browsers I'm able to use my key just fine. Example sites: - Any Google service and any site that the user uses their Google account for OAuth (like gitlab.com, digialocean.com, etc). - Github with a security key enabled on the user's account. STEPS TO REPRODUCE 1. 2. 3. OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 449273] Mouse clicks from openQA (automated test framework) in Fedora installer on KDE 5.23.90 stop working shortly after it starts
https://bugs.kde.org/show_bug.cgi?id=449273 --- Comment #12 from Adam Williamson --- Yeah, I can give that a shot tomorrow. Thanks. -- You are receiving this mail because: You are watching all bug changes.
