Enabling KDE tests for updates in openQA
by Adam Williamson
Hi folks!
Shortly I'll be enabling KDE tests of updates in openQA. We have had
the tests defined for years, but never turned them on because we didn't
have sufficient worker capacity. Now we do, so we're turning the tests
on.
This simply means that alongside the existing tests run by openQA on
critical path updates, we'll run the same subset of desktop tests on a
KDE disk image as we currently run on a GNOME disk image. Here's one of
the updates I used for a trial run in staging:
https://openqa.stg.fedoraproject.org/tests/overview?groupid=2&distri=fedo...
The new bit is the 'Flavor: updates-kde' tests. I'll also look at
adding an upgrade test - which would show up as 'upgrade_kde_64bit' in
a flavor called 'updates-kde-upgrade' - and a live image build and
install flavor ('updates-kde-live-iso') tomorrow, just to match what we
have for Workstation.
As noted above, openQA update tests run on critical path updates, plus
a whitelist of packages that aren't on the critical path but which we
want to run tests on anyway. We don't test every update for capacity
reasons: we do have more worker capacity now, but still not enough to
test every single update. (Also, the tests *do* flake sometimes;
running only on critpath and whitelisted updates keeps the volume low
enough that we can manually inspect, diagnose and if necessary re-run
every failure, this would be much more difficult if we tested every
single update).
If the KDE team is interested I'd be happy to work with them to see if
any significant KDE-related packages aren't in the critical path and
add them to the whitelist so that updates containing those packages
will be tested. Of course, this system means we quite often run
irrelevant tests (it's not at all likely that e.g. an update to gnome-
shell will change anything in KDE or FreeIPA, but since gnome-shell is
in the critical path, we will run the KDE and server tests on every
update containing gnome-shell), but there isn't much harm in that so we
don't worry about it.
As usual, you can see openQA results for an update you're interested in
either by browsing https://openqa.fedoraproject.org/ directly or from
the 'Automated Tests' tab in Bodhi. If an update you created or are
interested in causes a failure in these new KDE tests (or indeed any
*other* update test) but you're not sure what it means, please do
contact the QA team and we'll help you figure it out (or re-run the
test if it looks like a false alarm).
Thanks folks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
4 years, 4 months
Update on Fedora 31 + QWayland
by Jan Grulich
Hi,
recently there were few emails about users not being happy with QWayland being
used by default on GNOME desktop. I would like to make a summary of issues and
current plans and changes:
1) Some applications not working properly due to X11 dependencies:
There are quite a few applications which depend on X11 API. While this is not
fault of QWayland or Wayland as such, I understand this is a serious issue for
our users. Therefore I decided to modify the patch we have in qtbase to
blacklist these applications from Wayland usage.
These applications are: VirtualBox, smplayer, kdenlive, obs-studio, mixxx,
mythtv and also qtcreator.
Reason for blacklisting QtCreator is Bug 1774762 (non working drag and drop).
This issue has been already reported to upstream and once it's resolved, I
will enable QtCreator again to be used natively on Wayland.
2) Bug 1773650 - Qt Wayland backend has serious issues across the board
There is an issue about broken copy-pasting of non-ASCII characters. I
backported a fix from Qt 5.13 to our Fedora 31 builds, you can expect an
update soon. Other issues there are again about kdenlive or obs-studio, which
are broken because of X11 requirements and fixed with the change above.
Last but not least issue in this bug are window decorations. Problem is that
GNOME supports only client-side decorations, which means that we are
responsible for drawing the decorations. We have basic support for Adwaita-
like decorations in QGnomePlatform, but it's not really possible to cover all
the possible GNOME themes so please don't blame QWayland for that, it's not
really its fault.
Last thing I would like to mention is that I started working on Qt 5.13.2. It
is already almost finished in rawhide and I would like to have it in Fedora 31
as soon as possible. There are quite a lot of improvements in this release
regarding Wayland and I also plan to backport primary-selection support from
Qt 5.14.
Regards,
Jan
4 years, 4 months
sddm greeter in wayland
by Troy Dawson
Hi,
I am trying to use a complete wayland machine. No X at all. Just to
see if I can.
The sddm greeter looks like it will only run in X, as far as I can tell.
Does anyone know if it's even possible to run sddm in wayland, even if
it needs a recompile?
I have tried all sorts of searches through code and the sddm issues.
But it's possible I'm just looking for the wrong things.
Troy Dawson
4 years, 4 months
Release a USB device?
by Ed Greshko
My system is a fully updated F31 running the KDE desktop. It is the host, and I've got a qemu guest running
F31 and the Xfce desktop.
I would like to test access to a Samsung phone on the guest connected via USB.
However, the host system grabs it and I can't seem to find a way to release it so the guest can access.
There is no "eject" function in the "Device Notifier". Nor is does there seem to be a way to tell
KDE not to grab the device.
How to achieve the goal?
Thanks.
--
The key to getting good answers is to ask good questions.
4 years, 4 months
