autopkgtest: Specifying --apt-pocket causes wrong unwanted pinning to default release

[Paride Legovini]

Imported from Debian bug http://bugs.debian.org/1032314:

Package: autopkgtest
Severity: normal
X-Debbugs-Cc: <email address hidden>

Adding a pocket via --apt-pocket=<POCKET> causes the
_get_default_release() function to be called. This is needed to
construct the sources.list entry for the pocket, which will be in the
form of:

  deb <mirror> <default_release>-<POCKET> ...

The _get_default_release() function caches the detected default
release in the default_release variable, which is the same variable
used to store the --apt-default-release=<RELEASE> value. This has
no effect when only one test is present in d/t/control, but when
more than one test is present the tests after the first will have
unwanted/wrong pinning (as if --apt-default-release was specified).

[Paride Legovini (paride)]

The ingredients required to hit this bug are:

1. an all-proposed build (--apt-pocket=proposed with no package pinning)
2. multiple tests defined in d/t/control
3. the tests do not allow reusing the same testbed system

Condition 1. means that we don't hit the bug in tests runs triggered
by britney, as those are not all-proposed.

[Paride Legovini (paride)]

This is now Fix Released in Ubuntu.

[Paride Legovini (paride)]

autopkgtest (5.28ubuntu1) lunar; urgency=medium

  [ Paride Legovini ]
  * cross-arch testing
  * Prevent --apt-pocket from setting the wrong default release

 -- Heather Ellsworth <email address hidden> Tue, 14 Mar 2023 16:04:39 -0600

[Paul Gevers (paul-climbing)]

@Paride: I like to come back to this issue, because I'm working on some changes in the same function and I'm not getting why this was an issue in the first place. Do you recall why the function wasn't idem-potent as intended? Looking at the patch (the test code) I have an idea, but that would mean that the function misbehaves in the first test anyways.

[Paride Legovini (paride)]

Hi Paul, I think I remember. The function itself is idempotent, the issue is that by storing (caching) the guessed default release in self.default_release, this `if` will be affected, and change the pinning:

https://salsa.debian.org/ci-team/autopkgtest/-/blob/b4fb54e2a44bbf375d23e34837f377a402c981b2/lib/adt_testbed.py#L401

This only happens at the second test (and later tests), because while running the very first test _get_default_release() was never executed yet, so self.default_release is None and the code under the `if` I pointed to doesn't execute.

[Paul Gevers (paul-climbing)]

Thanks. I think that was the missing piece for me. After some checking, the solution now also makes sense.

Maybe we could have fixed that `if` instead (or maybe *also*). As the comment above it said, I wasn't sure if that `if` even was useful. But let's leave it as it is now.

[Łukasz Zemczak (sil2100)]

Please provide an clear Test Case and describe the possible Regression Potential for this bug in the bug description [1]. I see a possible test case in comment #1, but I'd like it to be made clear that this is what is expected to be performed to verify the upload.

[1] https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template