Monday meeting notes from 7/2/2022

[Ben Cooksley]

On Tue, Feb 8, 2022 at 4:43 AM Marco Martin <notmart at gmail.com> wrote:

> Nico
> * Don't crash plasma-integration on invalid color scheme setting:
> https://invent.kde.org/plasma/plasma-integration/-/merge_requests/34
> * Set proper name in desktop file for keditfiletype:
> https://invent.kde.org/plasma/kde-cli-tools/-/merge_requests/33
> * Work around a quirk in macOS in kidletime:
> https://invent.kde.org/frameworks/kidletime/-/merge_requests/15
> * Fix font change notification in
> qqc2-desktop-style/qqc2-breeze-style:
> https://invent.kde.org/frameworks/qqc2-desktop-style/-/merge_requests/124
> * perf optimization in qqc2-desktop-style/qqc2-breeze-style:
> https://invent.kde.org/frameworks/qqc2-desktop-style/-/merge_requests/125
> * Fix opening files on remote shares in Dolphin:
> https://invent.kde.org/system/dolphin/-/merge_requests/343
> * A question would be whether to backport the perf improvements in
> qqc2-breeze-style to 5.24
> * They are not strictly bug fixess
> * But perf improvements are very welcome on mobile
> [ Discussion seems to say yes go ahead]
>
> Nate
> * Did some MRs and lots of bug triage and minor bugfixes for  Plasma 5.24
> * we have 6 regressions left, if folks wanna have a look:
>
> https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&keywords=regression%2C%20&keywords_type=allwords&list_id=1974758&query_format=advanced&version=5.23.90
>
> Arjen
> * I did some system monitor bugfixing
> * and also apparently broke a few things in kirigami with the qmlmodule
> port
> * mostly because of random path issues
> * I'm now working on an ecm module that helps with writing qml unit
> tests, including having a function that adds a very simple
> instantiation test for a number of items
> * so that we can quickly verify that "public" qml items still work
>
> Fabian
> * There's this discover ocs topic...
> * The URL changes we have in 5.24 are at best a workaround, and
> probably won't hit the actually affected systems soon
> [apol well I know Ben is angry, I saw taht indeed there were some
> providers that were not hitting the cache and Ben addressed that]
>

Hopefully I got them all - unfortunately as I don't have everything
installed locally there is no guarantee that they have all been fixed.
I should note that LXR does not appear to pick up *.knsrc files too well,
so it cannot be relied on either.

This workaround should not in any form be considered a proper fix for the
issue.


> [apol I see there's a whole lot of people using unattended updates
> which is fairly new and is having an impact there, the changes we are
> merging today should have an impact]
> [apol I should look at how it scales for people with a lot of KNS
> resources that need updating on each run too]
>

Based on the traffic we are seeing, it appears that Discover makes a
request for each KNS resource the user has locally, which is fairly
non-scalable.


> [fvogt Would be great if someone could reproduce the issue locally
> somehow If it's actually really a bug and not just missing
> optimization]
> [nicofee There was a discussion about high requests for the providers
> a while ago, but it seems to have exploded the last two? days  Any
> idea why that could be?]
>

It crossed over a crucial threshold to come to Sysadmin's attention two
days ago, however our server monitoring system indicates that the base load
on the system has been climbing since at least October 2021 (we don't have
earlier data, however the load I am seeing in October is higher than what I
recall the base system load as being when it was originally deployed - it
should be around 1 during the EU day time and sub 1 during EU night).

This trend would be consistent with the KF 5.86 based distributions
starting to ship the automatic updater client.

I should note that high traffic load on autoconfig.kde.org led Sysadmin to
move autoconfig.kde.org to being CDN based back in September, so the issue
predates the release of Ubuntu 20.10.
This was when the issue was originally raised and when changes were made to
start setting User Agents and some caching was added (although seemingly
not enough?)

Please note that we need to backport any fixes and ask/firmly
push distributions to roll them out to users - preferably as security fixes
- otherwise it will take many months if not years for this situation to be
resolved.
This should be done even for versions we consider "out of support" - if an
actively current/supported distribution releases uses that version we
should ship an update.


> [apol maybe a distro enabled unattended updates by default?]
> [fvogt  I suspect that there's some loop with the updater, e.g.
> there's an update which fails to download, so it tries in a loop]
>
> Marco
> # Plasma
> * investigated into https://bugs.kde.org/show_bug.cgi?id=448609 : It
> is clearly *not* a regreession but something that always happened even
> in kde4 times every single time the appletsrc file is deleted. All it
> can be done is a workaround in doing a cleanup of old actions every
> time plasma starts from the default layout, tough all kglobalaccess
> api that could do such manipulation is deprecated
> * A small fix on kcms which have an header (merged):
> https://invent.kde.org/frameworks/kdeclarative/-/merge_requests/110
> * Helping a bit on the power kcm
> * Final work on the panel keyboard navigation mrs and now all merged \o/
> * More work on the plasmashell ScreenPool refactor
> * please review:
> https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1400
> * Now ShellCorona is ported ScreenPool as its single source of truth
> about what screens are available, and primarychanges. Concepts like
> fake screens or redundant screens are completely hidden from corona. a
> redundant screen is like it doesn't exists at all for corona
> * now has a fully working wayland based autotest for ScreenPool
> work/mart/screenPoolLogicWaylandTest, 14 tests so far which should be
> quite exaustive (maybe some day will be possible autotest a
> shellcorona instance itself, even tough that looks even more
> complicated)
> * Since is a lot of code copy from Qt's QWayland autotests, i am not
> completely sure on what to do with that, both on a licensing pow (gpl3
> only but since is just in an autotest should be fine) and on a code
> reusing pow (also, uses some private qplatform api) . perhaps a
> library exported from kwayland-server?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20220208/207f6059/attachment-0001.htm>