[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Wrong package version is installed

Hi Fabian,

On 22-09-2020 14:29, Fabian Wolff wrote:
> Hi,
> I've noticed an inconsistency in the debci logs for a
> reverse-dependency of a package that I maintain.
> This issue concerns the CI tests for the why3 package in testing:
>   https://ci.debian.net/packages/w/why3/testing/arm64/
> As you can see, on 2020-09-21 15:42:22 UTC, a test run for why3 was
> triggered by an update of z3, meaning the tests for why3 were run with
> all packages from testing except z3/4.8.9-1 from unstable. But if you
> take a look at the log:
>   https://ci.debian.net/data/autopkgtest/testing/arm64/w/why3/7125770/log.gz
> you'll notice that it installs the libcvc4-7 package, which at the
> time of writing is only available in unstable.
> This is a problem because the cvc4 update caused a regression for why3
> in unstable, but now the z3 package also can't migrate to testing
> because there's an apparent regression for why3, which is actually due
> to the wrong version of cvc4 being used in the CI test.

Not the wrong version. There is only one version to pick, but it only
lives in unstable *and* you have skip-not-installable enabled.

> How should I proceed here?

Contact the Release Team would be appropriate, but as I am member of
that too, so let's not bother. I was about to add a hint, however, your
z3 test definition says that only z3 < 4.8.7 is good enough (which is
only available in stable). So I suggest you make the test work with the
z3 in unstable, or drop the test (for now):

Broken autopkgtest-satdep:arm64 Depends on z3:arm64 < none | 4.8.9-1 @un
uH > (< 4.8.7)
  Removing autopkgtest-satdep:arm64 because I can't find z3:arm64

Once this new why3 migrates, the "problem" is gone.

> And is this a bug in debci/autopkgtest/...?

It's an artifact of using skip-not-installable. In a pure testing
environment, the test with cvc4 is skipped because cvc4 isn't
installable, but with testing enabled, cvc4 is installable (albeit from
unstable), but the whole tool chain britney -> debci -> autopkgtest ->
apt -> dpkg isn't smart enough (with acceptable settings) to actually
convey that. What we would want to have is to tell apt to only install
packages from unstable if explicitly mentioned and use testing for all
the rest, but for that we need a resolver that's non-default. So,
consider this a wontfix bug in the infrastructure.


Reply to: