Closed by 2e7cd3bc4704408358f11ad4d92af17a1b8ce2b5

I was going to say "can't reproduce the original problem", but that is because this patch has been in production in the FreeBSD (which uses OSS) packages for years. So with Marten's OK in mind, I'll ACK it as well.

Looks resolved, and thanks also to @yurchor

This was overcome by other changes in src/main.cpp, which were still not valid with older Clang or on FreeBSD. Fixed with other commits.

.. reconsidering. This is internal debugging / memory profiling that is dumped to stdout when some secret(-ish) extra arguments are given to k3b. The interface used was added to clang on march 15th 2017, so it's only available on very-very recent clangs .. I think the right thing to do is just remove this, as "accidentally committed debugging code".

update with tcberner's newer patch

Commandeering this one to upate the patch with tcb's second version.

Make the diff smaller: only de-bash it, and save make-validation-optional
for a later patch.

Taking over to follow up Albert's suggestion -- this could be two patches, one to de-bash it, one to make validation optional.

Add reviewers who have commented, or who have committed to baloo recently.

So this patch looks ready to land to me: it simplifies the code, defers fstype-detection to QStorageInfo (for FreeBSD, we should fix the original issue there), and is otherwise non-intrusive.

Adding potential reviewers who have committed to Dolphin recently.

A better version (which tcberner has prepared) checks for the existence of the header file and for the existence of the symbol.

https://phabricator.kde.org/R159:b5e20a709fbef7015874e9536cc06e5aa22aa5c0

This is partly related to another review, since committed, for actually filling the creation (birth) time of files. On FreeBSD, this information is available for some filesystems. On Linux, this information is not available through the stat() system call, but statx() was recently added to the kernel, so it's possible that KFileItemMetaData (or whatever that class was) gains support for creation time on Linux too, and then this column is filled in automagically.

LGoF (Looks Good on FreeBSD)

(also, this repo has a .reviewboardrc but no .arcconfig)

See, e.g., https://build-sandbox.kde.org/view/Plasma/job/Plasma kwallet-pam kf5-qt5 FreeBSDQt5.7/1/console

I guess one possibility would be to leave this task around, but moving it from done / abandoned to in progress, with a comment, when new store spam is spotted.

The recent change that uses signalfd() is a linuxism. Possibly a glibism as well. This patch introduces an alternate path for systems without signalfd(), using kevent() to do the Same Thing (tm) .. but as tcberner says, it's not been tested. Consider it a prototype.

It's a little more complicated than this:

The default configuration of kactivities has option KACTIVITIES_LIBRARY_ONLY set to OFF, which means src/imports is added as subdirectory, and it uses KIO and other tier-3 libraries. So the default build of kactivities is still tier-3. And as long as kactivities is listed as tier-3, kactivities-stats should be listed as tier-3 as well.

Very general comment: in the desktop file, does the name now overlap with the existing (non-functional?) x11 plugin?

LGTM on FreeBSD 10.3, both gcc and clang.

• Brain-o on the OpenBSD code
• Reduce whitespace changes
• Update comment

Take over the review so as to land it, based on tcberner's comments
from april 6th, and Albert's reminder.

I just happened to need a FindGperf in another project today, so I've tested this in non-ECM settings (adding this plus ECMFindModuleHelpers to that project's own cmake/) and it works fine on FreeBSD. The docs in the header are good, too: they let me replace some custom cruft in under five minutes with simpler ECM code.

Further to the Linux bits: while ext4 and btrfs have the necessary fields, stat(2) doesn't expose them, xstat(2) doesn't exist yet (see LWN from a few years back), and extracting the info using other tools depends on fun stuff like knowing what kind of filesystem the file resides on (e.g. debugfs is a userland tool that can get the bits, if it's allowed to open the raw filesystem device *and* it's ext[234]).

Might want to add a comment about "this is the actual inode creation time; support depends on the underlying filesystem (e.g. UFS and ZFS have this information, NFS doesn't)", and change the comment about buff.st_ctime and KDE 2.0.

Although we *could* add imported-target support to cmake/modules/FindLibVNCServer.cmake in the krfb sources, that's a bigger change for little benefit (while there, we'd re-write that find-module to match variable-case with modulename-case, among other things), so I'm just going to land this change unmodified.

Adding as reviewers people I could find that committed to krfb in the last month, since there's no .arcconfig or krfb group.

I'm going to claim feedback timeout, plus all it does is add some -I flags when compiling the tests.

Also, kactivities-stats could use an .arcconfig

Wrong repo, wrong reviewers, blech.

• Follow up on review

Adding Kevin as reviewer -- I feel uncomfortable having so little feedback and I'm not sure who should be added if #buildsystem and Frameworks don't ACK.

I've massaged the code for finding libclang on FreeBSD a little; it now finds the library, but that's not a good way to do it because of the risk of mismatching libclang with the clang you're actually using (e.g. having llvm39 installed while using clang++38). So there would have to be more done to get this right:

• check $(CXX) is clang >= 3.8
• look for libclang in $(CXX) --print-search-dirs

Well, except that libclang doesn't live in the directory printed that way :| OTOH, llvm-config38 has the right information, but I'm not sure how to get from the clang version to the llvm-config version (in particular, system clang on 10.3 is clang 3.4, but there is no llvm-config34 or unversioned llvm-config). Getting to the right ClangConfig.cmake from the clang-version is tricksy, too.

Forgot to add Frameworks as reviewer in original review.

(seems that arc diff doesn't like 'Subscribers: Krusader' yet)

gperf is also available in the base system for FreeBSD, so this doesn't have any effects on the build there, either.

Should Inotify_LIBRARIES and Inotify_INCLUDE_DIRS be set to empty strings after r54?