Package: meson
Version: 1.9.1-1
Severity: normal
Tags: patch upstream
Forwarded: https://github.com/mesonbuild/meson/pull/15056
X-Debbugs-Cc: valac@packages.debian.org, debian-cross@lists.debian.org
Control: affects -1 + src:vala src:gcr4 src:libportal
User: debian-cross@lists.debian.org
Usertags: ftcbfs

Some packages, for example gcr4 and libportal, run the
gobject-introspection tools at build time (see #1060838) to generate GIR
XML and typelibs, and then run vapigen to generate Vala bindings from
the GIR XML. To be multiarch-compatible, this requires configuring
vapigen to search architecture-specific paths for the host architecture
(#1061107) so that the correct GLib-2.0.gir can be found.

valac (>= 0.56.18-3) provides a script per host architecture named
${DEB_HOST_GNU_TYPE}-vapigen. If this executable exists, Meson should
use it during cross-builds, falling back to the unprefixed vapigen
otherwise. Because it follows the same pattern as many other cross-tools
like objdump, valac and g-ir-scanner, this just requires a one-line
addition to env2mfile (see the Github PR linked above).

To be practically useful, this requires three ingredients:

1. valac (>= 0.56.18-3), currently in experimental
2. `meson env2mfile` with the change proposed here
3. any one of:
   a. debhelper uses `meson env2mfile` directly (#1111001)
   b. debhelper uses Meson's debcrossgen, and debcrossgen is changed to
      run `meson env2mfile` by default
   c. the package exports MESON_USE_NEW_CROSSGEN=1 to opt-in to making
      debcrossgen run `meson env2mfile` even though it is not yet the
      default

but it should be harmless to make the `meson env2mfile` change any time,
even though it is not immediately useful on its own.

Thanks,
    smcv

Control: tags -1 + fixed-upstream

Change merged in upstream git, will presumably be in 1.10.0 (possibly
1.9.2, I don't know the specifics of the upstream stable-branch
policies).

     smcv