Your message dated Tue, 12 Aug 2025 11:09:08 +0000
with message-id <[email protected]>
and subject line Bug#1110825: fixed in glib2.0 2.84.4-2
has caused the Debian Bug report #1110825,
regarding libgirepository-2.0-0: ABI is dependent on current version of libffi
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.)
--
1110825: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1110825
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: libgirepository-2.0-0
Version: 2.84.4-1
Severity: important
libgirepository-2.0-0 has libffi data structures in its public API,
specifically everything in <girepository/girffi.h>:
- gi_type_tag_get_ffi_type()
- gi_type_info_get_ffi_type()
- gi_type_info_extract_ffi_return_value()
- gi_type_tag_extract_ffi_return_value()
- gi_function_info_prep_invoker()
- gi_function_invoker_new_for_address()
- gi_function_invoker_clear()
- gi_callable_info_create_closure()
- gi_callable_info_get_closure_native_address()
- gi_callable_info_destroy_closure()
Next time libffi does an ABI transition, the ABI of these functions will
change, but upstream is very unlikely to bump the SONAME of
libgirepository-2.0-0 for this (because nothing under their control will
have changed).
A mitigation is that as of trixie, nobody is using libgirepository-2.0-0
yet: the only rdep in the archive is python3-gi/experimental. I expect
that python3-gi and libgjs will both want to move to
libgirepository-2.0-0 in the forky cycle, though.
The way we dealt with this for libgirepository-1.0-1 was to provide a
virtual package with a mechanically-generated name:
Package: libgirepository-1.0-1
Version: 1.84.0-1
Provides: libgirepository-1.0-1-with-libffi8 (= 1.84.0-1)
and make it generate dependencies on that virtual package:
Package: python3-gi
Depends: ..., libgirepository-1.0-1-with-libffi8 (>= 1.62.0-4~), ...
I think we should teach src:glib2.0 to do the same thing.
We might want to limit the dependency generation so that only the
libffi-related functions listed above will generate a dependency on the
virtual package, which would allow packages to call functions like
gi_repository_prepend_library_path() without becoming dependent on a
specific libffi.
smcv
--- End Message ---
--- Begin Message ---
Source: glib2.0
Source-Version: 2.84.4-2
Done: Simon McVittie <[email protected]>
We believe that the bug you reported is fixed in the latest version of
glib2.0, 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 glib2.0 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: Tue, 12 Aug 2025 10:01:06 +0100
Source: glib2.0
Architecture: source
Version: 2.84.4-2
Distribution: unstable
Urgency: medium
Maintainer: Debian GNOME Maintainers
<[email protected]>
Changed-By: Simon McVittie <[email protected]>
Closes: 1110696 1110825
Changes:
glib2.0 (2.84.4-2) unstable; urgency=medium
.
* Mention #1110640 in previous changelog entry
* libgirepository-2.0-0: Generate a dependency on a virtual package
for libffi-related symbols, to avoid trouble during future libffi ABI
transitions (Closes: #1110825)
* libglib2.0-0t64: Make maintainer scripts shellcheck-clean
* libglib2.0-0t64.postrm:
- Refactor to use functions that early-return if we do not want to
do the cleanup, avoiding stacking conditionals
- Don't remove cache files if they would be non-empty,
guarding against issues similar to #1065022 and #1110696
(mitigates: #1110696)
* libglib2.0-0t64.preinst: Disarm libglib2.0-0 postrm for all
architectures, avoiding a corner case where the faulty postrm that
suffered from #1065022 would still exist if it belonged to a former
foreign architecture that was already disabled, but libglib2.0-0
from that architecture was still in removed-but-not-purged state,
resulting in #1065022 recurring when that version of libglib2.0-0
was subsequently purged (Closes: #1110696)
* d/tests/1065022-futureproofing:
- Fix a test regression by generating a versioned Provides when
building a mockup of a hypothetical future libglib2.0-0xyz.
This regression wasn't immediately obvious because the autopkgtest
is marked as flaky (it depends on various implementation details
which we can't completely rely on).
- Make sure required packages stay installed, failing the test early
if their dependencies cannot be satisfied
- Produce only TAP output on stdout, and a diagnostic log on stderr
- Improve diagnostic output
Checksums-Sha1:
7b4b612ea9add64d601fcdc49ddb0f201b506136 4963 glib2.0_2.84.4-2.dsc
a2b6194be42016daa843da43b33def9f22a6f607 140072 glib2.0_2.84.4-2.debian.tar.xz
b1717ef90d9bdc4709eee5cb003258b0fcae27fe 7556 glib2.0_2.84.4-2_source.buildinfo
Checksums-Sha256:
89b2a3567aad67d8da9c781aae9a79d3f78e370a10bececdaf524875bd04a475 4963
glib2.0_2.84.4-2.dsc
0064357458b263dbdffe9e39b8c5854d59e2fc7dabe78c6de1f0b476da80e1f1 140072
glib2.0_2.84.4-2.debian.tar.xz
b54ba9e45707fc9928a1dcf33d4adac419aeb33466b33b62bfbedb8fe9abed66 7556
glib2.0_2.84.4-2_source.buildinfo
Files:
c21f93bcf808f27bbf85a2f77089e307 4963 libs optional glib2.0_2.84.4-2.dsc
5cae702433594cef131abf7e2c2be7f7 140072 libs optional
glib2.0_2.84.4-2.debian.tar.xz
5061c3d6af6bfeb64120b586fb0dbeb1 7556 libs optional
glib2.0_2.84.4-2_source.buildinfo
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEegc60a5pT6Jb/2LlI1wJnT6zMHYFAmibHkQACgkQI1wJnT6z
MHZCfQ/9FigQQXjNmFgjic6T8M1Yu+kLQH/nrWvw+JOmpgmMVTnuMbzxWGulRYwN
v9wvAG2kw8T0ItvXpmvn5Va2huUw3iDlMGvLbg2LrE+Gbm9+DRGP4TyiA3um+4G6
jHDo+NVkx5T7Yb3TWaR6pWK6hrsdm7K+XmW/ehwZz6GH88dStl5jZuXVNjnFiC7Q
qISICC/jwzPW2uFC/pyDFqpv2o1pN77erH2YuZna1Ii3YYSqHlNRoDY9AwM5TGd9
MMKyCV03RsYcOLC6EmMAzQ6vBJ4oQUF47jkh8fnJhzQzeZ9MLe06Nd/452cXEFgV
vS/g7dK7N4NIBL9crcV1I0WTllIETselc1NqftG4xiB89KLkmdk04WORQ4VsvKPx
lETc8yZwMkkWnMd9FbB9fOJEF7eaZiogSyE+mR59UP1dCogh26P1v68lINwExkbu
goh+r7Zsh/wQbTIjiT+O+O57pFvOFo8WsiDCrcBcDPY8Ipx77BLLbrgXI4tQM7Nd
7tHzWR/2meSupgBrH1/q3a1gttrV9bTp6dliKVbpWpg6gYOo4IGlnZHG4wyp5o/7
hH50WNEWuoFWitas3VostPScMkbpje8HgHGc5LMQqZe/vgh1TXUtwpy2H5wYJTVo
26DKMn714Bb7v8hOA3QwDq8SIYUjHbrN1Yqs7fejMbgPfuY64Y0=
=y7Al
-----END PGP SIGNATURE-----
pgpDeCVPBGiEZ.pgp
Description: PGP signature
--- End Message ---
