This review should be closed: a change landed via invent that makes it unnecessary (<crypt.h> is no longer used in the users kcm).

In D29847#674811, @usta wrote:

In D29847#674807, @adridg wrote:

https://invent.kde.org/adridg/plasma-desktop/-/tree/normalize-includes

There's already a CMake-time check for <crypt.h>, it's just not used. (HAVE_CRYPT_H)

@adridg having or not having crypt_h I think won't solve this problem because it looks like Linux needs it on the other hand BSD system doesn't have it and use unistd.h
instead of crypt.h so doesn't we still need to check if the system is linux or not ? I have almost 0 knowledge about bsd systems so i think anyone who has knowledge
on this topic might be more suitable for this patch request. ( at first, I have just think about freebsd and now i can see there are other alternatives (net,open,... bsd has similar issue ) )

In D29847#674807, @adridg wrote:

https://invent.kde.org/adridg/plasma-desktop/-/tree/normalize-includes

There's already a CMake-time check for <crypt.h>, it's just not used. (HAVE_CRYPT_H)

There's already a CMake-time check for <crypt.h>, it's just not used. (HAVE_CRYPT_H)

or if this is just for linux think we can make it just directly
if defined(Q_OS_LINUX)

In T12977#226721, @adridg wrote:

If I mount the CD (e.g. by "make accessible from other applications") and then press the physical eject button (no applications are open on that mount), it does not eject. The disk stays mounted. I honestly don't know what behavior I expect, though.

No worries!

Yes, I think the issue is in the test itself. Thanks for poking with CI.

Thanks for the update.

KDevelop tests on FreeBSD are disabled now due to hangs, but the last test run shows that python support is working OK. The test fails somewhere in the middle, though, but python gets initialized OK.

Any update on this?

Hm, python is on:

Now the test says

@arrowd, the pkgs are upgraded, and gdb is at 8.1_5.

Let me build new packages then :)

It'll be up to @tcberner and @adridg as they look after the FreeBSD builders.

devel/gdb package has been updated to support UTF-8 in FreeBSD. With gdb-8.1_5 the test passes.

In T9249#152665, @kossebau wrote:

For the rest seems this needs some FreeBSD experts to continue here, so I added the respective tag for a start while stepping back for now myself.

That sounds like a bigger hurdle then :/

Closing due to lack of response.

Are you referring to the Qt 4 version of Amarok @vonreth?
If mysql.dll is sufficient, then perhaps we just need to adjust the MySQL search in Amarok.

Isn't that the mysql.dll? At least we used the same mysql package with the old amarok

Unfortunately it seems the MySQL package we have on Windows lacks MySQLEmbedded support, which Amarok needs.

We provide mysql on Windows?

All there for Linux and FreeBSD. Windows is postponed until amarok doesn't need mysqle anymore.

@graesslin Ping?

Ping?

@heikobecker Have you had a chance to look into the Windows build? Also, it looks like FreeBSD has regressed :(

Martin, any news on this?

The FreeBSD builds should now also be sorted out which resolves this I believe.

The Linux builds will come online following the completion of the following two Dependency Builds:

• https://build.kde.org/view/CI%20Management/job/Dependency%20Build%20Plasma%20stable-kf5-qt5%20SUSEQt5.10/1/console
• https://build.kde.org/view/CI%20Management/job/Dependency%20Build%20Plasma%20kf5-qt5%20SUSEQt5.10/1/console

Adding Adriaan and Tobias as it looks like FreeBSD only has Qt 5.9 at the moment.
Linux will switch to Qt 5.10 in a few moments.

Any news in regards to the MySQL issues on Windows?

libEGL is provided by the mesa-libs package in the CI

FreeBSD's ports configures libXcursor with --with-icondir=${PREFIX}/share/icons and installs cursors to there since August 17, 2017.
https://svnweb.freebsd.org/ports?view=revision&revision=448082

Yes, builds on Suse and FreeBSD properly find it and build successfully.

Did the upstream changes we were waiting on here end up landing @adridg / @tcberner?

Have you had a chance to look into this Tobias/Adriaan?

@graesslin Did you get the needed information following the changes above?

Any news in regards to FindMySQL,cmake?

In T8163#133698, @tcberner wrote:

> In regards to FreeBSD, is it possible to get MySQL Embedded made available @adridg?

mysql56-server is now installed (on all but vm1, as that one has a runing pkg process).

In T8163#133690, @bcooksley wrote:

For Linux it looks like you have a build regression which needs to be fixed.

Additionally it cannot seem to find MySQL properly, even though it is definitely there (Akonadi and Qt use it) so that needs checking as well.

> In regards to FreeBSD, is it possible to get MySQL Embedded made available @adridg?
mysql56-server is now installed (on all but vm1, as that one has a runing pkg process).

For Linux it looks like you have a build regression which needs to be fixed.

@bcooksley All the deps are available in the distro so yes, it's just a matter of adding them to the image.

Moved the taglib check to the end, although it still doesn't go through completely I can tell a bit more:

sorted: taglib-extras should be installed now.

In regards to Windows, can you please make the taglib failure fatal at the end rather than at the beginning, so anything else which is hard required can be sorted out at the same time?

Thanks for reporting, fixed packages have now been deployed on the CI Builders.

I'll upload patched packages later. Sorry

Looks like the QtCore build system strikes back.

This has since been resolved.

Qt 5.9 is now available on the CI system.

Yea sorry, Qt>5.7 changed the way the build is configured, which in turn breaks our split of QtBase into separate ports/packages.

This change is currently pending on the FreeBSD maintainers - there isn't anything we can do here.
From my understanding their packaging makes building Qt 5.9/5.10 somewhat difficult as Qt refactored their whole build system...

This has passed two weeks now. I'm going to merge in D8331 even if it breaks on FreeBSD.

ASAN_OPTIONS will be overridden by the CI tooling. I'll adjust that to set symbolise appropriately tonight.

These variables should now be exported via /etc/csh.cshrc:

# $FreeBSD: releng/11.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z peter $
#
# System-wide .cshrc file for csh(1).

It seems we may need to setup symbolization for this to work correctly: https://stackoverflow.com/questions/21163828/meaningful-stack-traces-for-address-sanitizer-in-gcc (applies to Clang as well apparently)

Doesn't look much better yet:

I updated the Qt packages in VM1 with debug symbols.

I'll update the installed packages with debug symbols... will take a while :)

In D7168#133094, @bshah wrote:

Looks good to me, probably though it's good idea to figure out why it returns 0 as processId?

Looks good to me, probably though it's good idea to figure out why it returns 0 as processId?

Shifting this to the FreeBSD Board as this isn't something Sysadmin can actively do anything about - it's waiting on changes upstream in FreeBSD.