Plan / proposal: enable openQA update testing and potentially
gating on Rawhide updates
by Adam Williamson
Hi folks!
We've had openQA testing of updates for stable and branched releases,
and gating based on those tests, enabled for a while now. I believe
this is going quite well, and I think we addressed the issues reported
when we first enabled gating - Bodhi's gating status updates work more
smoothly now, and openQA respects Bodhi's "re-run tests" button so
failed tests can be re-triggered.
A few weeks ago, I enabled testing of Rawhide updates in the openQA
lab/stg instance. This was to see how smoothly the tests run, how often
we run into unexpected failures or problems, and whether the hardware
resources we have are sufficient for the extra load.
So far this has been going more smoothly than I anticipated, if
anything. The workers seem to keep up with the test load, even though
one out of three worker systems for the stg instance is currently out
of commission (we're using it to investigate a bug). We do get
occasional failures which seem to be related to Rawhide kernel slowness
(e.g. operations timing out that usually don't otherwise time out), but
on the whole, the level of false failures is (I would say) acceptably
low, enough that my current regime of checking the test results daily
and restarting failed ones that don't seem to indicate a real bug
should be sufficient.
So, I'd like to propose that we enable Rawhide update testing on the
production openQA instance also. This would cause results to appear on
the Automated Tests tab in Bodhi, but they would be only informational
(and unless the update was gated by a CI test, or somehow otherwise
configured not to be pushed automatically, updates would continue to be
pushed 'stable' almost immediately on creation, regardless of the
openQA results).
More significantly, I'd also propose that we turn on gating on openQA
results for Rawhide updates. This would mean Rawhide updates would be
held from going 'stable' (and included in the next compose) until the
gating openQA tests had run and passed. We may want to do this a bit
after turning on the tests; perhaps Fedora 37 branch point would be a
natural time to do it.
Currently this would usually mean a wait from update submission to
'stable push' (which really means that the build goes into the
buildroot, and will go into the next Rawhide compose when it happens)
of somewhere between 45 minutes and a couple of hours. It would also
mean that if Rawhide updates for inter-dependent packages are not
correctly grouped, the dependent update(s) will fail testing and be
gated until the update they depend on has passed testing and been
pushed. The tests for the dependent update(s) would then need to be re-
run, either by someone hitting the button in Bodhi or an openQA admin
noticing and restarting them, before the dependent update(s) could be
pushed.
In the worst case, if updated packages A and B both need the other to
work correctly but the updates are submitted separately, both updates
may fail tests and be blocked. This could only be resolved by waiving
the failures, or replacing the separate updates with an update
containing both packages.
All of those considerations are already true for stable and branched
releases, but people are probably more used to grouping updates for
stable and branched than doing it for Rawhide, and the typical flow of
going from a build to an update provides more opportunity to create
grouped updates for branched/stable. For Rawhide the easiest way to do
it if you need to do it is to do the builds in a side tag and use
Bodhi's ability to create updates from a side tag.
As with branched/stable, only critical path updates would have the
tests run and be gated on the results. Non-critpath updates would be
unaffected. (There's a small allowlist of non-critpath packages for
which the tests are also run, but they are not currently gated on the
results).
I think doing this could really help us keep Rawhide solid and avoid
introducing major compose-breaking bugs, at minimal cost. But it's a
significant change and I wanted to see what folks think. In particular,
if you find the existing gating of updates for stable/branched releases
to cause problems in any way, I'd love to hear about it.
Thanks folks!
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
10 months, 2 weeks
Plasma logout oddness possible systemd-homed involvement
by Ian Malone
I'm not motivated to investigate this further, but in case anyone else
is having a similar problem. After recent updates (currently
plasma-desktop-5.27.1-1.fc37.x86_64
sddm-0.19.0^git20230201.3ee57e9-2.fc37.x86_64) I had a number of
issues, the most annoying of which was inability to log out on
Plasma+X11.
First the login screen only showed a password dialogue, white
background and a small (apparently power) icon at the bottom right,
user selection was not possible, no response to Esc key, power icon
not clickable. Login via password for my normal user worked. This
appears to have been fixed by using system settings to change the
login screen.
Second wallpaper setting was lost, but as this frequently happens with
Plasma upgrades recently it may be unconnected. More unusually the
lock screen background has changed to black, which I have not seen
before.
Lastly, as in the subject, logging out became an issue. Both
Plasma+X11 and Plasma+Wayland sessions simply hung on log out, whether
or not the logout screen option was selected. Without logout screen
this happened immediately on clicking logout, with logout screen it
happened after confirming logout. Whether the display blanked or just
froze appeared variable. Restarting and shutdown were fine. I was
unable to find any particularly noteable journal messages, however
there was a mention of systemd-homed being unable to find home for
sddm user and my account (Not a user managed by systemd-homed: No home
for user sddm known). On a whim I tried stopping systemd-homed during
a frozen logout (from a virtual terminal) then stopping
graphical.target and starting it again. After this I was able to log
out successfully from Plasma, and this has persisted across reboots
despite systemd-homed still running. Prior to this I had tried an
.autorelabel (without success) and, as mentioned, both X11 and Wayland
sessions had the same issue.
--
imalone
http://ibmalone.blogspot.co.uk
1 year, 1 month
welcome dialog on a Live image?
by Kamil Paral
There's a new Welcome dialog in KDE on F38. However, it's also started on a
Live image. Some part of it makes sense (basic info about the desktop), but
some part doesn't (usage collection request, online accounts
configuration). I wonder if it's supposed to start on a Live image or not?
1 year, 2 months
KDE Plasma (Fedora 37) performance on Raspberry Pi 4
by Syam Krishnan
Hi
I got a Raspberry Pi 4 board with 8 GB RAM today, and tried both KDE
Plasma and Fedora Workstation images on it. While the workstation (with
Gnome) works pretty well, the Plasma desktop is quite sluggish when it
comes to graphics. Moving windows around a bit fast, tool-tip popups on
taskbar elements etc. are noticeably sluggish and have significant
response delays. Gnome desktop does not have any such issues.
Both are running the same kernel versions. But they are two different
images (both downloaded from Fedora website), so I don't know if there
are any relevant differences in the pre-installed packages.
Any ideas on how to rectify this? I was on KDE/X11 most of the time, and
during a brief testing with KDE/Wayland, it didn't fare any better.
Thanks,
Syam
1 year, 2 months
Window moving virtual desktop
by Mark ＠ GMail
Now (since F37, I think), clicking on a URL in an email (in Evolution,
3.46.3-1.fc37) moves my browser (FireFox) to the same virtual desktop
that Evolution is in.
It didn't used to do this, and it's not what I want, but I can see some
might want that, so is it an option somewhere? If so, where?
Many thanks,
Mark
Fedora Linux 37, Workstation
KDE Plasma 5.26.5
KDE Frameworks 5.102.0
Qt 5.15.8
Kernel 6.1.10-200.fc37.x86_64
Graphics Platform X11
1 year, 2 months
Dolphin not saving state
by Patrick O'Callaghan
For years I've had a fixed set of three Dolphin windows opened (in a
saved session) when I log in, each of them in a specific directory, two
with split panels and one with a single panel. The single-panelled one
also has the terminal pane open.
Since installing dolphin-22.12.2-1.fc37.x86_64 this no longer works. I
still get the three windows in the right places, but they are all
showing my home directory and a single panel. None has the terminal
pane open.
Where does Dolphin store its session state? Or is this a wider problem?
I'm on X11 because of general issues with session restore on Wayland,
but this looks like a regression.
poc
1 year, 2 months
Screen locker fails after update to F37
by Tim Landscheidt
Hi,
I use a plain black screen as the screen locker in KDE/Way-
land, and I have "linger" enabled in systemd for my user. I
updated from F35 to F37 three days ago; there are parts of
my KDE configuration that are a decade old.
Whenever the time comes for the screen to lock up, a trans-
lated message appears on the screen instead informing that
the screen locker is broken and that I should use "loginctl
unlock-session $nr" in a plain shell (which works).
I searched for this error, and one suggestion was to exe-
cute:
| [tim@vagabond ~]$ /usr/libexec/kscreenlocker_greet --testing
| kscreenlocker_greet: Lockscreen QML outdated, falling back to default
| kf.kirigami: Failed to find a Kirigami platform plugin
| Speicherzugriffsfehler (Speicherabzug geschrieben)
| [tim@vagabond ~]$
(last line meaning core dumped).
So I went to the KDE "Systemeinstellungen" (system set-
tings?) to rewrite any relevant configuration in the current
format, disabled the lock screen, applied the configuration,
enabled it again, applied the configuration, no luck. Re-
booted, no luck.
There is a package kf5-kirigami2-5.102.0-1.fc37.x86_64
installed, and with
https://api.kde.org/frameworks/kirigami/html/ using "plat-
form" as referring to "Plasma Mobile, Desktop Linux, An-
droid, iOS and Windows", I don't see another package that
could be expected to provide a "Kirigami platform plugin".
On a whim, I also installed
kf5-kirigami-1.1.0-18.fc37.x86_64 because the error message
only referred to "Kirigami", not "Kirigami2", but this does
not change the failure.
So I would appreciate any ideas where to start looking for
a solution. Is "kscreenlocker_greet --testing" supposed to
work in Fedora? Fedora 37? Fedora 37 with Wayland?
TIA,
Tim
1 year, 2 months
