https://bugs.kde.org/show_bug.cgi?id=507217
--- Comment #16 from [email protected] --- (In reply to Nate Graham https://bugs.kde.org/show_bug.cgi?id=513569#c1) > Is this issue reproducible for you? It happens at every login? > > If so, can you run `plasma-discover --backends packagekit,flatpak,fwupd` and > then quit the app and see if the issue still happens? I'm suspecting it > *will not* happen. > > If that's correct, then do it again with `plasma-discover --backends > packagekit,flatpak,fwupd,kns` and quit the app and see if it still happens. > I'm suspecting that it *will* happen. Okay, so by some coincidence while discussing in another thread for Solus bugs, someone pitched me a similar command, and I ran it. Shockingly, Discover *did* open. The line they gave me was `plasma-discover --backends packagekit,snap,fwupd,flatpak`. I wondered why it was the case, and I noticed "snap" in there. I removed that term, and... it STILL opened. But that was weird, because that's the same as your first suggestion... Turns out, no, it's NOT the same as your first suggestion. The order of operations actually matters. `fwupd,flatpak` succeeded, but your `flatpak,fwupd` *failed*. The order of those two items matters (it seems to be because flatpak is dependent on fwupd -- it's not because flatpak has to go last specifically, because I was able to add the `kns` from your second suggestion to the end and it still ran). This bug is not over, though. That's because even after using that function, closing and trying to reopen Discover still fails (it only succeeds when I use the command line to send the valid types of commands where flatpak comes after fwupd). What this tells me is that the Discover shortcut on the taskbar is programmed to call one of the invalid types. It could probably be fixed simply by swapping it out for one of the valid commands, but that wouldn't answer the big question: What exactly breaks in the invalid ones, given that they always work the first time? Clearly, they are not invalid by their general nature, but because something changed. And knowing that would answer the question of why the order of `flatpak` and `fwupd` matters. Maybe `fwupd` (which sounds like an update or some kind of daemon) cleans up some stuff before flatpak initializes? The first run leaves something unclean when closing, so only wiping it *before* running again fixes that. I have absolutely no idea how this actually works (I have been in college for both IT and programming, so I have technical literacy, but that doesn't extend to knowing what any of these applications are made off on a logical level and what kinds of handshakes they make and what dependencies they have). But it is a very strong lead in my opinion. To draw something else (aside from "why does it break in the first place") back into focus: As mentioned, even after running the "valid" commands, despite how I can run them successfully as many times as I want, it never fixes the issue with clicking the icon, so closing the app after it's been opened in ANY manner leaves it broken. Also, something else you may want to know, since you suggested two options, one with "kns" and one without, expecting different results: Any command `plasma-discover --backends packagekit,fwupd,flatpak` works, even if we append `,kns` or `,snap` or `,kns,snap` or `,snap,kns` onto it. The extra terms have no bearing on the success or failure of any methods, nor the ability to reopen the app. ============================== Extra note: When I start installations in Discover through this command line manner, there is no install progress menu in the bottom left corner like there usually would be. ============================== Some separate info that is not related to the crashes but someone should probably investigate while we're here. When I use `,snap` or `,kns` anywhere in the list, although they don't impact the success or failure of opening the Discover app, they do BOTH have their own error in the logging output that looks important... ``` org.kde.plasma.libdiscover: Couldn't find the backend: "kns-backend" among QList("packagekit-backend", "kns-backend", "flatpak-backend", "fwupd-backend") org.kde.plasma.libdiscover: Plugin "snap-backend" doesn't have the right IID "" expected org.kde.discover.6.5.4.AbstractResourcesBackendFactory ``` To reiterate, these do not prevent the app from launching -- they sure look like issues, though, although I don't have the knowledge to grasp the consequences. Maybe I've found precisely why you through your second line would fail for me (while the first one was supposed to succeed), because you found that kns one in your JournalCTL? It just turns out that if it causes an issue, this is not the one. ============================== End of my comments on the duplicate issue. -- You are receiving this mail because: You are watching all bug changes.
