[KDE/Mac] another round of KF5 test-building please

[René J.V. Bertin]

On Saturday July 09 2016 18:50:05 Marko Käning wrote:

Hi Marko,

> sorry, but this will be a little longer post, as I was finally putting a bit of work into my tests,
> because I’d also like to see qt5-kde as an alternative port on MacPorts soonish. It would be best of
> course if this would be a joint activity of Michael, mcalhoun and you i.e. qt5-kde some part of qt5.


> But I guess that’s hard to synchronise if interests on both sides aren’t matching.

Yes, it's evident that neither mcalhoun nor Michael (as far as he's concerned) have any interest in having another captain on their ship. For Qt5 it was still technically feasible before port:qt5 was split up to install individual components but now that's been done it has become too complicated. Also, the argument that "ports cannot depend on another port's variant" still applies: it's still important that someone who installs Qt5 as a dependency for KF5 applications gets the best possible experience (i.e. with the QSP patch activated) without having to think about how to achieve that. 

> I only spotted this:
> -------
> --->  Checking kf5-kapidox for QSP XDG mode ...
> QSP XDG mode  check failed: command execution failed, -code 1 -level 0 -errorcode {CHILDSTATUS 63319 1} -errorinfo {command execution failed
>     while executing
> "system "fgrep 'DQT_USE_EXTSTANDARDPATHS -DQT_EXTSTANDARDPATHS_XDG_DEFAULT=true' -R ${build.dir} --include=CMake* --include=Makefile --include=*.make 2..."} -errorline 8
> --->  Installing kf5-kapidox @5.22.0_0+qt5kde
> -------
> Is that critical?

No. I also found a way to avoid this warning. There's no point in doing this check for ports that do not install binaries ("supported_archs noarch").

> I didn’t see Kurt’s issues with kdelibs4support and ktexteditor though...

I'm almost sorry to see that because that should have made it easier to understand what happened there ...

> AND I guess all these warnings are nothing to worry about, as those ports are just meta ports for a
> variety of other kf5-* ports:
> 
> -------
> --->  Staging kf5-portingaid-frameworks into destroot
> ####  Cannot check kf5-portingaid-frameworks for QSP XDG mode (not a CMake project).
> --->  Installing kf5-portingaid-frameworks @5.22.0_0+qt5kde

Yes, those are in fact only informational. The patch above cancels the message for these ports, but I also turned the message into one that shows only when building with -v.

> If this message is only debug output for you as the maintainer I think one should leave it out in
> the final release of port:qt5-kde in order to not to confuse the users too much.

That's a KF5 message, btw.

> Somehow I managed to crash Kate though… Need to try and figure out what I did to make it happen…

Without a backtrace I cannot say much...

> --->  Fetching distfiles for kf5-baseapps
> Error: This port doesn't have a release version yet.
> Error: org.macports.fetch for port kf5-baseapps returned: This port doesn't have a release version yet.

There are a few of those. KF5-baseapps only provides Konqueror at the moment, and KF5 konqueror isn't even in beta yet. 

> --->  Verifying checksums for kf5-config-modules                                     
> Error: Checksum (rmd160) mismatch for plasma-desktop-5.6.4.tar.xz
> Error: Checksum (sha256) mismatch for plasma-desktop-5.6.4.tar.xz
> Error: org.macports.checksum for port kf5-config-modules returned: Unable to verify file checksums

Right. That one had to be nuked; it's been replaced by kf5-plasma-desktop .

> --->  Fetching distfiles for kf5-dev-scripts
> Error: You need to select a python3 variant
> Error: org.macports.fetch for port kf5-dev-scripts returned: Please select a python3 variant

I can't remember why I added a Python3 dependency; it appears to be unnecessary. But if it were, there aren't many ways to force the user to chose a Python version ...

> --->  Verifying checksums for kf5-libkipi
> Error: Checksum (rmd160) mismatch for libkipi-16.04.2.tar.xz
> Error: Checksum (sha256) mismatch for libkipi-16.04.2.tar.xz
> Error: org.macports.checksum for port kf5-libkipi returned: Unable to verify file checksums

Fixed since.

> --->  Verifying checksums for kf5-kdenlive                                           
> Error: org.macports.checksum for port kf5-kdenlive returned: Unable to verify file checksums

Fixed, thanks,

> --->  Fetching distfiles for kf5-kdesvn
> --->  Fetching distfiles for kf5-purpose
> --->  Fetching distfiles for kf5-konversation
> --->  Fetching distfiles for kf5-kwebkitpart
> --->  Fetching distfiles for kf5-okular
> --->  Fetching distfiles for kf5-smb4k
> Error: This port doesn't have a release version yet.
> Error: org.macports.fetch for port kf5-kdesvn returned: This port doesn't have a release version yet.

See above. Ports like this need to be installed as the ${name}-devel . Would you suggest that I let kf5-kdesvn (etc) depend on kf5-kdesvn-devel until an official release is made?

> Error: KWayLand is not supported on darwin at the moment
> Error: org.macports.fetch for port kf5-kwayland returned: not supported on this platform

It shouldn't appear on OS X now.

> Having said that, I noticed only quite late in the process, that I had installed kf5-osx-integration-devel
> though: 
...
> But as this port doesn’t have a lot of dependencies:

Those are *dependents*, not dependencies!

> I believe it might be fine as is for now.

What do you mean?

> Due to the above issues the following ports could not be installed:
> -------
>  kf5-digikam

This one should have a release version now. Let me know what you think best for the other ports that do not yet have a release version.


>  kf5-kscreenlocker
>  kf5-kwin
>  kf5-plasma-integration

Those are Linux only ports. I can make them invisible on OS X, but only by returning the error when generating the portindex. Not really elegant, but OTOH it'll make it easier to know which ports to include in an official release ;)


> By the way, when starting kf5-dolphin’s Dolphin.app (later also seen for Okteta.app) it complains
> ---
> 	Could not start process
> 	Cannot talk to klauncher:
> 		The name org.kde.launcher5 was not provided by any .service. files
> ---
> all in one line. :-(

That message is "normal", sadly. It also doesn't mean anything; klauncher *is* started, at some point. Note that there is also an org.macports.kdeinit5.plist launchd file now, because I discovered myself that the kded5 plist didn't (always) start kdeinit5 and thus klauncher.
Still, those applications are supposed to be started automatically when required; the only reason I can see for that not to happen is if /opt/local/bin is not put in your path early enough . That is not required for dolphin itself, btw; if I start it via the FInder it works fine for me.

> Well, of course, as expected, Dolphin therefore doesn’t view anything from the filesystem...

> advising to start the daemon at boot time. Thus I ran it, but finally realised that Dolphin.app
> seems unaffected by it, i.e. is still showing above error.

What happens when you start it from a shell, with the `dolphin5` command?

Cheers,
René