Fail to build python-html5lib and python-webencodings

[Al Bailey]

Brief Description
-----------------
Build break.
The syntax of the centos_tarball-dl.lst does not work with the spec file macros
https://opendev.org/starlingx/integ/commit/fdaa4c4a9dd03d705c47f6ecc7069b10fe9be9f8

Either need to change the spec files or the lst file syntax

Severity
--------
Critical

Steps to Reproduce
------------------
Pull the code March 4th 2020 sometime around noon EST and attempt to build

Expected Behavior
------------------
Build should succeed

Actual Behavior
----------------
Build fails on 2 packages

Reproducibility
---------------
100%

System Configuration
--------------------
N/A

Branch/Pull Time/Commit
-----------------------
March 4, 2020 at around noon

Last Pass
---------
The previous day. This is due to a commit that went in.

Timestamp/Logs
--------------

15:57:37 *** Build Failed ***
15:57:37 Tried 3 times - following pkgs could not be successfully built:
15:57:37 *** Build Failed ***
15:57:37 /localdisk/loadbuild/jcasteli/starlingx-jan9/std/rpmbuild/SRPMS/python-webencodings-0.5.1-1.el7.tis.0.src.rpm
15:57:37 /localdisk/loadbuild/jcasteli/starlingx-jan9/std/rpmbuild/SRPMS/html5lib-python-1.0.1-1.el7.tis.0.src.rpm
15:57:37

Test Activity
-------------
Development

 Workaround
 ----------
None, other than changing the code. I have a fix coming.

[Ghada Khalil (gkhalil)]

stx.4.0 / critical - newly merged code is causing a build failure

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/711356
Committed: https://git.openstack.org/cgit/starlingx/integ/commit/?id=eeaaaf5796f3a028b9712065d01f249fd20f2e02
Submitter: Zuul
Branch: master

commit eeaaaf5796f3a028b9712065d01f249fd20f2e02
Author: albailey <email address hidden>
Date: Wed Mar 4 17:02:35 2020 -0600

    Fix build break for python-html5lib and python-webencodings

    The lst files which stage the downloaded tarballs were altering the
    internal directory structure during the mirror download phase, which
    meant the %setup commands in the spec files were failing.

    This change adapts the spec files to the files downloaded from
    the mirror.

    Change-Id: I8031c8af0f424a8e19bee062a4df6ddf3383f38d
    Closes-Bug: 1866133
    Signed-off-by: albailey <email address hidden>

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: f/centos8
Review: https://review.opendev.org/712610

[OpenStack Infra (hudson-openstack)]

Change abandoned by Lin Shuicheng (<email address hidden>) on branch: f/centos8
Review: https://review.opendev.org/712610

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: f/centos8
Review: https://review.opendev.org/716162

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/716162
Committed: https://git.openstack.org/cgit/starlingx/integ/commit/?id=246f33226dbb50a4c5e86d497df745120ca9e0e4
Submitter: Zuul
Branch: f/centos8

commit a745a5b6f8a02b74f69f828f14960e97a758853c
Author: Jim Somerville <email address hidden>
Date: Fri Mar 20 10:36:14 2020 -0400

    Kernel: Workaround broken bios affecting iommu

    Problem:
    Broken bios creates inaccurate DMAR tables,
    reporting some bridges as having endpoint types.
    This causes IOMMU initialization to bail
    out early with an error code, the result of
    which is vfio not working correctly.
    This is seen on some Skylake based Wolfpass
    server platforms with up-to-date bios installed.

    Solution:
    Instead of just bailing out of IOMMU
    initialization when such a condition is found,
    we report it and continue. The IOMMU ends
    up successfully initialized anyway. We do this
    only on platforms that have the Skylake bridges
    where this issue has been seen.

    This change is inspired by a similar one posted by
    Lu Baolu of Intel Corp to lkml

    https://lkml.org/lkml/2019/12/24/15

    Change-Id: Ief2df7099b6118eab7f99d5531616926a7a3eb27
    Closes-Bug: 1847335
    Signed-off-by: Jim Somerville <email address hidden>

commit 1435fe178ab88aa2b77970a3c07e8a907477a654
Author: Jim Somerville <email address hidden>
Date: Mon Mar 16 16:16:20 2020 -0400

    Build mpt2sas and mpt3sas drivers as modules

    History:
    Back in the day, we didn't have an initramfs
    to allow us to load disk drivers as modules. All
    disk drivers had to be built-in. In CentOS 7.3,
    the mpt2sas and mpt3sas driver code was reorganized
    to allow for a common code base. But along with that,
    those drivers would only now build as modules. We
    created a patch which involved taking a snapshot of
    mpt driver code, and massaged it all into building
    as built-in drivers.

    Problem:
    That old code snapshot along with the fact
    that those two drivers initialize without their
    associated hardware being present (they are built-in),
    seems to cause interference with some other LSI raid
    controllers, namely Harpoon in AVAGO MR9460-8i via a
    Huawei enclosure.

    Solution:
    Simply revert to building those two mptsas drivers as
    modules, the way CentOS intended. They will reside
    on initramfs and be loaded automatically if the
    appropriate hardware is present. With these drivers now
    out of the way, the problematic raid controller works
    fine, driven by the megaraid_sas driver.

    Change-Id: I054c2396df4e659c324e70bffcf3940ad93c9354
    Closes-Bug: 1866293
    Signed-off-by: Jim Somerville <email address hidden>

commit bed7388b678b9eda0d06b4d16fb00711741f9ef0
Author: Paul Vaduva <email address hidden>
Date: Tue Mar 10 12:05:31 2020 -0400

    Release FDs when stuck peering recovery

    During stuck peering recovery if file descriptors are
    not released the state machine does not advance to
    OPERATIONAL state

    Partial-bug: 1856064

    Change-Id: I3fba7be661ebf22...