he -virt
backends, to prevent breaking sbuild again in the future.
Ian Jackson [2016-08-14 22:12 +0100]:
> Martin Pitt writes ("Re: Bug#833407: Please put adt-virt-* binaries back onto
> PATH"):
> > Of course it's possible (and not hard) to re-use them -- I mean that
>
Martin Pitt writes ("Re: Bug#833407: Please put adt-virt-* binaries back onto
PATH"):
> Of course it's possible (and not hard) to re-use them -- I mean that
> from my perspective they were not meant to be public API,
Certainly they were so intended by me when I wrote an
Hi,
Quoting Martin Pitt (2016-08-14 16:25:54)
> Would you be okay with calling those from /usr/share/autopkgtest/virt/ for
> now?
I agree with Iain that the binaries belong into $PATH for the reasons he
mentioned. If autopkgtest changes that, then sbuild will follow because even
with your changes
Hello Johannes,
Johannes Schauer [2016-08-12 15:14 +0200]:
> > The adt-virt-* programs were just never advertised/packaged/documented to be
> > that,
>
> When I put adt-virt-* support into sbuild, I did that without having consulted
> with autopkgtest maintainers. So apparently it was advertised
Hi Martin,
Quoting Martin Pitt (2016-08-12 14:45:29)
> I wasn't aware that something else even used them directly. Hence the quick
> upload to put back the symlinks into /usr/bin/ as a stopgap
thanks for that.
> > My design approach has IMO been vindicated by the fact that there are now
> > out
Hello Ian,
Ian Jackson [2016-08-12 12:06 +0100]:
> But, now, on this question, I am upset. I designed what I thought was
> a good interface, which would be flexible and extensible enough to
> grow to solve a general problem.
It seems to me the core of the misunderstanding is that apparently you
Firstly I want to say that on the whole I am very pleased to see
autopkgtest being taken care of, and being deployed and developed.
But, now, on this question, I am upset. I designed what I thought was
a good interface, which would be flexible and extensible enough to
grow to solve a general prob
Hello Johannes,
Johannes Schauer [2016-08-12 9:11 +0200]:
> Are you suggesting that every consumer of the virt backends embeds Python code
> to do that?
I'm suggesting that using the Python API is much easier, *if* your
program is already written in Python or can embed Python easily [1]. If
this
Hi Martin,
Quoting Martin Pitt (2016-08-12 08:42:02)
> As for third-party users of the backends: Using the Python API
> (adt_testbed.py) is a lot easier and more robust than talking to the
> backend servers directly, due to all the encoding/decoding, timeout
> handling, environment passing etc. --
Control: tag -1 pending
Hello Johannes and Ian,
Ian Jackson [2016-08-04 0:47 +0100]:
> I see that after installing a recent autopkgtest, I no longer have
> adt-virt-schroot, adt-virt-null, etc. I would like to suggest that
> this change be reverted, for the following reasons:
> [...]
These are
Hi Ian,
Quoting Ian Jackson (2016-08-04 18:20:00)
> > In fact I only noticed this breakage because I wanted to add support for
> > adt-run-* to another tool: piuparts which already comes with lots of code
> > supporting the adt-run-* utilities. Now its broken.
>
> I think in the rest of this mail
Hi again,
On Thu, 4 Aug 2016 17:20:00 +0100 Ian Jackson
wrote:
> Johannes Schauer writes ("Re: Please put adt-virt-* binaries back onto PATH"):
> > Using codesearch.debian.net it is not hard to find that others depend on
> > specific functionality of your software. Next time you remove features,
Johannes Schauer writes ("Re: Please put adt-virt-* binaries back onto PATH"):
> thanks a lot Ian for making these four points. I could not've put it
> better. I was very happy with the original autopkgtest design as it
> finally gave us a way to abstract container access in a more or less
> unifie
Hi,
On Thu, 4 Aug 2016 00:47:47 +0100 Ian Jackson
wrote:
> I see that after installing a recent autopkgtest, I no longer have
> adt-virt-schroot, adt-virt-null, etc. I would like to suggest that
> this change be reverted, for the following reasons:
>
> My original design intent was that:
than
Package: autopkgtest
Version: 4.0.2
I see that after installing a recent autopkgtest, I no longer have
adt-virt-schroot, adt-virt-null, etc. I would like to suggest that
this change be reverted, for the following reasons:
My original design intent was that:
0. The autopkgtest virt server protoc
15 matches
Mail list logo
