That one in the install USB, remove it too. Show zypper lr -d again
~> zypper lr -d
# | Alias | Name | Enabled | GPG Check | Refresh | Keep | Priority | Type | URI | Service
--+----------------------------------+---------------------------+---------+-----------+---------+------+----------+--------+---------------------------------------------------------------------------------+--------
1 | download.opensuse.org-non-oss | Repository principale (-> | Sì | (r ) Sì | Sì | - | 99 | rpm-md | http://download.opensuse.org/tumbleweed/repo/non-oss/ |
2 | download.opensuse.org-oss | Repository principale (-> | Sì | (r ) Sì | Sì | - | 99 | rpm-md | http://download.opensuse.org/tumbleweed/repo/oss/ |
3 | download.opensuse.org-tumbleweed | Repository principale d-> | Sì | (r ) Sì | Sì | - | 99 | rpm-md | http://download.opensuse.org/update/tumbleweed/ |
4 | openSUSE-20240725-0 | openSUSE-20240725-0 | No | ---- | ---- | - | 99 | rpm-md | hd:/?device=/dev/disk/by-id/usb-JetFlash_Transcend_16GB_ZFURB3G5-0:0-part2 |
5 | packman-essentials | packman-essentials | Sì | (r ) Sì | Sì | - | 90 | rpm-md | https://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/Essentials/ |
6 | repo-debug | openSUSE-Tumbleweed-Debug | No | ---- | ---- | - | 99 | N/A | http://download.opensuse.org/debug/tumbleweed/repo/oss/ |
7 | repo-openh264 | Open H.264 Codec (openS-> | Sì | (r ) Sì | Sì | - | 99 | rpm-md | http://codecs.opensuse.org/openh264/openSUSE_Tumbleweed |
8 | repo-source | openSUSE-Tumbleweed-Sou-> | No | ---- | ---- | - | 99 | N/A | http://download.opensuse.org/source/tumbleweed/repo/oss/ |
9 | snappy | snappy | Sì | (r ) Sì | No | - | 99 | rpm-md | https://download.opensuse.org/repositories/system:/snappy/openSUSE_Tumbleweed/ |
It was not clear to me what I had to remove. Now I removed one more repo (openSUSE-20240725-0). Is it what you asked for?
:~> zypper lr -d
# | Alias | Name | Enabled | GPG Check | Refresh | Keep | Priority | Type | URI | Service
--+----------------------------------+---------------------------+---------+-----------+---------+------+----------+--------+---------------------------------------------------------------------------------+--------
1 | download.opensuse.org-non-oss | Repository principale (-> | Yes | (r ) Yes | Yes | - | 99 | rpm-md | http://download.opensuse.org/tumbleweed/repo/non-oss/ |
2 | download.opensuse.org-oss | Repository principale (-> | Yes | (r ) Yes | Yes | - | 99 | rpm-md | http://download.opensuse.org/tumbleweed/repo/oss/ |
3 | download.opensuse.org-tumbleweed | Repository principale d-> | Yes | (r ) Yes | Yes | - | 99 | rpm-md | http://download.opensuse.org/update/tumbleweed/ |
4 | packman-essentials | packman-essentials | Yes | (r ) Yes | Yes | - | 90 | rpm-md | https://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/Essentials/ |
5 | repo-debug | openSUSE-Tumbleweed-Debug | No | ---- | ---- | - | 99 | N/A | http://download.opensuse.org/debug/tumbleweed/repo/oss/ |
6 | repo-openh264 | Open H.264 Codec (openS-> | Yes | (r ) Yes | Yes | - | 99 | rpm-md | http://codecs.opensuse.org/openh264/openSUSE_Tumbleweed |
7 | repo-source | openSUSE-Tumbleweed-Sou-> | No | ---- | ---- | - | 99 | N/A | http://download.opensuse.org/source/tumbleweed/repo/oss/ |
8 | snappy | snappy | Yes | (r ) Yes | No | - | 99 | rpm-md | https://download.opensuse.org/repositories/system:/snappy/openSUSE_Tumbleweed/ |
After several updates, some of them very big, showFoto still doesn’t opens.
Opened a bug
1 Like
Unfortunately no news in forum nor from bugzilla. And it’s more than two months that ShowFoto doesn’t works.
Looking at the errors, from what I can decipher, they point to a possible cause, where the application is failing to find and load necessary resources, such as pixmaps and map theme files.
Case in Point:
The first set of errors, Detected locale “C” with character encoding “ANSI_X3.4-1968”, which is not UTF-8, suggests a locale misconfiguration. The application, which I think < unsure > is built on the Qt framework, requires a UTF-8 locale to function correctly. While the program attempts to fix this by switching to “C.UTF-8”, the locale setting may still be a symptom of an environment issue that could affect how the application looks for files.
The repeated messages like Invalid pixmap specified and QFSFileEngine::open: No file name specified are interesting. These suggest to me that showFoto is attempting to load icons, buttons, or other graphical elements but is either given an invalid file path or no path at all. The application can’t find the resources it needs to build its graphical user interface.
The digikam.geocore errors, specifically Map theme file does not exist: “”, suggest to me that that the application’s geolocation component is also failing to load some map (?) data. This again suggests to me that the application cannot find its required data files.
Having typed the above ( failing to find and load necessary resources) , I do not know the solution.
I assume you tried deleting showFoto and re-installing, in case you had a corrupted install?
Another possibility is your user configuration files for showFoto are corrupted. (usually in ~/.config/ or ~/.local/share/) . You could delete those and try again - although given you tried as another user, that is probably not likely.
I am curious to find out what may be the response to your bug report.
Thanks for detailed answer.
Of course. Tried again now and still doesn’t start.
Searching for “showfoto” I found “/home/giorgio/.cache/showfoto” that’s and empty folder. And "/home/giorgio/.local/share/showfoto/favorites.xml ", quite old. Deleted and started again ShowFoto nothing change and file is not recreated.
Hope that someone will look to bug report.
I don’t have any known answers.
I believe showfoto also comes with the digikam software (as opposed to installing separate)…
Are you using showfoto as standalone or as part of digikam?
If standalone, have you tried to remove it, install digikam, and see if it then runs ok as part of digikam?
As noted I don’t have any answers, I am just proposing possibilities.
Okay, I just installed showfoto in Leap 16 RC (running in VBox VM).
showfoto does NOT work in Leap 16 RC either.
I executed showfoto at the command line and I get the exact same output, except for the first 3-4 lines about the UTF output … so, my opinion - the problem is NOT about the encoding. (I may have some other arcane issue).
Okay, I’m putting my output here, first … I also show @Giorgio_os output below mine, if comparing is of interest to anyone.
And in the meantime … I’m gonna do some brief debugging, so see what turns up.
My CLI output
username@vbox:~> showfoto
VMware: No 3D enabled (0, Success).
libEGL warning: egl: failed to create dri2 screen
VMware: No 3D enabled (0, Success).
libEGL warning: egl: failed to create dri2 screen
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.
digikam.geocore: Map theme file does not exist: ""
QFSFileEngine::open: No file name specified
qt.svg: Cannot open file '', because: No file name specified
QFSFileEngine::open: No file name specified
qt.svg: Cannot open file '', because: No file name specified
QFSFileEngine::open: No file name specified
qt.svg: Cannot open file '', because: No file name specified
QFSFileEngine::open: No file name specified
qt.svg: Cannot open file '', because: No file name specified
QFSFileEngine::open: No file name specified
qt.svg: Cannot open file '', because: No file name specified
QFSFileEngine::open: No file name specified
qt.svg: Cannot open file '', because: No file name specified
QFSFileEngine::open: No file name specified
qt.svg: Cannot open file '', because: No file name specified
QFSFileEngine::open: No file name specified
qt.svg: Cannot open file '', because: No file name specified
QFSFileEngine::open: No file name specified
qt.svg: Cannot open file '', because: No file name specified
QFSFileEngine::open: No file name specified
qt.svg: Cannot open file '', because: No file name specified
QFSFileEngine::open: No file name specified
qt.svg: Cannot open file '', because: No file name specified
QFSFileEngine::open: No file name specified
qt.svg: Cannot open file '', because: No file name specified
digikam.geocore: Map theme file does not exist: ""
digikam.geocore: Falling back to default theme: "earth/srtm/srtm.dgml"
digikam.geocore: Map theme file does not exist: ""
digikam.geocore: Couldn't find a valid DGML map.
digikam.geocore: Map theme file does not exist: ""
digikam.geocore: Falling back to default theme: "earth/srtm/srtm.dgml"
digikam.geocore: Map theme file does not exist: ""
digikam.geocore: Couldn't find a valid DGML map.
digikam.geocore: Map theme file does not exist: ""
digikam.geocore: Falling back to default theme: "earth/srtm/srtm.dgml"
digikam.geocore: Map theme file does not exist: ""
digikam.geocore: Couldn't find a valid DGML map.
IFFChunk::innerFromDevice: unkwnown chunk "\x89PNG"
Segmentation fault (core dumped)
username@vbox:~>
Okay, nothing real important … but an observation.
I executed KDE’s “System Montior” application and noticed that “shotofoto” app was still listed in the “Applications” tab. So, I grabbed the PID of the process and looked it up at the command line … there is a process that STILL exists, even after showfoto has executed and crashed … it’s the “exiftool” process.
So, let’s say you execute showfoto 10 times, and it crashes, those “exiftool” processes will still be running … so after 10 crashes, there will be 10 instances of exiftool still running. (until you reboot or logout / log back in).
username@vbox:~> ps aux | grep exif
username 2021 0.9 0.4 23072 19980 pts/0 S 11:07 0:00 perl /usr/bin/exiftool -stay_open true -@ - -common_args -charset filename=UTF8 -charset iptc=UTF8
username 2077 0.0 0.1 6592 4172 pts/0 S+ 11:08 0:00 grep --color=auto exif
username@vbox:~> kill 2021
username@vbox:~> ps aux | grep exif
username 2097 0.0 0.1 6592 4184 pts/0 S+ 11:09 0:00 grep --color=auto exif
username@vbox:~>
Weird thing is: I’m on TW too, showfoto works as expected. The only repo difference here is that I use full Packman ( for AMD Mesa reasons ). Digikam was already installed when Showfoto was installed.
FYI: Plasma6 on Wayland.
(sidenote: I could not spend time debugging this using Plasma / wayland.
After logging in, within 5-10 minutes, it would lock up and I’d have to kill the VM.
I rebooted 5-6 times and after that many lockups …
Finally, I logged in using Plasma/X11 option and zero issues.
And able to determine the issue, on my install.)
Keep in mind, I’m using Leap 16 RC, not TW … although, I used to use showfoto often, when on TW. Haven’t done much photo processing in quite a while.
So, it seems the issue (here) is “missing files”.
In my strace output, the meaningful errors were:
.
2451 access("/home/username/.config/showfoto_systemrc", F_OK) = -1 ENOENT (No such file or directory)
2451 statx(AT_FDCWD, "/home/username/.local/share/digikam/dnnmodels/dnnmodels.conf", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT, STATX_ALL, 0x7ffcc21fa250) = -1 ENOENT (No such file or directory)
2451 statx(AT_FDCWD, "/home/username/.local/share/flatpak/exports/share/digikam/dnnmodels/dnnmodels.conf", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT, STATX_ALL, 0x7ffcc21fa250) = -1 ENOENT (No such file or directory)
2451 statx(AT_FDCWD, "/var/lib/flatpak/exports/share/digikam/dnnmodels/dnnmodels.conf", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT, STATX_ALL, 0x7ffcc21fa250) = -1 ENOENT (No such file or directory)
2451 statx(AT_FDCWD, "/usr/local/share/digikam/dnnmodels/dnnmodels.conf", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT, STATX_ALL, 0x7ffcc21fa250) = -1 ENOENT (No such file or directory)
2451 statx(AT_FDCWD, "/usr/share/digikam/dnnmodels/dnnmodels.conf", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT, STATX_ALL, 0x7ffcc21fa250) = -1 ENOENT (No such file or directory)
2451 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x8} ---
.
So, I simply used “touch” to create the files.
Of course, with touch, they will be empty. But hey, showfoto started up!
I ran these, in my home sub-dir:
:~> touch ./.config/showfoto_systemrc
:~> mkdir ./.local/share/digikam/dnnmodels
:~> touch ./.local/share/digikam/dnnmodels/dnnmodels.conf
Check for the existence of those files … why they are suddenly required … or if they were deleted because of the update … it’s unclear (to me).
I did check for a Flatpak version of ShowFoto, because I would prefer that option, but for Leap 16, it’s not found in Discover.
Digikam is involved in some way. Here’s is what is still installed (related to digikam) after removing ShowFoto:
Then I installed Digikam (and digikam lang). Digikam start normally and I see my photo in raw format. A small improvement.
With Digikam installed ShowFoto works too. This is a solution (may be not “the solution”).
If I remove Digikam again ShowFoto doesn’t start.
Then waiting for the best solution I keep Digikam installed.
Now suddenly Whatsapp for Linux doesn’t works anymore. It opens but no messages shown. I think it’s related to ShowFoto and Digikam.
What a mess!
I strongly doubt that. From what I see now, Showfoto cannot create it’s config files if the digikam folders aren’t there. But, I can’t imagine Whatsapp for Linux issues being related
Yesterday Whatsapp for Linux it stopped just after installing and removing Digikam and ShowFoto.
Today it works again without any changing in system, just sleeping. 
Hope that TW don’t became unstable.
Have to reply to this:
- Don’t draw conclusions based on circumstantial evidence, that may be nothing more than a coincidence
- Look for real messages, in this case install Digikam and Slowfoto, then fire up WhatsApp from a terminal and look for error / failed messages
- WhatsApp has a reputation of not being open source at all. Changes to their code are rolled out to the world without detailed information. The devs basically can only wait and then fix what WhatsApp broke.
- The above made me decide to use the Ferdium (a fork of Frantz, the multi-platform wrapper) flatpak years ago. Flatpaks run as isolated containers, i.e. cannot conflict with system libraries (disclaimer: there might be exceptions that I am not aware of ).
I’m not sure whether to take this with a grain of sait. I would have understood “I hope WhatsApp hasn’t become buggy/unstable”, but if you are serious, I cannot understand how you get into doubts about the entire distro by a single failing application to use a proprietary, closed source platform.
Since I love thinking in analogies:
- Yesterday there was a power outage in my apartment building affecting only the shared systems ( no intercom, no elevator, entrance and exit of the building non-functional ). Did the thought “I hope the entire building is not collapsing” come up even once? No, not even once. I waited for ~2 hours and it appeared that the system had shut itself down due to too big temperature difference in a 12h time span, maintenance remotely reset the system ( downtime was actually ~20 min ).
- Some years ago two of the spokes of my bike’s front wheel broke. Did I even once think “I hope the bike is not a total loss” ? Of course not, I thought “<nasty_word_here>, now I have to walk to the bike repair shop (~ 30m) with the front wheel off of the ground (so ~1h) and have lunch whilst waiting for it to be fixed”.
2 Likes
May be I’ve been too rushed. But Whatsapp stopped working exactly after solution of ShowFoto problem.
This was my situation yesterday night. I used terminal to start WA but no messages at all in terminal and WA screen was white. No change.
Even now, with WA working, no messages at all using terminal.
This is new for me. I think it was an open-source application to use WA in Linux.
This is quite bad. Given that WA is very used having an open-source application in Linux that can interact with WA could be very useful.
Anyway now WA works again without any “change” in system. Just an overnight sleep.
There is definitely no official open source client for WhatsApp. All of them are just wrappers that internally use WhatsApp Web, i.e. the browser version.