Opened 10 years ago

Closed 10 years ago

#44104 closed update (fixed)

digikam 4.0.0 update

Reported by: RJVB (René Bertin) Owned by: jgosmann (Jan Gosmann)
Priority: Normal Milestone:
Component: ports Version:
Keywords: haspatch Cc: cgilles (HumanDynamo), mojca (Mojca Miklavec), macports@…, NicosPavlov, ryandesign (Ryan Carsten Schmidt)
Port: digikam

Description

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).

Attachments (2)

digikam.tar.bz2 (3.9 KB) - added by RJVB (René Bertin) 10 years ago.
updated port directory for digikam
digikam-4.0.0.diff (5.1 KB) - added by mojca (Mojca Miklavec) 10 years ago.

Download all attachments as: .zip

Change History (24)

Changed 10 years ago by RJVB (René Bertin)

Attachment: digikam.tar.bz2 added

updated port directory for digikam

Changed 10 years ago by mojca (Mojca Miklavec)

Attachment: digikam-4.0.0.diff added

comment:1 Changed 10 years ago by mojca (Mojca Miklavec)

Cc: caulier.gilles@… mojca@… added
Owner: changed from macports-tickets@… to jan@…
Version: 2.3.0

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.

comment:2 Changed 10 years ago by 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)?

comment:3 in reply to:  1 Changed 10 years ago by 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

comment:4 Changed 10 years ago by 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.

comment:5 Changed 10 years ago by 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.

comment:6 Changed 10 years ago by 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)?

comment:7 Changed 10 years ago by 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.

comment:8 Changed 10 years ago by macports@…

Cc: macports@… added

Cc Me!

comment:9 in reply to:  7 Changed 10 years ago by 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.

comment:10 Changed 10 years ago by 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

Last edited 10 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:11 Changed 10 years ago by mojca (Mojca Miklavec)

comment:12 Changed 10 years ago by 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.

comment:13 Changed 10 years ago by 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]

Last edited 10 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:14 Changed 10 years ago by bugports@…

Thanks rjvbertin, that worked for me!

comment:15 Changed 10 years ago by 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!

Last edited 10 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:16 Changed 10 years ago by NicosPavlov

Cc: nicos@… added

Cc Me!

comment:17 Changed 10 years ago by 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.

comment:18 in reply to:  6 Changed 10 years ago by 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.

comment:19 Changed 10 years ago by 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:-) ).

comment:20 Changed 10 years ago by 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

comment:21 Changed 10 years ago by 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?

Last edited 10 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:22 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: ryandesign@… added
Keywords: haspatch added; kde removed
Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.