Ian Campbell writes ("Re: [PATCH OSSTEST v2 01/18] apt: lock osstest's usages
of apt-get against each other"):
> On Tue, 2015-01-20 at 18:19 +, Ian Jackson wrote:
> > I think target_run_apt ought to lose the $timeout parameter. Anyone
> > who calls it with other than the big 3000s timeout mig
On Tue, 2015-01-20 at 18:19 +, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST v2 01/18] apt: lock osstest's usages of
> apt-get against each other"):
> > Currently we rely on all apt-get invocations being in a single
> > ts-xen-build-prep job which can't run on a shared host.
> >
>
Ian Campbell writes ("[PATCH OSSTEST v2 01/18] apt: lock osstest's usages of
apt-get against each other"):
> Currently we rely on all apt-get invocations being in a single
> ts-xen-build-prep job which can't run on a shared host.
>
> That is a bit inflexible so instead use our own lock. We wait
>
Currently we rely on all apt-get invocations being in a single
ts-xen-build-prep job which can't run on a shared host.
That is a bit inflexible so instead use our own lock. We wait indefinitely and
rely on osstest's existing command timeout infrastructure to catch problems.
target_install_package