The package had in the past dependencies of the form

   python3 (<< 3.12), python3 (>= 3.11~), python3:any

the new one just

   python3:any

This leads to badly triggered autopkg tests, with a mismatching
python3-defaults.  Afaik, gobject-introspection can only handle the
default python version, not all supported python versions.

Currently seen in Ubuntu, where 3.12 already is the default, but we will
see this on a much larger scale when doing the 3.12 transition in
Debian.  From my point of view, this dependency has to be added back.

Same for the version in experimental.

Control: tags -1 + moreinfo

The parts that require a specific python3 version are now in the
gobject-introspection-bin binary package, which correctly depends on:

    python3 (<< 3.12), python3 (>= 3.11~), python3:any

via dh_python and ${python3:Depends}. The gobject-introspection package
no longer contains any binary Python extensions. This was necessary to be
able to make it a Multi-Arch: same wrapper around a build-architecture
gobject-introspection-bin.

As far as I can see, it would not be straightforward to add a
lockstep-Python-version dependency to gobject-introspection, because it
does not directly contain any binary Python extensions itself (although
of course anyone wanting to prove me wrong is welcome to provide an
implementation).

gobject-introspection depends on gobject-introspection-linux-little-endian
(= 1.78.1-15) (or -big-endian on s390x, etc.). That's a virtual package
provided by gobject-introspection-bin, ensuring that gobject-introspection
and gobject-introspection-bin are upgraded in lockstep; so it should
not be possible to install a mismatched set.

What is the situation that is going wrong in autopkgtest? Can you perhaps
provide a log?

If gobject-introspection explicitly depended on gobject-introspection-bin
by name (not just via a virtual package), would that help?

Thanks,
    smcv

see
https://autopkgtest.ubuntu.com/packages/m/meson/noble/ppc64el

the one triggered by python3-defaults/3.12.1-0ubuntu1
gobject-introspection/1.79.1-1

I think that would do it, deps there are:

python3 (<< 3.13), python3 (>= 3.12~), python3:any

The problem is, that the -bin package is new and that no rdeps know
about it yet.

Do you mean b2bf9aa6-b7bf-4f75-a69c-d2292de2ebbe, requested by you with
those two packages as triggers, which failed like this?

377s autopkgtest [20:34:18]: test exhaustive: preparing testbed
...
559s The following packages have unmet dependencies:
559s  gobject-introspection : Depends: python3 (< 3.12) but 3.12.1-0ubuntu1 is to be installed
559s  python3-dev : Depends: python3 (= 3.11.4-5ubuntu1) but 3.12.1-0ubuntu1 is to be installed
559s E: Unable to correct problems, you have held broken packages.
559s autopkgtest: WARNING: Test dependencies are unsatisfiable - calling apt install on test deps directly for further data about failing dependencies in test logs
559s exhaustive           FAIL badpkg

It isn't clear to me why that one is failing. apt seems to have started
by trying to install gobject-introspection_1.78.1-6, even though it had
--apt-pocket=proposed=src:python3-defaults,src:gobject-introspection on the
autopkgtest command-line - which I would have expected would make all binary
packages from src:gobject-introspection have 1.79.1-1 as the candidate
version?

Is it possible that autopkgtest might be adding pins for all of the
binary packages built by src:gobject-introspection in noble that will
take those binary packages from -proposed, but without adding similar pins
for the binary packages that were newly added in -proposed? Or some similar
interaction?

It's unfortunate that Ubuntu is trying to go directly from
gobject-introspection 1.78.1-6 to 1.79.x, without ever getting the higher
1.78.1-x revisions that are in Debian testing: that would have decoupled
the introduction of new binary packages from the GLib 2.79.x and Python
3.12 transitions.

rdeps are not meant to depend on the -bin package directly (it's meant
to be an implementation detail of the main g-i package), so any solution
that involves adding the -bin package to rdeps' dependencies seems like
the wrong thing. Ideally, all rdeps continue to not know about it.

    smcv

Unfortunately, gobject-introspection 1.78.1-13 was uploaded a few
hours after Ubuntu started the Python 3.12 transition which has not
quite finished. We also thought that it was getting late to not have
gotten glib into Ubuntu so we synced glib 2.79 which then forced us to
get gboject-introspection 1.79 too. So glib can't migrate without
gobject-introspection which has to wait for python3-defaults to
migrate.

https://salsa.debian.org/gnome-team/gobject-introspection/-/merge_requests/14

I think there are few enough packages involved that we can manually
trigger the autopkgtests we need this week since I got the meson
ppc64el autopkgtest to pass.

Thank you,
Jeremy Bícha

Matthias,

Since glib and gobject-introspection have migrated out of
noble-proposed, is there still a need to keep this bug open?

Thank you,
Jeremy Bícha

I'm unsure how many packages are affected by this. I need to trust your
assessment for that.

Suppose you would start again building glib2.0 (and depending packages)
for all supported Python versions, would that work with the current
gobject-introspection?

Matthias

I'm not sure I understand the question. When you say "start again" do
you mean bootstrapping (starting from the beginning), or do you mean
"resume doing something that we did in the past but we now don't"?

If you mean bootstrapping, there is a chain of builds that I believe would
work: build glib2.0 with -Pnogir, use it to build gobject-introspection,
and use that to rebuild glib2.0 with no special profiles.

If you mean "resume doing what we did in the past", I think that
question is based on a false assumption. You might be imagining that
gobject-introspection provides a public Python library, like python3-gi or
python3-dbus, which should be available for every supported Python version
in parallel, but that isn't the case: its role in the Python ecosystem is
more like borgbackup or vim, so it's correct for gobject-introspection-bin
to have a dependency on: python3 (>= current), python3 (<< next).

As far as I know, glib2.0 has never done a build pass or byte-compilation
for each supported Python version in parallel. Its only Python parts
are in libglib2.0-dev-bin (gdbus-codegen and other CLI tools) and
libglib2.0-dev (gdb extensions), both of which are only relevant to
the default Python version, and it has no Python extensions written in
C, only "pure Python" code. The only interface to any of this is by
running tools in /usr/bin, and the fact that they happen to be written in
Python is an implementation detail. It doesn't need any manual action
to be taken when a new Python version is introduced, unless there are
incompatibilities. Ideally the private modules used by gdbus-codegen get
byte-compiled when the default Python version changes, but that's done
automatically, and there would be no particularly significant impact if
it didn't happen.

As far as I know, gobject-introspection has also never been built once
per supported Python version, only for the default Python version. Its
Python part is a private library shared between several of its CLI tools,
and again, the only public interface is via running tools in /usr/bin.
Unlike glib2.0, the private library includes a C extension, so it does
need to be binNMU'd when the default Python version changes.

python3-gi from src:pygobject (a Python library that uses libgirepository)
*is* built for all supported Python versions, and it does provide a
public API to Python callers; but it can do that regardless of what
Python version happens to be used internally by gobject-introspection's
CLI tools. Is that perhaps the library you were thinking of?

If I understand correctly, the usual progression for adding a new Python
version goes like this:

1. Start with only python3.11 supported and default
2. Add python3.12 as supported but non-default
3. binNMU python3-gi and similar packages so they support both 3.11 and 3.12
4. Make python3.12 the default, with python3.11 still supported
5. binNMU gobject-introspection and similar packages for the new default
6. Drop support for python3.11
7. binNMU python3-gi and similar packages so they only support 3.12

python3-gi is involved in steps 3 and 7 (the same as e.g. python3-dbus),
but gobject-introspection is only involved in step 5 (the same as e.g. vim).

Does that answer your question?

    smcv

Control: severity -1 important

I will upload this change soon. It is not clear to me why it would be
helpful, but it's also unlikely to cause a problem.

If I am wrong about this and it somehow causes a regression, I will
try to revert it immediately, but I am quite burned-out at the moment
and I have responsibilities outside Debian, so I would appreciate it if
someone else in the team could keep an eye on this package.

I've explained why I believe this arrangement is correct, and therefore I
don't think there is a bug to be resolved here (certainly not a RC bug).
I am sorry if I have failed to understand the point you were making.

If you disagree and still consider there to be a serious bug here,
please describe a test scenario where the wrong thing happening can be
reproduced (either dependencies that permit an incorrect situation to
be installed, or package relationships that cause some other component
like britney or autopkgtest to misbehave), the result you would expect
from that test scenario, and the actual result.

Thanks,
    smcv