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

[Liu, ZhipengS]

Hi Scott,

For question #1,
When we built openstack ussuri image which is python3 only.
It needs python3-rbd and related dependency, so we add librados2-13.2.10 and related packages.
For local built librados2-13.2.2-0.el7.tis.25.x86_64.rpm, it is for python2.
Shouldn’t  we let the build choose local build first?
Another option is moving these packages to container layer, add rpms_centos.lst in config/centos/flock/?

Thanks!
Zhipeng

From: Scott Little <scott.little at windriver.com>
Sent: 2020年6月3日 15:57
To: starlingx-discuss at lists.starlingx.io
Subject: Re: [Starlingx-discuss] [build-report] STX_build_layer_flock_master_master - Build # 132 - Still Failing!

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<mailto: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<mailto: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/31b90c86/attachment-0001.html>