Hi Sean,
On Tue, 2 Aug 2016 07:23:08 -0700 Sean Whitton wrote:
> Per the discussion in #828025, I'm pretty sure this will fail because the
> .changes generated by sbuild doesn't contain the .dsc. So I think you need
>
> sudo -- autopkgtest foo.dsc foobar.changes -- null
not unconditionally
Dear Johannes,
Thank you for working on my feature request :)
On Tue, Aug 02, 2016 at 01:26:03PM +0200, Johannes Schauer wrote:
> I now have a local patch that adds autopkgtest support in the same way that
> piuparts support is added. But if I understand the changelog entry for version
> 4.0 corr
Control: tag -1 + pending patch
Hi Sean,
CC-ing Martin Pitt to get this right.
On Wed, 8 Jun 2016 15:13:58 +0900 Sean Whitton wrote:
> So the problem is to come up with a sensible default set of options to pass
> to adt-run that will Just Work? This should work without any schroot:
>
> ad
Dear Johannes,
On Tue, Jun 07, 2016 at 10:12:54PM +0200, Johannes Schauer wrote:
> To be able to run autopkgtests, one needs to have a chroot configured,
> needs to know which backend to use and needs to know which
> distribution to use. The sbuild wiki just plainly assumes that the
> user is usin
Control: tag -1 + moreinfo
Hi,
On Sat, 21 May 2016 23:11:03 +0900 Sean Whitton
wrote:
> It is possible to run autopkgtests by invoking adt-run as an sbuild
> post-build-command, as described on the wiki.[1] However, it would be
> better if sbuild could be configured to invoke adt-run as an ind
Package: sbuild
Version: 0.69.0-2
Severity: wishlist
Dear maintainer,
It is possible to run autopkgtests by invoking adt-run as an sbuild
post-build-command, as described on the wiki.[1] However, it would be
better if sbuild could be configured to invoke adt-run as an independent
stage of the bu
6 matches
Mail list logo
