kdepimlibs4: configure fails to find Nepomuk

[doug.mccomber@…]

Nepomuk fails with:

$ sudo port install nepomuk
--->  Fetching nepomuk
--->  Verifying checksum(s) for nepomuk
--->  Extracting nepomuk
Error: ######################################################
Error: A copy of phonon could not be found. Please install  
Error: qt4-mac to provide this. If you have already done this 
Error: your Qt installation is missing the phonon backend.  
Error: Please reinstall Qt4 with phonon support.            
Error: ######################################################
--->  Configuring nepomuk
Error: nepomuk is provided by kdelibs4.
Error: Target org.macports.configure returned: obsolete port
Log for nepomuk is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_kde_nepomuk/main.log
Error: Status 1 encountered during processing.
To report a bug, see <http://guide.macports.org/#p

Phonon is installed:

$ sudo port installed phonon
The following ports are currently installed:
  phonon @4.4.2_3 (active)

A cat of the Nepomuk main.log shows:

version:1
:debug:main Executing org.macports.main (nepomuk)
:msg:main --->  Fetching nepomuk
:debug:fetch fetch phase started at Tue Jul 12 08:41:04 ADT 2011
:debug:fetch Executing org.macports.fetch (nepomuk)
:msg:fetch --->  Verifying checksum(s) for nepomuk
:debug:checksum checksum phase started at Tue Jul 12 08:41:04 ADT 2011
:debug:checksum Executing org.macports.checksum (nepomuk)
:msg:checksum --->  Extracting nepomuk
:debug:extract extract phase started at Tue Jul 12 08:41:04 ADT 2011
:debug:extract Executing org.macports.extract (nepomuk)
:debug:extract Executing proc-post-org.macports.extract-extract-0
:debug:patch patch phase started at Tue Jul 12 08:41:04 ADT 2011
:debug:patch Executing org.macports.patch (nepomuk)
:debug:patch Executing proc-post-org.macports.patch-patch-0
:error:patch ######################################################
:error:patch A copy of phonon could not be found. Please install  
:error:patch qt4-mac to provide this. If you have already done this 
:error:patch your Qt installation is missing the phonon backend.  
:error:patch Please reinstall Qt4 with phonon support.            
:error:patch ######################################################
:msg:patch --->  Configuring nepomuk
:debug:patch Using compiler 'Mac OS X gcc 4.2'
:debug:configure configure phase started at Tue Jul 12 08:41:04 ADT 2011
:debug:configure Executing proc-pre-org.macports.configure-configure-0
:debug:configure Executing proc-pre-org.macports.configure-configure-1
:error:configure nepomuk is provided by kdelibs4.
:error:configure Target org.macports.configure returned: obsolete port
:debug:configure Backtrace: obsolete port
    while executing
"$pre $targetname"
:info:configure Warning: the following items did not execute (for nepomuk): org.macports.activate org.macports.configure org.macports.build org.macports.destroot org.macports.install
:notice:configure Log for nepomuk is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_kde_nepomuk/main.log

[ryandesign (Ryan Carsten Schmidt)]

Did you read the part of the message that says "nepomuk is provided by kdelibs4" and "obsolete port"? Install the kdelibs4 port instead of the nepomuk port.

[ryandesign (Ryan Carsten Schmidt)]

r80416

[doug.mccomber@…]

Replying to ryandesign@…:

r80416

Yes, but I have kdelibs4 installed. This led from installing digikam which failed on kdepimlibs4. kdepimlibs4's log showed:

:info:configure -- The following REQUIRED packages could NOT be located on your system.
:info:configure -- You must install these packages before continuing.
:info:configure -----------------------------------------------------------------------------
:info:configure    * Nepomuk  <http://www.kde.org>
:info:configure      Support for the semantic desktop, including indexing of PIM data
:info:configure      Nepomuk is part of kdelibs

[nerdling (Jeremy Lavergne)]

-- Could NOT find Nepomuk  (missing:  NEPOMUK_LIBRARIES NEPOMUK_INCLUDE_DIR SOPRANO_PLUGIN_RAPTORPARSER_FOUND SOPRANO_PLUGIN_REDLANDBACKEND_FOUND) 

[nerdling (Jeremy Lavergne)]

Let us know if this isn't fixed in r80434.

[jonathan.perichon@…]

Cc Me!

[doug.mccomber@…]

Replying to snc@…:

Let us know if this isn't fixed in r80434.

port -v selfupdate
port clean --dist kdepimlibs4
port install kdepimlibs4

equals success!

Thanks very much for your efforts.

[mkae (Marko Käning)]

This fixes the current issue, but introduced #30191 for kmymoney4(-devel) which relies on existence of KAddressbook functionality previously provided by port kdepimlibs4.

Although nepomuk should be provided by kdelibs4 it is not found, as shown above. Looks like the hunt for the real culprit has to start once again.

[mkae (Marko Käning)]

Cc Me!

[nerdling (Jeremy Lavergne)]

The culprit is soprano/raptor/redland.

[mkae (Marko Käning)]

So, what can be done to regain KAddressbook from kdepimlibs4?

[mkae (Marko Käning)]

Hi snc,

I just wondered why these cmake files actually get installed with the port:

  /opt/local/share/apps/cmake/modules/CheckTimezone.cmake
  /opt/local/share/apps/cmake/modules/FindAkonadi.cmake
  /opt/local/share/apps/cmake/modules/FindGpgme.cmake
  /opt/local/share/apps/cmake/modules/FindLdap.cmake
  /opt/local/share/apps/cmake/modules/FindLibical.cmake
  /opt/local/share/apps/cmake/modules/FindQGpgme.cmake
  /opt/local/share/apps/cmake/modules/KDEPimLibsDependencies.cmake

What are they needed for?

Funnily enough the last one's content looks like this:

$ cat /opt/clean-slate/share/apps/cmake/modules/KDEPimLibsDependencies.cmake

 message(FATAL_ERROR "For using this version of kdepimlibs (4.6.5) you need a newer version of kdelibs, please update.")
$

Well, and this although kdelibs4 is already at 4.6.5:

$ port installed kde*libs4
The following ports are currently installed:
  kdelibs4 @4.6.5_0 (active)
  kdepimlibs4 @4.6.5_0 (active)

[mkae (Marko Käning)]

Brad just pointed out this Soprano bug here:​http://sourceforge.net/tracker/?func=detail&aid=3192295&group_id=197043&atid=959883 or ​http://lists.debian.org/debian-qt-kde/2011/03/msg00169.html

[mkae (Marko Käning)]

Posting on KDE-DEVELOP mailing list gave this info:

On Jul 15, 2011, at 8:33 AM, Volker Krause wrote:

On Thursday 14 July 2011 22:33:48 Marko Käning wrote:
The kdepimlibs4 port had just disabled KABC due to option

	-DKDEPIM_ONLY_KLEO=ON

I'm lacking context here, but enabling this option sounds like a mistake to 
me. The only reason it exists is for building the installers for Gpg4Win 
(http://gpg4win.org/), other builds should not enable it.

regards
Volker

[nerdling (Jeremy Lavergne)]

If we remove that flag then the whole thing doesn't build. It was added so the project would build.

[mkae (Marko Käning)]

I know that it wouldn't build without this option. But this kind of fix is just fixing the build, but makes the lib unusable. As Brad communicated to me one needs to try to downgrade raptor/soprano/redland somehow.

[nerdling (Jeremy Lavergne)]

It seems strange that a client of another library should force those to downgrade. More appropriately, KDE should be doing actual testing.

[mkae (Marko Käning)]

OK, I understand what you mean. I guess you are right.

It's just a pain that soprano/raptor/redland actually killed kdepimlibs4.

[nerdling (Jeremy Lavergne)]

I think KDE killed it since the KDE developers appear to not test things on the Mac.

[mkae (Marko Käning)]

OK, I'll try to contact once again the KDE-DEVELOP mailing list. :-)

[nerdling (Jeremy Lavergne)]

They haven't solved some tickets I created from earlier releases. I have no confidence in them.

[mkae (Marko Käning)]

Oh, my goodness. I'll try it anyway.

[pixilla (Bradley Giesbrecht)]

kdelibs4 is not installing the nepomuk headers.
patch-kdelibs4-kdepimlibs4.diff has kdelibs4 install nepomuk headers and removes "-DKDEPIM_ONLY_KLEO=ON" from kdepimlibs4.

[nerdling (Jeremy Lavergne)]

Replying to pixilla@…:

Looks good. I'm going to compile then commit.

[pixilla (Bradley Giesbrecht)]

snc: this ​kdeutils4 patch closes this #30167 ticket by adding deps on kdepimlibs4 to find missing headers.
Would be nice to commit this once kdepimlibs4 builds again.

[macports@…]

r80434 makes kdepimlibs4 effectively useless. Pretty much nothing that uses them will build anymore. WHY THE FUCKING HELL WAS THIS COMMITED!? DON'T YOU DUMBFUCKS TEST ANYTHING? If shit is busted upstream, then don't bump the versions until you have it sorted out!

[nerdling (Jeremy Lavergne)]

Someone must have updated without checking for open tickets first.

[macports@…]

Replying to snc@…:

Someone must have updated without checking for open tickets first.

There is NO reason that broken shit should ever be committed. From a user point of view, macports is a fucking nightmare because its always a gamble as to what breaks. Updates are usually done in pursuit of a new feature or fix in something unrelated, but then all hell breaks loose more often than not. In fact, I have created this account for a sole purpose of making tickets to document the brokenness. Any patches submitted are in the hopes someone might test and commit them so I don't have to maintain them all myself just to have basic stuff working.

As to the patch provided in the ticket, its fucked to. kdelibs4 gets to the end and barfs on the xinstall because -d is nit a valid switch. Anyone care to explain just what the hell that was meant to do that can't be accomplished with mkdir -p?

[macports@…]

Oh and beyond the absurdity of expecting users to check open tickets before updating, there's only several hundred to wade through, some dating back to the start of the project. Yeah, that's some really awesome quality control. Its totally reasonable to expect end users to deal with this stuff...

I will be very happy the day I can say I no longer use OS X as this is just one of the purely awful things about using it and one of the areas where even the shitty Linux distros are a mile ahead.

[macports@…]

Portfile changed since last build; discarding previous state.

MOTHER. FUCKER. NO!

[mkae (Marko Käning)]

Replying to macports@…:

... WHY THE FUCKING HELL WAS THIS COMMITED!? DON'T YOU DUMBFUCKS TEST ANYTHING? ...

I am as annoyed as you are about the broken stuff. Right now not even dbus works for me. BUT...

But I think you should know that enthusiasts contributing to MacPorts are spending their spare time to keep this alive. I have invested many hours during the last few days researching with other MacPorts committers to find a solution to this problem. And from what I know there is a cure in sight. At least locally I do have a working setup right now. snc (who you have successfully chased away from this issue's CC list with your INAPPROPRIATE RANTS) has a first version of possible Portfile changes under review.

I think it would be more helpful to direct your anger at the problem itself and try as well to find solutions.

I am sorry, but I think that's the only way MacPorts can be kept alive. It needs testers, many of them, as well as their cooperation. And unfortunately KDE applications are not that frequently used...

So, please, stay tuned and I am sure you'll soon have a working installation again.

Concerning the build testing of ports triggered by port updates one can hope that future versions of MacPorts will have this functionality, hopefully centralized and automated.

Patience is the key!

[macports@…]

Replying to mk@…:

I am as annoyed as you are about the broken stuff. Right now not even dbus works for me. BUT...

But I think you should know that enthusiasts contributing to MacPorts are spending their spare time to keep this alive. I have invested many hours during the last few days researching with other MacPorts committers to find a solution to this problem. And from what I know there is a cure in sight. At least locally I do have a working setup right now. snc (who you have successfully chased away from this issue's CC list with your INAPPROPRIATE RANTS) has a first version of possible Portfile changes under review.

I think it would be more helpful to direct your anger at the problem itself and try as well to find solutions.

I am sorry, but I think that's the only way MacPorts can be kept alive. It needs testers, many of them, as well as their cooperation. And unfortunately KDE applications are not that frequently used...

So, please, stay tuned and I am sure you'll soon have a working installation again.

Concerning the build testing of ports triggered by port updates one can hope that future versions of MacPorts will have this functionality, hopefully centralized and automated.

Patience is the key!

I realize this is all a volunteer effort. I'm not criticizing people trying to help, but I am highly critical of tossing untested changes to the masses. As far as I can tell, a port version bump percolated up with other ports quickly changed to perhaps compile but be of no use. The proper solution is back-out the first change rather than break more ports on the way up with changes that will have to be undone once the base problem is fixed.

This got me thinking about how other projects handle this and what the problem is with the way MacPorts handles it. Aside from committing untested changes, the problem in MacPorts is that the normal way a user keeps current is via rsync so they have the newest port tree snapshot. That's simple,. but makes it hard to go back to an earlier version on the ports. Compare this to two other familiar systems. Gentoo also uses rsync, but has the notion of port version exposed in the filename, as well as stable/unstable flags (per platform) in the equivalent of the portfile. This allows several versions of both stable and testing to be provided to the users at any given time, which means its easier for individuals to back down a version or two if needed but also jump ahead onto a testing version with the easy possibility to drop back to a stable version. FreeBSD is more similar to MacPorts from the portfile perspective, in that its ports tree only ever provides a single version of the equivalent to a portfile. However, their normally supported method of keeping up to date is cvs or svn (user choice) which allows a user to very easily revert a portion or the entirety of the ports tree to an earlier version should they have a problem. It is the fatal combination of single versions in the tree and updating with rsync to latest that makes it such a headache for a user.

How to solve this going forward? First and foremost is simply more thorough testing. That will go a long way toward improving user experience. Second should be to put some thought into how best to restructure the portfiles system to allow users to drop back a version without the pain of manually fetching specific portfiles, which will then get stomped on during the next sync if that port is still broken in the tree.

[mkae (Marko Käning)]

I suggest you repost this to the mailing list. In the light of the upcoming version 2.0 it will be the right material for feature and design discussions.

I do understand your rage, since I felt equally mad about the state my MP installations were in after that "upgrade", but I much more liked your previous constructive post.

OK, please let's discuss this further on the ML.

[pixilla (Bradley Giesbrecht)]

macports AT mailinator.com: Macports supports port sync via svn, see the guide ​2.3.3. Subversion Install.
You only need to do item 3.

3. (Optional) Configure MacPorts to use port information from Subversion

[macports@…]

Cc Me!

[nerdling (Jeremy Lavergne)]

Fixed in r81073 and r81074.

[mf2k (Frank Schima)]

I'm still seeing this error.

• Mac OS X 10.6.8
• Xcode 3.2.6

-----------------------------------------------------------------------------
-- The following REQUIRED packages could NOT be located on your system.
-- You must install these packages before continuing.
-----------------------------------------------------------------------------
   * Nepomuk  <http://www.kde.org>
     Support for the semantic desktop, including indexing of PIM data
     Nepomuk is part of kdelibs

-----------------------------------------------------------------------------

CMake Error at /opt/local/share/apps/cmake/modules/MacroLogFeature.cmake:152 (MESSAGE):
  Exiting: Missing Requirements
Call Stack (most recent call first):
  CMakeLists.txt:207 (macro_display_feature_log)

I have the following installed:

$ port installed kde*
The following ports are currently installed:
  kdebase4 @4.6.4_0 (active)
  kdebase4-runtime @4.6.5_1 (active)
  kdeedu4 @4.6.0_0 (active)
  kdegraphics4 @4.6.0_2 (active)
  kdelibs4 @4.6.5_2 (active)
  kdepimlibs4 @4.6.5_0 (active)

And NOT installed:

$ port installed nepomuk
None of the specified ports are installed.

[nerdling (Jeremy Lavergne)]

Sounds like kdelibs4 was installed without the headers; consider checking port contents kdelibs4 to see if the nepomuk headers were installed. If not I'd recommend rebuilding kdelibs4 and any dependents.

You might consider finding the other ticket about adding the Devel component to the KDE PortGroup​, which would offload the installation of the headers from the portfile​. Remember, any KDE-based dependents would need rebuilt to pickup the changes.

[pixilla (Bradley Giesbrecht)]

Replying to macsforever2000@…:

I have the following installed:

$ port installed kde*
The following ports are currently installed:
  kdebase4 @4.6.4_0 (active)
  kdebase4-runtime @4.6.5_1 (active)
  kdeedu4 @4.6.0_0 (active)
  kdegraphics4 @4.6.0_2 (active)
  kdelibs4 @4.6.5_2 (active)
  kdepimlibs4 @4.6.5_0 (active)

kdelibs4 @4.6.5_2 should have provided nepomuk headers. If not, a ticket should be created against kdelibs4.

 $ port contents kdelibs4 | grep /nepomuk/

And NOT installed:

$ port installed nepomuk
None of the specified ports are installed.

Nepomuk is now provided by kdelibs4

 $ port cat nepomuk

[mf2k (Frank Schima)]

Rebuilding all the kde ports worked for me. Specifically:

kdebase4 kdebase4-runtime kdeedu4 kdepimlibs4 kdegraphics4 kdelibs4

Thanks!