Confirming, it segfaults.
Mga8-64, Plasma, i7, nvidia-current
This is using an old user /home, in case it matters (old settings)
 (note in case it matters i have wxgtk3.1 from testing installed)

Assigning to maintainer

Assignee: bugsquad => anaselli
CC: (none) => fri

[ich@laptop ~]$ LANGUAGE=C showfoto
QCommandLineParser: already having an option named "h"
QCommandLineParser: already having an option named "help-all"
QCommandLineParser: already having an option named "v"
digikam.general: No plugins loaded. Please check if the plugins were installed in the correct path, or if any errors occurred while loading plugins.
digikam.widgets: Invalid pixmap specified.
digikam.widgets: Invalid pixmap specified.
digikam.widgets: Invalid pixmap specified.
digikam.widgets: Invalid pixmap specified.
digikam.widgets: Invalid pixmap specified.
digikam.widgets: Invalid pixmap specified.
QPainter::begin: Paint device returned engine == 0, type: 2
QPainter::begin: Paint device returned engine == 0, type: 2
QPainter::begin: Paint device returned engine == 0, type: 2
QPainter::begin: Paint device returned engine == 0, type: 2
Speicherzugriffsfehler (Speicherabzug geschrieben)
[ich@laptop ~]$ 


Last line: "Memory access error (memory dumped)"

I only get three lines of output when launching, and the segmentation fault when trying to Configure 

$ LC_ALL=C showfoto
QCommandLineParser: already having an option named "h"
QCommandLineParser: already having an option named "help-all"
QCommandLineParser: already having an option named "v"
Segmenteringsfel (minnesutskrift skapad)

Angelo has not touched this (digikam) for years. Assigning instead to DavidG who has had most to do with it. Or to KDE team?

Source RPM: Showfoto V7.1.0 R4.1.mga8 => digikam-7.1.0-4.1.mga8.src.rpm
Assignee: anaselli => geiger.david68210
CC: (none) => kde

Please test upcoming digikam/showfoto 7.9.0 in Core/Updates_testing repo!

mga8_64 OK
Plasma, Intel, nvidia-current, backport kernel

Updated to
- digikam-7.9.0-1.mga8.x86_64
- lib64digikamcore7.9.0-7.9.0-1.mga8.x86_64
- lib64digikamdatabase7.9.0-7.9.0-1.mga8.x86_64
- lib64digikamgui7.9.0-7.9.0-1.mga8.x86_64
- lib64opencv_ml4.5-4.5.1-1.3.mga8.x86_64

It needed a reboot to not segfault (maybe a logout/in would suffice)

Opened a jpeg and a pdf, and printed them.
A bunch of mumbojumbo output in Konsole where i started it, but nothing that i think is a problem.

OOPS this have been broken for a year...

Updated packages in core/updates_testing:
========================
libdigikamdatabase7.9.0-7.9.0-1.mga8
lib64digikamdatabase7.9.0-7.9.0-1.mga8
libdigikam-devel-7.9.0-1.mga8
lib64digikam-devel-7.9.0-1.mga8
digikam-7.9.0-1.mga8
libdigikamgui7.9.0-7.9.0-1.mga8
lib64digikamgui7.9.0-7.9.0-1.mga8
libdigikamcore7.9.0-7.9.0-1.mga8
lib64digikamcore7.9.0-7.9.0-1.mga8
showfoto-7.9.0-1.mga8

from SRPMS:
digikam-7.9.0-1.mga8.src.rpm

Thanks
Works, with a couple quirks...

1)
Updated earlier using drakrpm, did not have time to test until now...
How did system end up with both versions of three files installed??

$ rpm -qa | grep digikam | sort
digikam-7.9.0-1.mga8
lib64digikamcore7.1.0-7.1.0-4.2.mga8
lib64digikamcore7.9.0-7.9.0-1.mga8
lib64digikamdatabase7.1.0-7.1.0-4.2.mga8
lib64digikamdatabase7.9.0-7.9.0-1.mga8
lib64digikamgui7.1.0-7.1.0-4.2.mga8
lib64digikamgui7.9.0-7.9.0-1.mga8
[morgan@svarten ~]$ rpm -qa | grep showfoto
showfoto-7.9.0-1.mga8

OK After removing the three old 7.1.0 files, i started showfoto from Konsole.
No messages in Konsole and showfoto can open that menu Settings > Configure Showfoto, and i can also edit a file it segfaulted on before.

But:

2)
When starting Showfoto, it wants to download binaries!
That is new.
But IMO it is good we do not supply them automatically as they are 300MB and is only face engine and red eye removal.

Created attachment 13672 [details]
Showfoto 7.9.0-1 wants to download 299.5 MB binaries

In that dialogue selecting Cancel, program works.

Next time you start it, it asks again.

Probably it is possible to configure it not to ask, but I could not find where in a quick try.

So OK for me, except 

a) I wonder about 1) in comment 8

b) It should be tested to let it download and use face engine & red eye.

(In reply to Morgan Leijström from comment #8)
> Thanks
> Works, with a couple quirks...
> 
> 1)
> Updated earlier using drakrpm, did not have time to test until now...
> How did system end up with both versions of three files installed??
> 
> $ rpm -qa | grep digikam | sort
> digikam-7.9.0-1.mga8
> lib64digikamcore7.1.0-7.1.0-4.2.mga8
> lib64digikamcore7.9.0-7.9.0-1.mga8
> lib64digikamdatabase7.1.0-7.1.0-4.2.mga8
> lib64digikamdatabase7.9.0-7.9.0-1.mga8
> lib64digikamgui7.1.0-7.1.0-4.2.mga8
> lib64digikamgui7.9.0-7.9.0-1.mga8
> [morgan@svarten ~]$ rpm -qa | grep showfoto
> showfoto-7.9.0-1.mga8
> 
I think I can answer that one. Look at the odd system of file names. I don't think drakrpm would see "lib64digikamcore7.9.0-<version>" as being an update of "lib64digikamcore7.1.0-<version>" Same with the others.

To drakrpm they would look like separate libraries. The new one was installed as a dependency, but not as an update, so the old one would not be removed.

We'll need to fix that somehow before pushing this update.

CC: (none) => andrewsfarm

Ah.

Back to packager then for comment 11


For my other concern I think we just let it be as it is.
We do not want tha tmuch extra donwload per default, ad th eupstream soluiton to download after askign user seem sane, and it seem to be working:

(In reply to Morgan Leijström from comment #10)
> b) It should be tested to let it download and use face engine & red eye.

After letting it download, it never ask again. (tested on both mga8 & 9 64 bits.)  I have neither tested using red eye nor face detection, but as it detect the binaries now it should be OK.

Assignee: qa-bugs => geiger.david68210
Keywords: (none) => feedback

urpme --auto-orphans should remove old libs "lib(64)digikam*7.1.0"

Many of our users, particularly our new users, are routinely warned against ever using urpme --auto-orphans because of the potential of breaking their systems. This comes from those who have had it happen, perhaps years ago, or from those who have heard that it has happened to others.

I don't want to debate the truth of that assertion. Nothing we say here is going to make that warning go away, but we should acknowledge that it exists, true or not.

Does leaving these libraries on the system have even the remote potential to cause any harm?

Yes we generally tell users not to use --auto-orphans (bu I do to test that it works, and it do for me...)

It probably does not hurt to keep the old libs, as long as no application use the old despite the new exist. Or may there some upgrade incompatibility against removing the old libs?

How do we usually do?

This bug disappeared, or was corrected in following upgrades. I close this ticket I created.
Thanks a lot to all.

Status: NEW => RESOLVED
Resolution: (none) => FIXED