RE: [PATCH 0/1] acquire database lock when calling reprepro

["Hombourger, Cedric" <Cedric_Hombourger@mentor.com>]

Hi Alex,

Yes I observed a dpkg_runbuild failure for a custom recipe because it was running apt-get update (from /build.sh) while the isar-apt database was being updated by another bitbake thread running do_deploy_deb

apt-get update was complaining that the hash of the isar-apt files was changed in the background

We should therefore let reprepro finish its job for the current recipe/package(s) before we update the database in /build.sh

I was lucky enough to get a test-case failing 100% (in our large Isar-based project)
With the lock rework, the issue was not observed anymore (neither on my machine nor on any of Jenkins nodes we have our CI running on)

Hope that helps
Cedric

-----Original Message-----
From: Alexander Smirnov [mailto:asmirnov@ilbers.de] 
Sent: Wednesday, August 22, 2018 1:59 PM
To: Hombourger, Cedric <Cedric_Hombourger@mentor.com>; isar-users@googlegroups.com
Subject: Re: [PATCH 0/1] acquire database lock when calling reprepro

Hi,

On 22.08.2018 14:34, Cedric Hombourger wrote:
> As bitbake performs multi-threaded builds, packages may be built while 
> others get deployed. A lock was already acquired within dpkg_runbuild 
> but accesses to the isar-apt database were not protected from 
> do_deploy_deb. Move the lock from the buildchroot to the isar-apt 
> repository and acquire the (same) lock from dpkg_runbuild, repo_clean 
> and do_deploy_deb.
> 

Have you observed any issues with current implementation? IIRC reprepro has it's own built-in lock file.

Alex

> Cedric Hombourger (1):
>    dpkg: acquire lock when calling reprepro
> 
>   meta/classes/dpkg-base.bbclass                   | 8 ++++++--
>   meta/recipes-devtools/buildchroot/files/build.sh | 2 +-
>   meta/recipes-kernel/linux/files/build-kernel.sh  | 2 +-
>   3 files changed, 8 insertions(+), 4 deletions(-)
>