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