Your message dated Mon, 19 Jan 2026 07:57:25 +0100
with message-id <[email protected]>
and subject line Re: meson: should use the host gobject-introspection-1.0.pc
for looking up g-ir-scanner
has caused the Debian Bug report #1060838,
regarding meson: should use ${DEB_HOST_GNU_TYPE}-g-ir-scanner when
cross-compiling
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1060838: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060838
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: meson
Version: 1.3.1-1
Severity: important
Tags: patch upstream
X-Debbugs-Cc: [email protected], [email protected]
User: [email protected]
Usertags: ftcbfs
Control: affects -1 + src:harfbuzz
Hi,
Simon worked a lot on making gobject-introspection workable with cross
compilation and this work has hit unstable now. While this seems to work
fine with autotools, it tends to fail with meson.
Among other things, Simon introduced new programs
/usr/bin/<triplet>-g-ir-scanner. When cross building, these should be
used and they'll automatically employ qemu-user when needed. He also
updated gobject-introspection-1.0.pc to have g_ir_scanner point at this
rather than plain /usr/bin/g-ir-scanner. Unfortunately, meson looks up
the gobject-introspection-1.0 dependency with native set to true. Hence,
it does not pick up the host triplet but the build triplet here and that
doesn't go well. We need to change the native argument to false here.
I'm attaching a patch demonstrating the change and it makes building
e.g. harfbuzz work. I expect this change to fix many packages hence
raising the severity to important. I'm not sure whether this is the
desired way to extend meson nor whether this has consequences for
downstreams other than Debian. How can we take care of these matters?
Helmut
--- meson-1.3.1.orig/mesonbuild/modules/__init__.py
+++ meson-1.3.1/mesonbuild/modules/__init__.py
@@ -96,7 +96,7 @@
wanted=wanted, silent=silent, for_machine=for_machine)
def find_tool(self, name: str, depname: str, varname: str, required: bool = True,
- wanted: T.Optional[str] = None) -> T.Union['build.Executable', ExternalProgram, 'OverrideProgram']:
+ wanted: T.Optional[str] = None, native: bool = True) -> T.Union['build.Executable', ExternalProgram, 'OverrideProgram']:
# Look in overrides in case it's built as subproject
progobj = self._interpreter.program_from_overrides([name], [])
if progobj is not None:
@@ -108,7 +108,7 @@
return ExternalProgram.from_entry(name, prog_list)
# Check if pkgconfig has a variable
- dep = self.dependency(depname, native=True, required=False, wanted=wanted)
+ dep = self.dependency(depname, native=native, required=False, wanted=wanted)
if dep.found() and dep.type_name == 'pkgconfig':
value = dep.get_variable(pkgconfig=varname)
if value:
--- meson-1.3.1.orig/mesonbuild/modules/gnome.py
+++ meson-1.3.1/mesonbuild/modules/gnome.py
@@ -328,7 +328,7 @@
}
depname = tool_map[tool]
varname = tool.replace('-', '_')
- return state.find_tool(tool, depname, varname)
+ return state.find_tool(tool, depname, varname, native=depname != "gobject-introspection-1.0")
@typed_kwargs(
'gnome.post_install',
--- End Message ---
--- Begin Message ---
Version: 1.10.1-1
On Mon, Jan 15, 2024 at 01:04:27PM +0100, Helmut Grohne wrote:
> I'm attaching a patch demonstrating the change and it makes building
> e.g. harfbuzz work. I expect this change to fix many packages hence
> raising the severity to important. I'm not sure whether this is the
> desired way to extend meson nor whether this has consequences for
> downstreams other than Debian. How can we take care of these matters?
The patch has been included in 1.10.1-1. Closing.
Helmut
--- End Message ---
