Bug#775352: unblock (pre-approval or jessie-p-u): autopkgtest (was "Fixing autopkgtest RC bug #775076 via t-p-u")
Control: tags -1 confirmed moreinfo
Hi,
On Wed, Jan 14, 2015 at 01:57:33PM -0200, Antonio Terceiro wrote:
> Opening a bug report since that's way more likely to be handled in this
> way.
Thanks for that.
> On Sun, Jan 11, 2015 at 02:00:45PM +0100, Martin Pitt wrote:
> > Hello release team,
> >
> > Christian Kastner discovered that when using vmdebootstrap with
> > autopkgtest's "VM setup" script it erroneously enables dpkg's
> > "force-unsafe-io" option on the host instead of the guest. This can
> > lead to potential system damage and thus should qualify as RC:
> >
> > https://bugs.debian.org/775076
> >
> > This is fixed in version 3.9.3 in unstable now, including a postinst
> > cleanup for cleaning up an erroneously created
> > /etc/dpkg/dpkg.cfg.d/autopkgtest on the host.
> >
> > At the time when testing froze, testing had 3.6, and unstable's 3.7
> > (with a lot of changes) was one day short of propagating to testing;
> > so as these were already out of sync, I just kept on uploading to
> > unstable as that's what most people use for development. So I prepared
> > a debdiff for testing-proposed-updates at
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=34;filename=autopkgtest.775076.jessie.debdiff;att=1;bug=775076
We prefer patches attached to the bug instead of links to somewhere else.
Anyway, please go ahead with the upload to jessie (the distribution should
also be set to 'jessie') and remove the moreinfo tag from this bug once the
upload is accepted into t-p-u.
> > autopkgtest is mostly a Debian/Ubuntu developer, QA, and continuous
> > integration tool, so honestly the testing version isn't that
> > interesting any more. So if you prefer, I'd be perfectly okay (and
> > in fact happier) with getting 3.9.3 into testing instead; it has a lot
> > of new features, but also a lot of bug fixes:
> >
> > https://people.debian.org/~mpitt/tmp/autopkgtest_3.6_3.9.3.debdiff
> >
> > It's clearly waaaay outside the current freeze rules, but as it's not
> > an end user tool but rather an internal QA one, I want to at least
> > consider it. If we want to go that route, I'm happy to provide more
> > details.
Obviously this isn't going to happen. Please pay attention to the freeze
policy next time!
Cheers,
Ivo
Reply to: