ubuntu shouldn't package beta version of digikam; needs upgrading to fix >200 bugs, and in particular import crashes #8 most reported KDE bug ever.

[Stephen Warren]

Binary package hint: digikam

Please see here for background:
https://bugs.kde.org/show_bug.cgi?id=223059

The digikam in Ubuntu Karmic is a beta version with a huge number of known bugs (>200). It needs to be upgraded to the 1.0.0 release to solve them all. In particular, I'm experiencing the #8 most "popular" bug in KDE's history, which prevents digikam from usefully implementing the whole photo import/management process.

I have photos from a camera on an SD card plugged into a USB reader. In digikam, I go to the menu: Import -> USB storage devices -> and select the USB device. digikam crashes. See the KDE bug for the full crash details.

ProblemType: Bug
Architecture: i386
Date: Sun Jan 17 11:43:28 2010
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: nvidia
Package: digikam 2:1.0.0~beta5-1ubuntu1
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-17.54-generic
SourcePackage: digikam
Uname: Linux 2.6.31-17-generic i686

[S-t-kdebugs (s-t-kdebugs)]

Application that crashed: digikam
Version of the application: 1.0.0-beta5
KDE Version: 4.3.2 (KDE 4.3.2)
Qt Version: 4.5.2
Operating System: Linux 2.6.31-16-generic i686
Distribution: Ubuntu 9.10

What I was doing when the application crashed:
Just requested digikam to import some photos, and it crashed.

 -- Backtrace:
Application: digiKam (digikam), signal: Segmentation fault
[Current thread is 1 (Thread 0xb7766700 (LWP 13830))]

Thread 19 (Thread 0xb6199b70 (LWP 13835)):
#0 0x0084b422 in __kernel_vsyscall ()
#1 0x00855e15 in pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:122
#2 0x0681587d in __pthread_cond_wait (cond=0xa5d6e40, mutex=0xa5d6e28) at forward.c:139
#3 0x01fafe67 in QWaitConditionPrivate::wait (this=0xa5c06c0, mutex=0xa5c06bc, time=4294967295) at thread/qwaitcondition_unix.cpp:87
#4 QWaitCondition::wait (this=0xa5c06c0, mutex=0xa5c06bc, time=4294967295) at thread/qwaitcondition_unix.cpp:159
#5 0x0830a2d9 in Digikam::ScanController::run (this=0xa55a320) at /build/buildd/digikam-1.0.0~beta5/digikam/scancontroller.cpp:499
#6 0x01faee32 in QThreadPrivate::start (arg=0xa55a320) at thread/qthread_unix.cpp:188
#7 0x0085180e in start_thread (arg=0xb6199b70) at pthread_create.c:300
#8 0x068088de in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

Thread 18 (Thread 0xb5900b70 (LWP 13837)):
#0 0x015a2e06 in *__GI_clock_gettime (clock_id=22704116, tp=0xb5900028) at ../sysdeps/unix/clock_gettime.c:100
#1 0x020cbbf3 in QTimerInfoList::getTime (this=0xa77b834, t=...) at kernel/qeventdispatcher_unix.cpp:339
#2 0x020cbde1 in QTimerInfoList::updateCurrentTime (this=0xa77b834) at kernel/qeventdispatcher_unix.cpp:297
#3 0x020cc88c in QTimerInfoList::timerWait (this=0xa77b834, tm=...) at kernel/qeventdispatcher_unix.cpp:420
#4 0x020ca210 in timerSourcePrepare (source=0xa77b800, timeout=0xb590011c) at kernel/qeventdispatcher_glib.cpp:141
#5 0x02298f90 in g_main_context_prepare () from /lib/libglib-2.0.so.0
#6 0x02299351 in ?? () from /lib/libglib-2.0.so.0
#7 0x02299863 in g_main_context_iteration () from /lib/libglib-2.0.so.0
#8 0x020ca067 in QEventDispatcherGlib::processEvents (this=0xa77a3a8, flags=...) at kernel/qeventdispatcher_glib.cpp:329
#9 0x0209dc79 in QEventLoop::processEvents (this=0xb59002e4, flags=) at kernel/qeventloop.cpp:149
#10 0x0209e0ca in QEventLoop::exec (this=0xb59002e4, flags=...) at kernel/qeventloop.cpp:201
#11 0x01fabb73 in QThread::exec (this=0xa77a0f8) at thread/qthread.cpp:487
#12 0x00525cbd in Digikam::ImageFilterModelWorker::Thread::run() () from /usr/lib/libdigikamdatabase.so.1
#13 0x01faee32 in QThreadPrivate::start (arg=0xa77a0f8) at thread/qthread_unix.cpp:188
#14 0x0085180e in start_thread (arg=0xb5900b70) at pthread_create.c:300
#15 0x068088de in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

Thread 17 (Thread 0xb5073b70 (LWP 13838)):
#0 0x015a2e06 in *__GI_clock_gettime (clock_id=22704116, tp=0xb5073028) at ../sysdeps/unix/clock_gettime.c:100
#1 0x020cbbf3 in QTimerInfoList::getTime (this=0xa787f34, t=...) at kernel/qeventdispatcher_unix.cpp:339
#2 0x020cbde1 in QTimerInfoList::updateCurrentTime (this=0xa787f34) ...

[Julien (julien-narboux)]

Thanks for the report, but this bug as already been fixed for a long time. It has also been reported multiple times (more than 94 !). Look here: https://bugs.kde.org/show_bug.cgi?id=210462
 In fact, it is the 8th most reported bug in the history of KDE (https://bugs.kde.org/duplicates.cgi). It means that it has impacted many people.
Digikam developpers are sorry as this gives a bad opinion of Digikam although the bug was in a beta version and has been fixed quickly in the next beta.
It is not your fault, your distribution (Ubuntu) has decided to package a beta version of Digikam in its stable release AND this beta version contains of bug with breaks one of the main features of Digikam AND Ubuntu is refusing to update the package to the final version 1.0.0 which fixes many bugs (>200).
They want to follow their rules about when a package should be updated (https://wiki.ubuntu.com/StableReleaseUpdates). These rules have been designed to provide a stable distribution. But in this case, it does not make sense in my opinion because:
- they packaged a beta version of Digikam
- this beta contains a bug which breaks one of the main features of Digikam
- the stable version is out
- no tools depends on Digikam
Please ask them to put the final 1.0.0 release in updates.
For the time being you can install 1.0.0 final using the backports repository, look here for details:
  https://help.ubuntu.com/community/UbuntuBackports

Julien

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

*** This bug has been marked as a duplicate of bug 210462 ***

[Luka Renko (lure)]

Digikam 1.0.0 final release is available in Karmic backports repositories. See this page for more info:
https://help.ubuntu.com/community/UbuntuBackports

[S-t-kdebugs (s-t-kdebugs)]

Huh. I swear I imported photos using digikam before and it worked; perhaps it's intermittent.

Anyway, I guess I'll go file a bug against Ubuntu...

[Stephen Warren (srwarren)]

So I have to enable a non-default repository whose name is "**Unsupported** updates"?

Why not just ship this as a regular update; almost every single Ubuntu user who uses digikam is going to be exposed to this bug, and if not then by the sound of it probably some other known/fixed bug. Shipping the fixes to those issues, in a way that the average Ubuntu user will actually receive them, seems like the obvious thing to do.

I can understand if the bugs were only fixed in digikam-1.1 then that would be shipped in a separate opt-in backports repository to aleviate any compatibility issues. However, a minor version upgrade from a beta release to the final release of a software is something that belongs in a given distro version's updates repository. If Ubuntu isn't willing to take that policy, it shouldn't choose to ship beta software in the initial release, or it's dooming itself to this kind of issue.

[Luka Renko (lure)]

Agreed, and true, shipping beta version in Karmic was mistake, we should avoid doing this in future. However, changes between Beta5 and final version are too big to be accepted as Stable Release Update, that is why we had to resort to Backports.

[Jonathan Thomas (echidnaman)]

Unfortunately, there's nothing that can be done about it now. :(

[Stephen Warren (srwarren)]

In the words of a friend "It's too buggy in the current release, so we can't upgrade to the version that works". This is absolutely ridiculous from an end-user perspective. While I can understand the rule in general, in this case, it's the *exact* opposite of what would be best for users.

Just to be clear: digikam is effectively useless in Karmic because of this.

(and gthumb import also has a bug that prevents import from working at all if there are movie files on the "disk", so these coupled together pretty much make Karmic in general useless for photo management).

Sigh.

[Luka Renko (lure)]

Stephen, I am sorry that you feel this way. As I said, solution is to install digikam from karmic-backports repository. You can install just digikam (and kipi-plugins), if you are concerned about "unsupported" status of backports (to prevent other backported packages to install).

For digikam itself, I can only assure you that the karmic backport version (1.0.0) will have same (or even better) attention than "supported" version.

For "supported" version in karmic, we could only get single fix for the crash (a bit hard to hunt actual patches as there were several changes for this crash issue), but this will not make our users happier, as they would probably then get other beta5 issue, that need attention. It is not useful use of our limited resources to do that (and yes, this is mostly done by community resources).

[Sean Reifschneider (jafo)]

Full disclosure: I'm the friend quoted by Stephen above. I'm just trying to provide some feedback on this whole thing, so take it as you will.

I'm imagining that there's some policy that you must stick with *EXACTLY* the version of what was released, and back-porting the fixes that are required. However, that seems to me to mean that only issues which get reported to the Ubuntu team in Launchpad get fixed, and results that the community resources are spread thin because of duplication of effort between the Ubuntu maintainers and upstream.

By this I mean that if Python (mentioned simply because I'm a committer there and most familiar with it) has a bug tracker, and does it's own releases of 2.6.0, 2.6.1, 2.6.2..., that really what needs to happen is that we mirror all bugs that go into those releases into launchpad so that you can be sure to keep the Ubuntu release up to date.

The option I would expect is that when we release a Python 2.6.3, for example, that we are stating that it's got the recommended set of updates from 2.6.2. I don't fully understand why you would spend the effort on cherry picking patches between the two when we've already done all that work for you. I imagine this might be due to some projects that don't do a very good job of making micro release numbers indicate only the recommended patches for people running the previous major/minor numbers, but that seems like it would be something you'd want an exception for rather than enforcing it on everyone.

Particularly, it seems like picking 1.0.0beta5 of digikam was a signal that you wanted 1.0.0 in Karmic, but it just wasn't available for the release. In other words, the 1.0.0 release when available really seems not surprising to put in place.

I mean, if the rules really are that you can't just wholesale upgrade to the 1.0.0 release, and you have to keep it beta5 with patches back-ported, it would seem like the Right Thing To Do would be to grab beta5 and 1.0.0, diff them, and use that as the patch-set for your 1.0.0beta5 packages.

As someone who did beta testing of digikam at beta5 through the 1.0.0 release, I can say with some little authority that 1.0.0 is very preferable to beta5.

Having it in backports makes it much less usable. As a user who recently gave a presentation on Digikam to our local Linux Users Group, I can say that the thought never crossed my mind that 1.0.0 would be in backports, I just figured that you hadn't gotten around to updating to it yet. I was going to grab the source for Lucid and build it, but I didn't have time, so I ended up demonstrating it on Fedora, where they *DID* release initial beta packages and then push out the 1.0.0 release once it was available.

Sean

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

Fixed with bug 210462