On Fri, Jan 31, 2020 at 1:05 AM Michael Reeves wrote:
>
> There seems to be some sort of ssl certificate issue with autoconfig.kde.org.
> On kubuntu this triggers a warning as soon as discover starts that may be a
> contributing factor.
I've checked and can find no fault with autoconfig.kde.org
Hi,
TLDR: removing the ProvidersUrl entry actually breaks things in non-Plasma
installations, so for now has to be hardcoded, using the non-deprecated
ProvidersUrl=https://autoconfig.kde.org/ocs/providers.xml
See below for investigation results:
Am Freitag, 31. Januar 2020, 00:14:19 CET schrie
On 01/30/20 13:53, Friedrich W. H. Kossebau wrote:
as found out by discussion on irc, a good solution for everyone relying on the
default GHNS storage as provided by KDE is to just not hard-code any value for
ProvidersUrl, but leave it out and let KNewStuff default to what is built into
the KNewS
There seems to be some sort of ssl certificate issue with autoconfig.kde.org.
On kubuntu this triggers a warning as soon as discover starts that may be a
contributing factor.
On Thu, Jan 30, 2020, 4:20 AM Ben Cooksley wrote:
> Hi all,
>
> While diagnosing an issue this evening with cdn.kde.org,
Hi,
as found out by discussion on irc, a good solution for everyone relying on the
default GHNS storage as provided by KDE is to just not hard-code any value for
ProvidersUrl, but leave it out and let KNewStuff default to what is built into
the KNewStuff library as current value.
So:
--- 8< --
Hi all,
While diagnosing an issue this evening with cdn.kde.org, I noticed
that we are still getting an extremely large number of requests for
the legacy OCS/GHNS providers.xml endpoint, which is supposed to only
exist for compatibility with older applications.
Looking on LXR i've found that a su
