On 04/19/2012 04:28 PM, David C. Rankin wrote: Darrell, This is the updated patch that fixes the remaining gcc47 and libpng15 issues in digikam beyond Tim's png_jmpbuf. Get a signoff on the 'color_type' change, then you can push it. -- David C. Rankin, J.D.,P.E.

On 04/19/2012 05:06 PM, Timothy Pearson wrote: Tim, (see end of message first -- I think I found the issue) Something is not working in digikam. The images do not show up in the albums. (jpg or png). I started digikam, got a 'could not create directory' error when I manually typed: /home/david/mmedia/digikam into the startup config window as the location for the digikam albums. I was then able to use the file-browser to create the directory from the startup dialog by clicking 'new folder'. Once created, I received an error that digikam was sorry, but it could not restart??: http://www.3111skyline.com/dl/dt/trinity/ss/digikam-cannnot-restart.jpg When the digikam app opened - there were virtually NO menus, just 'Settings' and 'Help': http://www.3111skyline.com/dl/dt/trinity/ss/digikam-empty.jpg I then added an album (see above) the went to import files: http://www.3111skyline.com/dl/dt/trinity/ss/digikam-import.jpg NOTE: The thumbnail creation of the alpha-enabled png files you were concerned about was WORKING. The files in the img directory were: 18:10 valkyrie:~/Documents/img> l1 CosmosRedXen.jpg digikam3.db earth-afloat_1440x900.jpg globe-colored.png (alpha channel enabled png) It looked like the import was working, but when I chose 'download all' nothing appeared in the viewer window?? (see 1st screenshot again) Nothing, just empty. No .jpg or .png files. I then decided to try and import the whole directory, so I chose import folder and just left the dialog alone (it was already reading /home/david/Documents/img in the top bar due to the previous file import. When I said OK, I got the following error: http://www.3111skyline.com/dl/dt/trinity/ss/digikam-albums.jpg Well then I decided to open the import dialog and check whether there was any problem with the alpha-enabled png, so I opened the import window and clicked on the properties of the png file -- all good: http://www.3111skyline.com/dl/dt/trinity/ss/digikam-alpha.jpg I then tried to re-import the images thinking that something might not have worked right the first time - I could have missed a button, etc... Nope, when I tried to import again, I got the normal 'You want to overwrite' dialog: http://www.3111skyline.com/dl/dt/trinity/ss/digikam-invisible.jpg So then I decided to cross check with gwenview to see if there was something tdelibs/tdebase related that prevented images from displaying - gwenview worked fine: http://www.3111skyline.com/dl/dt/trinity/ss/digikam-gwenview-test.jpg Last but not least, I decided to check 'Help' for digikam to make sure the documents were in the right place (I built without specifying any location, so the default was used) - nope NO help documentation: http://www.3111skyline.com/dl/dt/trinity/ss/digikam-no-help.jpg I don't know what is up with digikam -- it's broke, but I don't think it has anything to do with the color_type patches. It doesn't show any image (jpg or png). Further, thumbnail generation for alpha-enabled png images works (see screenshots) Lastly, there are NO menu entries for digikam after install. Nothing. I had to start digikam from the command line. WTF?? -- wait!! The build for digikam is broken -- 1/2 of the digikam install ended up in /share That's RIGHT! not ${PREFIX}/share, just /share off the root of the filesystem?? 18:36 valkyrie:~/Documents> l /share total 36 drwxr-xr-x 9 root root 4096 Apr 19 13:32 . drwxr-xr-x 24 root root 4096 Apr 19 17:23 .. drwxr-xr-x 3 root root 4096 Apr 19 13:32 applications drwxr-xr-x 5 root root 4096 Apr 19 13:32 apps drwxr-xr-x 3 root root 4096 Apr 19 13:32 icons drwxr-xr-x 51 root root 4096 Apr 19 13:32 locale drwxr-xr-x 3 root root 4096 Apr 19 13:32 man drwxr-xr-x 2 root root 4096 Apr 19 13:32 services drwxr-xr-x 2 root root 4096 Apr 19 13:32 servicetypes 18:39 valkyrie:~/Documents> l /share/applications/ total 12 drwxr-xr-x 3 root root 4096 Apr 19 13:32 . drwxr-xr-x 9 root root 4096 Apr 19 13:32 .. drwxr-xr-x 2 root root 4096 Apr 19 13:32 kde 18:39 valkyrie:~/Documents> l /share/applications/kde/ total 16 drwxr-xr-x 2 root root 4096 Apr 19 13:32 . drwxr-xr-x 3 root root 4096 Apr 19 13:32 .. -rw-r--r-- 1 root root 3067 Mar 11 12:14 digikam.desktop -rw-r--r-- 1 root root 3386 Feb 8 17:49 showfoto.desktop Full file list for digikam install (NOTE the last 1/2 of the list) http://www.3111skyline.com/dl/dt/tde/err/digikam/digikam-file.txt I think that is probably the problem - where could that problem be?? That smells like something a digikam/admin/acinclude.m4.in patch broke. Can somebody confirm and suggest a fix. My build was with: CXXFLAGS="${CXXFLAGS} -fpermissive" \ ./configure --prefix=${TDEDIR} \ --with-qt-dir=${QTDIR} \ --localstatedir=/var so that wasn't something I did.... Oh, brother, "Get a rope..." -- David C. Rankin, J.D.,P.E.

That would be this patch: http://git.trinitydesktop.org/cgit/admin/commit/?id=a7f223eb92dec6dc7e2ceb0… I haven't had any problems with the patch. Digikam builds here without error --- although I'm not fighting the windmills of gcc 4.7. I have built digikam against both gcc 4.4.4 (Slackware 13.1) and 4.5.2 (Slackware 13.37). You mentioned previously about digikam not creating a new database. That was happening to me several days ago until I scrubbed digikam of inadvertent TQ changes. That problem disappeared thereafter. Have you pulled the latest digikam sources? There are so many patches being uploaded to GIT that every couple of days I stop trying to build individual packages and start my build sequence from scratch. When I want to focus on one package, I"m careful not to pull the new source tree because often that means no less than building tdelibs and tdebase over, often TQt3 too, which often affects everything else. That patch could be the culprit, but if there were problems with that patch then everything built with automake would be affected. Darrell

Those imageplugin directories were part of the recent TQ patches: http://git.trinitydesktop.org/cgit/digikam/commit/?id=82e857b822ab15a2762a8… I'm trying to catch up to you so we can compare notes and get this crappola behind us. I finally have all of my 32-bit and 64-bit systems installed, two of which have gcc 4.7. However, I have to run my builds methodcially to control the process with each. If I try to do all at once then I'll get confused and will be fighting too many problems concurrently. I hate fighting windmills. Thus far I can build on 32-bit Slackware 13.1 (gcc 4.4.4) and 13.37 (gcc 4.5.2). Today I started polishing my scripts to support 64-bit and made a dent with Slackware 13.1. As I know 13.1 32-bit builds, I have a barometer for treading through the 64-bit version. Hopefully in a few days I'll have made a complete run with all 6 systems. Actually 4 systems. The newest two are gcc 4.7. I expect similar problems as you, but then at least we will stumble across the failures together and have other systems that are known to build without serious error. One. Day. At. A. Time. :) Some days I think my head will explode from this stuff. I probably should take a few days off. Plant flowers and prep the lawn. Spring clean the house. Cut firewood. Anything but computers. :) Darrell

Happens to me often enough. That is why every few days I rebuild everything from scratch. Yay for dual cores! Do kipi-plugins work? Welcome page branding look okay? Darrell

On 04/19/2012 08:44 PM, Darrell Anderson wrote: To make it official: http://bugs.pearsoncomputing.net/show_bug.cgi?id=958 patch: http://bugs.pearsoncomputing.net/attachment.cgi?id=552 -- David C. Rankin, J.D.,P.E.