By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.

Bug 963

Summary: Digikam can't create an initial database
Product: TDE Reporter: Darrell <darrella>
Component: other (any)Assignee: Timothy Pearson <kb9vqf>
Status: RESOLVED FIXED    
Severity: normal CC: bugwatch, darrella
Priority: P1    
Version: R14.0.0 [Trinity]   
Hardware: Other   
OS: Linux   
Compiler Version: TDE Version String:
Application Version: Application Name:
Attachments: Image showing digikam requesting to create an initial database
Image showing digikam failing to create an initial database

Description Darrell 2012-04-12 15:22:04 CDT
Created attachment 537 [details]
Image showing digikam requesting to create an initial database

When starting digikam for the first time, digikam creates an empty database container. In Trinity (GIT) this always fails.

When asked to create the database, I accept the defaults as shown in the first attached screen grab.

Then digikam scrolls through the various messages in the splash image. At the point when the messages say "Scan Albums" the process stops. Refer to the second attached screen grab.

The message dialog is misleading because there are no permission problems.

The error message string appears in albummanager.cpp. Looking at the sources indicates there is some kind upgrade test with the database. I don't understand what could be happening because the database is being created for the first time.

I can create a new database in KDE3 and copy that to my profile and then the Trinity digikam does not complain.
Comment 1 Darrell 2012-04-12 15:22:26 CDT
Created attachment 538 [details]
Image showing digikam failing to create an initial database
Comment 2 Darrell 2012-04-12 22:03:49 CDT
kipi-plugins, digikam, and gwenview were patched extensively through the following GIT hashes:

ba22066e 2012-04-12
0f64ac7c 2012-04-12
207d90d4 2012-04-12
6029a164 2012-04-12
70de38f0 2012-04-12
fe80f963 2012-04-12
1d778205 2012-04-12
303be455 2012-04-12
1eac443e 2012-04-12
ce3d59a5 2012-04-12

The packages build without errors. The problem reported here now seems resolved.