Re: [OE-core] [PATCH 01/15] rpm: upgrade to 4.15.1

["Richard Purdie" <richard.purdie@linuxfoundation.org>]

On Mon, 2020-04-27 at 14:24 +0200, Alexander Kanavin wrote:
> On Mon, 27 Apr 2020 at 12:08, Adrian Bunk <bunk@stusta.de> wrote:
> > > Yes, I thought of sending a patch that adds libgomp-dev to the
> > extended
> > > tarball, but... the mysterious problem is, in some cases, rpm-
> > native will
> > > compile on the same worker machines without any failure (and
> > maybe it then
> > > gets linked against 'wrong' gomp, hence failures)  - see links
> > above. I'd
> > > like to try to ssh in and see how this could happen.
> > 
> > Richard had a possible explanation for that:
> > 
> > On Sun, Apr 26, 2020 at 10:07:30PM +0100, Richard Purdie wrote:
> > > I think what may happen is that sstate may become populated and
> > then
> > > builds proceed further than they did previously.
> 
> I still don't understand this. In both cases, rpm-native is compiled
> (not taken from sstate). In one case, it fails due to missing omp.h,
> but in another, do_compile completes without error. How does sstate
> influence this?

Have you a pointer to a build where this succeeds and one where it
fails?

> I think the build should be run again, then particularly the build
> directory of debian/centos where rpm-native was able to complete
> should be preserved. I suspect it succeeds because,
> somehow, the old gcc from the host is used, which might be a serious
> issue :(
> 
> After that we can look into the (most likely different) issue of
> providing the header via buildtools-tarball.

The infrastructure doesn't make it very easy to do that unfortunately.
I can do it but it will involve shutting down all the cleanup
processes, stopping all other builds, monitoring and manually coercing
things back to the "right" state for you to look at. I can do that but
it will take me several hours.

Cheers,

Richard