[Bug 1845157] Re: runner/autopkgtest fails to setup env with binary packages moved to another packge, and different source/binary versions

[Dan Streetman]

This looks similar to bug 1831492.  @vorlon was insistent that was a bug
in autopkgtest, but personally it seemed like a real bug to me, for the
reasons i explained in that bug.

However for this bug, I think it actually is a bug in autopkgtest,
because the resulting binaries are in fact separated by arch, even
though autopkgtest doesn't realize that.


IIUC, autopkgtest is looking at the package list for binutils, and it sees the same packages provided by 'binutils' as well as 'binutils-mipsen'; for example:

in debian/control for binutils in eoan-proposed there is:
Package: binutils-mipsel-linux-gnu
Priority: optional
Architecture: mipsel

in debian/control for binutils-mipsen in eoan-proposed there is:
Package: binutils-mipsel-linux-gnu
Priority: optional
Architecture: amd64 i386 x32


autopkgtest seems not currently smart enough to notice that those source packages don't *actually* overlap with those binary packages, because they are limited to separate archs.  So autopkgtest thinks that both source packages provide the same binary package, which causes this confusing error, because it can't find the '4~c4ubuntu1' version of the binutils source package.

Since I assume that even if we *do* start building for mips arch, you
don't want the binutils source package to build for it (you would want
the binutils-mipsen package to build for it, right?), removing the
conflicting binary packages from the binutils package debian/control
would "fix" this autopkgtest error.

Alternately, the autopkgtest should be taught that it needs to parse the
arch fields for the binary package list, to account for situations like
this.

That's all assuming I haven't misunderstood everything, of course.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to autopkgtest in Ubuntu.
https://bugs.launchpad.net/bugs/1845157

Title:
  runner/autopkgtest fails to setup env with binary packages moved to
  another packge, and different source/binary versions

Status in autopkgtest package in Ubuntu:
  New
Status in autopkgtest package in Debian:
  Unknown

Bug description:
  seen at http://autopkgtest.ubuntu.com/packages/b/binutils/eoan/amd64

  looks like a combination of:

  - binary packages now built from a different source package

  - source and binary package version different (here in
    binutils-mipsen).

  
  <doko> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/b/binutils/20190924_072646_1d504@/log.gz
  <doko> where does this comparison come from, dpkg --compare-versions 2.32.90.20190917-0ubuntu1 lt 4~c4ubuntu1 ? 
  <doko> E: Can not find version '4~c4ubuntu1' of package 'binutils'
  <doko> E: Unable to find a source package for binutils
  <doko> that's the version of the binutils-mipsen source package, not the binutils package
  <cjwatson> I don't speak autopkgtest very well, but just from grepping that looks like:
  <cjwatson> runner/autopkgtest:472:  dpkg --compare-versions "$ver" lt "$maxver" || maxver="$ver";
  <cjwatson> (from my clone of https://salsa.debian.org/ci-team/autopkgtest)
  <doko> hmm, this looks too clever. some binary packages are now built from binutils-mipsen, and not from binutils anymore. wondering if we should just ignore these failures and see if things go green again once everything migrated?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1845157/+subscriptions