Your message dated Fri, 26 Sep 2025 16:20:47 +0000
with message-id <[email protected]>
and subject line Bug#1061107: fixed in vala 0.56.18-3
has caused the Debian Bug report #1061107,
regarding vapigen: Make it possible to cross-compile libraries with Vala 
bindings
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.)


-- 
1061107: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061107
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: valac
Version: 0.56.14-1
Severity: wishlist
X-Debbugs-Cc: [email protected]

Now that we can cross-compile GObject-Introspection data, many GNOME
packages that could not not previously be cross-compiled become available
for cross-compiling. However, some of the libraries we would like to be
able to cross-compile (for example ibus and libportal) have Vala bindings,
generated from the library's own GIR XML via the vapigen tool.

At the moment, during a cross-build, vapigen will generally be a
host-architecture binary which cannot always be run on the build
architecture, causing builds to fail.

Ideally, during a cross-build, we would like to run a build-architecture
vapigen binary, but configure it (perhaps via command-line options or
environment variables) so that it will find host-architecture GIR XML
in /usr/lib/${DEB_HOST_MULTIARCH}/gir-1.0. The search paths need to
be architecture-specific in order to find GLib-2.0.gir without having
libgirepository1.0-dev installed, because libgirepository1.0-dev
is not cross-compile-friendly. I don't think there are any other
architecture-dependent paths involved, but the Vala maintainers would
know what this tool does better than I do.

As a proof-of-concept, I was able to work around this in libportal by
generating some local wrappers and overrides; but ideally this would
be something that could be done centrally, with most of the work in the
vala package.

I'll follow up with more concrete suggestions, but I wanted to open the
bug with a relatively solution-neutral problem statement rather than
jumping directly to a solution.

This is related to #1060904, but perhaps more of a downstream issue;
some solutions to it would benefit from #1060904, but that isn't a
mandatory dependency.

Thanks,
    smcv

--- End Message ---
--- Begin Message ---
Source: vala
Source-Version: 0.56.18-3
Done: Simon McVittie <[email protected]>

We believe that the bug you reported is fixed in the latest version of
vala, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to [email protected],
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Simon McVittie <[email protected]> (supplier of updated vala package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [email protected])


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Fri, 26 Sep 2025 14:18:47 +0100
Source: vala
Architecture: source
Version: 0.56.18-3
Distribution: experimental
Urgency: medium
Maintainer: Debian GNOME Maintainers 
<[email protected]>
Changed-By: Simon McVittie <[email protected]>
Closes: 1061107
Changes:
 vala (0.56.18-3) experimental; urgency=medium
 .
   * Team upload
   * d/rules: Parameterize the vala major/minor version number
   * d/rules: Generate cross valac wrapper from a template
   * d/*.links: Create cross valac symlinks declaratively
   * Use absolute path to run valac in the cross wrapper.
     If the cross wrapper for valac has been found in /usr/bin, it
     seems less surprising if it runs the corresponding system copy of
     valac, bypassing any possible locally-installed valac that might
     conceivably be the same major version number.
   * Move vapigen, vapigen-0.56 to valac-bin, add required Breaks/Replaces
   * d/rules: Generate a ${DEB_HOST_GNU_TYPE}-vapigen which searches
     appropriate directories.
     For example, this means we find GLib-2.0.gir in
     /usr/lib/${DEB_HOST_MULTIARCH}/gir-1.0. (Closes: #1061107)
   * Generate a ${DEB_HOST_GNU_TYPE}-vala.ini to use valac, vapigen wrappers.
     This allows packages with a Meson build system to opt-in to using the
     host architecture valac and vapigen during cross-builds. Ideally this
     would be done more centrally, in debhelper or `meson env2mfile`, but
     we should make the infrastructure available first.
   * d/control, d/rules: Use build-architecture valac if cross-compiling.
     This allows vala itself to be cross-compiled, as long as the
     pkg.vala.nographviz build-profile is used (or #983886 is fixed)
     and a native build for the build architecture has been done first.
   * d/copyright: Don't quote the FSF's former postal address here
   * Standards-Version: 4.7.2 (no changes required)
   * Initially upload to experimental, since the cross-related changes
     are somewhat intrusive
Checksums-Sha1:
 a5e17d991d5bf063cd29a78bdb905f65adec0176 3424 vala_0.56.18-3.dsc
 a35a1f2d99f95f6790a39f0c2ee0a6d86ab6a026 36032 vala_0.56.18-3.debian.tar.xz
 0fc54cfc7a8fcf336c0fe4894cfcb68f302c4502 12739864 vala_0.56.18-3.git.tar.xz
 2b8c21bb56c73fb92b80bcb1a3bb5adb293c955a 18214 vala_0.56.18-3_source.buildinfo
Checksums-Sha256:
 e828f1e84beaa26cb98fa27aca2adebd8f0c1e5fbde939aaeaea781ab02cdfc8 3424 
vala_0.56.18-3.dsc
 8d656a8078b794524408689fb25f163ab0fdb115e0cbab619187f881c1754427 36032 
vala_0.56.18-3.debian.tar.xz
 4804af0f88357dd1a49596e2469b0d791adf8bba1b3b9a1e640872eb7f95c0e0 12739864 
vala_0.56.18-3.git.tar.xz
 fc2ac3e5c9025cc082168801584a7163b59cea989f347f28a079b7bab2929e88 18214 
vala_0.56.18-3_source.buildinfo
Files:
 aa4fdcdd42cad34a4d9f28a3660e1862 3424 devel optional vala_0.56.18-3.dsc
 909e494f73daaca8af519859db8288f2 36032 devel optional 
vala_0.56.18-3.debian.tar.xz
 6a2ec6f3e166fd69289047758cc5b31b 12739864 devel optional 
vala_0.56.18-3.git.tar.xz
 df70608fe5e78cc91f457129755b0462 18214 devel optional 
vala_0.56.18-3_source.buildinfo
Git-Tag-Info: tag=b4d5c0426c7623fa03953684a7d8e69408188853 
fp=7a073ad1ae694fa25bff62e5235c099d3eb33076
Git-Tag-Tagger: Simon McVittie <[email protected]>

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEN02M5NuW6cvUwJcqYG0ITkaDwHkFAmjWuKcACgkQYG0ITkaD
wHlKOg//f4EmiH7mpGXmqrcDvLYe8q+8fYyLnEhB6GsVnzyrnaNU1Py6VHVXhOJF
I6jly95lg+Zx95dQA558E4C9CvUAbqC/Go2xWnlBpDNTMkQxMdQ0gGmZQE5zsHNo
FQvEzX4vvAo3CV3HNvnb/N/jZ8aFsZcMWMtCReYnIWbuHgVRBs/NNDJCCZ/hr2k8
W+I03UAjDKsc5LwKbbFPH/R568creKrBtr4K4+eIp/7ie0sBMp6lt3suBbggo2wq
VePupoc+/+y02VTFf9L81874gbdKvNdPoUmU0kk++pAmR7AL12UOSd3MrTYMAqRN
JCNWW83+u78gT3NUqraTYx4prD0nwJKJIvD133EJwKV0lIBSYN/t2q6k2T1BZyv6
IiwQkUcp4B0HEQk0FLYo5e/UoFfQjT8R6nQvvo6iZavdHnACncNuH/PEGqoRYlvG
o69ALz/zVOD5asXuWT7WMVTCYPRTAc1pWNryRdgI4ee4cREiqJhQZ/D0fuVxSQA5
UKhpZ0XN7dPis4cBi/WyKijdIAkq4lkg18MLakBaW95VYHAhPo935Xc9MIzRQw7z
CBPXFQlKczOhMmg7uBHdzyc7qyMVJxMPHHHq5bXTcGO3M5Uv+Nmp8FcY3qDL9SUW
jbp8Ie5igK6YCj0hwJYHEVGZkCLdHWOm/0dDIWHgLpuTHgeaCO0=
=lA+6
-----END PGP SIGNATURE-----

Attachment: pgpljwduSWnp1.pgp
Description: PGP signature


--- End Message ---

Reply via email to