Hi Paul,
On Sat, May 4, 2024 at 10:27 PM Paul Gevers <elb...@debian.org> wrote:
> With a recent upload of sqlite3 the autopkgtest of tracker fails in
> testing when that autopkgtest is run with the binary packages of sqlite3
> from unstable.
[...]
> The new version of tracker in unstable also fails in unstable, but that
> already has bug 1068468 (which *may* be the same).
It _is_ the same bug. But start from the beginning. SQLite3 only got
bug fixes between the current testing (3.45.1-1) and unstable
(3.45.3-1) package versions [1]. All other packages build and
autopkgtest successfully with the SQLite3 version in Sid. Even tracker
(current Sid version, 3.7.3-1) itself was compiled and succeeded to
self-test with SQLite3 3.4.3-1 [2], see the build log parts:
dbus-run-session -- dh_auto_test --no-parallel -- --timeout-multiplier 5
cd obj-x86_64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb
LC_ALL=C.UTF-8 MESON_TESTTHREADS=1 meson test --timeout-multiplier 5
19/41 tracker:fts / fts OK 0.46s
25/41 tracker:core / service OK 12.03s
Installed-Build-Depends:
libsqlite3-0 (= 3.45.3-1),
While the autopkgtest results:
87s 8/29 tracker:fts / fts FAIL
0.22s killed by signal 6 SIGABRT
In short, how come that while building with SQLite3 version 3.45.3 it
works, but autopkgtest with the same version fails?
Your mentioned autopkg log spills out a lot of "ambiguous column name:
ROWID" as well. It seems the test environment setup is failing
somehow. The upstream maintainer of tracker also notes it [3]:
-- cut --
Looking at the configuration at
https://salsa.debian.org/gnome-team/tracker/-/blob/debian/latest/debian/tests/unit-tests,
this looks fishy:
[...]
I see some issues with this:
These loadable modules are not interchangeable with other versions,
the internal API may change between minor releases.
The libtracker-http-soup3.so is installed in that location, but is not
related and does not belong in the src/libtracker-common path.
These .so files are not expected in LD_LIBRARY_PATH, they are dlopened
from specific locations.
The library and test suite will already open the in-tree .so modules,
while run through ninja/meson test.
The build environment does not need any fooling to do the right thing
(i.e. test in-tree code), things might just work if you don't fight it
:).
-- cut --
Then a quick summary. As I see the autopkgtest configure the build
tree and copies installed libraries to it and as such the tests are
failing.
If I do the same manually from simple CLI then indeed the self testing fails.
Still the same environment, still from the same directory if I issue
dh_auto_build after the dh_auto_configure and then execute the same
"dbus-run-session -- dh_auto_test --no-parallel --
--timeout-multiplier 5": all tests pass.
The only difference is that every built binary is in place, not just
two libraries copied into the source tree missing something else. This
is what SIGABRT suggests, probably some binary or library can't be
dlopen-ed as it's (those are) not copied over.
It's the tracker autopkg testing that needs fixing.
Regards,
Laszlo/GCS
[1] https://sqlite.org/releaselog/3_45_3.html
[2]
https://buildd.debian.org/status/fetch.php?pkg=tracker&arch=amd64&ver=3.7.3-1&stamp=1714672833&raw=0
[3] https://gitlab.gnome.org/GNOME/tracker/-/issues/434#note_2077470
