A new Fedora badge has been proposed for "membership in the KDE SIG":
As far as I can see, there is not a formal definition of membership in
the group. Some options for awarding the badge:
- We could create a new FAS group and trigger the badge awarding off
of that. Lots of other badges work this way, so it is easy to do.
The only downside is that you have a FAS group with no other real
purpose than for handing out badges. It has to be maintained,
pruned eventually, etc..
- Or, instead, we could take one or two volunteers from the SIG to be
'in charge' of the badge. There is a self-service interface in the
webapp where they could manually award the badge to sig members as
they see fit.
I'd like to do it however the sig wants it done. Can you hash it out
and let the badges crew know by posting back in the trac ticket above?
An alternative baloo-kcmadv with more features and closer to the nepomuk
kcm is under development, and has been packaged in f20/kde-unstable repo.
disable indexing button
Once installed, you'll see a new item "Desktop Search Advanced" in
I did the switch to KDE 4.13 and I seem to lost the tags that I've added to my
files. This is most likely due to Nepomuk - > Baloo migration.
Could not find anything useful on the list or in the web, so :
Are the tags lost , or I need to dig deeper into how to attempt to retrieve
them from some data store that Nepomuk had ?
If so, any hints or links on how to do it ?
Before any comments, found and tried some info, but nepomukbaloomigrator
crashes on me, and I can't start nepomuk from my user, only from root (where
tags aren't existing, obviously)
Systems Administrator (LPIC 3, Novell CLA certified)
T: 0845 421 0444
For the last few weeks, I've had an annoying intermittent problem with kde-
plasma-nm. I'm connected to wired enet at work on my laptop. I go home and now
connected to wifi, after sleep/resume. But plasma-nm keeps showing a spinning
around graphic, and says it's connecting to the wired enet (which is not plugged
in). I wouldn't care, but it's causing kde plasma-desktop to eat about 30% cpu.
I can stop it by clicking on plasma-nm and choosing 'disconnect' from the wired
-- Those who don't understand recursion are doomed to repeat it
Another pkg in need of some reviewer love,
It's a new version of qca, but taking the opportunity to rename existing
qca2 to qca while we're at it.
I'll be happy to swap reviews, let me know, thanks.
I originally sent this message to the Fedora users list, but the only
response I got was a note from Patrick O'Callaghan suggesting it might be
better directed to the KDE on Fedora list. (I had previously posted on the
digikam users list, but got no response.) So here it is:
On a fully updated Fedora 20, I've had the following problems importing
images from a Canon EOS SL1 since the update from digikam 3.5 to 4.0
(which I got July 26):
- The digikam camera window doesn't show thumbnails or previews, just icons
for RAW and/or JPEG. I can't seem to preview the images to select the
ones to import. Digikam does recognize the camera, it just won't show
thumbnails or previews of the images on the camera.
- Digikam gets the date from JPEGs to do renaming as I have specified, but
it seems to think that all of the RAW files were created on 1969-12-31
at 19:00:00, at least from the filenames it's generating. Once the files
are imported (I just import all of them without doing any selection), the
"File properties" in digikam shows the correct date for each image. (Well,
up to time zone issues: my camera is set to Eastern Daylight Time, and
Digikam seems to be interpreting that as Universal Time and then correcting
for my computer's time zone, so things are off by 4 hours--but this was true
before the update, too. Is this a configuration problem on my part?)
- I have digikam set to create a new sub-album with the date; so I have
<root album>/<year>/<month>/<date>. I'm importing into the <month>.
JPEGs are correctly put in a sub-album with the date, but RAW images are
put into the <month>, not into a sub-album. I assume this is connected
to not being able to correctly get the date for the RAW images during the
All of this (except for the time zone stuff) worked fine with 3.5. I
tried downloading the bodhi builds of digikam 4.2 for Fedora 20, but I'm
seeing the same issues as with 4.0. I looked through the digikam mailing
list archives and saw that some other people had problems with previewing
images from the camera with Canon cameras on 4.0, but the only response
was a claim that digikam was using gphoto2, with no details or follow-up.
(I can download the images from the gphoto2 command line, too. The
problem is not seeing thumbnails in the camera window to decide
what to download, or getting the dates on RAW images.) Shotwell seems to
be able to generate thumbnails of images in the camera before downloading
and gets the correct dates on RAW images.
I only started using digikam in early July, so it may well be that this is
pilot error, but I haven't been able to figure it out from the
documentation. I don't think I changed any digikam settings with the
upgrade from 3.5 to 4.0, and nothing about the camera changed at that
Thanks for any help. If nobody's got a solution, should I file it on the
Fedora bugzilla, or upstream?
That's odd. libkompardiff2 had to be available in the copr to even build kompare in the first place.
I see it here in the results dir:
Other stuff (like kile, kbibtex) is ideally put into EPEL rather than in this copr (unless it requires newer or incompatible dependencies only available in the kde4 copr)
From: kde-bounces(a)lists.fedoraproject.org <kde-bounces(a)lists.fedoraproject.org> on behalf of Orion Poplawski <orion(a)cora.nwra.com>
Sent: Wednesday, November 19, 2014 5:28 PM
To: KDE on Fedora discussion
Subject: rdieter / kde4
kompare-4.14.1-1.el7.centos.x86_64 requires libkomparediff2.so.4()(64bit)
kompare-libs-4.14.1-1.el7.centos.x86_64 requires libkomparediff2.so.4()(64bit)
Also, seems like kile, kbibtex, others are missing. Any chance they could be
In F20, when using pam-kwallet and setting kwallet to
always remain open, no password was required when
In F21, when using pam-kwallet and setting kwallet to
always remain open, a password IS required when starting
kmail (even though kmail and the pop3 accounts are all
set to always allow).
Why is a password required? How to get rid of it?
this kind of reminder that I like to have :)
You may update to kde-4.14.3, if you haven't updates-testing enabled,
yum update --enablerepo=updates-testing --advisory
I testing it now and it is OK
Sérgio M. B.