Re: sbuild race with sporadic build breakages

["'MOESSBAUER, Felix' via isar-users" <isar-users@googlegroups.com>]

On Mon, 2024-11-11 at 16:56 +0100, Jan Kiszka wrote:
> On 11.11.24 16:17, Anton Mikanovich wrote:
> > 11/11/2024 16:52, Jan Kiszka wrote:
> > > We could only lock known sessions against each other. But that
> > > would
> > > already help everything that runs in a CI runner, maybe in a kas-
> > > isar
> > > container. Not perfect but would probably address 99% of cases
> > > today.
> > > 
> > > Jan
> > > 
> > This will result in serialization of do_dpkg_build tasks and will
> > cause
> > Isar
> > slowdown.
> > 
> 
> OK, that was the information I was looking for - and was afraid of.
> 
> But even if your PR would be merged tomorrow (which is completely
> unpredictable right now), it would still require backports to
> bookworm
> at least, and those would need to be deployed locally or integrated
> into
> future versions of kas. All that is not going to happen soon - if at
> all. It may even be that only trixes schroot will have all what we
> need.

We have similar problems with apt and proper rate-limit handling. But
that's OT.

At a second thought I'm wondering if we should drop schroot at all and
use mmdebstrap + unshare. By that, the sbuild also does no longer
require root access. I'm running sbuild with unshare backend for some
time locally now (not with ISAR, though).

Felix

> 
> Can't we break up the calls to schroot into those that need looking
> and
> those that actually build so that, inside do_dpkg_build, we only lock
> certain commands, not the complete task?
> 
> Jan
> 

-- 
Siemens AG, Technology
Linux Expert Center


-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/3ae3bf411ce45c92fbad61e674bc6af08c8b0c2f.camel%40siemens.com.