nntp (aka, usenet) client in kde?
by Gene Smith
I currently use t-bird with an nntp account pointing to gmane to read
this list and sereral others. Does kde have an nntp client program of
any sort? I don't see it as a possible new account type in kmail. Also,
search with kpackagekit yields nothing with "usenet" or "nntp" that is
kde specific.
-gene
2 weeks
KDE EPEL8 plan
by Troy Dawson
My apologies for not listening to others about KDE on EPEL8. As
promised, this will be an open discussion. What I propose will just
be a suggestion.
People have correctly pointed out that it would be best if we do not
have the main KDE in epel8 be a module. It would make things more
stable and compatible if we used the QT5 packages from RHEL8 as our
basis, and go from there.
With that in mind, these are the things that I think are good ideas.
* No kde4 or kde3
* Follow the KDE LTS branches as much as possible.
** qt5
*** There are about 10 packages that have to stay at 5.11 due to
RHEL's packages. The rest get built with 5.12.x
*** If RHEL8 updates their qt5, adjust with them.
*** https://download.qt.io/official_releases/qt/5.12/
** plasma
*** Follow the same LTS stream as qt5 (currently 5.12)
*** https://download.kde.org/stable/plasma/5.12.9/
** kf5
*** Pick a stream and stick with it ??
*** I don't know of kf5 having an LTS stream.
*** Try to keep all the kf5 packages at the same stream
*** https://download.kde.org/stable/frameworks/
** KDE apps
*** Let the version be the decision of each app maintainer ???
* For qt5, plasma and kf5, have a group be the the maintainer.
* For the apps, let it be maintained by either a group or individual.
Depending on the app.
What do people think?
Troy
3 weeks
GTK apps not shown in pager
by Ian Pilcher
Not sure when this started, but I've noticed that some(?) GTK
application windows are not shown in my plasma pager. Thus far, I've
seen this with Firefox, Thunderbird, and virt-manager.
These windows *are* listed in the pager's tooltip, so it seems to be
aware that the windows exist. For some reason, however, it's not
showing the window outlines.
Anyone else?
--
========================================================================
Ian Pilcher arequipeno(a)gmail.com
-------- "I grew up before Mark Zuckerberg invented friendship" --------
========================================================================
1 month, 3 weeks
KDE and GDM
by mario futire
I've been a KDE user for many years and have just recently switched to GNOME, for what is basically a single reason: GDM.
GDM in my opinion offers a fantastic user experience with a super simple "user switch" feature.
In family we all use the same PC so people are constantly switching user.
What happens when I run KDE in GDM or in its own login manager is something like this:
1) switch user
2) end up in a screen with various (dubious) icons, with "user name", a "+", a "create new session" button, an "unused" session??
3) press some of them a bit randomly till I finally go back to the GDM login
In GNOME this is super slick as the step 2) is completely removed.
"Switch user" takes you immediately to the user list.
Can this be achieved in KDE?
2 months, 1 week
Konsole and X11 operands
by George R Goffe
Hi,
"my" Konsole (konsole5-19.08.3-1.fc32.x86_64) doesn't seem to understand X11 operands... Didn't it sort of obey them in earlier releases? I seem to recall a discussion on what the units of measure for "-geometry".
Did this capability get removed or is this a bug/feature?
Thanks,
George...
2 months, 1 week
KDE EPEL8 module plan
by Troy Dawson
Hi,
As the final bugs of modularity in EPEL 8 get worked out, I'm working
on the plan for the kde modules. Right now, I'm leaning towards a
great big kde module with all the kde packages in it. There would be
two streams. rawhide and stable.
rawhide would follow the fedora master dist-git branch. It would get
updated at least once a month, or faster. No quicker than ever two
weeks, because that's how long it takes for things to go through
bodhi. I'm leaning towards once a month.
stable would follow the stable Fxx branch, and get updated every three
months, or when security and/or major bugs happen.
The modules would have *all* the qt5 packages in them, including those
that are in RHEL8. Because of this, we will not be able to mark them
as "default". People will have to enable them to use them.
I am currently working my way through all the packages, making sure
they build and making fixes in rawhide/master when they don't. I
think there should only be about 15 to 20 packages that need tweaking.
Thoughts and/or comments?
Troy Dawson
2 months, 1 week
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
2 months, 1 week
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
2 months, 1 week
