I was curious about something. KDE has its own crash handling system.
How does this community track any metrics around code stability if
upstream gets reports? Kontact has segfaulted 20 times on me today.
Each time it says it cannot generate a bug report. Abrtd does not seem
to pick up anything. Shouldn't it? How does this community track
when a recent update suddenly starts making things crash? Kontact was
fine 3 weeks ago. I updated today (3 weeks of patches) and its crashing
all the time to the point its unusable. It won't generate a bug report,
abrtd seems not to notice either.
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
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.
*** 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.
*** Follow the same LTS stream as qt5 (currently 5.12)
*** 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
** 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?
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.
Ian Pilcher arequipeno(a)gmail.com
-------- "I grew up before Mark Zuckerberg invented friendship" --------
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?
"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?
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?
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
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:
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
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).
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net