Wednesday, 28 November 2018

Re: /usr-merge by default for new installations, with backwards compat

On Wed, Nov 28, 2018 at 03:03:20PM -0200, Andreas Hasenack wrote:
> On Thu, Nov 8, 2018 at 9:22 AM Robie Basak <> wrote:

> > I see that you blocked the SRU for debootstrap in LP: #1773496 / LP:
> > #1800945 on a usr-merge problem. Please can you resolve this, given that
> > you chose to drive this change in Ubuntu? I believe this is what is
> > causing the sbuild autopkgtests in stable releases to fail - because
> > distro-info-data now mismatches what debootstrap knows about.

> Looks like this is blocking an SRU of mine:

> Verification was done on Oct 26th (~1 month ago).

> DEP8 is clean except for sbuild/0.75.0-1ubuntu1:

> This is the failure in sbuild's test:
> autopkgtest [16:51:16]: test build-procenv: [-----------------------
> INFO: Creating sbuild chroot 'disco-amd64-sbuild' for release 'disco'
> in directory '/tmp/autopkgtest.gqMpRP/autopkgtest_tmp/schroot-disco'
> from url ''
> mkdir /tmp/autopkgtest.gqMpRP/autopkgtest_tmp/schroot-disco
> E: No such script: /usr/share/debootstrap/scripts/disco
> E: Error running debootstrap at /usr/sbin/sbuild-createchroot line 274.

In such circumstances, it's legitimate to either ask the SRU team to hint
the sbuild autopkgtests as bad (since this is not a regression introduced by
exim4, but is reproducible in the release pocket) or to retrigger the tests
in such a way that the -proposed debootstrap is also pulled in, getting a
passing test.

I've done the latter now:

retry-autopkgtest-regressions --series bionic --blocks exim4 \
| sed -e's,$,\&trigger=debootstrap/1.0.95ubuntu0.3,' \
| xargs -rn1 -P10 wget --load-cookies ~/.cache/autopkgtest.cookie -O-

retry-autopkgtest-regressions is from lp:ubuntu-archive-tools.

This should clear the test blockage for the exim4 SRU.

Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer