Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
10.2(EOL), 10.3(EOL), 10.4(EOL)
Description
Currently for RHEL8-like systems RPMs are built with the explicit -DWITH_JEMALLOC=no option.
cmake . -DBUILD_CONFIG=mysql_release -DCMAKE_COMMAND_DEP=cmake -DRPM=rocky84 -DWITH_JEMALLOC=no
|
It was added to the buildbot config by this commit
commit 57e294e278c59573dd01d72cff4e7db175d35ea1
|
Author: Sergei Golubchik
|
Date: Wed Aug 25 22:41:29 2021 +0200
|
|
|
buildbot: centos8/rhel8 don't have jemalloc
|
Technically it is true, jemalloc is not provided by default repos on RHEL8 and alike, although it can be fetched from the EPEL repo. However, it is not important for this ticket.
Thus the packages are built without jemalloc dependency.
But the spec file in the resulting source rpm doesn't have this option, it contains the cmake command as
'/usr/bin/cmake' -DRPM=rocky84 -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_CONFIG=mysql_release -DWITH_SSL=system -DCPACK_PACKAGING_INSTALL_PREFIX=/ ../mariadb-10.4.23
|
So, when we build from srpm on RHEL8-s, there is no jemalloc in BuildRequires, and it doesn't attempt to install jemalloc along with its dependencies, regardless whether we enable EPEL or not; but when it comes to compiling, it fails because TokuDB wants jemalloc and cannot find it.
CMake Error at cmake/jemalloc.cmake:38 (MESSAGE):
|
jemalloc is not found
|
Call Stack (most recent call first):
|
storage/tokudb/CMakeLists.txt:53 (CHECK_JEMALLOC)
|
It can be circumvented by installing jemalloc[-devel] from EPEL manually before building from srpm. But then, the srpm test in buildbot fails at the end, because it compares requirements of the rebuilt packages with the original ones and finds the extra jemalloc in the new ones.
+ diff -u requires-rebuilt.txt requires-vendor.txt
|
--- requires-rebuilt.txt 2021-12-26 05:03:30.100166826 +0000
|
+++ requires-vendor.txt 2021-12-26 05:03:29.665166847 +0000
|
@@ -16,7 +16,6 @@
|
gawk
|
grep
|
iproute
|
-jemalloc
|
ld-linux-x86-64.so.2
|
libaio.so.1
|
libcom_err.so.2
|
I don't suppose there is any point in installing jemalloc now on build machines and getting rid of WITH_JEMALLOC=NO, it would only add an extra dependency to old maintenance versions without any gain. So, the choice is between suppressing the test failure above, or making srpms inherit build options from the original build. Patching the test is easy, but building from srpms the same way as the original packages were built (if possible and unless it contradicts some normal practices) sounds like a more valid approach.
Attachments
Activity
| Field | Original Value | New Value |
|---|---|---|
| Assignee | Sergei Golubchik [ serg ] |
| Description |
Currently for RHEL8-like systems RPMs are built with the explicit {{-DWITH_JEMALLOC=no}} option.
It was added to the buildbot config by this commit {noformat} commit 57e294e278c59573dd01d72cff4e7db175d35ea1 Author: Sergei Golubchik Date: Wed Aug 25 22:41:29 2021 +0200 buildbot: centos8/rhel8 don't have jemalloc {noformat} _Technically it is true, jemalloc is not provided by default repos on RHEL8 and alike, although it can be fetched from the EPEL repo. However, it is not important for this ticket._ Thus the packages are built without jemalloc dependency. However, the spec file in the resulting source rpm doesn't have this option, it contains the cmake command as {noformat} '/usr/bin/cmake' -DRPM=rocky84 -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_CONFIG=mysql_release -DWITH_SSL=system -DCPACK_PACKAGING_INSTALL_PREFIX=/ ../mariadb-10.4.23 {noformat} So, when we build from srpm on RHEL8-s, it doesn't attempt to install jemalloc along with srpm dependencies, regardless whether we make it available via EPEL or not (there is no jemalloc in BuildRequires), but when it comes to compiling, it fails because TokuDB wants jemalloc and cannot find it. It can be circumvented by installing jemalloc[-devel] from EPEL manually before building from srpm. But then, the srpm test in buildbot fails at the end, because it compares requirements of the rebuilt packages with the original ones and finds the extra jemalloc in the new ones. {noformat} + diff -u requires-rebuilt.txt requires-vendor.txt --- requires-rebuilt.txt 2021-12-26 05:03:30.100166826 +0000 +++ requires-vendor.txt 2021-12-26 05:03:29.665166847 +0000 @@ -16,7 +16,6 @@ gawk grep iproute -jemalloc ld-linux-x86-64.so.2 libaio.so.1 libcom_err.so.2 {noformat} I don't suppose there is any point in installing jemalloc now on build machines and getting rid of {{WITH_JEMALLOC=NO}}, it would only add an extra dependency to old maintenance versions without any gain. So, the choice is between suppressing the test failure above, or making srpms inherit build options from the original build. Patching the test is easy, but building from srpms the same way as the original packages were built (if possible and unless it contradicts some normal practices) sounds like a more valid approach. |
Currently for RHEL8-like systems RPMs are built with the explicit {{-DWITH_JEMALLOC=no}} option.
{noformat} cmake . -DBUILD_CONFIG=mysql_release -DCMAKE_COMMAND_DEP=cmake -DRPM=rocky84 -DWITH_JEMALLOC=no {noformat} It was added to the buildbot config by this commit {noformat} commit 57e294e278c59573dd01d72cff4e7db175d35ea1 Author: Sergei Golubchik Date: Wed Aug 25 22:41:29 2021 +0200 buildbot: centos8/rhel8 don't have jemalloc {noformat} _Technically it is true, jemalloc is not provided by default repos on RHEL8 and alike, although it can be fetched from the EPEL repo. However, it is not important for this ticket._ Thus the packages are built without jemalloc dependency. However, the spec file in the resulting source rpm doesn't have this option, it contains the cmake command as {noformat} '/usr/bin/cmake' -DRPM=rocky84 -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_CONFIG=mysql_release -DWITH_SSL=system -DCPACK_PACKAGING_INSTALL_PREFIX=/ ../mariadb-10.4.23 {noformat} So, when we build from srpm on RHEL8-s, it doesn't attempt to install jemalloc along with srpm dependencies, regardless whether we make it available via EPEL or not (there is no jemalloc in BuildRequires), but when it comes to compiling, it fails because TokuDB wants jemalloc and cannot find it. It can be circumvented by installing jemalloc[-devel] from EPEL manually before building from srpm. But then, the srpm test in buildbot fails at the end, because it compares requirements of the rebuilt packages with the original ones and finds the extra jemalloc in the new ones. {noformat} + diff -u requires-rebuilt.txt requires-vendor.txt --- requires-rebuilt.txt 2021-12-26 05:03:30.100166826 +0000 +++ requires-vendor.txt 2021-12-26 05:03:29.665166847 +0000 @@ -16,7 +16,6 @@ gawk grep iproute -jemalloc ld-linux-x86-64.so.2 libaio.so.1 libcom_err.so.2 {noformat} I don't suppose there is any point in installing jemalloc now on build machines and getting rid of {{WITH_JEMALLOC=NO}}, it would only add an extra dependency to old maintenance versions without any gain. So, the choice is between suppressing the test failure above, or making srpms inherit build options from the original build. Patching the test is easy, but building from srpms the same way as the original packages were built (if possible and unless it contradicts some normal practices) sounds like a more valid approach. |
| Labels | affects-tests |
| Labels | affects-tests | affects-tests not-10.5 not-10.6 not-10.7 |
| Description |
Currently for RHEL8-like systems RPMs are built with the explicit {{-DWITH_JEMALLOC=no}} option.
{noformat} cmake . -DBUILD_CONFIG=mysql_release -DCMAKE_COMMAND_DEP=cmake -DRPM=rocky84 -DWITH_JEMALLOC=no {noformat} It was added to the buildbot config by this commit {noformat} commit 57e294e278c59573dd01d72cff4e7db175d35ea1 Author: Sergei Golubchik Date: Wed Aug 25 22:41:29 2021 +0200 buildbot: centos8/rhel8 don't have jemalloc {noformat} _Technically it is true, jemalloc is not provided by default repos on RHEL8 and alike, although it can be fetched from the EPEL repo. However, it is not important for this ticket._ Thus the packages are built without jemalloc dependency. However, the spec file in the resulting source rpm doesn't have this option, it contains the cmake command as {noformat} '/usr/bin/cmake' -DRPM=rocky84 -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_CONFIG=mysql_release -DWITH_SSL=system -DCPACK_PACKAGING_INSTALL_PREFIX=/ ../mariadb-10.4.23 {noformat} So, when we build from srpm on RHEL8-s, it doesn't attempt to install jemalloc along with srpm dependencies, regardless whether we make it available via EPEL or not (there is no jemalloc in BuildRequires), but when it comes to compiling, it fails because TokuDB wants jemalloc and cannot find it. It can be circumvented by installing jemalloc[-devel] from EPEL manually before building from srpm. But then, the srpm test in buildbot fails at the end, because it compares requirements of the rebuilt packages with the original ones and finds the extra jemalloc in the new ones. {noformat} + diff -u requires-rebuilt.txt requires-vendor.txt --- requires-rebuilt.txt 2021-12-26 05:03:30.100166826 +0000 +++ requires-vendor.txt 2021-12-26 05:03:29.665166847 +0000 @@ -16,7 +16,6 @@ gawk grep iproute -jemalloc ld-linux-x86-64.so.2 libaio.so.1 libcom_err.so.2 {noformat} I don't suppose there is any point in installing jemalloc now on build machines and getting rid of {{WITH_JEMALLOC=NO}}, it would only add an extra dependency to old maintenance versions without any gain. So, the choice is between suppressing the test failure above, or making srpms inherit build options from the original build. Patching the test is easy, but building from srpms the same way as the original packages were built (if possible and unless it contradicts some normal practices) sounds like a more valid approach. |
Currently for RHEL8-like systems RPMs are built with the explicit {{-DWITH_JEMALLOC=no}} option.
{noformat} cmake . -DBUILD_CONFIG=mysql_release -DCMAKE_COMMAND_DEP=cmake -DRPM=rocky84 -DWITH_JEMALLOC=no {noformat} It was added to the buildbot config by this commit {noformat} commit 57e294e278c59573dd01d72cff4e7db175d35ea1 Author: Sergei Golubchik Date: Wed Aug 25 22:41:29 2021 +0200 buildbot: centos8/rhel8 don't have jemalloc {noformat} _Technically it is true, jemalloc is not provided by default repos on RHEL8 and alike, although it can be fetched from the EPEL repo. However, it is not important for this ticket._ Thus the packages are built without jemalloc dependency. But the spec file in the resulting source rpm doesn't have this option, it contains the cmake command as {noformat} '/usr/bin/cmake' -DRPM=rocky84 -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_CONFIG=mysql_release -DWITH_SSL=system -DCPACK_PACKAGING_INSTALL_PREFIX=/ ../mariadb-10.4.23 {noformat} So, when we build from srpm on RHEL8-s, there is no jemalloc in BuildRequires, and it doesn't attempt to install jemalloc along with srpm dependencies, regardless whether we make it available via EPEL or not, but when it comes to compiling, it fails because TokuDB wants jemalloc and cannot find it. It can be circumvented by installing jemalloc[-devel] from EPEL manually before building from srpm. But then, the srpm test in buildbot fails at the end, because it compares requirements of the rebuilt packages with the original ones and finds the extra jemalloc in the new ones. {noformat} + diff -u requires-rebuilt.txt requires-vendor.txt --- requires-rebuilt.txt 2021-12-26 05:03:30.100166826 +0000 +++ requires-vendor.txt 2021-12-26 05:03:29.665166847 +0000 @@ -16,7 +16,6 @@ gawk grep iproute -jemalloc ld-linux-x86-64.so.2 libaio.so.1 libcom_err.so.2 {noformat} I don't suppose there is any point in installing jemalloc now on build machines and getting rid of {{WITH_JEMALLOC=NO}}, it would only add an extra dependency to old maintenance versions without any gain. So, the choice is between suppressing the test failure above, or making srpms inherit build options from the original build. Patching the test is easy, but building from srpms the same way as the original packages were built (if possible and unless it contradicts some normal practices) sounds like a more valid approach. |
| Description |
Currently for RHEL8-like systems RPMs are built with the explicit {{-DWITH_JEMALLOC=no}} option.
{noformat} cmake . -DBUILD_CONFIG=mysql_release -DCMAKE_COMMAND_DEP=cmake -DRPM=rocky84 -DWITH_JEMALLOC=no {noformat} It was added to the buildbot config by this commit {noformat} commit 57e294e278c59573dd01d72cff4e7db175d35ea1 Author: Sergei Golubchik Date: Wed Aug 25 22:41:29 2021 +0200 buildbot: centos8/rhel8 don't have jemalloc {noformat} _Technically it is true, jemalloc is not provided by default repos on RHEL8 and alike, although it can be fetched from the EPEL repo. However, it is not important for this ticket._ Thus the packages are built without jemalloc dependency. But the spec file in the resulting source rpm doesn't have this option, it contains the cmake command as {noformat} '/usr/bin/cmake' -DRPM=rocky84 -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_CONFIG=mysql_release -DWITH_SSL=system -DCPACK_PACKAGING_INSTALL_PREFIX=/ ../mariadb-10.4.23 {noformat} So, when we build from srpm on RHEL8-s, there is no jemalloc in BuildRequires, and it doesn't attempt to install jemalloc along with srpm dependencies, regardless whether we make it available via EPEL or not, but when it comes to compiling, it fails because TokuDB wants jemalloc and cannot find it. It can be circumvented by installing jemalloc[-devel] from EPEL manually before building from srpm. But then, the srpm test in buildbot fails at the end, because it compares requirements of the rebuilt packages with the original ones and finds the extra jemalloc in the new ones. {noformat} + diff -u requires-rebuilt.txt requires-vendor.txt --- requires-rebuilt.txt 2021-12-26 05:03:30.100166826 +0000 +++ requires-vendor.txt 2021-12-26 05:03:29.665166847 +0000 @@ -16,7 +16,6 @@ gawk grep iproute -jemalloc ld-linux-x86-64.so.2 libaio.so.1 libcom_err.so.2 {noformat} I don't suppose there is any point in installing jemalloc now on build machines and getting rid of {{WITH_JEMALLOC=NO}}, it would only add an extra dependency to old maintenance versions without any gain. So, the choice is between suppressing the test failure above, or making srpms inherit build options from the original build. Patching the test is easy, but building from srpms the same way as the original packages were built (if possible and unless it contradicts some normal practices) sounds like a more valid approach. |
Currently for RHEL8-like systems RPMs are built with the explicit {{-DWITH_JEMALLOC=no}} option.
{noformat} cmake . -DBUILD_CONFIG=mysql_release -DCMAKE_COMMAND_DEP=cmake -DRPM=rocky84 -DWITH_JEMALLOC=no {noformat} It was added to the buildbot config by this commit {noformat} commit 57e294e278c59573dd01d72cff4e7db175d35ea1 Author: Sergei Golubchik Date: Wed Aug 25 22:41:29 2021 +0200 buildbot: centos8/rhel8 don't have jemalloc {noformat} _Technically it is true, jemalloc is not provided by default repos on RHEL8 and alike, although it can be fetched from the EPEL repo. However, it is not important for this ticket._ Thus the packages are built without jemalloc dependency. But the spec file in the resulting source rpm doesn't have this option, it contains the cmake command as {noformat} '/usr/bin/cmake' -DRPM=rocky84 -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_CONFIG=mysql_release -DWITH_SSL=system -DCPACK_PACKAGING_INSTALL_PREFIX=/ ../mariadb-10.4.23 {noformat} So, when we build from srpm on RHEL8-s, there is no jemalloc in BuildRequires, and it doesn't attempt to install jemalloc along with its dependencies, regardless whether we enable EPEL or not; but when it comes to compiling, it fails because TokuDB wants jemalloc and cannot find it. It can be circumvented by installing jemalloc[-devel] from EPEL manually before building from srpm. But then, the srpm test in buildbot fails at the end, because it compares requirements of the rebuilt packages with the original ones and finds the extra jemalloc in the new ones. {noformat} + diff -u requires-rebuilt.txt requires-vendor.txt --- requires-rebuilt.txt 2021-12-26 05:03:30.100166826 +0000 +++ requires-vendor.txt 2021-12-26 05:03:29.665166847 +0000 @@ -16,7 +16,6 @@ gawk grep iproute -jemalloc ld-linux-x86-64.so.2 libaio.so.1 libcom_err.so.2 {noformat} I don't suppose there is any point in installing jemalloc now on build machines and getting rid of {{WITH_JEMALLOC=NO}}, it would only add an extra dependency to old maintenance versions without any gain. So, the choice is between suppressing the test failure above, or making srpms inherit build options from the original build. Patching the test is easy, but building from srpms the same way as the original packages were built (if possible and unless it contradicts some normal practices) sounds like a more valid approach. |
| Description |
Currently for RHEL8-like systems RPMs are built with the explicit {{-DWITH_JEMALLOC=no}} option.
{noformat} cmake . -DBUILD_CONFIG=mysql_release -DCMAKE_COMMAND_DEP=cmake -DRPM=rocky84 -DWITH_JEMALLOC=no {noformat} It was added to the buildbot config by this commit {noformat} commit 57e294e278c59573dd01d72cff4e7db175d35ea1 Author: Sergei Golubchik Date: Wed Aug 25 22:41:29 2021 +0200 buildbot: centos8/rhel8 don't have jemalloc {noformat} _Technically it is true, jemalloc is not provided by default repos on RHEL8 and alike, although it can be fetched from the EPEL repo. However, it is not important for this ticket._ Thus the packages are built without jemalloc dependency. But the spec file in the resulting source rpm doesn't have this option, it contains the cmake command as {noformat} '/usr/bin/cmake' -DRPM=rocky84 -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_CONFIG=mysql_release -DWITH_SSL=system -DCPACK_PACKAGING_INSTALL_PREFIX=/ ../mariadb-10.4.23 {noformat} So, when we build from srpm on RHEL8-s, there is no jemalloc in BuildRequires, and it doesn't attempt to install jemalloc along with its dependencies, regardless whether we enable EPEL or not; but when it comes to compiling, it fails because TokuDB wants jemalloc and cannot find it. It can be circumvented by installing jemalloc[-devel] from EPEL manually before building from srpm. But then, the srpm test in buildbot fails at the end, because it compares requirements of the rebuilt packages with the original ones and finds the extra jemalloc in the new ones. {noformat} + diff -u requires-rebuilt.txt requires-vendor.txt --- requires-rebuilt.txt 2021-12-26 05:03:30.100166826 +0000 +++ requires-vendor.txt 2021-12-26 05:03:29.665166847 +0000 @@ -16,7 +16,6 @@ gawk grep iproute -jemalloc ld-linux-x86-64.so.2 libaio.so.1 libcom_err.so.2 {noformat} I don't suppose there is any point in installing jemalloc now on build machines and getting rid of {{WITH_JEMALLOC=NO}}, it would only add an extra dependency to old maintenance versions without any gain. So, the choice is between suppressing the test failure above, or making srpms inherit build options from the original build. Patching the test is easy, but building from srpms the same way as the original packages were built (if possible and unless it contradicts some normal practices) sounds like a more valid approach. |
Currently for RHEL8-like systems RPMs are built with the explicit {{-DWITH_JEMALLOC=no}} option.
{noformat} cmake . -DBUILD_CONFIG=mysql_release -DCMAKE_COMMAND_DEP=cmake -DRPM=rocky84 -DWITH_JEMALLOC=no {noformat} It was added to the buildbot config by this commit {noformat} commit 57e294e278c59573dd01d72cff4e7db175d35ea1 Author: Sergei Golubchik Date: Wed Aug 25 22:41:29 2021 +0200 buildbot: centos8/rhel8 don't have jemalloc {noformat} _Technically it is true, jemalloc is not provided by default repos on RHEL8 and alike, although it can be fetched from the EPEL repo. However, it is not important for this ticket._ Thus the packages are built without jemalloc dependency. But the spec file in the resulting source rpm doesn't have this option, it contains the cmake command as {noformat} '/usr/bin/cmake' -DRPM=rocky84 -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_CONFIG=mysql_release -DWITH_SSL=system -DCPACK_PACKAGING_INSTALL_PREFIX=/ ../mariadb-10.4.23 {noformat} So, when we build from srpm on RHEL8-s, there is no jemalloc in BuildRequires, and it doesn't attempt to install jemalloc along with its dependencies, regardless whether we enable EPEL or not; but when it comes to compiling, it fails because TokuDB wants jemalloc and cannot find it. {noformat} CMake Error at cmake/jemalloc.cmake:38 (MESSAGE): jemalloc is not found Call Stack (most recent call first): storage/tokudb/CMakeLists.txt:53 (CHECK_JEMALLOC) {noformat} It can be circumvented by installing jemalloc[-devel] from EPEL manually before building from srpm. But then, the srpm test in buildbot fails at the end, because it compares requirements of the rebuilt packages with the original ones and finds the extra jemalloc in the new ones. {noformat} + diff -u requires-rebuilt.txt requires-vendor.txt --- requires-rebuilt.txt 2021-12-26 05:03:30.100166826 +0000 +++ requires-vendor.txt 2021-12-26 05:03:29.665166847 +0000 @@ -16,7 +16,6 @@ gawk grep iproute -jemalloc ld-linux-x86-64.so.2 libaio.so.1 libcom_err.so.2 {noformat} I don't suppose there is any point in installing jemalloc now on build machines and getting rid of {{WITH_JEMALLOC=NO}}, it would only add an extra dependency to old maintenance versions without any gain. So, the choice is between suppressing the test failure above, or making srpms inherit build options from the original build. Patching the test is easy, but building from srpms the same way as the original packages were built (if possible and unless it contradicts some normal practices) sounds like a more valid approach. |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Status | In Progress [ 3 ] | Stalled [ 10000 ] |
| Fix Version/s | 10.2.42 [ 26803 ] | |
| Fix Version/s | 10.3.33 [ 26805 ] | |
| Fix Version/s | 10.4.23 [ 26807 ] | |
| Fix Version/s | 10.2 [ 14601 ] | |
| Fix Version/s | 10.3 [ 22126 ] | |
| Fix Version/s | 10.4 [ 22408 ] | |
| Resolution | Fixed [ 1 ] | |
| Status | Stalled [ 10000 ] | Closed [ 6 ] |
While looking into it, I added this to the buildbot config:
diff --git a/buildbot/maria-master.cfg b/buildbot/maria-master.cfgindex 4c2b914..41438db 100644--- a/buildbot/maria-master.cfg+++ b/buildbot/maria-master.cfg@@ -1746,6 +1746,10 @@ elif command -v dnf > /dev/null; thenelsesudo dnf config-manager --enable PowerTools || truefi+ if [[ "%(branch)s" =~ 10.[234] ]] && ! rpm -qa | grep jemalloc ; then+ sudo dnf -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm || true+ sudo dnf -y install jemalloc jemalloc-devel || true+ fisudo dnf module -y enable mariadb-devel || truesudo dnf --setopt=install_weak_deps=False install -y rpm-build perl-generatorssudo dnf --setopt=install_weak_deps=False builddep -y srpms/*.src.rpmBut since the test fails anyway, just much later with requirements diff, there is no point in wasting time on it, so I have commented the change for now:
diff --git a/buildbot/maria-master.cfg b/buildbot/maria-master.cfgindex 4c2b914..669b2a9 100644--- a/buildbot/maria-master.cfg+++ b/buildbot/maria-master.cfg@@ -1746,6 +1746,12 @@ elif command -v dnf > /dev/null; thenelsesudo dnf config-manager --enable PowerTools || truefi+ ## See MDEV-27364 (jemalloc discrepancy)+ ## Let's keep it here but commented until the decision is made what to do about it+ # if [[ "%(branch)s" =~ 10.[234] ]] && ! rpm -qa | grep jemalloc ; then+ # sudo dnf -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm || true+ # sudo dnf -y install jemalloc jemalloc-devel || true+ # fisudo dnf module -y enable mariadb-devel || truesudo dnf --setopt=install_weak_deps=False install -y rpm-build perl-generatorssudo dnf --setopt=install_weak_deps=False builddep -y srpms/*.src.rpmIf we decide not to do anything about srpm but just suppress the test failure, we should uncomment it again and modify the requirement check.
If, on the other hand, srpms get fixed, the above should be removed from the buildbot config altogether.