You are not logged in.
Pages: 1
Upgraded to Daedalus, all seems well. Next I installed DigiKam. Appears in menu (xfce) but does not start. When starting digikam from terminal window it says there is no libtiff.so.5. Got that one in place, but now it misses libIlmImf-2_5.so.25. I am probably doing something wrong. What are the correct steps after apt-get install digikam?
Offline
Hello:
Upgraded to Daedalus ...
... installed DigiKam.
... but does not start.
... from terminal window it says there is no libtiff.so.5.
Some dependency issue (?)
... probably doing something wrong.
Not necessarily.
... correct steps after apt-get install digikam?
If it is being installed from the correct Devuan repositories, apt install digikam (as sudo or root) should suffice.
I run Beowulf (not Daedalus) with a backported kernel and XFCE so if I try to install it a HUGE 176MB of files get drawn in.
I do not like KDE so it is definitely not for me.
But being Daedalus a recent release, you should check if all dependencies are being met, maybe something slipped through the packager's error detecting sieve, happens sometimes:
~$ apt show digikam
Package: digikam
Version: 4:5.9.0-1+b1
Priority: optional
Section: graphics
Source: digikam (4:5.9.0-1)
Maintainer: Debian KDE Extras Team <pkg-kde-extras@lists.alioth.debian.org>
Installed-Size: 3731 kB
Depends: digikam-private-libs (= 4:5.9.0-1+b1), libc6 (>= 2.14), libgcc1 (>= 1:3.0), libkf5configcore5 (>= 4.97.0), libkf5coreaddons5 (>= 4.100.0), libkf5filemetadata3 (>= 5.1.0.1), libkf5i18n5 (>= 4.97.0), libqt5core5a (>= 5.11.0~rc1), libqt5gui5 (>= 5.4.0), libqt5sql5 (>= 5.4.0), libqt5widgets5 (>= 5.4.0), libstdc++6 (>= 4.1.1), perl:any, libqt5sql5-sqlite, libqt5sql5-mysql, digikam-data (= 4:5.9.0-1), kipi-plugins (= 4:5.9.0-1+b1)
Recommends: www-browser, ffmpegthumbs
Suggests: digikam-doc, systemsettings
Homepage: http://www.digikam.org
Tag: field::arts, hardware::camera, implemented-in::c++,
interface::graphical, interface::x11, role::program,
scope::application, suite::kde, uitoolkit::qt, use::browsing,
use::learning, use::organizing, use::searching, use::viewing,
works-with::image, works-with::image:raster, x11::application
Download-Size: 3577 kB
APT-Sources: http://deb.devuan.org/merged beowulf/main amd64 Packages
Description: digital photo management application for KDE
~$
In my case (Beowulf), it boils down to this:
Depends:
digikam-private-libs (= 4:5.9.0-1+b1)
libc6 (>= 2.14)
libgcc1 (>= 1:3.0)
libkf5configcore5 (>= 4.97.0)
libkf5coreaddons5 (>= 4.100.0)
libkf5filemetadata3 (>= 5.1.0.1)
libkf5i18n5 (>= 4.97.0)
libqt5core5a (>= 5.11.0~rc1)
libqt5gui5 (>= 5.4.0)
libqt5sql5 (>= 5.4.0)
libqt5widgets5 (>= 5.4.0)
libstdc++6 (>= 4.1.1)
perl:any
libqt5sql5-sqlite
libqt5sql5-mysql
digikam-data (= 4:5.9.0-1)
kipi-plugins (= 4:5.9.0-1+b1)
Once you get your own (Daedalus) depends list, check to see if the right libraries/versions are present and let us know.
Someone who knows more than I about this will surely chip in.
Best,
A.
Offline
Some dependency issue (?)
Thanks for responding!
No, no dependency issues reported during install.
...maybe something slipped through the packager's error detecting sieve, happens sometimes:
Could well be. Here is what I get:
Package: digikam
Version: 4:7.9.0-1+b2
Priority: optional
Section: graphics
Source: digikam (4:7.9.0-1)
Maintainer: Debian KDE Extras Team <pkg-kde-extras@lists.alioth.debian.org>
Installed-Size: 271 kB
Depends: digikam-private-libs (= 4:7.9.0-1+b2),
libc6 (>= 2.34),
libgcc-s1 (>= 3.0),
libkf5configcore5 (>= 4.97.0),
libkf5coreaddons5 (>= 4.100.0),
libkf5i18n5 (>= 4.97.0),
libmagick++-6.q16-8,
libqt5core5a (>= 5.15.1),
libqt5gui5 (>= 5.4.0) | libqt5gui5-gles (>= 5.4.0),
libqt5sql5 (>= 5.4.0),
libqt5widgets5 (>= 5.4.0),
libstdc++6 (>= 4.1.1),
perl:any, libqt5sql5-sqlite,
libqt5sql5-mysql,
digikam-data (= 4:7.9.0-1)
Recommends: www-browser, ffmpegthumbs
Suggests: digikam-doc, breeze-icon-theme, systemsettings
Homepage: http://www.digikam.org
Tag: field::arts, hardware::camera, implemented-in::c++,
interface::graphical, interface::x11, role::program,
scope::application, suite::kde, uitoolkit::qt, use::browsing,
use::learning, use::organizing, use::searching, use::viewing,
works-with::image, works-with::image:raster, x11::application
Download-Size: 82.2 kB
APT-Manual-Installed: yes
APT-Sources: http://deb.devuan.org/merged daedalus/main amd64 Packages
Description: digital photo management application for KDE
I edited the Depends list to one entry per line for better reading, but I don't see libtiff5 nor libIlmImf.
Offline
My system is also Daedalus. Recently upgraded to kernel 6.1.0-12. Something must be skew-whiff in your system. In the following, I do not have DigiKam installed.
$ apt show libtiff.so.5
N: Unable to locate package libtiff.so.5
N: Couldn't find any package by glob 'libtiff.so.5'
N: Unable to locate package libtiff.so.5
N: Couldn't find any package by glob 'libtiff.so.5'
E: No packages found
$ locate libtiff.so
/usr/lib/x86_64-linux-gnu/libtiff.so.6
/usr/lib/x86_64-linux-gnu/libtiff.so.6.0.0
$ apt search tiff
# …
libtiff-tools/stable,now 4.5.0-6 amd64 [installed,automatic]
TIFF manipulation and conversion tools
libtiff6/stable,now 4.5.0-6 amd64 [installed,automatic]
Tag Image File Format (TIFF) library
Online
You need to add Chimaera to your sources list:
deb http://deb.devuan.org/merged/ chimaera main contrib non-free
Refresh:
sudo apt update
Afterwards:
sudo apt install libopenexr25 libtiff5
Offline
Hello:
Thanks for responding!
You're welcome.
... no dependency issues reported during install.
As apt takes care of the pesky dependencies, when you have an issue it won't be reported because it wasn't declared to apt in the first place, which in itself is the issue.
ie: apt won't know about it, won't bitch about it but the application will say it cannot find it. There are other scenarios, of course.
At least I think it works that way and there are other scenarios.
... don't see libtiff5 nor libIlmImf.
It seems that libtiff.so.5 library is provided by the libtiff5 package.
See here: https://packages.debian.org/search?sear … e&arch=any
As for libIlmImf it is provided by the libopenexr package.
See here: https://packages.debian.org/search?mode … =libIlmImf
See if you have it with this: ~$ apt list | grep libtiff5 (do the same as below for libopenexr.
If you do you should get this line:
libtiff5/oldoldstable-security,now 4.1.0+git191117-2~deb10u8 amd64 [installed,automatic]
If you don't have it, try installing it ...
~# apt install libtiff5
... and then see if DigiKam works
Please post the result.
Best,
A.
Offline
As apt takes care of the pesky dependencies, when you have an issue it won't be reported because it wasn't declared to apt in the first place, which in itself is the issue.
As DigiKam is a KDE thing, I wonder if I have underestimated the KDE installation as a prerequisite, it may provide all the libs not explicitly stated as dependencies in the digikam package.
It seems that libtiff.so.5 library is provided by the libtiff5 package.
Yes. As I wrote in my opening post: Got that one in place, ... but digikam wants more and I thought I'd better ask before continuing down the path of "lib-by-lib until quiet". I will think about it.
Last edited by OddS (2023-09-11 06:49:22)
Offline
...Something must be skew-whiff in your system.
Always a possibility.
If I understand you correctly, you say and show that your Daedalus installation has no libtiff.so.5. Thus, our installations agree on that. I don't get how and why that makes my end skewed.
I wrongly expected the digikam package to trigger installations required to meet dependencies or notify me of those that were not available.
Offline
I wrongly expected the digikam package to trigger installations required to meet dependencies or notify me of those that were not available.
…and that is why I used the words 'skew-whiff'. It was NOT intended as a comment on you personally, the comment was aimed at your situation.
I've personally been in the classic Linux situation of dependency-hell. I was running an internet server at the time (CentOS, which was derived from RHEL). My guts therefore squirm in sympathy with anyone finding themselves in a similar situation.
Anyone that has been in that state will also know the classic response from the Distribution maintainers / long-term users to such a problem (the image is of a set of people all placing their arms in front of their chests into the sign of the cross & mumbling the words "all your own fault, nothing to do with me, guv").
Credit to Debian for attempting to escape from Dependency Hell with a well-maintained & documented Repository system that, by majority, keeps everyone's system clean & responsive.
Credit to Devuan for attempting to escape from the brand-new SystemD Hell, a process of escape that echoes many of the characteristics of ridding a forest of Japanese Knotweed, and a virus that promises a level of software Hell lower & more pernicious than any previously known in human experience.
In the face of your situation I tried to help by reporting on my system's (also Daedalus) response to searches on your problematic binaries.
Online
It was NOT intended as a comment on you personally, the comment was aimed at your situation.
Wow! I am sorry if I came across as being offended. I automatically took "system" to mean my Daedalus installation and hoped you had spotted something that escaped me.
Offline
Wow! I am sorry if I came across as being offended.
...and I'm sorry if I over-reacted.
Online
Thanks to all who responded. I did not fully test installing the additional libraries, but I am sure that would have worked. I took the cheap way out using an AppImage.
Offline
Pages: 1