-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MDBF-883 - CentOS 7 bintar compatibility with old buildbot #684
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see from MDBF task that the gnutls is a static library build so this looks acceptable.
@cvicentiu @grooverdan |
if you haven't tested main - after MariaDB/server#3758 might be a good revisit. Some other builders are before gcc 9 so I'm not expecting too much trouble. |
c9852ce
to
f441620
Compare
@cvicentiu
I restricted this builder to run for >= 11.7 |
As part of the MDBF, I am preparing several (manual) changes to the centos-7-bintar container image, one of which will bump GnuTLS version to 3.7.x, as in buildbot.mariadb.net GNUTLS_NO_SIGNAL flag was introduced in GnuTLS 3.4.x so there's no need to disable the macro anymore. (the flag is not present in buildbot.mariadb.net) More on that, from my tests (10.11), disabling the macro will cause the compilation to fail when using the newer GnuTLS (static library). <command-line>:0:18: error: expected identifier before numeric constant. Important notes: This code change should only be deployed in Production when the updated centos7-bintar is published in quay, in this order: - deploy code changes - stop master-docker-nonstandard (where the builder is defined) - update image on quay - start master-docker-nonstandard I will probably deploy this change manually because there are some pending other changes which need to be tested and given the BLOCKER status of the MDBF, it should be deployed ASAP.
Make the command be more readable. Add explicit usage of ccache.
A new bintar builder (non-EOL) will handle builds for 11.7/11.8. For now, it's important that GnuTLS is updated and can build 11.4
s_packages is useless in this context, bintar is already producing a standalone package used for release s_bigtest - was never triggered for bintar, if one looks in the history. If there isn't a special need for it, I suggest removing it to avoid confusion
f441620
to
9b0e12d
Compare
@cvicentiu I added 9b0e12d |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
The schedulers one is a little bit tricky to spot. I realized that the key for those schedulers is for the parent-builder-name to be a substring of the s_packages / s_bigtest builder names.
We really should make that more obvious.
As part of the MDBF, I am preparing several (manual) changes to the
centos-7-bintar
container image, one of which will bumpGnuTLS version to 3.7.x,
as inbuildbot.mariadb.net
GNUTLS_NO_SIGNAL
flag was introduced inGnuTLS 3.4.x
so there's no need to disable the macro anymore. (the flag is not present in buildbot.mariadb.net configuration)More on that, from my tests << 10.11 >> (thanks @cvicentiu for help) disabling the macro will cause the compilation to fail when using the newer GnuTLS (static library).
<command-line>:0:18: error: expected identifier before numeric constant.
Important notes:
This code change should only be deployed in Production when the updated
centos7-bintar
is published in quay, in this order:I will probably deploy this change manually because there are some pending
other changes which need to be tested and given the BLOCKER
status of the MDBF, it should be deployed ASAP.