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
I am running plasma 5.15.90 from the mkyral-plasma-unstable repo.
Everything works and the only problem I have is that applications that usually
are docked like amarok does not show up anymore in the system tray
The application are running but I do not see them. Is there any way to get
them back to visibility instead of being cloaked?
I was trying to setup a Bonjour (local XMPP) account in KDE Plasma System Settings for KDE Telepathy. In `System Settings > Online Accounts > Create`, I clicked "Bonjour" in the list on the right. This action was answered with an error dialogue box: "This IM Account cannot be created - a Telepathy Connection Manager named 'salut' is missing or it cannot handle protocol 'local-xmpp'. Please try installing salut with your package manager." However, `telepathy-salut` is already installed on my machine. Does anyone have an idea how to debug this, or where I would find the actual error message that led to this?
I am using Fedora 27 KDE, with telepathy-salut currently being at version 0.8.1 (release 12.fc27), telepathy-mission control at version 5.16.4 (epoch 1, release 4.fc27) and ktp-accounts-kcm at version 17.12.1(release 1.fc27).
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 use KDE in dark mode.
I have firefox 67 install on f30 and its not honouring the prefers-color-scheme CCS media query.
This works for Firefox 67 on LXDE on F28.
Is this expected to be working? Should I create bug report for this?
(A little long... sorry)
I've been given a new desktop PC at work to replace my (5 year old?) tower PC.
I have run Fedora/KDE for many years, but when previously given new hardware I
have tended to just copy the entire home directory to the new PC. Needless to
say, and with upgrading Fedora from the command-line rather than fresh
installations, a lot of guff has no doubt accumulated in directories and config
For that reason I decided that I would perform a fresh installation this time.
So, next was to see how to export my desktop and panel settings. I was a bit
surprised to see no way of doing this at all. I appreciate that I will have to
export/import settings for various apps that I use - like evolution and firefox
(okay so neither of those is a KDE app!) - but I would have thought KDE would
have something similar.
Googling about this it seems that people have asked for this, but, as far as I
can tell, nothing has happened with it. I noticed
but this is almost 10 years old now, and seems to have made no progress.
I'm not looking to just 'backup' the settings though, I already did that when
backing up the whole home directory. What I would like is something that
exports modified settings, and which I can then import on the upgraded O/S. (So
export on Fedora 29; import on Fedora 30.) The import though would check the
settings to see if they are still valid, and perform some action - even just a
message would be fine - so that the setting can be removed or adjusted as
required. That way no guff should be left around.
Anyway, anyone any advice or know of any progress on this at all?
My current thoughts are to just go for a completely fresh start, and go through
various settings when I feel they need adjusting. I'll keep a note of them for
next time though :-)
John Horne | Senior Operations Analyst | Technology and Information Services
University of Plymouth | Drake Circus | Plymouth | Devon | PL4 8AA | UK
This email and any files with it are confidential and intended solely for the use of the recipient to whom it is addressed. If you are not the intended recipient then copying, distribution or other use of the information contained is strictly prohibited and you should not rely on it. If you have received this email in error please let the sender know immediately and delete it from your system(s). Internet emails are not necessarily secure. While we take every care, University of Plymouth accepts no responsibility for viruses and it is your responsibility to scan emails and their attachments. University of Plymouth does not accept responsibility for any changes made after it was sent. Nothing in this email or its attachments constitutes an order for goods or services unless accompanied by an official order form.
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?
On Fri, 2019-05-17 at 01:09 +0200, Reindl Harald wrote:
> Am 17.05.19 um 00:46 schrieb Patrick O'Callaghan:
> > On Thu, 2019-05-16 at 15:37 -0500, Jason L Tibbitts III wrote:
> > > > > > > > "PO" == Patrick O'Callaghan <pocallaghan(a)gmail.com> writes:
> > >
> > > PO> [...] so I may just leave it for now as I don't want to lose the
> > > PO> background database updating (which I had thought was a function of
> > > PO> dnf proper, but apparently isn't).
> > >
> > > Isn't that what dnf-makecache.timer does? systemctl list-timers and see
> > > if it's enabled. Runs ten minutes after boot and every hour after that,
> > > and just does "dnf makecache --timer". Or is that not the database
> > > updating you were expecting dnf to do? All you need to do is enable and
> > > start the timer:
> > >
> > > systemctl enable dnf-makecache.timer
> > > systemctl start dnf-makecache.timer
> > Yes, that is enabled. I was confused because on trying to remove
> > dnfdragora-updater I get:
> > I mistakenly thought that dnfdaemon was what handled the background
> > updating, but apparently not.
> amazing given that how many years are you now active on fedora
> mailing-lists and still no clue or development of knowledge
Unlike some, I don't claim to know everything. I also believe that the
best way to get answers is to ask questions.