[Starlingx-discuss] [build-report] STX_build_layer_flock_master_master - Build # 132 - Still Failing!

Scott Little scott.little at windriver.com
Wed Jun 3 07:56:47 UTC 2020


This was an interesting one.

We have been building librados2-13.2.2-0.el7.tis.25.x86_64.rpm as part 
of the distro layer for some time.

A recent update added librados2-13.2.10-0.el7.x86_64.rpm to the lst of 
the flock layer.

Now build-iso preferres locally built packages over downloaded ones, 
even if the downloaded on is of higher version.  Now that policy is open 
for debate, but that is what it does.

Monolithic build uses the lst files of all layers, but having built 
librados2-13.2.2-0.el7.tis.25.x86_64.rpm, it selects 
librados2-13.2.2-0.el7.tis.25.x86_64.rpm over 
librados2-13.2.10-0.el7.x86_64.rpm when building the iso.

Flock layer build, downloads librados2-13.2.2-0.el7.tis.25.x86_64.rpm 
from the distro layer build.  It doesn't build it itself.  The downloads 
from the two sources are lumped into a common repo, so it has no reason 
to prefer the lower versioned rpm.  It selects 
librados2-13.2.10-0.el7.x86_64.rpm.

The final piece of the puzzle is the transitive list of requires for 
librados2-13.2.10-0.el7.x86_64.rpm.  It has a new dependency that pulls 
in lttng-ust-2.10.0-1.el7.x86_64.rpm, which in turn needs 
userspace-rcu-0.10.0-3.el7.x86_64.rpm, which is not present.  It's 
wasn't included in the recent lst file changes that added 
librados2-13.2.10-0.el7.x86_64.rpm.

A flock layer build-iso should have caught this.  I suspect build-iso 
was only performed on a monolithic build.

Open questions.
1) Is there a need to move to librados2-13.2.10 from librados2-13.2.2.  
If yes, do we still need whatever modifications were applied to 
librados2-13.2.2?  Do they need to be ported to librados2-13.2.10 , or 
can we drop librados2 from the set of packages we have patches against?

2) For build-iso... should we prefer locally built packages even though 
there is a higher package named in an lst?  If yes, then layered build 
needs apply the local first policy accross layers. Alternatively, 
perhaps drop the local first policy, but add an audit tool to detect 
when a locally built package is being masked in this way.

Scott


On 2020-06-02 10:30 p.m., build.starlingx at gmail.com wrote:
> Project: STX_build_layer_flock_master_master
> Build #: 132
> Status: Still Failing
> Timestamp: 20200603T020359Z
>
> Check logs at:
> http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200603T020359Z/logs
> --------------------------------------------------------------------------------
> Parameters
>
> FULL_BUILD: false
> FORCE_BUILD: false
>
> _______________________________________________
> Starlingx-discuss mailing list
> Starlingx-discuss at lists.starlingx.io
> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20200603/227a4f1f/attachment.html>


More information about the Starlingx-discuss mailing list