[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