Opened 5 years ago

Closed 5 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 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) 5 years ago.
updated port directory for digikam
digikam-4.0.0.diff (5.1 KB) - added by mojca (Mojca Miklavec) 5 years ago.

Download all attachments as: .zip

Change History (24)

Changed 5 years ago by RJVB (René Bertin)

Attachment: digikam.tar.bz2 added

updated port directory for digikam

Changed 5 years ago by mojca (Mojca Miklavec)

Attachment: digikam-4.0.0.diff added

comment:1 Changed 5 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

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

comment:2 Changed 5 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 5 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 5 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 5 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 5 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 5 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 5 years ago by macports@…

Cc: macports@… added

Cc Me!

comment:9 in reply to:  7 Changed 5 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 5 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 5 years ago by ryandesign (Ryan Schmidt) (previous) (diff)

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

comment:12 Changed 5 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 5 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 5 years ago by ryandesign (Ryan Schmidt) (previous) (diff)

comment:14 Changed 5 years ago by bugports@…

Thanks rjvbertin, that worked for me!

comment:15 Changed 5 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 5 years ago by ryandesign (Ryan Schmidt) (previous) (diff)

comment:16 Changed 5 years ago by NicosPavlov

Cc: nicos@… added

Cc Me!

comment:17 Changed 5 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 5 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 5 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 5 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 5 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 5 years ago by ryandesign (Ryan Schmidt) (previous) (diff)

comment:22 Changed 5 years ago by ryandesign (Ryan 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.