[Starlingx-discuss] [Important] STX_build_pre_installer_layered - Build # 53 - Failure!
Scott Little
scott.little at windriver.com
Wed Feb 26 20:59:15 UTC 2020
The only way to make this work is to place the kernel and out-of-tree
kernel modules into a layer of their own.
Scott
On 2020-02-25 7:39 p.m., Hu, Yong wrote:
> Hi Scott,
> It's a fantastic sharing and thanks for comprehensive explanation!
>
> Inspired by the case here (with 2 versions of python-oslo-concurrency
> for different layers), I would like to hear your ideas on a similar
> case (a tech challenge) which we met during CentOS 8 upgrade. Simply
> we wanted to use new version gcc-8.2.1 for kernel 4.18, and then old
> version gcc-4.8.5 for user space packages.
> Is there a way to support this case above under the context of layered
> build design?
> We know currently kernel (and out of tree kernel modules) and a set
> user space packages belong to "disto" layer.
> But what if we create a new layer for kernel and kernel related
> modules? Will this make 2 different versions of GCC work for 2 layers?
>
> regards,
> Yong
> ------------------------------------------------------------------------
> *From:* Scott Little [scott.little at windriver.com]
> *Sent:* Wednesday, February 26, 2020 12:49 AM
> *To:* starlingx-discuss at lists.starlingx.io
> *Subject:* Re: [Starlingx-discuss] [Important]
> STX_build_pre_installer_layered - Build # 53 - Failure!
>
> *This was an interesting failure*
>
> An update to distributed cloud changed the minimum version of
> python-oslo-concurrency
>
> /cgcs-root/stx/distributedcloud/distributedcloud/centos/distributedcloud.spec:BuildRequires:
> python-oslo-concurrency>= 3.29.1
>
> A corresponding change was attempted in ...
>
> stx-tools/centos-mirror-tools/config/centos/distro/rpms_centos.lst
> -python2-oslo-concurrency-3.27.0-1.el7.noarch.rpm
> +python2-oslo-concurrency-3.29.1-1.el7.noarch.rpm
>
> but it was not made in ...
>
> stx-tools/centos-mirror-tools/config/centos/flock/rpms_centos.lst
> python2-oslo-concurrency-3.27.0-1.el7.noarch.rpm
>
> *The monolithic build was ok, but not the flock layer build failed.
> Why? *
>
> Distributed cloud builds under the flock layer. The flock layer build
> only uses flock layer lst file. So it needs 3.29.1, but only 3.27.0
> is available. Build fails.
>
> The monolithic build merges the lst files of all layers. We ended up
> with two copies of python2-oslo-concurrency, 3.27.0 and 3.29.1, and
> the highest version was used in the build. So all would seem ok if
> the designer tested with a monolithic build rather than a flock layer
> build.
>
> The monolithic build is going away.
>
> *Designers need to do layer builds to test their changes!*
>
>
> Other thoughts ...
>
> *Does **python2-oslo-concurrency need to be listed in two places?*
>
> Yes.
>
> There are distro layer components that BuildRequire
> python2-oslo-concurrency as well. A distro layer build would look at
> stx-tools/centos-mirror-tools/config/centos/distro/rpms_centos.lst
>
> *What if I only upversion the flock layer and not the distro layer?*
> *
> *
> While it would have passed build on all layers, I don't think it's a
> good idea. The iso is built from the flock layer, and will use the
> newer version. The distro layer packages would have run there tox
> tests versus an older version of the library than would be used at
> runtime. An error that might have been caught by a unit test will now
> only be caught at runtime.
>
> All lst files should agree on the version to use.
>
> *What if the need to upversion was being driven by a distro layer
> package? Would I still need to upversion the flock layer lst file in
> addition to the distro layer lst?*
>
> Yes.
>
> A package with a 'BuildRequire' on a newer version will also usually
> have a 'Require' on the newer version as well. Updating the distro
> layer lst will allow the distro layer build-pkgs to succeed. However,
> build-iso runs under the flock layer, only uses the flock layer lst.
> Omitting the flock layer lst update will fail on the 'Require' when
> build-iso is run.
>
>
>
>
>
>
>
>
> On 2020-02-24 2:35 p.m., build.starlingx at gmail.com wrote:
>> Project: STX_build_pre_installer_layered
>> Build #: 53
>> Status: Failure
>> Timestamp: 20200224T192300Z
>>
>> Check logs at:
>> http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200224T185245Z/logs
>> --------------------------------------------------------------------------------
>> Parameters
>>
>> MY_WORKSPACE: /localdisk/loadbuild/jenkins/master-flock/20200224T185245Z
>> DOCKER_BUILD_ID: jenkins-master-flock-20200224T185245Z-builder
>> OS: centos
>> MY_REPO: /localdisk/designer/jenkins/master-flock/cgcs-root
>> PUBLISH_LOGS_URL:http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200224T185245Z/logs
>> PUBLISH_LOGS_BASE: /export/mirror/starlingx/master/centos/flock/20200224T185245Z/logs
>> MASTER_JOB_NAME: STX_build_layer_flock_master_master
>> LAYER: flock
>> MY_REPO_ROOT: /localdisk/designer/jenkins/master-flock
>> BUILD_ISO: true
>>
>> _______________________________________________
>> 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/20200226/5bdffa46/attachment.html>
More information about the Starlingx-discuss
mailing list