On Sun, 23 Feb 2025 at 23:28:05 +0000, Daniel Markstedt wrote: > Thank you for reporting the issue. Looking at the full build log, I can see > that this is caused by Meson failing to find the sparql dependency: > > Run-time dependency tracker-sparql-3.0 found: NO (tried pkgconfig and cmake) > Run-time dependency tracker-sparql-2.0 found: NO (tried pkgconfig and cmake) > Run-time dependency tracker-sparql-1.0 found: NO (tried pkgconfig and cmake) > ../meson.build:895: WARNING: Tracker SPARQL or TinySPARQL not found (required > for Spotlight support)
This was actually #1098537, a regression in libtracker-sparql-3.0-dev (which no longer provides a working tracker-sparql-3.0.pc pkg-config file, but should). I believe I've reassigned all the remaining instances of the same root cause to tinysparql, and a fix is pending (see #1098537 and https://salsa.debian.org/gnome-team/tinysparql/-/merge_requests/13). I see that Jonas worked around this in 4.1.2~ds-2, thinking that it was a netatalk bug that was being solved "correctly" in netatalk, by replacing the libtracker-sparql-3.0-dev B-D with libtinysparql-dev. Unfortunately, this was not the correct solution to this particular FTBFS, and it only worked because of "compensating errors". netatalk still requires the tracker-sparql-3.0 API, therefore it should still build-depend on libtracker-sparql-3.0-dev, which is the package that is meant to provide that API (although until today it was broken, and that's bug #1098537). The change in 4.1.2~ds-2 only worked because libtinysparql-dev had a dependency on libtracker-sparql-3.0-dev, which in fact is the wrong way round (see the tinysparql bug and MR for more details). As a result, after fixing #1098537, netatalk will start to FTBFS again. We can't make libtinysparql-dev work around what was already done in netatalk without introducing a circular dependency, which seems like a bad idea, so tinysparql unfortunately does need to make netatalk regress (and also nautilus and tracker-miners, but the GNOME team will fix those). I see two possible solutions: 1. Build-depend on both libtracker-sparql-3.0-dev (correct) and libtinysparql-dev (to work around #1098537). The extra B-D is a little bit ugly, but harmless, because versions of libtracker-sparql-3.0-dev where #1098537 has been fixed will pull in libtinysparql-dev anyway. 2. Wait for a version of tinysparql that fixes #1098537 (should be 3.8.2-4) to be built on at least all of the release architectures, and then swap the B-D back to libtracker-sparql-3.0-dev (only). This is the more "pure" approach, but if someone does a mass-rebuild before that upload and reports the resulting FTBFS, the maintainers of netatalk will have to be prepared to respond to that FTBFS bug without stacking more workarounds on top of workarounds. After the upstream source code has been changed (upstream or in a patch) to look for the tinysparql-3.0 name as a preferred alternative, it will become correct to B-D on libtinysparql-dev only - but that has not yet happened, and until then, libtinysparql-dev is not enough. Thanks, smcv
