Bug#1075614: Please cancel NMU of v-sim + help needed for autopkgtest of new upstream version

[Simon McVittie]

On Thu, 27 Feb 2025 at 10:49:04 +0100, Andreas Tille wrote:
> autopkgtest [08:21:22]: test autodep8-python3: set -e ; for py in $(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c "import gi.overrides.v_sim; print(gi.overrides.v_sim)" ; done
...
>     import gi.overrides.v_sim; print(gi.overrides.v_sim)
...
> gi.RepositoryError: Typelib file for namespace 'xlib', version '2.0' not found

The problem here seems to be that the proposed version of gir1.2-v-sim-1.0
is unable to find xlib-2.0.typelib. That should come from gir1.2-xlib-2.0,
which is the systematic name for the package from which you can import
a GObject-Introspection typelib with namespace xlib and version 2.0. In
fact gir1.2-xlib-2.0 happens to be a virtual package, provided by the
real package gir1.2-freedesktop.

I'm a little confused by this, because python3-v-sim depends on
gir1.2-v-sim-1.0, and all the versions of gir1.2-v-sim-1.0 that I can
see in apt-cache *do* have that dependency: in the original upload of 3.7.2-9

    Package: gir1.2-v-sim-1.0
    Source: v-sim
    Version: 3.7.2-9
    ...
    Depends: gir1.2-freedesktop, ...

(because older versions of the GObject-Introspection toolchain generated a
dependency on the real package)

and in the recent binNMU

    Package: gir1.2-v-sim-1.0
    Source: v-sim (3.7.2-9)
    Version: 3.7.2-9+b1
    ...
    Depends: gir1.2-cairo-1.0, ..., gir1.2-xlib-2.0, ...

(because newer versions of the GObject-Introspection toolchain generate a
dependency on each of the systematically-named virtual packages, which apt
will resolve by installing the single real package that Provides them)

Is the new upstream version perhaps not generating that dependency? That
could indicate a regression in the new upstream version, or it could
indicate that dh_girepository is failing to parse the typelib or generating
the wrong dependencies or something. A build log for the new/proposed
version would be useful, perhaps attached to a "new upstream release"
bug report.

Or is the test perhaps installing mismatched versions of the relevant
packages, or versions that are not of the architecture combination that you
would expect?

If an urgent workaround is required, hard-coding a Depends on
gir1.2-xlib-2.0 would not be the worst thing.

Looking at the build log for the recent binNMU, I see some warnings:

> dh_girepository -pgir1.2-v-sim-1.0
> dh_girepository: warning: Missing Build-Depends: gir1.2-gl-1.0-dev (ideally with <!nogir>)
> dh_girepository: warning: Missing Build-Depends: gir1.2-gmodule-2.0-dev (ideally with <!nogir>)
> dh_girepository: warning: Missing Build-Depends: gir1.2-gobject-2.0-dev (ideally with <!nogir>)
> dh_girepository: warning: Missing Build-Depends: gir1.2-gtk-3.0-dev (ideally with <!nogir>)
> dh_girepository: warning: Missing Build-Depends: gir1.2-cairo-1.0-dev (ideally with <!nogir>)
> dh_girepository: warning: Missing Build-Depends: gir1.2-xlib-2.0-dev (ideally with <!nogir>)
> dh_girepository: warning: /usr/lib/girepository-1.0/v_sim-3.7.typelib should be installed into /usr/lib/x86_64-linux-gnu/girepository-1.0

The missing Build-Depends are non-critical in practice, but it would be a
good bit of future-proofing to add them. You can ignore the part
about <!nogir> if this is a package that is unlikely to be interesting to
cross-compile.

The typelib should ideally be installed into the multiarch directory,
/usr/lib/${DEB_HOST_MULTIARCH}/girepository-1.0, instead of into the
legacy directory. I can't help wondering whether this could be triggering
a bug in dh_girepository that doesn't apply when the recommended directory
is used, or something like that.

I also notice that the name of the GIR package doesn't match its contents:
the package name claims to contain v_sim version 1.0, but the typelib is
v_sim version 3.7. This is the GObject-Introspection equivalent of making
sure that the package that contains libfoo.so.37 is libfoo37, or at least
Provides libfoo37.

This could be at least partially resolved without needing NEW by adding
Provides: ${gir:Provides} to the package containing the typelib. Ideally
also add the same Provides to whichever package contains the GIR XML (a
.gir file) - in this case that seems to be v-sim - which should result
in it having "Provides: gir1.2-v-sim-3.7-dev (= ${binary:Version})".

The advantage of having dh_girepository generate the Provides, instead of
hard-coding them, is that they will continue to be correct over time,
even if the API version of the typelib changes.

(And if you were to implement the nogir build-profile for easier
cross-compiling, they would automatically disappear in builds where the
GIR XML and typelib were not included - but that's probably not worth it
for this particular package.)

    smcv