usb camera list does not show up anymore in digikam

[Martin Hoefling]

Binary package hint: digikam

martin@orthanc:~$ gphoto2 --auto-detect
Modell Port
----------------------------------------------------------
Canon Digital IXUS 70 (PTP mode) usb:
Canon Digital IXUS 70 (PTP mode) usb:006,016

Architecture: amd64
digikam
Version: 2:0.9.2-2ubuntu1

martin@orthanc:~$ uname -r
2.6.22-12-generic

libgphoto2
Version: 2.4.0-2ubuntu1

[Michal Kolodziejczyk (miko-wp)]

Version: 0.8.1 (using KDE KDE 3.5.2)
Installed from: Compiled From Sources
Compiler: gcc 4.0.3
OS: Linux

When libgphoto is upgraded to 2.1.99 (and probably upcoming 2.2 version), it does not connect to USB camera (I am using C 350D, but it probably does not matter). I have checked digikam 0.8.1 and 0.8.2-beta1.
Version 2.1.99 of libgphoto2 was released on December 26th.

[Marcus Meissner (marcus-jet)]

does it work with the command line gphoto2?

which exact camera is this? C 350d? Canon 350D?

You might need to xswitch the camera "PTP" mode.

[Michal Kolodziejczyk (miko-wp)]

It is Canon 350D. It works with command-line gphoto2 and with gtkam (which is a GUI). Digikam works again when you downgrade libgphoto2 to 2.1.6.
I always have the PTP mode on.
In my opinion, digikam is not compatible with libgphoto2 2.1.99, at least when it comes to connecting to the camera with USB.

[Kent-i (kent-i)]

I've been dabbling with this bug for a few months now with a Canon A620, after having downgraded to 2.1.6 and back and forth. I saw an addition in the gphoto2 docs about the print-usb-usermap being depreciated. With the pre 2.1.99 I have to add a special entry for the camera in the .usermap to use it as a generic PTP camera. After installing 2.1.99 there is no camera listing at all in digikam and thus no functionality. Using the command line gphoto2 and gtkam, the A620 is properly detected.

Relevent line from gphoto2 doc:
Note (TODO). print-usb-usermap is deprecated as of 2.1.99.1. Use print-camera-list instead. Description of udev rules and HAL setup missing here.

[pavel heimlich (tropikhajma)]

the bug is present in 0.8.2-rc1 in Mandriva Cooker. Downgrading to libgphoto2-2.1.6-8 fixes it for me.

[Cpeikert-i (cpeikert-i)]

I see this bug as well, with the new gphoto 2.2.0 release in Debian unstable. I have a "generic PTP camera" set up in digikam, which worked under gphoto 2.1.6 with my PowerShot SD450. Now digikam will not connect to the camera at all to download thumbnails etc, nor will it auto-detect my camera.

The camera works fine from the command line with the gphoto2 utility: auto-detection, downloads, etc.

[Marcus Meissner (marcus-jet)]

libgphoto2 2.2.0 has a new library major version. you need to recompile digikam very likely.

you can see this if you try to list all available cameras in digikam.

[Cpeikert-i (cpeikert-i)]

I have found a fix to this bug, for Debian at least (no recompile of digikam needed).

Install the libgphoto2-2-dev package. Then everything works fine in digikam: auto-detect, connecting to camera, downloading, etc. None of these features work without the -dev package.

I cannot tell what is in that package that might make a difference: the only binaries I see are gphoto2-port-config, gphoto2-config, libgphoto2_port.so, and libgphoto2.so. The rest are documentation files, headers, and various .a and .la camera libraries.

[Marcus Meissner (marcus-jet)]

then its likely the missing .la files for the camera drivers and port drivers.

While libtool .la files are usually only used during compilation, for libgphoto2 they are used during runtime too.

[Toma-u (toma-u)]

Gilles, can't you link against this?

[Hubert Figuiere (hub)]

libgphoto2 does not have a new major... It is still .so.2

[Achim Bohnet (allee)]

Reproduceable in Kubuntu/Dapper and SuSE 10.1.

#6 (Marcus Meisner) #10 (Hubert Fuguiere):

also in Kubuntu/Dapper and debian/sid libghoto2 2.1.6 and 2.2.0 (rebuild debian
pkg in dapper) have both major version 2:

$ l 2.*/usr/lib/libgph*.so.2.*
-rw-r--r-- 1 ach ach 101800 2006-05-10 16:31 2.1.6/usr/lib/libgphoto2.so.2.0.3
-rw-r--r-- 1 ach ach 101696 2006-06-20 00:40 2.2/usr/lib/libgphoto2.so.2.1.0
$ objdump -p 2.*/usr/lib/libgph*.so.2.* | grep SONAME
  SONAME libgphoto2.so.2
  SONAME libgphoto2.so.2

Gilles and I tried to rebuild digikam with libgphoto2-2 installed.
Still without the 2.2.0's .la files camera list is empty. So it's
a runtime, not a build time problem.

One difference between 2.1.6 and 2.2.0 is that the camera plugins
are
    /usr/lib/libgphoto2/2.1.6/libgphoto2_<type>.so
and
    /usr/lib/libghoto2/2.2.0/<type>.so
respectively.

With strace one gets:

$ strace digikam --detect-camera 2>&1 | grep /usr/lib/libgphoto2/2.2.0/
open("/usr/lib/libgphoto2/2.2.0/adc65.la", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/libgphoto2/2.2.0/adc65", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/libgphoto2/2.2.0/agfa_cl20.la", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/libgphoto2/2.2.0/agfa_cl20", O_RDONLY) = -1 ENOENT (No such file or directory)
...

and for gtkkam instead

allee(130) ~/tmp $ strace gtkam 2>&1 | grep /usr/lib/libgphoto2/2.2.0/
open("/usr/lib/libgphoto2/2.2.0/adc65.la", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/libgphoto2/2.2.0/adc65.so", O_RDONLY) = 5
open("/usr/lib/libgphoto2/2.2.0/agfa_cl20.la", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/libgphoto2/2.2.0/agfa_cl20.so", O_RDONLY) = 5

So while gtkam and digikam use the same libgphoto2

$ ldd /usr/bin/digikam | grep libgphoto
        libgphoto2.so.2 => /usr/lib/libgphoto2.so.2 (0xb6565000)
        libgphoto2_port.so.0 => /usr/lib/libgphoto2_port.so.0 (0xb653e000)
$ ldd /usr/bin/gtkam | grep libgphoto
        libgphoto2.so.2 => /usr/lib/libgphoto2.so.2 (0xb7f0c000)
        libgphoto2_port.so.0 => /usr/lib/libgphoto2_port.so.0 (0xb7f05000)

the sequence of files that the apps try to open differ.

    digikam: .la, then ""
    gtkam: .la, then .so

With the .la files installed digikam tries .la then .so as gtkam does
even without the .la files. [the .la files are in kubuntu and debian
in the pkg libghoto2-2-dev, that's the reason why the hack/workaround
of installing the 2.2.0 devel pkgs fixes a runtime problem]

Both use the same ltdl library:

$ ldd /usr/bin/digikam /usr/bin/gtkam | grep ltdl
        libltdl.so.3 => /usr/lib/libltdl.so.3 (0xb62ec000)
        libltdl.so.3 => /usr/lib/libltdl.so.3 (0xb761d000)

I've no glue yet what goes wrong. My guess is that somehow KDE seems
to influence the list of extentions and makes digikam/libghoto2 combo
fail to dynamicly load the camera drivers.

coolo ping? ;)

Achim

[Achim Bohnet (allee)]

FWIW: libghoto2 2.2.0 contains a subdir libltdl and the code in their
is at least compiled.

It's too late now to check if it's used/linked.

Nite!
Achim

[F-faber-pro (f-faber-pro)]

gphoto2 2.2 is out and this bug is still valid.

[Erik Andrén (erik-andren)]

I can confirm this bug on Gentoo, using gphoto2 2.2 and a Canon Digital Ixus 50.

[Benjamí Villoslada (benjami)]

Debian related bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=396249

[Benjamí Villoslada (benjami)]

Solved today in Debian Sid:

digiKam Debian changelog:

------------------------------------------
digikam (1:0.9.0~beta3-3) unstable; urgency=low

  [ Mark Purcell ]

[...]

  * Re-Add Build-Depends: libgphoto2-2-dev
    - libgphoto2-2-dev needed (Closes: #396249)

[...]

 -- Debian KDE Extras Team <email address hidden> Sat, 4 Nov 2006 10:12:50 +0000
------------------------------------------

[Caulier-gilles-9 (caulier-gilles-9)]

Benjamí,

Something have been changed in digiKam Debian package to solve this problem ? I want mean something must be changed in current digiKam implementation ?

If no, i will close this file...

Gilles

[Anaselli (anaselli)]

Gilles,
I'm not sure you can close the bug for that. We should
check if it is *only* a distro issue or not
recall:
Re-Add Build-Depends: libgphoto2-2-dev

IIRC, mandriva patched digikam as well to have a libgphoto-devel
dependency, now I wonder why digikam needs a devel package
to run....

My 2 €cents
Angelo

[Achim Bohnet (allee)]

Hi Angelo, Gilles,

Problem is that the new libgphoto plugin names without the 'lib' prefix
are not found without the .la files that are in the -devel pkgs.

Solutions: move .la files run -devel to -runtime pkgs or find/patch
the code so plugins without 'lib' prefix are found without the .la
files (see comment #11). Then the dependency on the -devel pkg can
be removed.

I doubt that it's digikam's fault. IMHO the bug should not be closed
but reassigned to the 'lookup plugin' code. (remember gtkam finds the
new plugin names without problem, see comment #11)

Achim

[Marcus Meissner (marcus-jet)]

the .la files for the camlibs and ports MUST be in the runtime package.

they are NOT development files, but are used during runtime.

tell this to the libgphoto2 packager ;)

[Benjamí Villoslada (benjami)]

Gilles,

Only that libgphoto2-2-dev now is needed in Debian [Sid]. Changelog says:

  * Re-Add Build-Depends: libgphoto2-2-dev
     - libgphoto2-2-dev needed (Closes: #396249)

Angelo: a friend says that in Ubuntu Edgy he have libgphoto2-2-dev dependency too.

Benjamí

[Anaselli (anaselli)]

> Angelo: a friend says that in Ubuntu Edgy he have libgphoto2-2-dev dependency too.

That probably means it's a packaging issue...

[Thomas-bettler (thomas-bettler)]

Just a wild guess: (had this troubles too)

using udev (but maybe with wrong rules?)

1. check if it works as root
 -> if yes continue
2. check you got write permissions on your camera
$ ls -l /dev/bus/usb/*/*
 -> have a look at the respective device...
You don't? -> set them manually and check if it works now...

Solution: you probably want to update your libgphoto package to a recent version
or correct the udev rules manually.

PS: Need more information: see
http://bugs.gentoo.org/show_bug.cgi?id=153471

[Mark Purcell (msp)]

From a Debian perspective depending on libgphoto2-2-dev is just a workaround.

The real issue is getting the .la files into the runtime package.

We are now tracking this issue at http://bugs.debian.org/390703

Mark

[Marcus Meissner (marcus-jet)]

I wonder why digikam does not use the .so prefix.

It is very strange.

Using the .la files will fix it, but perhaps someone should
check why it does not look for .so. :/

[Marcus Meissner (marcus-jet)]

i can confirm this behavior on openSUSE 10.2 too.

[Mark Purcell (msp)]

Marcus has just informed me that the .la files are not necessary.

On Friday 19 January 2007 18:34, Marcus Meissner wrote:
> Err, actually the .la files not necessary as I now know. ... Sorry for the confusion.

So what is the solution?

Does digikam need to be patched to access the .so files and not the .la files, per comment #11 from Achim above??

Mark

[Marcus Meissner (marcus-jet)]

msp: my mistake... in this case they seem to be as bug workaround for digikam.

I have tried finding on why digikam is special here, but so far not much
success.

[Marcus Meissner (marcus-jet)]

Breakpoint 3, 0x00002b99bab7df70 in lt_dlopenext () from /opt/kde3/lib64/libkdecore.so.4

it has its own libltdl compiled in.

We use lt_dlopenext ("foo.so"); and it does not handle it correctly

=> the KDE libltdl version is too old for the stuff libgphoto2 does with it :(

[İsmail Dönmez (ismaildonmez)]

So we need to upgrade kdelibs' internal libltdl. Is that safe?

[Marcus Meissner (marcus-jet)]

It would help more to have LTDL_SHLIB_EXT supported in this libltdl copy.

if LTDL_SHLIB_EXT is set (to ".so" on Linux), the code would work.

[İsmail Dönmez (ismaildonmez)]

so something like CFLAGS=-DLTDL_SHLIB_EXT=".so" ./configure should work for kdelibs?

[npfistner (norbert-pfistner)]

The bug seems to be still alive with
digikam 2:0.8.2-3
libgphoto2-2 2.2.1-12
libgphoto2-2-dev 2.2.1-12
on debian testing using our canon EOS 350D in PTP mode (non-PTP mode doesn't work either, but PTP-mode worked fine before the upgrade).

[Caulier-gilles-9 (caulier-gilles-9)]

Marcus,

Is the problem with digiKam Makefile.am and libgphoto2 ?

If Kamera tool work fine, well take a look of the current Makefile.am relevant here:

http://websvn.kde.org/branches/KDE/3.5/kdegraphics/kamera/kioslave/Makefile.am?rev=466285&view=auto

... and compare with digiKam Makefile.am:

==> for the camera gui :

http://websvn.kde.org/trunk/extragear/graphics/digikam/utilities/cameragui/Makefile.am?rev=610979&view=auto

Look like it's different, especially about LDFLAGS stuff and $(GPHOTO2_LIBS) witch is not present in cameragui Makefile.am.

This can be the problem ?

Gilles Caulier

[Skip VerDuin (verduin)]

I confirm this with FC-6 and Olympus 3030 hardware today, also gphoto2 result.
My FC-6 is a fresh install with all updates per two days ago.
  See comment #33 / all revs are later than those listed.
  Add digiKam is R0.9.0(Using KDE 3.5.5-...fc6), gphoto2 is R2.3.1
Analysis:
With digiKam -- The camera connect request
  First opens a camera window - then opens a fatal error window.
    "Failed to connect to the camera. ..."
With gphoto2 --list ports
  Two ports found prior to camera - ptpip:, and usb:
  Two more found after camera "ON" - usb:001,004, usb:002,003
With gphoto --auto-detect
  Olympus C-2100UZ found (wrong!? Olympus-3030Z also exists in .fdi)
     May not matter? from inspection of .fdi, 2100UZ and 3030Z seem similar...
     Forcing use of C-3030Z yields same result.
  Two ports listed - usb:, usb:001,005
     I suspect first (without x,y) entry may be incorrect...?
     NOTE! from /proc/bus/usb directory listing
        usb:001,005 does exist with OK UID & permissions
        usb:002,003 does exist with only root perms
        usb:001,004 does not exist (see --list ports above)
With gphoto2 -a
  On the surface the output seems normal and correct
With gphoto2 ... -l
  Fatal error: "Could not release interface 0 (Invalid argument)."
  I have debug trace available -- if useful eamil me for attachment...
  Error began with this:
    "...gphoto2-port(0): Could not query kernel driver of device"
NOTE:
My FC-5 had lesser problem - only root could use USB camera interface. Today the issue is a more total failure, probably with HAL and setting USB drivers. I find nothing to adjust nor a workaround. Advise if I can can further test.

[npfistner (norbert-pfistner)]

After fiddling around with gphoto2 I finally got my Canon EOS 350D working (again):
1) I had to add users to group plugdev (group camera is not used any more). Well so far simply some permissions.
2) I had to use CANON EOS 350D without(!) PTP mode despite the camera itself is still set to PTP connection (PC connection does not work!). Funny, isn't it?

So at least my bugreport should better be posted to the gphoto dev.
Just for information:

digikam 2:0.8.2-4
libgphoto2-2 2.2.1-12
libgphoto2-2-dev 2.2.1-12
gphoto2 2.2.0-3
on debian testing

Norbert Pfistner

[Mark Purcell (msp)]

Ubuntu are claiming they have been able to fix this issue due to the way Kubuntu KDE finds the gphoto libs..

I can confirm this issue is not fixed in Debian with KDE 3.5.7 and digikam 0.9.2 final. Thus Debian is continuing to ship with a dependency on libgphoto2-2-dev.

I have asked the Ubuntu guys, what changes they made to kdelibs...

Mark

[Mark Purcell (msp)]

Created attachment 21091
The Camera dialog with libgphoto2-2-dev installed

[Mark Purcell (msp)]

Created attachment 21092
Camera dialog without libgphoto2-2-dev

[Arthur Penn (arthur-penn)]

Same problem. gphoto2 --auto-detect shows:

Model Port
----------------------------------------------------------
Canon PowerShot A95 (PTP mode) usb:
Canon PowerShot A95 (PTP mode) usb:001,004

However, the camera list in digikam is completely empty, and the Canon PowerShot A95 (normal mode) I had configured that used to work no longer works. It just keeps saying that it failed to detect the camera. F-Spot doesn't have any problem detecting the camera.

[David Solbach (d-vidsolbach)]

I can confirm this bug with output:

david@sun:~$ gphoto2 --auto-detect
Modell Port
----------------------------------------------------------
Canon Digital IXUS 900Ti (PTP mode) usb:
david@sun:~$

But digikam can't detect the kamera and the list is empty. (I'm on a feisty system that was upgraded to gutsy)

[Achim Bohnet (allee)]

Weired. Looks like digikam in kubuntu now needs the .la files of the libgphoto2 plugins too.
Debian always had this problem: Plugings not starting with lib* need the .la files:

   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=390703

At least in Feisty digikam/kdelibs works fine without the .la files. Looks like Kubuntu 'merged'/
inherited the problem now :(

Long discussion about this problem at:

   http://bugs.kde.org/125696

As it's quite late in the release cycle, I've move the .la files from libgphoto2-2-dev to
libghoto2-port0 and libgphoto2-2, instead of playing with the core infrastructure of KDE.
Fix was already uploaded and should soon arrive in the archive.

Let's see if a libgphoto2 upload can 'Fix releases' a digikam bug...

Achim

[Daniel Hahler (blueyed)]

Confirmed the bug to be fixed with the libgphoto2 2.4.0-2ubuntu2 upload.

Thanks, Achim.

btw: you must use "LP: #xxx" to close a bug, see https://wiki.ubuntu.com/ClosingBugsFromChangelog

[Arthur Penn (arthur-penn)]

Fixed for me as well--camera auto-detect and the resulting camera entry again works. Thank you very much!

[Kde-bugzilla (kde-bugzilla)]

The Ubuntu bug report is at https://launchpad.net/bugs/145239

[Martin Hoefling (martoss)]

i can confirm that this fixes the problem

[Bremm (bremm)]

$ dpkg -s libgphoto2-2 | grep Ver
Version: 2.4.0-2ubuntu2

Problem was solved and now Kamera and digiKam can see the attached devices again.

Thanks a lot.

[Johan van der Lingen (johanlingen-hotmail)]

Should this fix already have been downloaded through automatic updating?

I have the same version of libgphoto2-2 as Bremm, but my camera is still not detected automatically. I have a traveler DC-6900. If I must post additional information, I will be pleased to do so, just explain what package I should install or what command I should give in the konsole.

[Achim Bohnet (allee)]

@Johan: yes, libgphoto2-2 version 2.4.0-2ubuntu2 should have fixed it.
When it does not for you, you have another problem.

Install gphoto2 and run

  gphoto2 --auto-detect

if gphoto2 finds your camera and digikam does not then you _still_ have the
bug, but I doubt it. Did your camera work before in LInux?

  gphoto2 --list-cameras

does not list your camera so I assume it's not supported. Check www.gphoto.org
if you model if there's a known workaround.

Achim

[Johan van der Lingen (johanlingen-hotmail)]

I had contact with Bremm, he suggested it concerns a bug in the kernel: https://bugs.launchpad.net/bugs/157700

My camera model is not listed, but it worked before (in Feisty) as a USB Mass Storage camera.

[Achim Bohnet (allee)]

Ah, okay. So your bug is not related at all to this one:
digikam does not use libgphoto for USB Mass Storage cameras.
It has it's own implementation for them.

USB mass storage cameras/devices /plain dirs work fine here
ith digikam, so maybe it's really a bug in the kernel as you suspects.

Achim

[Bremm (bremm)]

2007/10/27, Achim Bohnet <email address hidden>:
> Ah, okay. So your bug is not related at all to this one:

Not mine, Johan's bug. :-)

> digikam does not use libgphoto for USB Mass Storage cameras.
> It has it's own implementation for them.

Yes, I'm sure about this, since I'm using PTP and gphoto2 to connect
my Canon S3 IS. Only once it stopped, with the ".la" bug on digiKam
0.9.2.

> USB mass storage cameras/devices /plain dirs work fine here
> ith digikam, so maybe it's really a bug in the kernel as you suspects.

It worked fine with me even in the past, using Olympus C350Z under
Edgy and Feisty stock kernels.

I hope that I did it well in this question.

Regards,
--
Márcio Bremm -- http://vtnc.org/

Pessoas não mudam, apenas mascaram sua real identidade.
People don't change, only mask their real identity.

[Mark Purcell (msp)]

Thanks to pusling this seems to fix:

--- kdelibs-3.5.8.dfsg.1.orig/libltdl/ltdl.c
+++ kdelibs-3.5.8.dfsg.1/libltdl/ltdl.c
@@ -184,6 +184,7 @@
 #define LT_DLSTRERROR(name) lt_dlerror_strings[LT_CONC(LT_ERROR_,name)]

 static const char objdir[] = LTDL_OBJDIR;
+#define LTDL_SHLIB_EXT ".so"
 #ifdef LTDL_SHLIB_EXT
 static const char shlib_ext[] = LTDL_SHLIB_EXT;
 #endif

[Caulier-gilles-9 (caulier-gilles-9)]

Mark,

What's this patch. Where it is applied exactly ??? Sound like a file from KDE core library... Right ???

Laurent, Please, please, please take a look and fix it in svn... (:=)))

Gilles

[Mark Purcell (msp)]

This is what pusling has done with Debian kdelibs:

kdelibs (4:3.5.8.dfsg.1-4) unstable; urgency=low

  * Add a patch to allow to dlopen .so files and not only .la files.
    Now kamera, digikam and others doesn't need to depend on -dev packages.

 -- Sune Vuorela <email address hidden> Mon, 12 Nov 2007 13:00:41 +0100

[Caulier-gilles-9 (caulier-gilles-9)]

Mark,

Thanks a lots for this patch. This is what i suspected but never find it...

So, the problem come from KDELibs. This one need to be patched in svn to close this file definitively...

Angelo,

For Mandriva package, i recommend you to patch kdelibs temporally, as Debian team...

Gilles Caulier

[Caulier-gilles-9 (caulier-gilles-9)]

To KDE-Libs team :

I re-affect this file to your part. The solution to solve it is described by Debian team in #41 and #43. Patch is really simple and easy to test.

Please take a look. Thanks in advance...

Gilles Caulier

[Sune Vuorela (debian-pusling)]

To add a bit more details.

It seems that gphoto dlopens its plugins (on debian placed in /usr/lib/libgphoto2/2.4.0/)

gphoto uses normally the system libltdl to do the dlopens.

But in this case ... kdelibs ships its own embedded libltdl - and in kde applications kdelibs gets loaded first - and then "wins" over the systems other libraries when looking for some functions.

The real fix would be to use the system libltdl instead of embedding a copy in kdelibs.

(it was comments 31 and 32 that lead me in the right direction - but I just couldn't find the proper way to escape the ".so" if I wanted a -DLTDL_SHLIB_EXT=".so" passed in. That should do the trick as well)

[Sune Vuorela (debian-pusling)]

I just made kdelibs build against external libltdl instead of the embedded one. I wonder how much breakage to expect from this. Any clues what to test ?

The usage of lt_dlopen_flag in kinit.cpp and klibloader.cpp needed to go away to make it build. I have no clue wether it breaks anything or not.

[Sune Vuorela (debian-pusling)]

oh well.. it just broke kded and maybe a couple of other things. Using external libltdl is not recommended right now at least.

/Sune

[Dario Andres (andresbajotierra)]

Any news on this with recent versions ?

[Mark Purcell (msp)]

We fixed this is Debian with a patch to kdelibs..
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=416123

kdelibs (4:3.5.8.dfsg.1-4) unstable; urgency=low

  * Add a patch to allow to dlopen .so files and not only .la files.
    Now kamera, digikam and others doesn't need to depend on -dev packages.

 -- Sune Vuorela <email address hidden> Mon, 12 Nov 2007 13:00:41 +010

All looks good in KDE4 too.

Mark

[Michal Kolodziejczyk (miko-wp)]

Since I am using recent version of KDE4 and digikam (on archlinux - the package contains no patches), things work for me, and I am ready to close this bug report. Should I close it, or should it still be open?

[Caulier-gilles-9 (caulier-gilles-9)]

It's fine for me to close this file.

Any objections from others peoples ?

Gilles Caulier

[Johannes Wienke (languitar)]

No objections since more than half a year. Closing this now.