fsearch: update to 0.3.1

[gc-user]

Testing the changes

• I tested the changes in this PR: briefly

Local build testing

• I built this PR locally for my native architecture, (x86_64)
• I built this PR locally for these architectures (crossbuilds): aarch64, i686 (builds fine locally)

Notes:

Due to build errors I added the packages itstool intltool icu-devel.
Due to cross-build error I added build_helper="qemu".

[Edit]

Added @ihateemoji's solution to solve the 64bit-musl cross-build error.

[/Edit]

[gc-user]

Not sure why the -musl builds for 64bit archs fail and if this is an upstream issue or can be fixed by modifying the template / adding a patch.

[ihateemoji]

if [ "$XBPS_TARGET_LIBC" = "musl" ]; then
	CFLAGS+=" -D_LARGEFILE64_SOURCE"
fi

post_extract() {
    sed -i '/#include <linux\/fanotify.h>/d' \
        src/fsearch_folder_monitor_fanotify.c
}

Append this to your template and see if it solves your issue.

From my quick look, the project uses the off64_t type, which can be exposed on musl with the -D_LARGEFILE64_SOURCE flag, and fsearch_folder_monitor_fanotify.c includes both <linux/fanotify.h> and <sys/fanotify.h>, which is not an issue on glibc, but will not work on musl. I've removed <linux/fanotify.h>, and it seems to build fine without it.

[gc-user]

Thank you very much for looking into the PR and the error messages!

Your proposed solution works for me locally, so I'm assuming it does so, too, for the PR.

[ihateemoji]

Out of curiosity, can you check if it builds (and cross-builds) without the patch file (query.patch)?

[gc-user]

I tested for x86_64 and aarch64 (cross) without the patch, both built fine locally.

[ihateemoji]

It seems that everything builds fine on i686; however, one of the unit tests fails. Note that when you cross-compile locally, you do not automatically run any unit tests, because the binary you get is built for a different architecture, which is why it only fails in CI and not when you cross-compile.

Just a wild guess, but try to amend the PR by removing the patch file and see if the unit tests pass without it?

[gc-user]

Thanks for your help.
I deleted the patch for testing to see if github doesn't fail the tests for i686.
Let's see what happens.

Update:

Apparently, i686 build still fails due to the 2 failing tests.
Not sure what to try now. But I guess, I put the patch back in for now?

[ihateemoji]

Swap the patch file for this:

diff --git a/src/fsearch_database_scan.c b/src/fsearch_database_scan.c
index 5f1628ef..f6343847 100644
--- a/src/fsearch_database_scan.c
+++ b/src/fsearch_database_scan.c
@@ -75,7 +75,7 @@ add_folder(DatabaseWalkContext *walk_context, const char *name, const char *path
                                                                       parent,
                                                                       DATABASE_ENTRY_TYPE_FOLDER,
                                                                       DATABASE_INDEX_PROPERTY_MODIFICATION_TIME,
-                                                                      mtime,
+                                                                      (int64_t)mtime,
                                                                       DATABASE_INDEX_PROPERTY_NONE);
     if (!folder_entry) {
         return NULL;
@@ -101,9 +101,9 @@ add_file(DatabaseWalkContext *walk_context, const char *name, off_t size, time_t
                                                                     parent,
                                                                     DATABASE_ENTRY_TYPE_FILE,
                                                                     DATABASE_INDEX_PROPERTY_SIZE,
-                                                                    size,
+                                                                    (int64_t)size,
                                                                     DATABASE_INDEX_PROPERTY_MODIFICATION_TIME,
-                                                                    mtime,
+                                                                    (int64_t)mtime,
                                                                     DATABASE_INDEX_PROPERTY_NONE);
     if (!file_entry) {
         return NULL;

[ihateemoji]

You should send all our findings upstream and see what happens. Chances are these are genuine bugs in the code.

[gc-user]

Thanks, again, for all your help and fixing all the bugs!

[gc-user]

@ihateemoji

I created an issue upstream as per your suggestion.

[ihateemoji]

Awesome, thank you for doing this! Let’s wait and see what happens.

[gc-user]

Well, thank you for finding and fixing the issue in the first place! :-)

[RandallFlagg]

I created this a month ago but for some reason it was ignored:
#61841

[gc-user]

@RandallFlagg
Sorry about that, I must have missed that PR! I'll close mine.

@ihateemoji
Sorry I "made" you do all the work for, well, hopefully at least upstream?

[RandallFlagg]

@gc-user thanks
@ihateemoji can you start the tests on my PR?

[ihateemoji]

@gc-user thanks

@ihateemoji can you start the tests on my PR?

Just take the template and patches from here, and amend your PR with them.

[gc-user]

@ihateemoji

I think I can always reopen the PR if necessary, e.g. if @RandallFlagg's PR doesn't go through. But he also could just adopt your changes into his PR, so that your work wasn't for nothing.

@Duncaen made some comments on @RandallFlagg's PR, so it has gotten some attention finally.