digikam 4.0.0 update

[RJVB (René Bertin)]

Attached an updated port directory that pulls digikam 4.0.0 into MacPorts. In addition to just bumping the version I also include a patch that makes digikam search ICC ("ColorSync") profiles in the standard locations on OS X ({/System,~,}/Library/ColorSync).

[RJVB (René Bertin)]

updated port directory for digikam

[mojca (Mojca Miklavec)]

I just re-uploaded René's patch in a different format (to avoid the need to download, extract and compare).

Just a question: there are currently 13 other digikam tickets open. Do you have any idea whether this patch resolves any of them?

#30838

Digikam @2.0.0 hangs at launch.

#31926

digikam @2.1.1 unknown protocol 'digikamalbums'

#34264

digikam: Undefined symbols for architecture x86_64

#37030

Digikam hangs at "Reading database" on start in Mountain Lion

#37592

digikam @2.9.0 flickr module cannot authenticate

#40912

DigiKam 3.5 corrupts JPG, TiFF, PNG images

#41659

digikam crash-Very unstable

#44023

Digikam crashes when using the editor window

#44748

Update digikam 3.5.0 to 4.-- produces error:: command execution failed while executing "system -nice 0 $fullcmdstring"

#44985

digikam @4.0.0_0: No drag and drop to the Dock anymore

#46445

port uninstall does not remove the app files

#47290

digikam: Add variant for external mysql database; rename variant for internal mysql database; update mysql dependency

#47749

digikam @4.10.0 No video playback [Portfile PATCH]

#47772

digikam: update to 4.10.0, mariadb variant and dependency cleanup

#48081

digikam @4.9.0: build fails after upgrade to opencv 3.0.0 due to API/header changes

#50270

digikam @4.9.0 fails to build: lensfun.h:2506:5: error: templates must have C++ linkage

#57407

Digikam 4.9.0 fails to install: LibKface cannot be compiled

#62755

digikam: update to 8.4.0

#69811

py27-mutagen missing, but required for digikam

#70384

opencv3 fails to provide legacy module in contrib variant, which is required by digikam port

A while back I started wondering whether this port works at all.

[mojca (Mojca Miklavec)]

Can you please also submit the patch upstream and add a link to the upstream ticket (or whatever they use to collect patches)?

[RJVB (René Bertin)]

Replying to mojca@…:

Just a question: there are currently 13 other digikam tickets open. Do you have any idea whether this patch resolves any of them?

#44023 looks like it might be related to an issue currently occurring under Ubuntu but the backtrace suggests it's not. All the other tickets concern older versions and/or issues I didn't encounter. Both 3.5 and 4.0.0 built cleanly for me, but then I haven't tried yet on OS X 10.9 . 4.0.0 does build fine with MacPorts clang 3.4 though, so I'm not expecting any issues with Apple's current clang.

Either way, my patch is completely unrelated to all open issues, it just allows digikam to find the icc profiles available in the standard locations.

Upstream ticket: ​https://bugs.kde.org/show_bug.cgi?id=336553

[mojca (Mojca Miklavec)]

Thank you for reporting this upstream.

I asked in a clumsy way. I wanted to ask whether you had any clue if these are still problems. There is a reasonable chance that tickets such as "Digikam @2.0.0 hangs at launch" could be closed, either now or after upgrading to version 4.0.0. There is also a chance that some tickets are open because users didn't know that they would need to run launchctl etc.

Dear maintainers of the port: please check the patch and let us know if you agree with it or if you have something to add.

[NicosPavlov]

I would tend to disagree about copying the note concerning launchctl into digikam's port, as it is more general than just for this one. As for now, the note is in kdelibs4 (the main basic port for KDE), to avoid repeating the note too often, but if it is considered that it should be reminded, it should be transferred to the kde4 portgroup, and not in Portfiles.

[RJVB (René Bertin)]

I'd agree with that were it not that there are probably enough KDE ports that do not really require a kbuildsycoca4 invocation. In fact, one could also argue that the message need appear only when installing the base KDE ports, because once those are installed the OS takes care of loading the required agent(s). At least that's how it seems to work on my 10.6.8 system (and I'd better not try to launchctl unload them because the commands shown in the note don't seem to be enough to restore KDE functionality after that). 10.9 may indeed be different and require a manual launchctl load of at least the dbus agent.

In short, I'm not sure if it's useful to clutter the output when installing/upgrading all KDE packages with this note. One could think of a more terse message reminding only to execute kbuildsycoca4 by hand if a newly installed port seems to lack functionality like I had with digikam. Is it possible to display such a note only after a new install, and not after an upgrade (supposing an upgrade doesn't introduce new components or suppress existing ones)?

[macports@…]

I tried to build digikam 4.0.0 but configure fails.

CMake Error at extra/kipi-plugins/panorama/CMakeLists.txt:10 (FLEX_TARGET):
  Unknown CMake command "FLEX_TARGET".

The patch applied cleanly. Do I need to update cmake? I'm using cmake 3.0.0 and libkipi 4.12.5.

[macports@…]

Cc Me!

[RJVB (René Bertin)]

Replying to macports@…:

I tried to build digikam 4.0.0 but configure fails.

CMake Error at extra/kipi-plugins/panorama/CMakeLists.txt:10 (FLEX_TARGET):
  Unknown CMake command "FLEX_TARGET".

That kind of error usually means a dependency required at least for building is missing. In this case I'm guessing you don't have flex installed, or do you? If you don't, please install flex (port install flex) and try to build digikam again.

[cgilles (HumanDynamo)]

CMake Error at extra/kipi-plugins/panorama/CMakeLists.txt:10 (FLEX_TARGET):
  Unknown CMake command "FLEX_TARGET".

Problem reproducible here : there is a conflict between FindFlex.cmake script from Kdlibs and FindFlex.cmake script from CMake.

KDelibs file is wrong and uncomplete. Removing it from MAcports install fix the problem.

Gilles Caulier

[mojca (Mojca Miklavec)]

#44119

[bugports@…]

Exactly the same problem here with Digikam 3.5.0.1. Completely uninstalling Macports and reinstall Digikam (sudo port install digikam) leads to :

CMake Error at extra/kipi-plugins/panorama/CMakeLists.txt:10 (FLEX_TARGET):
Unknown CMake command "FLEX_TARGET".

DevTools 3.2.6, MacOS 10.6.8.

[RJVB (René Bertin)]

How come the kdelibs can replace a file already belonging to another port, usually that kind of thing raises an error, no?

In any case, I think I didn't encounter this problem because no kdelibs upgrade was pushed after cmake was upgraded to 3.0 . So could you try

port uninstall -f cmake
port install cmake

to see if that puts back a proper FindFLEX.cmake ?

[OT] On a cmake-related note, I see that cmake 3.0 still creates shared modules with -bundle instead of -dynamiclib ... [/OT]

[bugports@…]

Thanks rjvbertin, that worked for me!

[RJVB (René Bertin)]

See comment:ticket:44119:1. I now think I didn't encounter problems because my MacPorts directory is on a case-sensitive partition. kdelibs4 does NOT replace cmake's FindFLEX file, it just adds a FindFlex.cmake file elsewhere. I cannot even explain why reinstalling cmake solved your issue!

[NicosPavlov]

Cc Me!

[macports@…]

Reinstalling cmake does not solve the problem for me. As already mentioned FindFlex.cmake (from KDE) and FindFLEX.cmake are in different directories. I'm not on a case-sensitive filesystem. So this might be further proove for 44104#comment:16

I renamed /opt/local/share/apps/cmake/modules/FindFlex.cmake and was able to successfully configure digikam.

[NicosPavlov]

Replying to rjvbertin@…:

I'd agree with that were it not that there are probably enough KDE ports that do not really require a kbuildsycoca4 invocation.

Well, at least all the ones making any use of plugins, which should not be negligible. As it would be cumbersome to track each port, the simplest should be to consider this a general issue in my point of view. And since the command builds a binary database, it still should be run each time something new is installed to maintain the database up to date.

In fact, one could also argue that the message need appear only when installing the base KDE ports, because once those are installed the OS takes care of loading the required agent(s). At least that's how it seems to work on my 10.6.8 system (and I'd better not try to launchctl unload them because the commands shown in the note don't seem to be enough to restore KDE functionality after that). 10.9 may indeed be different and require a manual launchctl load of at least the dbus agent.

That is the current state, with the message appearing at activation of kdelibs4, but not for the reason you state. The system does not in principle load agents without explicitely asking for it. That is true in particular for the one we talk about, as it must be run at user (and not root) level.

In short, I'm not sure if it's useful to clutter the output when installing/upgrading all KDE packages with this note. One could think of a more terse message reminding only to execute kbuildsycoca4 by hand if a newly installed port seems to lack functionality like I had with digikam. Is it possible to display such a note only after a new install, and not after an upgrade (supposing an upgrade doesn't introduce new components or suppress existing ones)?

I do not know of any way to differentiate between install and upgrade at Portfile level. But as this would imply further complication by tracking possible changes, I would keep the current policy of the provided agent, which is to always run it just in case.

[RJVB (René Bertin)]

I have no objections not to add the note to digikam's portfile - I just hope for those installing it that my experience was unique (or else I won't be the only one posting about digikam not finding any photos in an existing library O:-) ).

[jgosmann (Jan Gosmann)]

Digikam 4 is not building for (OS X 10.9).

Relevant lines of the log file:

:info:build Linking CXX static library ../../../lib/libadvancedrename.a
:info:build cd /opt/local/var/macports/build/_Volumes_Home_blubb_Public_ports_kde_digikam/digikam/work/build/core/utilities/advancedrename && /opt/local/bin/cmake -P CMakeFiles/advancedrename.dir/cmake_clean_target.cmake
:info:build cd /opt/local/var/macports/build/_Volumes_Home_blubb_Public_ports_kde_digikam/digikam/work/build/core/utilities/advancedrename && /opt/local/bin/cmake -E cmake_link_script CMakeFiles/advancedrename.dir/link.txt --verbose=1
:info:build /usr/bin/ar cr ../../../lib/libadvancedrename.a  CMakeFiles/advancedrename.dir/advancedrename_automoc.cpp.o CMakeFiles/advancedrename.dir/advancedrenamedialog.cpp.o CMakeFiles/advancedrename.dir/advancedrenameinput.cpp.o CMakeFiles/advancedrename.dir/advancedrenamemanager.cpp.o CMakeFiles/advancedrename.dir/advancedrenameprocessdialog.cpp.o CMakeFiles/advancedrename.dir/advancedrenamewidget.cpp.o CMakeFiles/advancedrename.dir/common/dynamiclayout.cpp.o CMakeFiles/advancedrename.dir/common/highlighter.cpp.o CMakeFiles/advancedrename.dir/common/modifier.cpp.o CMakeFiles/advancedrename.dir/common/option.cpp.o CMakeFiles/advancedrename.dir/common/parser.cpp.o CMakeFiles/advancedrename.dir/common/parseresults.cpp.o CMakeFiles/advancedrename.dir/common/rule.cpp.o CMakeFiles/advancedrename.dir/common/ruledialog.cpp.o CMakeFiles/advancedrename.dir/common/token.cpp.o CMakeFiles/advancedrename.dir/common/tooltipcreator.cpp.o CMakeFiles/advancedrename.dir/common/tooltipdialog.cpp.o CMakeFiles/advancedrename.dir/parser/defaultrenameparser.cpp.o CMakeFiles/advancedrename.dir/parser/importrenameparser.cpp.o CMakeFiles/advancedrename.dir/parser/modifiers/casemodifier.cpp.o CMakeFiles/advancedrename.dir/parser/modifiers/defaultvaluemodifier.cpp.o CMakeFiles/advancedrename.dir/parser/modifiers/rangemodifier.cpp.o CMakeFiles/advancedrename.dir/parser/modifiers/removedoublesmodifier.cpp.o CMakeFiles/advancedrename.dir/parser/modifiers/replacemodifier.cpp.o CMakeFiles/advancedrename.dir/parser/modifiers/trimmedmodifier.cpp.o CMakeFiles/advancedrename.dir/parser/modifiers/uniquemodifier.cpp.o CMakeFiles/advancedrename.dir/parser/options/cameranameoption.cpp.o CMakeFiles/advancedrename.dir/parser/options/dateoption.cpp.o CMakeFiles/advancedrename.dir/parser/options/directorynameoption.cpp.o CMakeFiles/advancedrename.dir/parser/options/filepropertiesoption.cpp.o CMakeFiles/advancedrename.dir/parser/options/metadataoption.cpp.o CMakeFiles/advancedrename.dir/parser/options/sequencenumberoption.cpp.o CMakeFiles/advancedrename.dir/parser/options/database/databaseoption.cpp.o CMakeFiles/advancedrename.dir/parser/options/database/dbheaderlistitem.cpp.o CMakeFiles/advancedrename.dir/parser/options/database/dbkeyscollection.cpp.o CMakeFiles/advancedrename.dir/parser/options/database/dbkeyselector.cpp.o CMakeFiles/advancedrename.dir/parser/options/database/keys/commonkeys.cpp.o CMakeFiles/advancedrename.dir/parser/options/database/keys/metadatakeys.cpp.o CMakeFiles/advancedrename.dir/parser/options/database/keys/positionkeys.cpp.o
:info:build /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../../../lib/libadvancedrename.a(advancedrename_automoc.cpp.o) has no symbols
:info:build /usr/bin/ranlib ../../../lib/libadvancedrename.a
:info:build /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../../../lib/libadvancedrename.a(advancedrename_automoc.cpp.o) has no symbols

[RJVB (René Bertin)]

I haven't yet had the occasion to test the Portfile under 10.9, but I did test it with (MacPort's) clang-3.4 . That's one thing you could try, see if the build succeeds with configure.compiler=macports-clang-3.4 . What does the compile command that created advancedrename_automoc.cpp.o look like?

[ryandesign (Ryan Carsten Schmidt)]

I updated the port to 4.0.0 in r123279. This ticket is getting a bit long already so if there are further remaining issues let's do those in new tickets.