[Discover] [Bug 488388] Discover shows an unrecoverable error when packages are unsigned, even if the repo has `gpgcheck=0`; could make use of available PK API for this
https://bugs.kde.org/show_bug.cgi?id=488388 --- Comment #10 from Adam Williamson --- I think there was some debate about that in the GNOME issue(s), which is partly why I linked there... -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 488388] Discover shows an unrecoverable error when packages are unsigned, even if the repo has `gpgcheck=0`; could make use of available PK API for this
https://bugs.kde.org/show_bug.cgi?id=488388 --- Comment #8 from Adam Williamson --- actually, I *think* https://fedorapeople.org/groups/qa/openqa-repos/openqa-testrepo-2/ should fit the bill, it contains an unsigned package. This repo definition should work: [openqa-testrepo-2] name=openQA test repo 2 baseurl=https://fedorapeople.org/groups/qa/openqa-repos/openqa-testrepo-2 enabled=1 metadata_expire=30 gpgcheck=0 then try to install the package called "testpackage"... -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 488388] Discover shows an unrecoverable error when packages are unsigned, even if the repo has `gpgcheck=0`; could make use of available PK API for this
https://bugs.kde.org/show_bug.cgi?id=488388 --- Comment #6 from Adam Williamson --- well, I ran into this testing Fedora side tags, which are designed to be ephemeral unfortunately. There aren't any permanent ones AFAIK. It should be relatively easy to just build a dummy RPM package and create a repo containing it, though. That would not be signed, obviously. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 488388] Discover shows an unrecoverable error when packages are unsigned, even if the repo has `gpgcheck=0`
https://bugs.kde.org/show_bug.cgi?id=488388 --- Comment #3 from Adam Williamson --- On a quick look, it seems like PK does actually provide an interface for this which g-s is using. g-s sets an `untrusted_question` attribute on some class (there is too much obfuscation for me to bother figuring out what kind of class it is exactly, god I hate C): https://gitlab.gnome.org/GNOME/gnome-software/-/blob/4ca259f74911d39ccf5c93b4c0e323b62819623d/plugins/packagekit/gs-packagekit-task.c#L194 it seems like the other end of that isn't in gnome-software, but in PackageKit, unless I'm misreading: see https://github.com/PackageKit/PackageKit/blob/e5df9e89e5841f102cd1f5587aaf987083e32562/lib/packagekit-glib2/pk-task.c#L881 . It occurred to me you can get the "just go ahead" behaviour by implementing a "question" callback which isn't interactive, it just says everything's fine, and sure enough, there seems to be an implementation within PK itself which does this: https://github.com/PackageKit/PackageKit/blob/e5df9e89e5841f102cd1f5587aaf987083e32562/lib/packagekit-glib2/pk-task-wrapper.c#L50 . I don't know if it's possible to do this *only* in the case that the repo config has `gpgcheck=0`, though, or something like that. I don't know the exact contours of when PackageKit would trigger this 'untrusted_question' mechanism vs doing something else. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 487595] Breeze icon theme uses copyrighted icons without acknowledgement or compliance with the owners' guidelines
https://bugs.kde.org/show_bug.cgi?id=487595 --- Comment #7 from Adam Williamson --- Not beyond the one in the initial comment, no. That's as far as I looked. I got here via https://bugzilla.redhat.com/show_bug.cgi?id=2270572 , where I noticed that the Papirus icon theme has some copyrighted logos in it - https://bugzilla.redhat.com/show_bug.cgi?id=2270572#c3 - and the Papirus maintainer then decided the invoke the classic "everyone else is doing it too!" defence (note: this one does not work well in court) and throw Breeze under the bus - https://bugzilla.redhat.com/show_bug.cgi?id=2270572#c13 . So I verified that, found that there were at least three apparently-affected cases, and filed this bug. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 487595] Breeze icon theme uses copyrighted icons without acknowledgement or compliance with the owners' guidelines
https://bugs.kde.org/show_bug.cgi?id=487595 --- Comment #5 from Adam Williamson --- Nate: I asked Richard Fontana and he broadly confirmed my view, seems we didn't get around to getting a public comment posted, though. > Adam, please do feel free to contact a lawyer about this, as it would provide > some legal clarity surrounding the topic. In the meantime, could you provide > a full list of potentially problematic icons? I mean, I could try, but it's neither my job nor my competency, and I do have a lot of other stuff to do that *is* my job and my competency. I also wouldn't particularly want to accept any implied liability that I had done the job completely... -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 488388] Discover shows an unrecoverable error when packages are unsigned, even if the repo has `gpgcheck=0`
https://bugs.kde.org/show_bug.cgi?id=488388 --- Comment #1 from Adam Williamson --- This is specifically an issue for doing openQA testing of side tags in Fedora, which we do for e.g. the Python mass rebuilds. The packages in the side tag are not signed. We set up a repo config with `gpgcheck=0`, which makes dnf happily install and test the packages. GNOME Software at least just shows a warning we can make openQA click through. But we cannot make the Discover test work at all in this scenario. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 488388] New: Discover shows an unrecoverable error when packages are unsigned, even if the repo has `gpgcheck=0`
https://bugs.kde.org/show_bug.cgi?id=488388 Bug ID: 488388 Summary: Discover shows an unrecoverable error when packages are unsigned, even if the repo has `gpgcheck=0` Classification: Applications Product: Discover Version: 6.1.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: PackageKit Assignee: plasma-b...@kde.org Reporter: ad...@happyassassin.net CC: aleix...@kde.org Target Milestone: --- SUMMARY If you configure a yum/dnf-style repo that contains unsigned packages with `gpgcheck=0`, then try to install any packages from that repo using Discover, it will show an unrecoverable error, "There was an issue installing this update. Please try again later". It should either just allow the install, or show a warning the user can click through. STEPS TO REPRODUCE 1. Set up a repository containing unsigned packages 2. Write a yum/dnf config file for the repo, including the directive `gpgcheck=0` 3. Attempt to install or update a package from the repo using Discover OBSERVED RESULT Unrecoverable error message EXPECTED RESULT No error, or a warning that can be accepted to proceed SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora Rawhide KDE Plasma Version: 6.0.90 ADDITIONAL INFORMATION See GNOME Software tickets https://gitlab.gnome.org/GNOME/gnome-software/-/issues/603 and https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2246 for some background on how this was discussed and handled there. The behaviour of dnf in this case is that if the repo config says `gpgcheck=0` it will not run any GPG verification or post any warnings and will happily install unsigned or unverifiable packages from the repo. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 487715] New: alt-d-s shortcut to open desktop settings does nothing until you click on the desktop once (Plasma 6.0.90)
https://bugs.kde.org/show_bug.cgi?id=487715 Bug ID: 487715 Summary: alt-d-s shortcut to open desktop settings does nothing until you click on the desktop once (Plasma 6.0.90) Classification: Plasma Product: kwin Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: core Assignee: kwin-bugs-n...@kde.org Reporter: ad...@happyassassin.net Target Milestone: --- SUMMARY When first starting a Plasma 6.0.90 desktop, if you hit alt-d-s without doing anything else, it doesn't launch Desktop Settings as it should. However, e.g. alt-f2 does work to open a launcher dialog. If you click on the desktop once, alt-d-s now works as expected. I guess this is a focus issue? STEPS TO REPRODUCE 1. Log into a clean Plasma 6.0.90 desktop (tested on Fedora Rawhide) 2. Immediately, without doing anything else, hit alt-d-s 3. Now click once on the desktop and hit alt-d-s again OBSERVED RESULT First alt-d-s does not launch desktop settings, second one does EXPECTED RESULT First alt-d-s should launch desktop settings SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora Rawhide, Plasma 6.0.90 -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 487595] Breeze icon theme uses copyrighted icons without acknowledgement or compliance with the owners' guidelines
https://bugs.kde.org/show_bug.cgi?id=487595 --- Comment #2 from Adam Williamson --- The icon you are using for Facebook *is* the 'f' from the Facebook logo, isolated from the rest of the Facebook logo and with its color changed, both against Facebook's guidelines for using the logo - https://about.meta.com/brand/resources/facebook/logo/ . It is copyrighted, obviously, by Meta, and is definitely not under the LGPL. "However, a few companies provide their own icon graphic for various sizes, in which case, we should simply copy/paste into the icon collection for our system." I really think you need to refer this to an actual lawyer. I can refer you to Red Hat's legal team if it would help. You cannot assume you are legally permitted to just "copy/paste" an icon whose copyright is owned by someone else into your project, because that isn't the case. It is legally equivalent to copying the entire text of a popular novel, or the entirety of Taylor Swift's latest song, into your project. If you don't have their permission to do it, you can get in trouble. Brands typically focus on typical promotional activities when publishing guidelines that provide implicit permission to reuse their branding in certain cases - for e.g. the Facebook guidelines I posted are highly focused on marketing things like including the logo in a business website. When the guidelines don't cover your case, the safest course is to assume you have *no* permission to use or redistribute the copyrighted material, because that's typically how the law works. It's never safe to assume you can just redistribute somebody else's copyright material, and it's certainly never safe to imply that *you* created it, and it's under the LGPL, if it isn't. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 487595] New: Breeze icon theme uses copyrighted icons without acknowledgement or compliance with the owners' guidelines
https://bugs.kde.org/show_bug.cgi?id=487595 Bug ID: 487595 Summary: Breeze icon theme uses copyrighted icons without acknowledgement or compliance with the owners' guidelines Classification: Plasma Product: Breeze Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: critical Priority: NOR Component: Icons Assignee: visual-des...@kde.org Reporter: ad...@happyassassin.net CC: kain...@gmail.com, m...@nueljl.in Target Milestone: --- SUMMARY The breeze icon theme repo includes https://github.com/KDE/breeze-icons/blob/master/COPYING-ICONS , which appears to describe the copyright claims for icons in the repository. It seems to claim that all the icons are original works and copyrighted under the LGPL. However, this is clearly not true. For example, breeze-icons/icons/actions/22/im-skype.svg is very clearly a modified version of Microsoft's Skype icon. This is copyrighted by Microsoft, and is very definitely not under the LGPL. Also, Microsoft provides a restrictive set of "brand guidelines" for Skype - currently at https://secure.skypeassets.com/content/dam/scom/pdf/skype_brand_guidelines.pdf - which specifically states "Do not alter the Skype icon in any way, including changing the colors, angle, or dimensions", but Breeze has made it monochrome. Similarly, breeze-icons/icons/actions/22/im-facebook.svg is a modified version of Facebook's own icon, which again is very definitely not LGPL. And again, this project is also violating the owner's brand guidelines - https://about.meta.com/brand/resources/facebook/logo/ - which specifically state "DON'T change the color of the logo" and "DON'T use just the 'f' from our logo". These are only two examples, there are several others (e.g. im-google.svg ). STEPS TO REPRODUCE 1. Clone the git repo. 2. Read the copyright information. 3. Observe the presence of icons copyrighted by others without acknowledgement or license compliance. OBSERVED RESULT There are lots. EXPECTED RESULT There shouldn't be any. SOFTWARE/OS VERSIONS Irrelevant. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478614] Cursor "hit box" is offset under Wayland on QEMU VMs
https://bugs.kde.org/show_bug.cgi?id=478614 Adam Williamson changed: What|Removed |Added CC||ad...@happyassassin.net --- Comment #6 from Adam Williamson --- I'm seeing offset today in Fedora 40 on Wayland with a libvirt VM with virtio graphics :( The usual "real position is slightly lower and to the right of the apparent position" case. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-qqc2-desktop-style] [Bug 479235] System Monitor crashes in ItemBranchIndicators::paint()
https://bugs.kde.org/show_bug.cgi?id=479235 Adam Williamson changed: What|Removed |Added CC||ad...@happyassassin.net --- Comment #4 from Adam Williamson --- Also affecting Fedora 40 downstream: https://bugzilla.redhat.com/show_bug.cgi?id=2273737 . It's a release blocker candidate ATM. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 473835] disable auto-suspend for VMs by default to avoid virtio hang
https://bugs.kde.org/show_bug.cgi?id=473835 Adam Williamson changed: What|Removed |Added CC||ad...@happyassassin.net --- Comment #3 from Adam Williamson --- That returns: kvm -- You are receiving this mail because: You are watching all bug changes.
[Welcome Center] [Bug 466282] RFE: Add a live environment mode so Plasma Welcome is useful on live media
https://bugs.kde.org/show_bug.cgi?id=466282 --- Comment #5 from Adam Williamson --- No, that can't work. It has to be something that can be poked by a script during startup, basically - some kind of config file entry, magic file, something like that. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 466318] fwupd backend errors on startup with fwupd 1.8.11: "user agent unset"
https://bugs.kde.org/show_bug.cgi?id=466318 --- Comment #1 from Adam Williamson --- https://invent.kde.org/plasma/discover/-/merge_requests/486 seems to fix it. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 466318] New: fwupd backend errors on startup with fwupd 1.8.11: "user agent unset"
https://bugs.kde.org/show_bug.cgi?id=466318 Bug ID: 466318 Summary: fwupd backend errors on startup with fwupd 1.8.11: "user agent unset" Classification: Applications Product: Discover Version: 5.27.1 Platform: Other OS: Linux Status: REPORTED Severity: major Priority: NOR Component: fwupd Backend Assignee: plasma-b...@kde.org Reporter: ad...@happyassassin.net CC: aleix...@kde.org, sharma.abhijeet2...@gmail.com Target Milestone: --- SUMMARY With fwupd 1.8.11 (recently released), Discover with the fwupd backend shows an error on startup: "user agent unset". I don't know yet whether this prevents use of Discover entirely (it was caught by an automated test system which isn't smart enough to try closing the dialog and continuing), but I'm pretty sure it at least will render the fwupd backend non-functional. STEPS TO REPRODUCE 1. Run Discover with the fwupd backend enabled and fwupd 1.8.11 installed (e.g. on current Fedora Rawhide) OBSERVED RESULT Error is shown. EXPECTED RESULT No error. SOFTWARE/OS VERSIONS Plasma 5.27.1 on Fedora Rawhide (39). ADDITIONAL INFORMATION I've root caused this (I think) in the downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=2173022 . The change that triggered this is a check in `fwupd_client_set_user_agent_for_package` that was added in fwupd 1.8.11: it now bails out if priv->daemon_version is not set. See https://github.com/fwupd/fwupd/commit/34743ff6f48510839ca3ef5f4ad6fe51ffd3425c . This check was added for a good reason: priv->daemon_version is used in constructing the user agent string, so if it's not set, you get "NULL" in the second part of the string, which is bad and apparently confused LVFS. Discover calls `fwupd_client_set_user_agent_for_package` as just about the first thing it does after creating the client instance. This apparently is too early, nothing has set the daemon version yet. gnome-software, as best as I can tell, waits until it has done `fwupd_client_connect_async` and `fwupd_client_set_feature_flags_async` (and the corresponding `finish` calls) before it does `fwupd_client_set_user_agent_for_package`, with an explicit comment that "/* we know the runtime daemon version now */". So it's intentionally doing the user agent after those two other things with the intent that one of them causes the daemon version to be set. See https://gitlab.gnome.org/GNOME/gnome-software/-/blob/main/plugins/fwupd/gs-plugin-fwupd.c#L285-286 and the blocks around there. Logically speaking, I guess this means Discover should do something similar: do client_connect and/or set_feature_flags before it does set_user_agent_for_package. I'm trying to write a patch to do that, but I am no kind of C coder so I may fail miserably, so I figured I'd file a bug so better C coders can look at it. :D -- You are receiving this mail because: You are watching all bug changes.
[Welcome Center] [Bug 466282] RFE: Add a live environment mode so Plasma Welcome is useful on live media
https://bugs.kde.org/show_bug.cgi?id=466282 --- Comment #2 from Adam Williamson --- well, there may not be a good cross-distro way to do it :/ AFAIK, live boot is implemented differently on different distros, so there isn't just one reliable indicator. Fedora's live environment user is called 'liveuser', but I doubt it's the same on other distros. for GNOME, we do this customization [downstream](https://pagure.io/livesys-scripts/blob/main/f/libexec/livesys/sessions.d/livesys-gnome) - specifically, lines 58-61 disable the upstream GNOME welcome tour, and lines 51-56 enable the custom welcome screen we show on live boots instead. It may be the case that we need to do something similar for Plasma - upstream just needs to allow some sort of mechanism here (give the welcome tour a "live mode" or whatever), and we do the actual customization to make it kick in downstream. -- 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.
[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.
[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.
[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.
[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.
[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.
[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.
[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 #10 from Adam Williamson --- Um. I think maybe not, because it seems when running as the live installer, we actually force anaconda to run with the X11 backend: https://github.com/rhinstaller/anaconda/blob/master/data/liveinst/liveinst#L134-L135 liveinst is a wrapper script which is what gets called to run anaconda on live images - it does various customizations specific to the live environment, like that one, before running anaconda itself. -- 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 #6 from Adam Williamson --- I just realized I didn't mention, so in case it's not obvious - the installer app in use here is built on GTK+. -- 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 #5 from Adam Williamson --- Sure, here's one of the most recent failures - https://openqa.fedoraproject.org/tests/1114561 . Logs and video at https://openqa.fedoraproject.org/tests/1114561#downloads . You should be able to see from the autoinst-log.txt log that the mouse_hide calls do seem to take effect - there are several moves to 1023, 767 which are mouse_hide events (either explicit ones or the ones that happen as part of assert_and_click ). I did run a test where I disabled the mouse_hide that happens at the end of assert_and_click , and the result of that is that the test gets one step further - the Continue button works, but it fails at the next step. The next thing that happens is a child window pops up with a warning about this being a pre-release, with a button you have to click to continue. It looks like this (from the Workstation live test): https://openqa.fedoraproject.org/tests/1114249#step/_boot_to_anaconda/12 clicking on the "I want to proceed" button there doesn't work. It does seem potentially interesting that that button is in a different window. I wonder if I could get past it somehow, would subsequent clicks back in the main installer window continue to work. Next week I'll see if we can get past it with keyboard inputs (I haven't actually checked that yet). -- 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 #3 from Adam Williamson --- Bisecting is turning out to be hard because older commits just don't build against current (everything else), like kwayland-server :( Can't build anything before f2b29e35 by the looks of it due to an incompatibility with `setSupportedFormatsAndModifiers`, and f2b29e35 doesn't build because of a "static assertion failed: Signal and slot arguments are not compatible." error I haven't totally traced out yet. But even just those two mean I'm missing like several months of history in the bisect attempt, so it's not likely to work out well. -- 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 #2 from Adam Williamson --- I tested a build of current git 5.24 head, same bug. I'll try and bisect back between 5.23.5 and 5.23.90, though it will take a bit of time to do. -- 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 #1 from Adam Williamson --- Created attachment 146003 --> https://bugs.kde.org/attachment.cgi?id=146003=edit how the screen we're trying to interact with looks -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 449273] New: 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 Bug ID: 449273 Summary: Mouse clicks from openQA (automated test framework) in Fedora installer on KDE 5.23.90 stop working shortly after it starts Product: kwin Version: 5.23.90 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: input Assignee: kwin-bugs-n...@kde.org Reporter: ad...@happyassassin.net Target Milestone: --- SUMMARY I maintain Fedora's instance of an automated test system called openQA: https://openqa.fedoraproject.org . openQA allows for "human-like" testing of graphical applications by matching areas of screenshots and performing mouse and keyboard input operations via a VNC connection. We run a suite of openQA tests on Fedora composes and updates. Since KDE/Plasma 5.23.90 landed in Fedora Rawhide, the test that runs a Fedora installation from the KDE live image is failing. The test boots the live image, double-clicks an icon on the desktop to launch the installer - which runs maximized and without a window title, see attached screenshot - then starts trying to navigate through it with keyboard and mouse inputs. For example, the first page of the installer is a language selection screen (as shown in the screenshot). The test first checks that it's at this screen and clicks on a non-active area of it (the word "FEDORA" in "WELCOME TO FEDORA 36") to ensure the window is active. Then it clicks in the text entry box at bottom left and types the word "english". Then it looks for "English (United States)" on the right-hand side and clicks on that. Then it looks for the button labelled "Continue" and clicks on that. Ordinarily this would indeed continue the installation process, and that's what happens on the same test run on the GNOME live image, and on the same test run on our dedicated installer images (which use gnome-kiosk), and what used to happen when running the test on KDE. But with Plasma 5.23.90, when openQA clicks on "Continue", nothing happens. We've established a few things by experimentation. It seems that once we reach the broken state, clicking on anything in the installer no longer works. For instance, I tried modifying the test to click on a different language, which should lead to that language being selected - but it doesn't. It seems the first one or two clicks in the installer window work OK, but after that, they stop working. However, clicking on something outside the installer window - e.g. the KDE "kicker" icon - works fine. We also found that if we hijack the VNC connection the openQA test runner uses to inject input events, we can click on things in the installer successfully by hand. The bug for some reason only affects the events as input by openQA's test runner. Here are some more details about exactly how this is implemented in os-autoinst (the openQA test runner). The test is run on a qemu VM, with the built-in VNC server enabled. os-autoinst sends mouse and keyboard events via this VNC server. This is precisely what happens when it wants to "click on something": * Match the relevant area and determine its centre point * Set the cursor to that precise position; it does not "move" the cursor the way a human would, it just zaps it there with a single VNC event (see https://github.com/os-autoinst/os-autoinst/blob/master/consoles/VNC.pm#L745-L760) * Send a 'mouse button down' event * Wait 0.15 seconds * Send a 'mouse button up' event * Wait 1 second * Set the cursor to 1023,767: this is called a "mouse hide" event, the purpose is to position the cursor somewhere we hope it won't happen to interfere with a subsequent match attempt (i.e. the bottom right corner of the screen) Notably, this means that between clicks, the cursor is instantly repositioned to 1023x767 and then instantly positioned to the click target location. This is the most obvious part of the runner's behaviour that a human cannot replicate - when we take over the VNC connection and interact with the VM manually, obviously, we can't instantly zap the cursor wherever we want, we're just moving it there with our human hands and human mice. So this repositioning behaviour may be significant (it was in a similar bug we found in GNOME recently). STEPS TO REPRODUCE This is trivial to reproduce if you have an instance of openQA deployed with Fedora's test configuration, and probably close to impossible to reproduce if you don't, unfortunately. At least you'd probably have to replicate the whole 'instant cursor repositioning' thing. I can reproduce it on demand and provide whatever debugging information would be useful. I'm available on libera.chat IRC and chat.fedoraproject.org (they're bridged) as adamw. OBSERVED RESULT Mouse clicks stop working shortly after installer runs. EXPECTED RESULT Mouse clicks should keep working. SOFTWARE/OS
[Discover] [Bug 443455] Disabled Flatpak repos can't be successfully removed
https://bugs.kde.org/show_bug.cgi?id=443455 --- Comment #15 from Adam Williamson --- https://invent.kde.org/plasma/discover/-/merge_requests/191 should resolve this. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 443583] Toggled repos in Discover jump to the bottom of the list, and other repo names are changed to undefined
https://bugs.kde.org/show_bug.cgi?id=443583 --- Comment #7 from Adam Williamson --- Aleix filed https://invent.kde.org/plasma/discover/-/merge_requests/192 that should address the remaining parts of this. I'll try it out later. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 443583] Toggled repos in Discover jump to the bottom of the list, and other repo names are changed to undefined
https://bugs.kde.org/show_bug.cgi?id=443583 --- Comment #6 from Adam Williamson --- OK, so backporting https://codereview.qt-project.org/c/qt/qtdeclarative/+/372646 does seem to fix the 'undefined' problem. Now every time I change the state of a PackageKit repo, the *entire page* refreshes shortly afterwards, including all the sources from other backends, and they all show correct state - rather than only the sources from PK backends refreshing, and sources from other backends going to 'undefined'. It's still kinda surprising behaviour in a way that the entire page refreshes when you click a checkbox, but it'd be quite a major change to not do that. The ordering within the PK source list can still change, but we should be able to fix that by doing some consistent ordering when we construct that list. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 443455] Disabled Flatpak repos can't be successfully removed
https://bugs.kde.org/show_bug.cgi?id=443455 --- Comment #14 from Adam Williamson --- ohhh, wait, I see the problem. We're reusing the `error` pointer from the `flatpak_installation_list_remote_refs_sync()` call for the `flatpak_installation_remove_remote()`, but that's not safe if the `remote_refs_sync()` call actually resulted in an error. We need to re-initialize (is that the word? not a C guy) the error pointer between the calls. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 443455] Disabled Flatpak repos can't be successfully removed
https://bugs.kde.org/show_bug.cgi?id=443455
--- Comment #13 from Adam Williamson ---
oh, that error is from the qml, indicating backend.removeSource returned false:
if (!backend.removeSource(sourceId)) {
console.warn("Failed to remove the source",
model.display)
}
but I'm still not sure why. I'll look at it a bit harder.
--
You are receiving this mail because:
You are watching all bug changes.
[Discover] [Bug 443455] Disabled Flatpak repos can't be successfully removed
https://bugs.kde.org/show_bug.cgi?id=443455 --- Comment #12 from Adam Williamson --- I'm not sure that would change it at all, actually. This seems to be a bug in FlatpakSourcesBackend::removeSource(), but I'm not totally sure what. oddly, the error we get on the console - "qml: Failed to remove the source XXX" - doesn't quite match the log line you'd think we'd be htting in the backend - "Failed to remove %1 remote repository: %2". -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 443455] Disabled Flatpak repos can't be successfully removed
https://bugs.kde.org/show_bug.cgi?id=443455 --- Comment #11 from Adam Williamson --- I don't think so. It's just a bug in -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 443455] Disabled Flatpak repos can't be successfully removed
https://bugs.kde.org/show_bug.cgi?id=443455 Adam Williamson changed: What|Removed |Added Status|RESOLVED|REOPENED Summary|Flatpak remotes are always |Disabled Flatpak repos |shown as enabled and greyed |can't be successfully |out, disabled ones can't be |removed |successfully removed| Resolution|FIXED |--- --- Comment #9 from Adam Williamson --- So the fix fixed the "always shown as enabled but greyed out" part, but not the "can't delete disabled remotes" part. That is still true - you can successfully delete an enabled remote, but trying to delete a disabled remote fails. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 443583] Toggled repos in Discover jump to the bottom of the list, and other repo names are changed to undefined
https://bugs.kde.org/show_bug.cgi?id=443583 Adam Williamson changed: What|Removed |Added Ever confirmed|0 |1 Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #5 from Adam Williamson --- That won't solve the ordering of the PK repos potentially changing when you do anything to them, though. For that it would need to *not* refresh the entire list on a checkbox click, or always order the repos in some predictable way, when refreshing them, I think? -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 406295] State of checkboxes is not immediately updated after I enable/disable a firmwares source in "Settings" page
https://bugs.kde.org/show_bug.cgi?id=406295
--- Comment #6 from Adam Williamson ---
huh, another finding which kinda surprised me: if you take out the call to
`sourcesView.model.setData` so that the block just looks like this:
onClicked: {
checked = Qt.binding(function() { return modelChecked
!== Qt.Unchecked; })
}
you get the same behaviour as if you remove the block entirely. The checkboxes
change state correctly every time you click them, but do nothing. That's not
what I was expecting, actually - I was expecting them to do nothing and have
buggy behaviour (probably stay in the same state no matter how often you
clicked them). Not sure of the significance of that, though.
--
You are receiving this mail because:
You are watching all bug changes.
[Discover] [Bug 406295] State of checkboxes is not immediately updated after I enable/disable a firmwares source in "Settings" page
https://bugs.kde.org/show_bug.cgi?id=406295 --- Comment #5 from Adam Williamson --- oh, sorry, one more note: if you apply my partial fix for https://bugs.kde.org/show_bug.cgi?id=443455 so that the checkboxes for flatpak sources are also clickable, you'll find that they behave exactly the same as fwupd ones, *even though setData is not overridden for the fwupd backend at all*. So the bug reproduces with *just* the qml change from 'upstream' behaviour - it seems we don't need to be concerned about it being affected by anything in the flatpak backend's setData implementation. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 406295] State of checkboxes is not immediately updated after I enable/disable a firmwares source in "Settings" page
https://bugs.kde.org/show_bug.cgi?id=406295 --- Comment #4 from Adam Williamson --- Note I think this code, which was essentially identical at the time, must have been working back in late 2018, or else it's hard to see how this bug could have been reported and fixed: https://bugs.kde.org/show_bug.cgi?id=401663 so it almost seems like something in Qt or even Kirigami may have broken this, somehow, between then and when this bug was reported in April 2019? -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 406295] State of checkboxes is not immediately updated after I enable/disable a firmwares source in "Settings" page
https://bugs.kde.org/show_bug.cgi?id=406295 Adam Williamson changed: What|Removed |Added CC||aleix...@kde.org -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 406295] State of checkboxes is not immediately updated after I enable/disable a firmwares source in "Settings" page
https://bugs.kde.org/show_bug.cgi?id=406295
--- Comment #3 from Adam Williamson ---
So I've been beating my head against this all day and not getting *that* far,
but I can at least say the problem is caused by our handling of clicks on the
checkbox in discover/qml/SourcesPage.qml:
onClicked: {
sourcesView.model.setData(idx, checkState,
Qt.CheckStateRole)
checked = Qt.binding(function() { return modelChecked
!== Qt.Unchecked; })
}
this is the bit that makes clicking the checkbox actually do something. What
it's *supposed* to do is tell the source backend to actually enable or disable
the source and then update its record as to whether the checkbox should be
checked or not - this all happens when we call sourcesView.model.setData - and
then reset the 'checked' state to whatever the backend now thinks it should be
(so the checkbox should change state if it did, or stay the same if it didn't).
If you take the onClicked block out entirely, the checkboxes will respond
perfectly to being clicked whichever state they're in. Of course, they won't
*do* anything. If that block is there, clicking them does what it is supposed
to so long as the backend supports it, but the checkbox gets sort of 'stuck' as
described here. Note that a *second* click while it's stuck does not change the
state again.
Interestingly, neither taking the `checked = Qt.binding(function() { return
modelChecked !== Qt.Unchecked; })` line out nor exactly inverting its logic (to
=== instead of !==) changes the observed behaviour *at all*.
The bug is not apparent on flatpak sources because of
https://bugs.kde.org/show_bug.cgi?id=443455 (the flatpak source backend is just
flat out missing the code to enable or disable sources), and it's not apparent
on PackageKit sources because the way that backend works is that it entirely
rebuilds the source list any time the repo configuration changes at all, which
sort of hides the bug.
--
You are receiving this mail because:
You are watching all bug changes.
[Discover] [Bug 443583] Toggled repos in Discover jump to the bottom of the list, and other repo names are changed to undefined
https://bugs.kde.org/show_bug.cgi?id=443583 --- Comment #2 from Adam Williamson --- Oh, I'm not sure yet why we get the 'other repo names changed to undefined' behaviour. I suspect possibly the PK backend clearing and re-generating its entire source list somehow causes that, I'm not sure of the exact mechanism yet. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 443583] Toggled repos in Discover jump to the bottom of the list, and other repo names are changed to undefined
https://bugs.kde.org/show_bug.cgi?id=443583 Adam Williamson changed: What|Removed |Added CC||ad...@happyassassin.net --- Comment #1 from Adam Williamson --- so I've been looking into this, https://bugs.kde.org/show_bug.cgi?id=406295 and https://bugs.kde.org/show_bug.cgi?id=443455 because they're all kiiinda in the same area: enabling and disabling software sources, under different backends. It's interesting that the PackageKit, fwupd and flatpak backends all handle this very differently, it almost feels like the abstraction model should be at a higher level so they're forced to do it in more similar ways and can't have really different behaviours. In this case, as best as I can tell, the way the PackageKit backend works is through a lot of signal callbacks between the Discover backend and PackageKit itself. The Discover PK backend connects to PackageKit's repoListChanged signal, and any time that signal is triggered, it regenerates its *entire* internal sources list from scratch (it runs its own resetSources method). When you click to enable or disable a source in Discover, the PK backend intercepts what Qt would usually do when you click a checkbox, and just calls PackageKit's repoEnable function on the relevant repo and then returns; it doesn't even explicitly redraw the checkbox. Instead it relies on PK then emitting the repoListChanged and triggering a call to resetSources, which figures everything out from scratch again. Presumably when it does this, PackageKit sends the repos in a different order - I guess it sends them in order of last change? - which is why we see the 'jump to the bottom of the list' behaviour. So, theoretically we could fix that by having resetSources not just use the repos in whatever order it gets them from PackageKit, but sort them in some kind of consistent order (alphabetically?) so that hopefully we'll get the same ordering every time it's called. Alternatively, we could have it *not* rely on the repoListChanged -> resetSources trigger, but disconnect that when we're dealing with a checkbox click and just have it call repoEnable and then change the checkbox state if it's successful, or log an error and leave the checkbox state as-is if it's not. This is more or less what the fwupd backend tries to do...although 406295 is precisely about that not actually *working*, so we'd have to figure that out too. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 443455] Flatpak remotes are always shown as enabled and greyed out, disabled ones can't be successfully removed
https://bugs.kde.org/show_bug.cgi?id=443455 --- Comment #6 from Adam Williamson --- So I looked into this a bit today. It appears to be basically just flat-out missing functionality; if you compare the similar FlatpakSourcesBackend.cpp, FwupdSourcesBackend.cpp and PackageKitSourcesBackend.cpp , you can see that the fwupd and pk backends have both code to set the initial check state of the QStandardItems that are used for source rows here based on the source state and also code to enable or disable a source when the box is clicked, but the flatpak backend has neither of those. I am no kind of C++ coder at all. I could successfully make the default state of the box for flatpak sources match the actual state of the source with a simple patch: --- a/libdiscover/backends/FlatpakBackend/FlatpakSourcesBackend.cpp +++ b/libdiscover/backends/FlatpakBackend/FlatpakSourcesBackend.cpp @@ -338,6 +361,8 @@ void FlatpakSourcesBackend::addRemote(FlatpakRemote *remote, FlatpakInstallation it->setData(remoteUrl.isLocalFile() ? remoteUrl.toLocalFile() : remoteUrl.host(), Qt::ToolTipRole); it->setData(remoteUrl, Qt::StatusTipRole); it->setData(id, IdRole); +it->setCheckable(true); +it->setCheckState(flatpak_remote_get_disabled(remote) ? Qt::Unchecked : Qt::Checked); #if FLATPAK_CHECK_VERSION(1, 4, 0) it->setData(QString::fromUtf8(flatpak_remote_get_icon(remote)), IconUrlRole); #endif ...but this also makes the boxes active, you can click on them, but doing so of course doesn't actually change the source's real state as clicking on them isn't hooked up to anything. (Note that when you first click on the box the state won't appear to change, but if you leave the page and come back it will be in the other state; this is https://bugs.kde.org/show_bug.cgi?id=406295 ). I did try and implement changing the state in response to a click too, but didn't make that compile yet, let alone work, if nobody else wants to work on it, I'll keep trying. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 443455] Flatpak remotes are always shown as enabled and greyed out, disabled ones can't be successfully removed
https://bugs.kde.org/show_bug.cgi?id=443455 --- Comment #5 from Adam Williamson --- Created attachment 142273 --> https://bugs.kde.org/attachment.cgi?id=142273=edit screenshot from Fedora 35 KDE note how the flatpak remote 'checkboxes' are grey, while the 'Firmware Updates' ones are blue. The 'Firmware Updates' ones change when you mouse over them, indicating they can be changed, and indeed they can be (you can enable and disable them). The Flatpak ones do not change when you mouse over them, and nothing happens when you click them. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 443455] Flatpak remotes are always shown as enabled and greyed out, disabled ones can't be successfully removed
https://bugs.kde.org/show_bug.cgi?id=443455 --- Comment #4 from Adam Williamson --- That's not how it looks here. I'll attach a screenshot... -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 443455] Flatpak remotes are always shown as enabled and greyed out, disabled ones can't be successfully removed
https://bugs.kde.org/show_bug.cgi?id=443455 --- Comment #2 from Adam Williamson --- I'm testing on F35, as is Kamil. Note that removing an *enabled* remote works fine, it's only removing *disabled* remotes that doesn't work. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 443456] New: Toggling repo in Discover doesn't redraw the checkbox, confusing users
https://bugs.kde.org/show_bug.cgi?id=443456 Bug ID: 443456 Summary: Toggling repo in Discover doesn't redraw the checkbox, confusing users Product: Discover Version: 5.23.0 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: discover Assignee: lei...@leinir.dk Reporter: ad...@happyassassin.net CC: aleix...@kde.org Target Milestone: --- This is an upstream report of downstream Fedora bug https://bugzilla.redhat.com/show_bug.cgi?id=2011333 . As reported there, if you go to Settings and toggle a repository from enabled to disabled or vice versa, the operation does actually happen, but the checkbox is not redrawn until you leave the Settings tab, go somewhere else, and come back. This is very confusing and could lead users not to know what repositories are actually enabled after trying to change the states. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 443455] New: Flatpak remotes are always shown as enabled and greyed out, disabled ones can't be successfully removed
https://bugs.kde.org/show_bug.cgi?id=443455 Bug ID: 443455 Summary: Flatpak remotes are always shown as enabled and greyed out, disabled ones can't be successfully removed Product: Discover Version: 5.23.0 Platform: Other OS: Linux Status: REPORTED Severity: major Priority: NOR Component: Flatpak Backend Assignee: lei...@leinir.dk Reporter: ad...@happyassassin.net CC: aleix...@kde.org, jgrul...@redhat.com Target Milestone: --- This is an upstream report of Fedora downstream bug https://bugzilla.redhat.com/show_bug.cgi?id=2011291 . As described there, configured Flatpak remotes are always shown as enabled but greyed out - whether they are actually disabled or not. This is misleading. The 'remove' button is available, and works for enabled repos, but for disabled repos it fails with a "Can't fetch summary from disabled remote" error. This bug is still present in 5.23.0, I just tested that today. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 443357] Real cursor position is slightly offset from displayed position on Wayland in virtual machine
https://bugs.kde.org/show_bug.cgi?id=443357 --- Comment #9 from Adam Williamson --- Thanks for the check, both of you. I've applied that to our package downstream. Sounds like no more upstream 5.22 releases are planned, so I won't bother submitting it for that branch. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 443357] Real cursor position is slightly offset from displayed position on Wayland in virtual machine
https://bugs.kde.org/show_bug.cgi?id=443357
--- Comment #6 from Adam Williamson ---
Oh, hmm, think I may have managed it myself after all. Does anyone see anything
wrong with this?
diff --git a/src/plugins/platforms/drm/drm_output.cpp
b/src/plugins/platforms/drm/drm_output.cpp
index 917bb857d..7ee387219 100644
--- a/src/plugins/platforms/drm/drm_output.cpp
+++ b/src/plugins/platforms/drm/drm_output.cpp
@@ -102,10 +102,15 @@ bool DrmOutput::hideCursor()
return drmModeSetCursor(m_gpu->fd(), m_crtc->id(), 0, 0, 0) == 0;
}
-bool DrmOutput::showCursor(DrmDumbBuffer *c)
+bool DrmOutput::showCursor(DrmDumbBuffer *c, const QPoint )
{
const QSize = c->size();
-if (drmModeSetCursor(m_gpu->fd(), m_crtc->id(), c->handle(), s.width(),
s.height()) == 0) {
+int ret = drmModeSetCursor2(m_gpu->fd(), m_crtc->id(), c->handle(),
s.width(), s.height(), hotspot.x(), hotspot.y());
+if (ret == ENOTSUP) {
+// for NVIDIA case that does not support drmModeSetCursor2
+ret = drmModeSetCursor(m_gpu->fd(), m_crtc->id(), c->handle(),
s.width(), s.height());
+}
+if (ret == 0) {
if (RenderLoopPrivate::get(m_renderLoop)->presentMode ==
RenderLoopPrivate::SyncMode::Adaptive
&& isCursorVisible()) {
m_renderLoop->scheduleRepaint();
@@ -122,7 +127,8 @@ bool DrmOutput::showCursor()
return false;
}
-const bool ret = showCursor(m_cursor[m_cursorIndex].data());
+const Cursor * const cursor = Cursors::self()->currentCursor();
+const bool ret = showCursor(m_cursor[m_cursorIndex].data(),
logicalToNativeMatrix(cursor->rect(), scale(),
transform()).map(cursor->hotspot()));
if (!ret) {
qCDebug(KWIN_DRM) << "DrmOutput::showCursor(DrmDumbBuffer) failed";
return ret;
diff --git a/src/plugins/platforms/drm/drm_output.h
b/src/plugins/platforms/drm/drm_output.h
index 1f89f9064..af46c88a0 100644
--- a/src/plugins/platforms/drm/drm_output.h
+++ b/src/plugins/platforms/drm/drm_output.h
@@ -45,7 +45,7 @@ public:
///queues deleting the output after a page flip has completed.
void teardown();
void releaseGbm();
-bool showCursor(DrmDumbBuffer *buffer);
+bool showCursor(DrmDumbBuffer *buffer, const QPoint );
bool showCursor();
bool hideCursor();
bool updateCursor();
--
2.32.0
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 443357] Real cursor position is slightly offset from displayed position on Wayland in virtual machine
https://bugs.kde.org/show_bug.cgi?id=443357 Adam Williamson changed: What|Removed |Added CC||butir...@gmail.com --- Comment #5 from Adam Williamson --- So, it looks like the DrmPipeline addition changed all the cursor setting code considerably, such that it's beyond me how the bug can be fixed on the 5.22 branch. CCing Andrey Butirsky, who wrote the fix on the development branch - Andrey, would you possibly have time to see if this can be fixed on the 5.22 code? Thanks! -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 443357] Real cursor position is slightly offset from displayed position on Wayland in virtual machine
https://bugs.kde.org/show_bug.cgi?id=443357 Adam Williamson changed: What|Removed |Added Version|unspecified |git-stable-Plasma/5.22 --- Comment #4 from Adam Williamson --- Aha. Looks like this was fixed on the development branch: https://github.com/KDE/kwin/commit/998bbf4eba724a9b94a5bae62182456b85b11383#diff-034885748897f413c645e3efd125d7c0db9a8454d580f6093e40c885d974c818 unfortunately, that was after a big change that moved a ton of code around: https://github.com/KDE/kwin/commit/586efe94d4f3b2c9759a26f27661edcaa54dce0b#diff-034885748897f413c645e3efd125d7c0db9a8454d580f6093e40c885d974c818 I'll have a go at backporting it to the 5.22 stable branch today, as that's what we need downstream for Fedora 35. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 443357] Real cursor position is slightly offset from displayed position on Wayland in virtual machine
https://bugs.kde.org/show_bug.cgi?id=443357 --- Comment #3 from Adam Williamson --- jadahl - who dealt with the similar problems on the mutter (GNOME) side - passes this along: "one possibility is that kde changed to do what mutter did for a while, which is to emulate atomic mode setting with legacy mode setting. what mutter did was to offset things manually, always setting a 0,0 hotspot. when the virtual machine viewer bugs showed up, I had to re-introduce the hotspot to the atomic mode setting layer even if it couldn't be used" -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 443357] Real cursor position is slightly offset from displayed position on Wayland in virtual machine
https://bugs.kde.org/show_bug.cgi?id=443357 Adam Williamson changed: What|Removed |Added Summary|Don't use atomic mode |Real cursor position is |setting with virtual GPUs |slightly offset from |(causes cursor offset) |displayed position on ||Wayland in virtual machine -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 443357] Don't use atomic mode setting with virtual GPUs (causes cursor offset)
https://bugs.kde.org/show_bug.cgi?id=443357 --- Comment #2 from Adam Williamson --- Hum, well. Turning off atomic mode setting doesn't actually solve the problem, for some reason, on Plasma. It does on GNOME, but not Plasma. I thought my patch wasn't working so I tested with KWIN_DRM_NO_AMS=1 in /etc/environment and confirmed via `qdbus org.kde.KWin / KWin supportInformation` output that AMS is disabled: Atomic Mode Setting on GPU 0: false but the cursor offset is still present when running Plasma on Wayland. When running Plasma on X11, there is no offset. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 443357] Don't use atomic mode setting with virtual GPUs (causes cursor offset)
https://bugs.kde.org/show_bug.cgi?id=443357 --- Comment #1 from Adam Williamson --- I'm trying to do a PR for this, but me writing C++ is like the old gag about dancing bears, so it may take a minute. :D -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 443357] New: Don't use atomic mode setting with virtual GPUs (causes cursor offset)
https://bugs.kde.org/show_bug.cgi?id=443357 Bug ID: 443357 Summary: Don't use atomic mode setting with virtual GPUs (causes cursor offset) Product: kwin Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: platform-drm Assignee: kwin-bugs-n...@kde.org Reporter: ad...@happyassassin.net Target Milestone: --- When running KDE on Wayland in a VM, the cursor location is slightly offset from where it is drawn. Usually the 'real' location is slightly above and to the left of the 'apparent' location. This is most obvious when drag-selecting text in e.g. a text editor or console. As explained in https://bugzilla.redhat.com/show_bug.cgi?id=2009304#c12 , this is caused by using atomic mode setting: "The atomic API does not allow specifying the cursor hotspot causing issues with virtual-machines which draw the cursor them-selves. The solution is to not use the atomic API (at least for the cursor) when running on say QXL graphics or a couple of other virtual GPUs." mutter has a denylist of virt-y GPUs to not use atomic mode setting on: https://gitlab.gnome.org/GNOME/mutter/-/blob/af0460d0cedd5a66b2110ab2a99e67c647e7b6fb/src/backends/native/meta-kms-impl-device-atomic.c#L1149-1152 kwin should probably have the same. I think I found the place where atomic mode setting is enabled - https://github.com/KDE/kwin/blob/6a68caef7be72a3ae004c71bb844a0716966ca98/src/plugins/platforms/drm/drm_gpu.cpp#L90 and the function it calls - and it doesn't appear to have any such denylist. STEPS TO REPRODUCE 1. Run KDE on Wayland in a virtual machine (e.g. a Fedora 34 KDE image in a qemu VM using qxl or virtio graphics) 2. Run a text editor or console and get some text displayed 3. Position the cursor at the beginning of a line and try to select the text OBSERVED RESULT You will likely select from the line above, or not select at all as the cursor is 'really' outside the window. EXPECTED RESULT Accurate selection due to cursor being where it appears to be. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Any KDE/Linux combination in a VM on Wayland. ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 430036] konsole no-toolbar setting missing or forgotten
https://bugs.kde.org/show_bug.cgi?id=430036 Adam Williamson changed: What|Removed |Added CC|ad...@happyassassin.net | -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 430036] konsole repeatedly losing no-toolbar setting
https://bugs.kde.org/show_bug.cgi?id=430036 --- Comment #31 from Adam Williamson --- ah, sorry, forgot to explain that - for the F34 branch -2 is effectively a no-op. -2 was a straight rebuild on the Rawhide branch for the Rawhide mass rebuild, it did not happen on the F34 branch. But the commit for -2 was merged into the F34 branch presumably as the maintainer is keeping those branches equal for now (this is a fairly common strategy). So still the only actual difference betweeen -1 and -3 is the same patch. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 430036] konsole repeatedly losing no-toolbar setting
https://bugs.kde.org/show_bug.cgi?id=430036 Adam Williamson changed: What|Removed |Added CC||ad...@happyassassin.net --- Comment #29 from Adam Williamson --- The change between Fedora -2 and -3 was indeed a backport from upstream. It was a backport of https://github.com/KDE/konsole/commit/b43548b , which fixes bug #437791 (the Konsole window initially appearing at a very small size on launch). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 435389] User switching freezes at login
https://bugs.kde.org/show_bug.cgi?id=435389 Adam Williamson changed: What|Removed |Added CC||ad...@happyassassin.net --- Comment #10 from Adam Williamson --- What Kamil is describing and what Geraldo is describing in the downstream bug may not necessarily be the same thing. Kamil's reports are usually accurate and comprehensive, so I'd focus on that part. I'll try and get them both to test a build with your fix, thanks. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 350039] krdb throws away all previous settings if no specific font DPI value is given
https://bugs.kde.org/show_bug.cgi?id=350039 --- Comment #7 from Adam Williamson --- no, sorry, I just figured that was the appropriate state to set it back to from NEEDINFO. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 350039] krdb throws away all previous settings if no specific font DPI value is given
https://bugs.kde.org/show_bug.cgi?id=350039 Adam Williamson changed: What|Removed |Added Ever confirmed|0 |1 Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |ASSIGNED --- Comment #5 from Adam Williamson --- Well, the code that wipes the whole rdb is still there: https://github.com/KDE/plasma-desktop/blame/master/kcms/krdb/krdb.cpp#L476 One thing has changed around it, though. This commit: https://github.com/KDE/plasma-desktop/commit/873cbc1da8f3f2b589f9f2722a4e15a8fcbfe4e5 adds default values for anti-aliasing, which I think are what you're seeing. I don't really think the problem is 'solved', though. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 411876] Plasma themes require non-FDO-compliant .desktop files
https://bugs.kde.org/show_bug.cgi?id=411876 --- Comment #2 from Adam Williamson --- It seems rather misleading to use the same extension and the same general format as a very widely-recognized specification, but not actually meet that specification. At the very least it could be specifically noted in the docs. It did cause a real-world problem, yes: https://bugzilla.redhat.com/show_bug.cgi?id=1745846#c10 it sufficiently confused a reviewer on the Fedora 31 backgrounds package that they required desktop-file-validate be run on the file and it be modified to pass that check...which of course meant it didn't work any more. This contributed to Fedora 31 Beta shipping with KDE having the wrong desktop background. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 411876] New: Plasma themes require non-FDO-compliant .desktop files
https://bugs.kde.org/show_bug.cgi?id=411876 Bug ID: 411876 Summary: Plasma themes require non-FDO-compliant .desktop files Product: plasmashell Version: master Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: k...@davidedmundson.co.uk Reporter: ad...@happyassassin.net CC: plasma-b...@kde.org Target Milestone: 1.0 Sorry if this is the wrong component, it's very hard to figure out the right one. To create a working Plasma 5 theme, you are required to include a metadata.desktop file which seems not to be compliant with the FDO spec: https://techbase.kde.org/Development/Tutorials/Plasma5/ThemeDetails (Plasma theme instructions) https://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html (FDO spec) The instructions for Plasma cover sections named 'Settings', 'Wallpaper', 'ContrastEffect', and 'BlurBehindEffect' (it seems a section named 'Branding' is also possible). However, none of these sections is defined in the FDO spec, and the spec says: "Alternatively, fields can be placed in their own group, where they may then have arbitrary key names. If this is the case, the group should follow the scheme outlined above, i.e. [X-PRODUCT GROUPNAME] or something similar. These steps will avoid namespace clashes between different yet similar environments." i.e. when inventing a new group that is not covered in the spec, it is supposed to have X- prepended to its name (and ideally X-PRODUCT, e.g. X-Plasma or X-KDE in this case). desktop-file-validate enforces the spec in this way: if a .desktop file contains a non-standard group that is not prefixed with X-, validation will fail, so these metadata.desktop files fail validation. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 355970] Plasma crashes on boot of current Fedora Rawhide nightly live image in a KVM (Spice/QXL)
https://bugs.kde.org/show_bug.cgi?id=355970 Adam Williamson <ad...@happyassassin.net> changed: What|Removed |Added Resolution|WAITINGFORINFO |WORKSFORME Status|NEEDSINFO |RESOLVED --- Comment #8 from Adam Williamson <ad...@happyassassin.net> --- This hasn't been happening for a while, current Fedora images are fine. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 355970] Plasma crashes on boot of current Fedora Rawhide nightly live image in a KVM (Spice/QXL)
https://bugs.kde.org/show_bug.cgi?id=355970 --- Comment #7 from Adam Williamson <ad...@happyassassin.net> --- https://bugzilla.redhat.com/show_bug.cgi?id=1285666 -- You are receiving this mail because: You are watching all bug changes.
