vcswatch reports that
this package seems to have new commits in its VCS but has
not yet updated debian/changelog. You should consider updating
the Debian changelog and uploading this new version into the archive.
Here are the relevant commit logs:
commit f4bdbe4856c4483aa851134d2bc0619b9c83f579
Merge: 020ec62 ce4a497
Author: Martin Pitt <mpitt@debian.org>
Date: Tue Oct 8 07:33:32 2019 +0000
Merge branch 'package_arch_regression_fix' into 'master'
autopkgtest: when checking binary pkg arch, allow *-$ARCH-* values also
See merge request ci-team/autopkgtest!64
commit ce4a497a7f0d32c36110c859ae624b93e143d802
Author: Dan Streetman <ddstreet@canonical.com>
Date: Mon Oct 7 13:15:00 2019 -0400
autopkgtest: when checking binary pkg arch, allow *-$ARCH-* values also
The list of possible valid arch strings, provided by:
$ dpkg-architecture -L
can include plain archs like 'amd64' or 'any', but also can contain
'linux-any' or other dash-separated values. So to match those as well
from the awk script, include - as a possible value delimiter, so arch
values are separated by either , or -.
The correct way to check the arch would be to call out to dpkg-architecture
from the awk script, which probably is possible using awk system() but
would have to also check for 'all'. However this entire awk script
is difficult to understand and maintain; I prefer this minor patch
for this regression, and then looking at complete replacement using
something else.
commit 020ec6285a836d20ab799742649712f7224d61c8
Author: Dan Streetman <ddstreet@canonical.com>
Date: Thu Sep 26 07:45:56 2019 -0400
autopkgtest: When finding src pkg, skip binary pkgs for other archs
When looking for the src pkg, the entire Package-List is searched for every
binary package name. However, there are some rare source packages that
provide binary packages for specific arch(s), while the same binary package
is provided by another source packge for a different arch. One example
is the 'binutils' and 'binutils-mipsen' source packages; currently the
'binutils-mipsen' package provides several 'binutils-mips*' named
binary packages for intel archs, while the main 'binutils' source package
provides the same-named binary packages specifically for the mips arch.
In cases such as this, autopkgtest needs to make sure to only consider
source packages that provide the binary for the current testbed arch,
otherwise it will be confused about what source package name and what
version to look for in the archive.
An example of this is: https://launchpad.net/bugs/1845157
LP: #1845157
Closes: #939790
commit 22efd48b113097350102dbe2788b382f38ee2101
Merge: e3db341 747d553
Author: Paul Gevers <elbrus@debian.org>
Date: Thu Sep 26 08:15:10 2019 +0000
Merge branch 'lxd-test' into 'master'
tools/autopkgtest-build-lxd: pass /dev/null on stdin to lxc launch
See merge request ci-team/autopkgtest!62
commit 747d55377c943143f71a56c6decb8e26957f178d
Author: Dan Streetman <ddstreet@canonical.com>
Date: Tue Sep 24 17:16:51 2019 -0400
tools/autopkgtest-build-lxd: pass /dev/null on stdin to lxc launch
Recent changes to lxd cause 'lxc launch' to fail if there is any input on
stdin queued, which is the case (at least) during the 'lxd' autopkgtest
included in this package, which calls autopkgtest-build-lxd from a here
document passed to a shell. It may be the case for other external uses as
well, so it's best to leave the 'lxd' autopkgtest as is and fix the
autopkgtest-build-lxd script to use lxc launch with the new restriction.
The only other call to 'lxc launch' is from autopkgtest-virt-lxd, which
passes it to check_exec(), and that function explicitly sets stdin to
/dev/null, so no change is needed there.
(LP: #1845037)
![[bug history graph]](https://qa.debian.org/data/bts/graphs/a/autopkgtest.png){kind=link}