Bug 501946

The problem is that what is supported differs from product to product. Someone would have to maintain a comprehensive list of what is and isn't supported. And frankly I don't see that happening - it's already not getting updated half the time for plasma.

There is also the question if it is worth the code. What does the user gain by drkonqi refusing to report the bug? They'd not have to create a bugzilla account. That's all, no?

Letting them create a new account (normal people hate this!) only for the bot to say "lol git good update your system n00b" does feel a bit Kafka-esque!

True but that is the distros doing more than ours.

The problem here is that doing this differently comes at considerable code cost to us when it's really the distro that decided to ship outdated software and the user is having a miserable time because of that. I am not sure the useless account creation is the big problem when discover is crashing every time the user clicks on it.

This goes beyond drkonqi even. It's also the bug report link in the help menu for example that lets users report bugs from garbage versions.

The low budget approach is to simply have drkonqi's mainpage show a variant of the bot's message on every distro that hasn't been explicitly allowed to report bugs (which is pretty much everything except for arch, fedora, neon, tumbleweed, and based on these). i.e. "disable" drkonqi on slow distros. Whether or not that is entirely fair I don't know.

It sounds like that's more or less the same thing as what's being proposed here, just in a different form.

It's tricky though. After a Debian or Kubuntu non-LTS version is released, bug reports from their users will be useful and actionable for six months, maybe a year if we're generous. After that, they become time-wasting noise. This is true even if the Plasma version they're using is technically "LTS", because by that point all of us have pretty much started to ignore the LTS Plasma release too. And of course Gear and Frameworks have no LTS releases in the first place.

We could perhaps have a time-based lockout for these distros. And I also think we could cancel the idea of the Plasma LTS release; it's always been a broken promise.

(In reply to Nate Graham from comment #2)
> Letting them create a new account (normal people hate this!) only for the
> bot to say "lol git good update your system n00b" does feel a bit
> Kafka-esque!

Agree. The user takes the time to report a bug, download debug symbols, write a description, check for duplicates (well .. sometimes), create an account ... just so the bug report gets auto closed without any human interaction. That doesn't seem fair.

If there is enough information for the bug to be auto closed, there is enough information to handle it properly (Eg. report to the distribution instead, or install a flatpak or whatever should be done instead.)

(In reply to Harald Sitter from comment #1)
> The problem is that what is supported differs from product to product.
> Someone would have to maintain a comprehensive list of what is and isn't
> supported. And frankly I don't see that happening - it's already not getting
> updated half the time for plasma.

I don't see this as a problem. Not all projects need to opt in. But if its handled by the bugzilla bot it should also be handled by drkonqi.


> There is also the question if it is worth the code. 

Thats the question. I think so. If you disagree I am not upset if you close this bug report.



(In reply to Nate Graham from comment #4)
> It sounds like that's more or less the same thing as what's being proposed
> here, just in a different form.
> 
> It's tricky though. After a Debian or Kubuntu non-LTS version is released,
> bug reports from their users will be useful and actionable for six months,
> maybe a year if we're generous. After that, they become time-wasting noise.
> This is true even if the Plasma version they're using is technically "LTS",
> because by that point all of us have pretty much started to ignore the LTS
> Plasma release too. And of course Gear and Frameworks have no LTS releases
> in the first place.
> 
> We could perhaps have a time-based lockout for these distros. And I also
> think we could cancel the idea of the Plasma LTS release; it's always been a
> broken promise.

Afaik there are currently no Plasma LTs versions planned. Maybe that will change with whatever the stable version of KDE Linux does. Anyway this question seems out of scope for this issue. (You probably should discuss this in the Plasma sprint instead.)


Sorry for the short response, but I hope this clears it up. If not, I can explain it in more detail.

> We could perhaps have a time-based lockout for these distros.

How would that work? We don't know when a given binary was released :|

(In reply to Harald Sitter from comment #1)
> The problem is that what is supported differs from product to product.
> Someone would have to maintain a comprehensive list of what is and isn't
> supported. And frankly I don't see that happening - it's already not getting
> updated half the time for plasma.

This bug report is about the bugs immediately closed by the Bugzilla bot.
So the same data could be used by DrKonqi: https://invent.kde.org/sysadmin/bugzilla-bot/-/blob/master/data/versions.yml

(In reply to Thomas Bertels from comment #7)
> (In reply to Harald Sitter from comment #1)
> > The problem is that what is supported differs from product to product.
> > Someone would have to maintain a comprehensive list of what is and isn't
> > supported. And frankly I don't see that happening - it's already not getting
> > updated half the time for plasma.
> 
> This bug report is about the bugs immediately closed by the Bugzilla bot.
> So the same data could be used by DrKonqi:
> https://invent.kde.org/sysadmin/bugzilla-bot/-/blob/master/data/versions.yml

That would be the data that doesn't get updated half the time ;)

There is huge cost associated with using that data ranging from network availability to actual UX considerations - It's not just a matter of showing a message some where, we have the fully automated workflow to consider that somehow need to obtain the data (network permitting) and then discard crashes accordingly. But to do that we'd first need to know what is and isn't plasma and we only know that after having resolved the bugzilla product of a crash, which is actually a number of network queries that can go wrong. Not to mention that for the automated workflow we don't talk to bugzilla at all and also don't want to.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/drkonqi/-/merge_requests/364

Git commit 9df12d6ec68381ba5ca0675a53616a611e108dc8 by Harald Sitter.
Committed on 27/11/2025 at 09:32.
Pushed by sitter into branch 'master'.

cmake: new feature option WITH_DRKONQI_REPORTING

this controls whether the drkonqi based UX is enabled. we'd like
distributions that ship older software to disable drkonqi so the user
doesn't report bugs against unmaintained software versions.

since this would require huge amounts of infrastructure to pull off
automatically we instead offer a single knob to turn drkonqi reporting
off.

we now have global UX to guide the user to distribution bug trackers
even when they have no crash reporting tool of their own, allowing for
crashes to not go unnoticed regardless of the drkonqi main UI being
involved or not.

to be clear: this only disables the drkonqi based KDE bugzilla/sentry
UX. the general coredump tech remains active and picks up the slack.

notably this should be enabled for distributions that follow the
releases of KDE software relatively closely. distributions that do not
should either disable the reporting outright or disable it when the
software stack goes out of support

M  +8    -0    CMakeLists.txt
M  +3    -0    src/coredump/launcher/CMakeLists.txt
M  +4    -0    src/coredump/launcher/main.cpp

https://invent.kde.org/plasma/drkonqi/-/commit/9df12d6ec68381ba5ca0675a53616a611e108dc8