Hello Adam, Steve,
Steve Langasek [2015-11-10 13:52 -0800]:
> On Tue, Nov 10, 2015 at 02:16:39PM -0700, Adam Conrad wrote:
> > Robert's still on the right track here, though. This is just poor use of
> > pinning. See the following:
> > (wily-amd64)root@nosferatu:~# cat /etc/apt/preferences.d/10adt-pinning
> > Package: *
> > Pin: release a=xenial
> > Pin-Priority: 900
> > Package: *
> > Pin: release a=xenial-proposed
> > Pin-Priority: 800
> > (wily-amd64)root@nosferatu:~# apt-get dist-upgrade
> > Reading package lists... Done
> > Building dependency tree
> > Reading state information... Done
> > Calculating upgrade... Done
> > 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> So the notable difference between this, and what autopkgtest is currently
> doing, is the use of a Pin-Priority of 800 vs. 100. Martin, do you want to
> check that raising the pin priority for xenial-proposed solves the problems
> we were seeing earlier?
I actually already did that earlier, and using 100 vs. 800 for
"release a=xenial-proposed" makes no noticeable difference.
autopkgtest's test case for this where the -proposed version of a
package has a versioned depends on a lib that can only be satisfied in
-proposed fails with either, and conversely the real-life tests that
are running seem to work well enough with 100.
I'm fine to bump it to 800 as that seems to work equally well, though;
done in .
Note that several tests failed with "test dependencies are
unsatisfiable" over night. The reason for that was that autopkgtest
had an insufficient fallback to no apt pinning (now fixed in ), and
that we currently dist-upgrade the testbed to the entirety of
-proposed before we start installing test dependencies and running
tests. That dist-upgrade can make the testbed's installed packages
incompatible with the apt pinning. E. g. in  libsqlite3-0 (which is
part of the cloud image) already got upgraded, but then the test tried
to install "sqlite3" from xenial-release, which explodes. With the fix
from  this is now handled properly .
The question remains whether in the new "do isolated tests" regime we
still actually want to dist-upgrade the entire base testbed to
-proposed, or just leave it as -release. Many of our basic packages
(kernel, systemd, coreutils, etc.) have proper autopkgtests, some have
tests with bad coverage (util-linux) and many don't have tests at all
(initramfs-tools, openssl, curl, grub). As long as that's the case I'd
still prefer breaking other tests due to broken versions of those over
silently promoting them because they lack tests.
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)