Control: tags -1 + moreinfo

On Tue, 20 Feb 2024 at 22:15:21 +0100, Matthias Klose wrote:

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.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 20 Feb 2024 at 23:15:09 +0100, Matthias Klose wrote:

On 20.02.24 22:50, Simon McVittie wrote:

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

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

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.

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Control: severity -1 important

On Tue, 20 Feb 2024 at 23:15:09 +0100, Matthias Klose wrote:

On 20.02.24 22:50, Simon McVittie wrote:

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

I think that would do it

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.

On Tue, 20 Feb 2024 at 22:15:21 +0100, Matthias Klose wrote:

The package had in the past dependencies of the form

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

the new one just

python3:any

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.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)