kde December 2019

kde@lists.fedoraproject.org

16 participants
14 discussions

Enabling KDE tests for updates in openQA
by Adam Williamson 11 Dec '19

11 Dec '19

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=fedora… 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

1 0

Update on Fedora 31 + QWayland
by Jan Grulich 10 Dec '19

10 Dec '19

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

1 0

sddm greeter in wayland
by Troy Dawson 09 Dec '19

09 Dec '19

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

2 1

Release a USB device?
by Ed Greshko 02 Dec '19

02 Dec '19

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.

3 8

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

kde December 2019