Discussion:
britney: Failing autopkgtest for package that got merge into another one
(too old to reply)
Markus Blatt
2024-11-21 17:20:01 UTC
Permalink
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.:

Package: libopm-models-dev
Architecture: all
Section: oldlibs
Depends: libopm-simulators-dev (>= 2024.10~),
${misc:Depends}
Description: transitional package
This is a transitional package. It can safely be removed.

Package: libopm-simulators-dev
Section: libdevel
Architecture: amd64 arm64 armel ia64 m68k mips64el mipsel ppc64el riscv64 loong64
Multi-Arch: same
Depends: ${opm:shared-library}, ${misc:Depends}, libopm-grid-dev (>= 2024.10),
libboost-date-time-dev
Replaces: libopm-simulators1-dev,
libopm-models-dev (<< 2024.10~)
Suggests: libopm-simulators-doc
Breaks: libopm-models-dev (<< 2024.10~)
Description: Parallel porous media / reservoir simulators -- development files
The Open Porous Media (OPM) software suite provides libraries and
...

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.

Is there another way?

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?

Thanks a lot.

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
Soren Stoutner
2024-11-22 00:10:02 UTC
Permalink
Post by Markus Blatt
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
***@debian.org
Markus Blatt
2024-11-22 13:40:02 UTC
Permalink
Post by 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~,
[...]
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
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)
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
Post by Markus Blatt
[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>

Loading...