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
Looking over some broken deps reports, I came across some old packages:
Of these, the only one that's not a pure leaf package is perl-Qt (debconf-
kde depends on it).
any comment or objection to considering orphaning most (all minus
smokeqt/perl-Qt) or all of these ?
Just moved from Fedora 21 to F25. Under F21 I had a file ~/.gtkrc-2.0 which contained
gtk-key-theme-name = "Emacs"
This enabled basic Emacs cursor motion keyboard commands in text input boxes throughout KDE,
Firefox, &c. (Outside of input boxes, KDE shortcuts ruled.)
How can I get this same behaviour for Plasma 5 w/in F25? From reading around, I've created
gtk-key-theme-name = Emacs
in this empty file. This has given the desired result in Firefox and Thunderbird,
but not w/in arbitrary text boxes in KDE (e.g. Alt-F2). The ~/.gtkrc-2.0 file is still
intact, by the way. It seems to have no effect. Any ideas?
since both KDE upstream and the Fedora KDE SIG refuse to fix the regression
that Dolphin, KWrite, and Kate can no longer be run as root, I have decided
to write a small metapackage that automatically applies the binary patch to
fix the issue.
The patch that is applied is the 's/getuid/getpid/g' hack, see:
for an explanation of how it works.
The patched executables are written to /usr/local/bin. The metapackage uses
file triggers so that the patched version is automatically updated when the
original copy in /usr/bin is updated from the system package. While it would
be possible in principle with this method to apply the patches in place in
/usr/bin, I have decided against it, for 2 reasons:
1. integrity checks such as rpm -Va would fail on the patched executables,
2. delta RPMs would fail because the original RPM could not be
Writing the patched executables to a different directory avoids this issue.
After installing this package, e.g., "kdesu kwrite" should just work again.
You can get the package from the Kannolo Copr:
Direct package link:
After the recent updates of qt5-qtwebengine there are white spaces in the
message window when using a Dark Theme.
Another user has just reported this on kde.bugs with a screen shot
I don't know if it is a kmail or qtwebengine bug or even related to mesa/
Fedora 25 (Twenty Five)
Registered Linux user number #342953
On a new Fedora 26 installation, I am seeing a delay of around 30
seconds when logging into a Plasma session. (This delay doesn't exist
on F25 on this system.)
Any ideas where I can look to figure out what is going on?
Ian Pilcher arequipeno(a)gmail.com
-------- "I grew up before Mark Zuckerberg invented friendship" --------
There used to be a 'move to screen' along with the 'move to desktop' in the
taskbar, if you had multiple screens. This was really helpful sometimes
when I connect a 2nd screen and can't get things configured right (usually
when I'm giving a presentation!) The options is no longer there, although
it is on kde window decorations (but not on apps such as evince).
Is there a way to get this back?
I've been using KMail with Akonadi/IMAP for a number of years and have been
able to use GSSAPI authentication without issue at least back through F23.
After upgrading to F26, KMail now asks for a password every X minutes.
Without entering a password, I click "Ok" and it proceeds to retrieve my
My Cyrus logs indicate I logged in with GSSAPI.
Has anyone else run into this sort of thing?
Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery
F9B6 560E 68EA 037D 8C3D D1C9 FF31 3BDB D9D8 99B6
Has anyone tried running a F26/KDE guest in qemu/kvm and 4.12.8-300 kernel?
It seems I need to remove "rhgb quiet" from the start to get it to run. And, when I
do get it to run I can't get the display size to change.
This was just a new install of a guest so the only other kernel I have
kernel-4.11.11-300 works fine. I can boot to it, resize the window, and then use
"xrandr --output Virtual-0 --auto" and the display will properly resize and continue
to resize if I change the window size it is running within.
But with the 4.12.8-300 kernel while xrandr shows it has acquired the desired
resolution it does not in-fact resize to fill the window.
Fedora Users List - The place to go to speculate endlessly