On Wed, Nov 28, 2018 at 03:03:20PM -0200, Andreas Hasenack wrote:
> On Thu, Nov 8, 2018 at 9:22 AM Robie Basak <email@example.com> 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 'http://archive.ubuntu.com/ubuntu'
> 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
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 https://www.debian.org/