Re: [PATCH v2] dpkg: acquire a read (shared) locks while building packages

[cedric_hombourger@mentor.com]

[-- Attachment #1.1: Type: text/plain, Size: 3024 bytes --]

observed another failure in our CI environment because of this missing lock
any objections to getting this applied to next given that it was acked by 
Jan?

On Friday, March 8, 2019 at 5:38:09 PM UTC+1, Jan Kiszka wrote:
>
> On 08.03.19 16:49, Cedric Hombourger wrote: 
> > As debhelper scripts involved during the actual build process 
> > (dpkg-buildpackage) may access the dpkg database, we need to 
> > make sure it does not get modified in the background by other 
> > build tasks for other packages (such as install_build_deps). 
> > An example of a reader is dh_shlibdeps/dpkg-shlibdeps: it 
> > needs to find packages providing the shared libraries the 
> > package depends on to substitute shlibs variables found in its 
> > control file with package dependencies. Acquire the isar-apt 
> > lock as a shared lock to block writers. 
> > 
> > Special care may be needed in other classes/users of the 
> > dpkg_runbuild API. Due to some limitations with bitbake (to be 
> > discussed with the maintainers), we could not grab the lock 
> > from dpkg-base. A statement such as "flock <my-lock.lock> 
> > dpkg_run_build" would fail as flock can't exec() dpkg_run_build 
> > (since it is a shell function, not an executable). The popular 
> > shell construct "( flock -n 9; dpkg_run_build ) 9> <my-lock.lock>" 
> > cannot be parsed by bitbake. And finally the lockfiles task 
> > attribute (implemented in bitbake) only handles exclusive locks. 
> > 
> > This commit is only addressing dpkg.bbclass. dpkg-raw.bbclass 
> > is left intact as the generated control file does require 
>
> ( Actually, dpkg-raw just uses dpkg these days, so no work to be done 
> anyway. ) 
>
> > dh_shlibdeps. linux-custom.inc was also left out as the Debian 
> > packaging scripts only use low-level packaging tools and do not 
> > use debhelper scripts during packaging (at this time). In 
> > agreement with the Isar project maintainers, we will not grab 
> > the Isar lock from linux-custom.inc to let kernel builds run 
> > in parallel with do_install_deps() and do_deploy_deb() that 
> > may be executed by other bitbake threads. 
> > 
> > Signed-off-by: Cedric Hombourger <Cedric_H...@mentor.com <javascript:>> 
> > --- 
> >   meta/classes/dpkg.bbclass | 1 + 
> >   1 file changed, 1 insertion(+) 
> > 
> > diff --git a/meta/classes/dpkg.bbclass b/meta/classes/dpkg.bbclass 
> > index 24b9fe3..f4e3d7a 100644 
> > --- a/meta/classes/dpkg.bbclass 
> > +++ b/meta/classes/dpkg.bbclass 
> > @@ -19,5 +19,6 @@ do_install_builddeps[stamp-extra-info] = 
> "${DISTRO}-${DISTRO_ARCH}" 
> >   # Build package from sources using build script 
> >   dpkg_runbuild() { 
> >       E="${@ bb.utils.export_proxies(d)}" 
> > +    flock -s "${REPO_ISAR_DIR}/isar.lock" \ 
> >       sudo -E chroot --userspec=$( id -u ):$( id -g ) ${BUILDCHROOT_DIR} 
> /isar/build.sh ${PP}/${PPS} ${DISTRO_ARCH} 
> >   } 
> > 
>
> Looks good to me. 
>
> Jan 
>
> -- 
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE 
> Corporate Competence Center Embedded Linux 
>

[-- Attachment #1.2: Type: text/html, Size: 3737 bytes --]