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 ?
I discovered in a recent update that KDE now directly supports the
"windows" key for launching the start menu. So I removed ksuperkey and the
auto-start entry, and everything works fine! Except that after some time,
it stops working.
So far I haven't been able to pin down a specific action that causes it to
break, but I am trying to do so.
Has anyone else seen this?
There was a gpgme update last night and this morning I notice
that kmail doesn't work any longer.
When I start it from the command line, I get the error message:
kmail: relocation error: /lib64/libKF5Gpgmepp-pthread.so.5:
symbol gpgme_pubkey_algo_string, version GPGME_1.1 not defined in
file libgpgme.so.11 with link time reference
My question is about Wayland. Using, sddm, is Xorg the default unless
you enable Wayland in the sddm.conf file?
I am about to upgrade three other machines and with Nvidia not
supporting Wayland, then I want to ensure that I can still use the
Nvidia closed source drivers.
I installed a package a few weeks back and added a widget to my Plasma
panel for easy access. I subsequently removed the package so the widget
now points at nothing, but I can't seem to get rid of it. None of the
right-click options seem to apply.
This can't be that hard can it?
On 11/01/17 02:16, Piotr Gbyliczek wrote:
> I have a pretty old machine with ATI R4850 in it using open source drivers. It
> runs F25, and until recently was booting fine.
> I have changed my old monitor to an UHD monitor, and that's where the problems
> started. I simply can't get screen to display anything, it seems, unless :
> 1. I connect old monitor. It shows Plymouth, then it is only active screen in
> SDDM, and then it turns off, leaving UHD display working. That last feature is
> I think thanks to fact that I've disabled it in System Settings -> Display and
> Monitor -> Display Configuration, as before it stayed on.
> 2. I set grub to use a theme. UHD screen is flashing through Plymouth run
> (trying to find correct resolution ?), then SDDM is shown, fully working. Upon
> login I can see KDE loading screen, and I'm back to blank screen presumably
> cycling through resolutions, as screen goes off, then on, then off and displays
> My assumption is that the monitor's preferred resolution is way more than my
> old machine can display, and it struggles with it. Any ideas on how to set the
> correct resolution for it KDE, and maybe for Plymouth ?
> I've tried setting modelines and resolution in xorg.conf file
> (/etc/X11/xorg.conf.d/00-video.conf to be precise), as well as presumably
> disabling EDID. It seems to have no effect.
> For Plymouth, I'm not too concern about it, I can live with text boot, but it
> was nice thing to have. I would prefer to have text based grub, rather than a
> themed one.
> Any ideas I could try ? Any specific settings for this ? As said, tried to set
> up modelines and specific resolution, but maybe this was not picked up
> Thanks in advance.
I had a similar problem some years ago but with KDM. I had to tell it
what monitor to use on boot as there was a projector and monitor configured.
Can you get to your BIOS screen when you boot with the UHD monitor? If
not, then you have to sort that out first. You have to configure the
system to default to the UHD monitor.
On my dual monitor system at work, I get boot screen on both monitors so
I wonder if there is an issue with the ATI card.
Is this a built in video card on the mother board?
what about forward fedora tickets to upstream?
no - when you have write permissions the correct way is always to write
into the file directly because then you don't even need write
permissions on the folder
and don't give write permissions on the folder is the only way to
prevent users from replace files which they are not allowed because with
write permissions in a directory is enough the rename read-only files
and create a new one with the same name
guess what happens with kate - "you hae no permissions..." when you try
to save a file even owned by you in a ro-folder *because* of that
tempfile behavior i am talking about
the issue exists for much longer than 2014 and was multiple times
reported - and no don't pint me to the upstream bugtracker, they don't
care about bugreports when they don't come from distro maintainers (