Opened 4 years ago

Last modified 3 years ago

#46552 new update

phonon update to 4.8.3, with Qt5 support

Reported by: RJVB (René Bertin) Owned by: michaelld (Michael Dickens)
Priority: Normal Milestone:
Component: ports Version:
Keywords: haspatch Cc: springermac (Jonathan Springer), RJVB (René Bertin)
Port: phonon

Description

Attached is an update for port:phonon, bringing it up to date to the current stable version, 4.8.3 .

I've added a subport to build "4Qt5". I haven't gotten the demos to build (qt5-phonon +demos), yet; help from cmake gurus appreciated.

Attachments (4)

phonon-483.diff (9.6 KB) - added by RJVB (René Bertin) 4 years ago.
updated against mainstream Portfile r134243
phonon-483-alt.diff (9.5 KB) - added by RJVB (René Bertin) 4 years ago.
phonon.diff (10.8 KB) - added by RJVB (René Bertin) 3 years ago.
patch-cmake_PhononMacros.cmake.diff (825 bytes) - added by RJVB (René Bertin) 3 years ago.

Download all attachments as: .zip

Change History (48)

comment:1 Changed 4 years ago by mf2k (Frank Schima)

Cc: michaelld@… removed
Owner: changed from macports-tickets@… to michaelld@…

Thanks. The revision line should be deleted because it starts at 0 when increasing the version and that is the default value.

comment:2 Changed 4 years ago by RJVB (René Bertin)

The demos build now, and are installed in ${qt_bins_dir}.

Phonon used to be built forcing the compatibility version to 4.4.0 on the generated libraries, for "historical reasons". It seems that that dependency (can) make(s) it into Qt4's libraries if phonon is present when Qt4 is built. Or it's a hard-coded requirement; I have no way of telling at the moment without rebuilding Qt4 which is not an option right now. Hence, building without the patches and thus phonon's default creates libraries with compat. version 4.0.0, which are rejected by dyld. This is not the case for Qt5.

So the new patch introduces a default variant compversion440 for Qt4, which may be removed when Qt4 gets a version bump (4.8.7, or my "concurrent" version is committed). To be continued...

NB: I haven't bumped the revision because this is an unpublished Portfile.

comment:3 Changed 4 years ago by mkae (Marko Käning)

Cc: mk@… added

Cc Me!

comment:4 Changed 4 years ago by springermac (Jonathan Springer)

Cc: springermac@… added

Cc Me!

comment:5 Changed 4 years ago by RJVB (René Bertin)

Aligned the Qt5 subport to using a name suffix, as it seems we settled down on that as a preferred labelling approach.

comment:6 Changed 4 years ago by RJVB (René Bertin)

New version removes an implicit dependency on PulseAudio that got pulled in if installed.

comment:7 Changed 4 years ago by michaelld (Michael Dickens)

I updated phonon to 4.8.3 in r133625. I did not add support for Qt5. Can you load the latest dports tree & tweak your patch to be Qt5 specific? Do you know if we can have phonon-qt4 and phonon-qt5 installed at the same time by default (without having to use different install prefixes or lots of tweaks to the CMake files)?

comment:8 in reply to:  7 Changed 4 years ago by RJVB (René Bertin)

Replying to michaelld@…:

Can you load the latest dports tree & tweak your patch to be Qt5 specific?

What exactly do you mean by that? A patch against the version you just uploaded that just adds the Qt5 subport?

Did you actually rename the port to phonon-qt4? AFAIK that's not exactly in line with how things are done generally; Linux too seems to keep the implicit version at qt4 (so we'll probably be migrating to a scheme that includes the Qt version starting with qt5).

Do you know if we can have phonon-qt4 and phonon-qt5 installed at the same time by default (without having to use different install prefixes or lots of tweaks to the CMake files)?

You do remember that I've made Qt4 and Qt5 co-installable, right? So, yes, I have both installed, and I also have the VLC backends installed for both (not yet ready for submitting here).

Your question is moot IMHO as long as the co-installable Qt4 and Qt5 portfiles haven't been incorporated officially. The Qt5 subport should build regardless of how Qt is installed so users with an old-style exclusive Qt install will be able to install only the phonon version for their Qt version.

comment:9 Changed 4 years ago by michaelld (Michael Dickens)

This issue has 2 or more parts: update to 4.8.3, add support for Qt5, tweak support for Qt4. I addressed the first part, but that means your patch is no longer valid based on the current Portfile. Hence, I'm asking if you want to redo your patch based on the new Portfile. I think we can separate out co-installable Qt4 and Qt5 and just work on making phonon co-installable -- so 2 ports, one for Qt4 and another for Qt5. When co-installabilily is added to Qt4 and Qt5, if we've worked over this port correctly then it will just need a rev-bump to get the change in place. Maybe.

comment:10 in reply to:  9 Changed 4 years ago by RJVB (René Bertin)

Replying to michaelld@…:

I addressed the first part, but that means your patch is no longer valid based on the current Portfile.

I see that. I'm going to need to gather courage to dive back in :(

When co-installabilily is added to Qt4 and Qt5, if we've worked over this port correctly then it will just need a rev-bump to get the change in place. Maybe.

I have no reason to believe that my version was incompatible with the Qt (4 and 5) versions currently in MacPorts. My portfile used macros defined by the Qt PortGroups (either version, before and after my interventions) and didn't make any assumptions concerning the way Qt is installed. The Qt plugins directories where phonon is installed were never exclusive.

comment:11 in reply to:  7 ; Changed 4 years ago by dbevans (David B. Evans)

Replying to michaelld@…:

I updated phonon to 4.8.3 in r133625. I did not add support for Qt5. Can you load the latest dports tree & tweak your patch to be Qt5 specific? Do you know if we can have phonon-qt4 and phonon-qt5 installed at the same time by default (without having to use different install prefixes or lots of tweaks to the CMake files)?

This morning after upgrading phonon to 4.8.3, I found that digikam and several of its dependencies are broken due to the libphonon version change involved.

Specifically

     digikam @4.0.0 
         /Applications/MacPorts/KDE4/digikam.app/Contents/MacOS/digikam
         /opt/local/lib/kde4/kipiplugin_advancedslideshow.so
         /opt/local/lib/kde4/kipiplugin_gpssync.so
         /opt/local/lib/libdigikamcore.4.0.0.dylib
         /opt/local/lib/libkgeomap.1.0.0.dylib
     kde4-baseapps @4.14.3 
         /Applications/MacPorts/KDE4/dolphin.app/Contents/MacOS/dolphin
         /opt/local/lib/kde4/adblock.so
         /opt/local/lib/kde4/domtreeviewerplugin.so
         /opt/local/lib/kde4/konq_aboutpage.so
         /opt/local/lib/kde4/konq_sound.so
         /opt/local/lib/kde4/konqsidebar_web.so
         /opt/local/lib/kde4/minitoolsplugin.so
         /opt/local/lib/kde4/rellinksplugin.so
         /opt/local/lib/kde4/validatorsplugin.so
         /opt/local/lib/kde4/webarchiverplugin.so
         /opt/local/lib/kde4/webarchivethumbnail.so
         /opt/local/lib/libkdeinit4_dolphin.dylib
     kde4-runtime @4.14.3 
         /Applications/MacPorts/KDE4/khelpcenter.app/Contents/MacOS/khelpcenter
         /Applications/MacPorts/KDE4/knotify4.app/Contents/MacOS/knotify4
         /opt/local/lib/kde4/libkmanpart.so
         /opt/local/lib/libkdeinit4_khelpcenter.dylib
     marble @4.14.3 
         /Applications/MacPorts/KDE4/marble.app/Contents/MacOS/marble
         /opt/local/bin/marble-mobile
         /opt/local/bin/marble-qt
         /opt/local/bin/marble-touch
         /opt/local/lib/kde4/libmarble_part.so
         /opt/local/lib/kde4/marblethumbnail.so
         /opt/local/lib/kde4/plasma_applet_worldclock.so
         /opt/local/lib/kde4/plasma_runner_marble.so
         /opt/local/lib/kde4/plugins/designer/LatLonEditPlugin.so
         /opt/local/lib/kde4/plugins/designer/MarbleNavigatorPlugin.so
         /opt/local/lib/kde4/plugins/designer/MarbleWidgetPlugin.so
         /opt/local/lib/kde4/plugins/marble/AnnotatePlugin.so
         /opt/local/lib/kde4/plugins/marble/AprsPlugin.so
         /opt/local/lib/kde4/plugins/marble/AtmospherePlugin.so
         /opt/local/lib/kde4/plugins/marble/CachePlugin.so
         /opt/local/lib/kde4/plugins/marble/CompassFloatItem.so
         /opt/local/lib/kde4/plugins/marble/CrosshairsPlugin.so
         /opt/local/lib/kde4/plugins/marble/CycleStreetsPlugin.so
         /opt/local/lib/kde4/plugins/marble/EarthquakePlugin.so
         /opt/local/lib/kde4/plugins/marble/EclipsesPlugin.so
         /opt/local/lib/kde4/plugins/marble/ElevationProfileFloatItem.so
         /opt/local/lib/kde4/plugins/marble/ElevationProfileMarker.so
         /opt/local/lib/kde4/plugins/marble/FlightGearPositionProviderPlugin.so
         /opt/local/lib/kde4/plugins/marble/FoursquarePlugin.so
         /opt/local/lib/kde4/plugins/marble/GosmoreReverseGeocodingPlugin.so
         /opt/local/lib/kde4/plugins/marble/GosmoreRoutingPlugin.so
         /opt/local/lib/kde4/plugins/marble/GpsInfo.so
         /opt/local/lib/kde4/plugins/marble/GpsbabelPlugin.so
         /opt/local/lib/kde4/plugins/marble/GpsdPositionProviderPlugin.so
         /opt/local/lib/kde4/plugins/marble/GpxPlugin.so
         /opt/local/lib/kde4/plugins/marble/GraticulePlugin.so
         /opt/local/lib/kde4/plugins/marble/HostipPlugin.so
         /opt/local/lib/kde4/plugins/marble/JsonPlugin.so
         /opt/local/lib/kde4/plugins/marble/KmlPlugin.so
         /opt/local/lib/kde4/plugins/marble/LatLonPlugin.so
         /opt/local/lib/kde4/plugins/marble/License.so
         /opt/local/lib/kde4/plugins/marble/LocalDatabasePlugin.so
         /opt/local/lib/kde4/plugins/marble/LocalOsmSearchPlugin.so
         /opt/local/lib/kde4/plugins/marble/LogPlugin.so
         /opt/local/lib/kde4/plugins/marble/MapQuestPlugin.so
         /opt/local/lib/kde4/plugins/marble/MapScaleFloatItem.so
         /opt/local/lib/kde4/plugins/marble/MeasureTool.so
         /opt/local/lib/kde4/plugins/marble/MonavPlugin.so
         /opt/local/lib/kde4/plugins/marble/NavigationFloatItem.so
         /opt/local/lib/kde4/plugins/marble/NominatimReverseGeocodingPlugin.so
         /opt/local/lib/kde4/plugins/marble/NominatimSearchPlugin.so
         /opt/local/lib/kde4/plugins/marble/OSRMPlugin.so
         /opt/local/lib/kde4/plugins/marble/OpenCachingComPlugin.so
         /opt/local/lib/kde4/plugins/marble/OpenDesktopPlugin.so
         /opt/local/lib/kde4/plugins/marble/OpenRouteServicePlugin.so
         /opt/local/lib/kde4/plugins/marble/OsmPlugin.so
         /opt/local/lib/kde4/plugins/marble/OverviewMap.so
         /opt/local/lib/kde4/plugins/marble/Photo.so
         /opt/local/lib/kde4/plugins/marble/PlacemarkPositionProviderPlugin.so
         /opt/local/lib/kde4/plugins/marble/Pn2Plugin.so
         /opt/local/lib/kde4/plugins/marble/PntPlugin.so
         /opt/local/lib/kde4/plugins/marble/PositionMarker.so
         /opt/local/lib/kde4/plugins/marble/PostalCode.so
         /opt/local/lib/kde4/plugins/marble/ProgressFloatItem.so
         /opt/local/lib/kde4/plugins/marble/RouteSimulationPositionProviderPlugin.so
         /opt/local/lib/kde4/plugins/marble/RoutingPlugin.so
         /opt/local/lib/kde4/plugins/marble/RoutinoPlugin.so
         /opt/local/lib/kde4/plugins/marble/SatellitesPlugin.so
         /opt/local/lib/kde4/plugins/marble/Speedometer.so
         /opt/local/lib/kde4/plugins/marble/StarsPlugin.so
         /opt/local/lib/kde4/plugins/marble/SunPlugin.so
         /opt/local/lib/kde4/plugins/marble/Weather.so
         /opt/local/lib/kde4/plugins/marble/Wikipedia.so
         /opt/local/lib/kde4/plugins/marble/YoursPlugin.so
         /opt/local/lib/libmarblewidget.0.19.2.dylib
         /opt/local/share/qt4/imports/org/kde/edu/marble/libMarbleDeclarativePlugin.so
     kdelibs4 @4.14.3 
         /opt/local/lib/kde4/kfileaudiopreview.so
         /opt/local/lib/kde4/khtmlimagepart.so
         /opt/local/lib/kde4/libkhtmlpart.so
         /opt/local/lib/libkhtml.5.14.3.dylib
         /opt/local/lib/libknotifyconfig.4.14.3.dylib
         /opt/local/lib/libplasma.3.0.0.dylib
     kdepimlibs4 @4.14.3 
         /opt/local/lib/libakonadi-calendar.4.14.3.dylib
         /opt/local/lib/libakonadi-contact.4.14.3.dylib

They all give an error similar to the following

Incompatible library version: /opt/local/lib/kde4/khtmlimagepart.so requires version 4.4.0 or later, but /opt/local/lib/libphonon.4.dylib provides version 4.0.0

Reverting to phonon @4.7.2_1 fixed the issue.

So looks like all binary dependents of phonon (those that link with libphonon) need to be revbumped as a result of this upgrade.

Last edited 4 years ago by dbevans (David B. Evans) (previous) (diff)

comment:12 Changed 4 years ago by RJVB (René Bertin)

Well, that's a different thing: Michael apparently forgot to add the compversion440 variant, or to make it a default variant.

comment:13 in reply to:  11 Changed 4 years ago by dbevans (David B. Evans)

Cc: nicos@… added

They all give an error similar to the following

Incompatible library version: /opt/local/lib/kde4/khtmlimagepart.so requires version 4.4.0 or later, but /opt/local/lib/libphonon.4.dylib provides version 4.0.0

Reverting to phonon @4.7.2_1 fixed the issue.

So looks like all binary dependents of phonon (those that link with libphonon) need to be revbumped as a result of this upgrade.

Worse than that most of them fail to configure with the following error

CMake Error at /opt/local/share/cmake-3.1/Modules/FindPackageHandleStandardArgs.cmake:138 (message):
  Did not find automoc4 (Automoc4Config.cmake, install
  git://anongit.kde.org/automoc).  (missing: AUTOMOC4_EXECUTABLE)
Call Stack (most recent call first):
  /opt/local/share/cmake-3.1/Modules/FindPackageHandleStandardArgs.cmake:374 (_FPHSA_FAILURE_MESSAGE)
  cmake/modules/FindAutomoc4.cmake:49 (find_package_handle_standard_args)
  cmake/modules/FindKDE4Internal.cmake:428 (find_package)
  CMakeLists.txt:56 (find_package)

automoc is installed

$ port installed automoc
The following ports are currently installed:
  automoc @0.9.88_5 (active)

comment:14 Changed 4 years ago by michaelld (Michael Dickens)

I removed the library compatibility patch because, well, it was old and why would anybody need it anyway? So ... now we know why the library compatibility patch was in place. Reinstated in r133635.

Last edited 4 years ago by michaelld (Michael Dickens) (previous) (diff)

comment:15 Changed 4 years ago by michaelld (Michael Dickens)

As for automoc, I moved it's CMake files to be in $[prefix}/share/cmake/Modules/automoc ... phonon's are in ${prefix}/cmake/Modules/phonon, so I'm not sure why automoc's don't work (they were located in ${prefix}/lib/cmake, which is non-standard on OSX). ${prefix}/cmake/Modules is a standard install location for "new style" cmake module files. I will try building some of the KDE ports to see what happens for me.

comment:16 in reply to:  15 ; Changed 4 years ago by dbevans (David B. Evans)

Replying to michaelld@…:

As for automoc, I moved it's CMake files to be in $[prefix}/share/cmake/Modules/automoc ... phonon's are in ${prefix}/cmake/Modules/phonon, so I'm not sure why automoc's don't work (they were located in ${prefix}/lib/cmake, which is non-standard on OSX). ${prefix}/cmake/Modules is a standard install location for "new style" cmake module files. I will try building some of the KDE ports to see what happens for me.

Thanks, I'm not a KDE kind of guy as you can see. By the way, I can confirm that your update to phonon fixed the previous binary linking issue.

comment:17 in reply to:  15 ; Changed 4 years ago by RJVB (René Bertin)

Replying to michaelld@…:

As for automoc, I moved it's CMake files to be in $[prefix}/share/cmake/Modules/automoc ... phonon's are in ${prefix}/cmake/Modules/phonon, so I'm not sure why automoc's don't work

Maybe because they were/are looked for elsewhere?

When did you move the automoc cmake files? I'm running out-of-date versions on my own system, but I've been able to build quite a few KDE packages on Bradley's VM with my version of the phonon port in place...

comment:18 in reply to:  17 Changed 4 years ago by michaelld (Michael Dickens)

Replying to rjvbertin@…:

Replying to michaelld@…:

As for automoc, I moved it's CMake files to be in $[prefix}/share/cmake/Modules/automoc ... phonon's are in ${prefix}/cmake/Modules/phonon, so I'm not sure why automoc's don't work

Maybe because they were/are looked for elsewhere?

CMake looks for these files in a variety of places. CMAKE_INSTALL_PREFIX/share/cmake* is one of them. Phonon uses them correctly. Maybe it's ports that don't use cmake directly to do configuration but still require cmake for other things (I have no idea what this means; just throwing it out there)?

When did you move the automoc cmake files? I'm running out-of-date versions on my own system, but I've been able to build quite a few KDE packages on Bradley's VM with my version of the phonon port in place...

I did the checkin Friday night (US/ET); r133624.

comment:19 in reply to:  16 ; Changed 4 years ago by michaelld (Michael Dickens)

Replying to devans@…:

Thanks, I'm not a KDE kind of guy as you can see.

I'm not a KDE user either, but there are plenty of other folks who are & want the various KDE ports to work well on OSX.

By the way, I can confirm that your update to phonon fixed the previous binary linking issue.

Great; thanks! I added a comment into the Portfile with that patch, so that in the future hopefully we'll remember why it's there :)

comment:20 in reply to:  19 Changed 4 years ago by RJVB (René Bertin)

Replying to michaelld@…:

Replying to devans@…:

Thanks, I'm not a KDE kind of guy as you can see.

I'm not a KDE user either, but there are plenty of other folks who are & want the various KDE ports to work well on OSX.

Yes. Please, install a few representative KDE ports and test against those if you modify things that are used by KDE ... We're having issues enough as it is.

Anyway, it seems you pushed a new version that works now?

Great; thanks! I added a comment into the Portfile with that patch, so that in the future hopefully we'll remember why it's there :)

I have a rather distinct memory of having discussed that tweak with someone in a recent past, presumable you, and presumable when I started updating phonon (or Qt, or both).

Maybe because they were/are looked for elsewhere?

CMake looks for these files in a variety of places.

I wasn't thinking of CMake per se, but rather that CMake can be instructed to look elsewhere. Possibly even because the automoc cmake files were installed in a non-standard location (where CMake doesn't look by default, or does it?).

A bit like how the kde4 PortGroup file hardcodes a QCA location that is no longer valid when Qt is installed in "concurrent mode" (not that this particular hardcoding isn't necessary either way...)

Last edited 4 years ago by RJVB (René Bertin) (previous) (diff)

comment:21 in reply to:  14 Changed 4 years ago by RJVB (René Bertin)

Replying to michaelld@…:

I removed the library compatibility patch because, well, it was old and why would anybody need it anyway? So ... now we know why the library compatibility patch was in place. Reinstated in r133635.

Note that it's probably unnecessary in itself: I didn't apply it in the Qt5 subport. But removing it forces a rebuild on a potentially enormous amount of ports, some of which are pretty enormous themselves. Which is why that exchange about this "tweak" that I can remember resulted in the conclusion that "it doesn't hurt so we can just as well leave it in for Qt4".

comment:22 Changed 4 years ago by michaelld (Michael Dickens)

OK; automoc issue should be fixed in r133636 and r133637. I don't know how it was working before (when the files were installed into "${prefix}/lib/cmake/automoc4/*". The issue was that the Automoc4Config.cmake script tries to find the install ${prefix} by finding the directory that is "../.." from it's current location (in this case, "${prefix}/lib"). It then looks for "automoc4" in the "bin" subdirectory therein, which just won't work. So, I added another ".." to the relative path lookup, which now works for me when configuring kdelibs4.

Phonon doesn't actually use this Automoc4 because newer cmake provides this functionality built-in; it does a "find_package(Automoc4)" only for older CMake, which is why I didn't see this issue before.

comment:23 Changed 4 years ago by michaelld (Michael Dickens)

And, r133638. Forgot the patch! I'm getting sloppy in my "advanced" age ...

comment:24 in reply to:  22 Changed 4 years ago by RJVB (René Bertin)

Replying to michaelld@…:

Phonon doesn't actually use this Automoc4 because newer cmake provides this functionality built-in; it does a "find_package(Automoc4)" only for older CMake, which is why I didn't see this issue before.

Which would mean that phonon-backend-vlc (and ~-gstreamer) no longer need to declare automoc as a dependency; they're the only ones I apparently have installed to do that?

comment:25 in reply to:  23 Changed 4 years ago by dbevans (David B. Evans)

Replying to michaelld@…:

And, r133638. Forgot the patch! I'm getting sloppy in my "advanced" age ...

After this commit, the ports that I was having automoc problems with (dependencies of digikam that depend on phonon) now configure and build. In particular,

kdelibs4
kdepimlibs4
kde4-runtime
kde4-baseapps
marble

Thanks for the fix.

comment:26 Changed 4 years ago by mkae (Marko Käning)

So, can we commit this then?

comment:27 in reply to:  26 Changed 4 years ago by RJVB (René Bertin)

Replying to mk@…:

So, can we commit this then?

As I already said in PM: no. Unless you want to commit again as soon as I've found the courage to reintroduce the Qt5 subport.

comment:28 Changed 4 years ago by mkae (Marko Käning)

Cc: mk@… removed
Owner: changed from michaelld@… to mk@…

comment:29 Changed 4 years ago by mkae (Marko Käning)

I don't know what made me remove michaelld as owner back then.

What's the status of this patch, René? I figure this is not compatible with current qt5-mac, right?

comment:30 Changed 4 years ago by RJVB (René Bertin)

The status is that I haven't touched it. I wrote about finding courage 3 months ago, and what really happened is that I got side-tracked (by things requiring courage to start from scratch, not redo what had already been done) and then completely forgot about it...

That said, the Portfile I have should work with both the old and the current qt5-mac, the only thing that I cannot guarantee is how it'll work when you try to install both the Qt4 and the Qt5 versions. Binary builds would probably work, but it's not currently possible to build Qt5 ports with an active qt4-mac present.

I'll see if I remember what and why I did at the time, and then see if I can merge my changes with Michael's Portfile or vice-versa.

comment:31 Changed 4 years ago by RJVB (René Bertin)

The unified and side-by-side diffs are much more impressive than what actually had to be done.

Michael's version has removed all calls to install_name_tool that I think the compversion440 variant should make for backward compatibility. I've found it safer to leave them in.

comment:32 Changed 4 years ago by mkae (Marko Käning)

Two points I spotted:

  • Why did you leave lines 159-163 still in the diff?
  • Perhaps there should be a comment why line 78 was commented out?

Question is also how I could test whether this port actually functions as expected.

Changed 4 years ago by RJVB (René Bertin)

Attachment: phonon-483.diff added

updated against mainstream Portfile r134243

comment:33 in reply to:  32 Changed 4 years ago by RJVB (René Bertin)

Replying to mk@…:

Question is also how I could test whether this port actually functions as expected.

The answer to the more important question is: not now, go take a break! ;)

comment:34 Changed 4 years ago by mkae (Marko Käning)

Don't know why, but your diff doesn't apply here on my end:

$ svn log -l 1
------------------------------------------------------------------------
r134243 | michaelld@macports.org | 2015-03-20 15:52:09 +0100 (Fri, 20 Mar 2015) | 2 lines

phonon: use new cmake 1.0 PortGroup feature cmake.out_of_source (ticket #47197).

------------------------------------------------------------------------
$ patch -p0 <phonon-483.diff 
patching file Portfile
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 21.
Hunk #3 FAILED at 95.
Hunk #4 succeeded at 151 with fuzz 1 (offset -12 lines).
3 out of 4 hunks FAILED -- saving rejects to file Portfile.rej
Last edited 4 years ago by mkae (Marko Käning) (previous) (diff)

comment:35 Changed 4 years ago by RJVB (René Bertin)

Attaching a redone patch based against the r134243 Portfile (with md5 sum 362a8033383f760540572a18a38ec0fb)

comment:36 Changed 4 years ago by RJVB (René Bertin)

Cc: rjvbertin@… added

Cc Me!

Changed 4 years ago by RJVB (René Bertin)

Attachment: phonon-483-alt.diff added

comment:37 Changed 4 years ago by mkae (Marko Käning)

This is what I get with current qt5-mac installed:

$ sudo port install phonon-qt5
.
.
.
--->  Applying patches to phonon-qt5
Error: org.macports.patch for port phonon-qt5 returned: can't read "qt_cmake_module_dir": no such variable

:-(

comment:38 Changed 4 years ago by mkae (Marko Käning)

Uncommenting the post-patch phase actually seems to have solved this issue for me.

comment:39 Changed 4 years ago by RJVB (René Bertin)

You'd probably also want to remove the patch that introduces MACPORTS_CMAKE_DIR into CMakeLists.txt ...

comment:40 Changed 4 years ago by mkae (Marko Käning)

Probably, but I haven't checked that, as it did seem to work fine up to now. Which patch would that be?

comment:41 Changed 3 years ago by NicosPavlov

Cc: nicos@… removed

Cc Me!

comment:42 Changed 3 years ago by mkae (Marko Käning)

Cc: michaelld@… added

OK, Michael's commit r140960 is not yet sufficient. The phonon-qt5 subport is still missing...

This does work for me.

Last edited 3 years ago by mkae (Marko Käning) (previous) (diff)

comment:43 Changed 3 years ago by mkae (Marko Käning)

Cc: michaelld@… removed
Owner: changed from mk@… to michaelld@…

Changed 3 years ago by RJVB (René Bertin)

Attachment: phonon.diff added

comment:44 Changed 3 years ago by RJVB (René Bertin)

phonon and phonon-qt5 updated to 4.9.0

Changed 3 years ago by RJVB (René Bertin)

Note: See TracTickets for help on using tickets.