Issue with Discover on the Plasma/5.14 branch

Dan Leinir Turthra Jensen admin at
Tue Jan 22 11:33:05 GMT 2019

On Monday, 21 January 2019 20:20:24 GMT Nate Graham wrote:
> Hello folks,
> We have a non-ideal situation with Discover. Its package update
> functionality is broken for many users of Plasma 5.14 due to
> The fix requires:
> - Frameworks 5.54 for
> 9d90692 - Plasma 5.15 for
> bd8c9170a
> Unfortunately, because there are no more 5.14 bugfix releases scheduled,
> Plasma 5.14 users would be out of luck even if we could backport a
> version of that fix that didn't have any string changes.
> Ideas regarding how to proceed? If we prepare a targeted
> string-change-less fix for 5.14.x, could we re-spin the tars for
> Discover to include it?
> Nate

So i've been poking about with this for a bit, and think i might have a 
workable proposal for a minimal fix to work around this problem:

Both Attica and KNewStuff are part of Frameworks, and so arguably can be 
considered a single entity for releasey/patchy purposes, so it seems to make 
sense to suggest the following. Even if it means introducing new Attica API, 
it doesn't introduce the much more invasive KNewStuff API, allowing the 
Discover patch to be fairly minimal as well.

Pick this patch

Pick this patch

Discover bits for KNSBackend.cpp's old error handler, removed in:

        if(error == QLatin1Literal("All categories are missing")
          || error == QLatin1Literal("Error initializing provider."
          || error.startsWith(QLatin1Literal("Loading of providers from 
          || error.startsWith(QLatin1Literal("Could not load get hot new stuff 
providers from file:")
          || error.startsWith(QLatin1Literal("Configuration file is invalid:")
          || error.startsWith(QLatin1Literal("Configuration file exists, but 
cannot be opened:")) {

It cannot be done purely on any error (as all errors go through this signal, 
including installation errors which should not invalidate the backend), so it 
needs to be handled per-message.

Optionally, we would also want to remove the i18n calls on the messages in 
KNewStuff, as otherwise this won't work for anyone who runs Discover in not-
US-English... This would also be a fairly simple thing to do, though these 
strings are translated because they are also user-facing in certain cases... 
In other words, there is no optimum solution to this problem that i can really 
see, but if we accept fault reduction over retaining translations, this would 

..dan / leinir..

More information about the release-team mailing list