GNOME Bugzilla – Bug 733201
unit-tests fail in a buildd chroot build
Last modified: 2021-05-26 22:25:09 UTC
We want to enable the unit-tests on ubuntu builds, however as they are currently setup, they fail in our buildd chroot builders due to the service desktop files (and the rest of tracker) not being installed. Needless to say, it seems wrong for build-time unit tests to be calling system (or previous built jhbuild) libraries while testing. It would be better for the tests to launch a private dbus instance, or otherwise convert the unit-test suite to the "installed-tests" style like glib and a few other GNOME libs are now using.
(/«PKGBUILDDIR»/tests/libtracker-miner/.libs/lt-tracker-file-notifier-test:5956): Tracker-CRITICAL **: Could not get SPARQL connection: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Tracker1 was not provided by any .service files
So the good news is, I updated the unit test system not long ago to be similar to GLib's, so it allows for installable tests. We just need to change all the test Makefiles and make sure they work.
Hi Darkxst, is this still happening now I have improved many of the unit tests? I noticed distcheck was failing a lot lately after switching to the new unit test tools, so hopefully, now they are OK.
I will re-check this when I get a chance.
This is still happening atleast with 1.0.4
(In reply to comment #1) > (/«PKGBUILDDIR»/tests/libtracker-miner/.libs/lt-tracker-file-notifier-test:5956): > Tracker-CRITICAL **: Could not get SPARQL connection: > GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name > org.freedesktop.Tracker1 was not provided by any .service files So this looks like the tracker-store DBus files are not in $prefix correctly and so tracker-store can't be started automatically. The way round this is to start the store ourselves in a sandbox. Does this sound about right ?
martyn, in the builders tracker is not installed. 'make install' gets diverted to a temporary folder from which the binary packages are created. At no point during the build will tracker end up installed in $prefix I think what needs to happen here is to use g_test_dbus to launch a private dbus session. https://developer.gnome.org/gio/unstable/GTestDBus.html I had a quick look at trying that for tracker-file-notifier however didn’t manage to get it working yet. - that test also needs the gvfs dbus interface which isn't available in the private session, I hacked around that by copying in the gvfs daemon service file, but that seems pretty much the wrong way to do it. - org.freedesktop.Tracker1 is getting launched correctly, but seems to be vanishing again shortly after. As a result tracker_sparql_connection_get ends up segfaulting
Created attachment 285797 [details] [review] use Gtestdbus WIP hack to try use GTestDbus to launch private dbus session, fails miserably as it though
(In reply to comment #7) > martyn, in the builders tracker is not installed. 'make install' gets diverted > to a temporary folder from which the binary packages are created. At no point > during the build will tracker end up installed in $prefix > > I think what needs to happen here is to use g_test_dbus to launch a private > dbus session. > > https://developer.gnome.org/gio/unstable/GTestDBus.html Looks like you're probably right. I've been running tests by using: $ make install $ tracker-control -rs $ make check .... Mainly because until more recently, we've not had a better way to do this. The unit test landscape has changed though and I think your idea here makes a lot of sense. > I had a quick look at trying that for tracker-file-notifier however didn’t > manage to get it working yet. > > - that test also needs the gvfs dbus interface which isn't available in the > private session, I hacked around that by copying in the gvfs daemon service > file, but that seems pretty much the wrong way to do it. > > - org.freedesktop.Tracker1 is getting launched correctly, but seems to be > vanishing again shortly after. As a result tracker_sparql_connection_get ends > up segfaulting Can you share the code, I suspect you're setting up DBus INSIDE the test and not OUTSIDE the tests (i.e. before calling g_test_add() and g_test_run() etc. Thanks :)
I took another look at this, I think the previous issue was schemas not getting found, but even with that fixed it still fails. If I try to start tracker-store in the chroot, I get the following messages, makes me think there are other dependencies that need to be running? (lt-tracker-store:10192): GLib-CRITICAL **: g_dir_read_name: assertion 'dir != NULL' failed (lt-tracker-store:10192): GLib-CRITICAL **: g_dir_close: assertion 'dir != NULL' failed (lt-tracker-store:10192): Tracker-WARNING **: FTS tables creation failed (lt-tracker-store:10192): Tracker-DEBUG: Preparing query: 'SELECT MAX("tracker:modified") AS A FROM "rdfs:Resource"' (lt-tracker-store:10192): Tracker-WARNING **: Could not get new resource ID: no such table: rdfs:Resource Tracker-Message: Current and DB locales match: 'C' (lt-tracker-store:10192): Tracker-DEBUG: Initial collation locale is 'C', subscribing for updates... Tracker-Message: Setting up predicates for writeback notification... (lt-tracker-store:10192): Tracker-CRITICAL **: Unable to retrieve tracker:writeback properties: 1.56: syntax error, use of undefined prefix `tracker' Tracker-Message: No predicates set, none are configured in ontology Tracker-Message: Waiting for D-Bus requests...
Moving bugs into new "tests" component.
See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851155 With LANG=C.UTF-8 added into the environment (see the bug I just filed [1]), the build-time tests get a little further but still fail, with multiple errors similar to those below. The build-time tests should set GSETTINGS_SCHEMA_DIR, and run a temporary dbus-daemon whose search path for .service files includes one for the just-built Tracker1 service. (Unfortunately this would make them unsuitable for use as autopkgtests in debian/tests/unit-tests, but I suspect that debian/tests/unit-tests is not actually a particularly valid autopkgtest anyway - it doesn't take any steps to avoid using the just-built Tracker libraries.) [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851154
Created attachment 350064 [details] log from make check This is still true on RHEL-7 with tracker 1.10.5
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new enhancement request ticket at https://gitlab.gnome.org/GNOME/tracker/-/issues/ Thank you for your understanding and your help.