On Thursday, November 21, 2024 9:44:15 AM MST Markus Blatt wrote:

How do other developers usually prevent this situation when merging packages with autopkgtests? Would you first upload a version of the package to be merged without autopkgtests and once that has migrated to testing start the merge?

Without ever having personally encountered a situation like this, I would probably go this route. Only because the dropping of autopkgtest is
temporary. In my mind, autopkgtest are there to help the maintainer catch problems they would otherwise miss. In this case, it is creating a problem.
As it is unlikely that something important that autopkgtest would catch will surface during this brief transition period, I would disable them to make the transition.

--
Soren Stoutner
soren@debian.org
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEJKVN2yNUZnlcqOI+wufLJ66wtgMFAmc/yggACgkQwufLJ66w tgN/lw/+IORf5mWhWyAxibsJI7TCGBeqDKPckHlkfFmC/egsOU91RbZITZyQAdka iJd0j6Ost/A52189SVMXflZdXH2TAL5crVfCPBtGxkDwzrv25WjNOFNoCe+DTuVO qgPuSzHsYqEdkNOzZb6cFoASJPZ6UBBP819491SKDHlqnrFVT6gxwykPax4J79rF E6Kbh0Q92D2wYuOyDXlit52z/6r5QIZQVO2h++luig8SRTTrJhIFaCLT4F7UVRKG dmJDHAHsIiBU5tfhlIesaW6z+RGden2qcucFNd94L6ibbQnqdLM4ked/HmT5rOJh eWmst/P82zkm2BXgdN8cgvo/MbcUK1ja+aNmfVj5DjVzlsdnVFc46Kty19noKtLA wUX4mlzGB6a6ygxrn6H6AEGPnoYCvUyGaYWJ1gaYNIJuF4GiXbkSgRUlynWMMNkO rPVhGlkT3JZ2rI7l1vbNSQnTkUgQw6sRBA3lVGP9xMmEiutEp6XFVhZ80DPu7VMB pthU1rs1UGIliuPX2aGfPdOCieTBTdFi7+Y/OhEUmV41ZBqfUpgkWZFcPSciJp4f ewsvz2eTKV6k6tBs+mdYjqlqYQXlh7vHDUXGIWY4MyWkKSfzIHlAlxmnkD02iwVj WSjG7r+xj6YS1u5CYkc/ju7kxfVe0Uz9taKmwyIizPUBhs2uVPw=
=X3Iy
-----END PGP SIGNATURE-----

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

Am Thu, Nov 21, 2024 at 05:44:15PM +0100 schrieb Markus Blatt:

Hi,

I maintain package opm-models [1] that got merged into opm-simulators [2] (by upstream)
for the new release 2024.10. The opm-models package has autopkgtests.

I have added transitional packages for opm-models in debian/control of opm-simulators version >=2024.10~,
e.g.:

[...]

This seems to work fine for the packages in local tests.

Unfortunately, britney still wants to execute the autopackgetest of source package
opm-models to find out whether migration to testing is safe. This fails in a strange
way. On the tracker [2] it reads:

autopkgtest for opm-models/n/a: amd64: Regression or new test

In the log [3] the test ends with

28s Reading state information...
29s Starting pkgProblemResolver with broken count: 0
29s Starting 2 pkgProblemResolver with broken count: 0
29s Done
29s 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
29s autopkgtest [12:05:44]: rebooting testbed after setup commands that affected boot
45s autopkgtest [12:06:00]: testbed running kernel: Linux 6.1.0-27-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.115-1 (2024-11-01)
46s autopkgtest [12:06:01]: @@@@@@@@@@@@@@@@@@@@ apt-source opm-models
48s blame: opm-models
48s badpkg: rules extract failed with exit code 1
48s autopkgtest [12:06:03]: ERROR: erroneous package: rules extract failed with exit code 1

I tried to replicate this in a chroot of unstable. I somehow fail to do this. >I get different problems: Getting the source and unpacking works, but compilation of the tests
fails as the version of opm-models merged into the new opm-simulators package (2024.10) is not
100% compatible with the sources in the old version (opm-models 2024.04) that are used for the autopkgtests

I wonder how I would be able to resolve this.

One idea would be posting a release critical bug to opm-models in testing and wait until the autoremoval takes place.

I have now posted such a bug, see [4]
This seems to be a known issue when merging/renaming packages, see [5]

Best,

Markus

[1] https://tracker.debian.org/pkg/opm-models
[2] https://tracker.debian.org/pkg/opm-simulators
[3] https://ci.debian.net/data/autopkgtest/testing/amd64/o/opm-models/54496650/log.gz

[4] <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1088035>
[5] <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979181>

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