-
Notifications
You must be signed in to change notification settings - Fork 37.8k
ci: Combine 32-bit build with CentOS 7 build #17900
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
ci: Combine 32-bit build with CentOS 7 build #17900
Conversation
One of the initial goals to run CentOS task on Travis was to check the Bitcoin Core compatibility with aged (system) dependencies. Using our built |
32-bit gitian is going to be removed, so we might as well not use depends in here. See #17504 |
Without building the depends I don't see a way to do a cross-compile from 64 bit to 32 bit, one would need all the needed libraries also for i686, which is unfortunately not the case in CentOS 7 -- the following packages are only available for x86_64: libdb4-devel, libdb4-cxx-devel, miniupnpc-devel, zeromq-devel. |
For quick reference: http://mirror.centos.org/altarch/7/os/i386/Packages/ Also there is no 32-bit EPEL repository: https://fedoraproject.org/wiki/EPEL#What_packages_and_versions_are_available_in_EPEL.3F |
Concept ACK
I'm not sure 32-bit gitian binaries and depends 32-bit support should be equated here. Deciding not to ship 32 bit gitian binaries does not necessarily mean making it harder to build on/for 32 bit for those that still want to. I dunno. |
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsNo conflicts as of last run. |
ef63f5f ci: Combine 32-bit build with CentOS 7 build (Sebastian Falbesoner) Pull request description: Combines the CentOS build with the 32-bit (i686) build to avoid Travis bottlenecks, as suggested in bitcoin#17757 by MarcoFalke. This keeps most of the properties of the 32-bit build (dash as config shell, building QT5 GUI) and just builds it with depends inside the CentOS docker container. Making the depends in `05_before_script.sh` with unset config shell (`CONFIG_SHELL=`) https://github.com/bitcoin/bitcoin/blob/6196e930018181301b5972842ae384ea4288ff34/ci/test/05_before_script.sh#L28 caused problems for building the library libevent (resulting in a Makefile with no shell set (`SHELL=`)), that's why I set it explicitely to `/bin/bash` if we have a CentOS Docker container. A Travis output of this 32-bit CentOS build can be seen here: https://travis-ci.org/theStack/bitcoin/jobs/634472394 (has been restarted once due to too long build time and appearance of the `CACHE_ERR_MSG`). For anyone wanting to verify the outputs, I found these instructions useful to reproduce a Travis build locally: https://github.com/erdc/proteus/wiki/Replicating-the-TravisCI-Environment-on-your-Local-Machine (steps 1-3). In this case it's a bit tricky since you run Docker inside Docker -- within the Travis Docker container, the CentOS Docker container is created. To make this possible, the Docker socket has to be exposed to the Travis container via bind-mounting (`docker run -v /var/run/docker.sock:/var/run/docker.sock ...`), as suggested in https://stackoverflow.com/a/33003273. Top commit has no ACKs. Tree-SHA512: af508241cec3a10a66c37673d56691717b78375340e910fcdd3fb3870741eba623a436e1e85b26b54f013375611896f5411c5a7fec2437d367d27172230129fe
ef63f5f ci: Combine 32-bit build with CentOS 7 build (Sebastian Falbesoner) Pull request description: Combines the CentOS build with the 32-bit (i686) build to avoid Travis bottlenecks, as suggested in bitcoin#17757 by MarcoFalke. This keeps most of the properties of the 32-bit build (dash as config shell, building QT5 GUI) and just builds it with depends inside the CentOS docker container. Making the depends in `05_before_script.sh` with unset config shell (`CONFIG_SHELL=`) https://github.com/bitcoin/bitcoin/blob/6196e930018181301b5972842ae384ea4288ff34/ci/test/05_before_script.sh#L28 caused problems for building the library libevent (resulting in a Makefile with no shell set (`SHELL=`)), that's why I set it explicitely to `/bin/bash` if we have a CentOS Docker container. A Travis output of this 32-bit CentOS build can be seen here: https://travis-ci.org/theStack/bitcoin/jobs/634472394 (has been restarted once due to too long build time and appearance of the `CACHE_ERR_MSG`). For anyone wanting to verify the outputs, I found these instructions useful to reproduce a Travis build locally: https://github.com/erdc/proteus/wiki/Replicating-the-TravisCI-Environment-on-your-Local-Machine (steps 1-3). In this case it's a bit tricky since you run Docker inside Docker -- within the Travis Docker container, the CentOS Docker container is created. To make this possible, the Docker socket has to be exposed to the Travis container via bind-mounting (`docker run -v /var/run/docker.sock:/var/run/docker.sock ...`), as suggested in https://stackoverflow.com/a/33003273. Top commit has no ACKs. Tree-SHA512: af508241cec3a10a66c37673d56691717b78375340e910fcdd3fb3870741eba623a436e1e85b26b54f013375611896f5411c5a7fec2437d367d27172230129fe
ef63f5f ci: Combine 32-bit build with CentOS 7 build (Sebastian Falbesoner) Pull request description: Combines the CentOS build with the 32-bit (i686) build to avoid Travis bottlenecks, as suggested in bitcoin#17757 by MarcoFalke. This keeps most of the properties of the 32-bit build (dash as config shell, building QT5 GUI) and just builds it with depends inside the CentOS docker container. Making the depends in `05_before_script.sh` with unset config shell (`CONFIG_SHELL=`) https://github.com/bitcoin/bitcoin/blob/6196e930018181301b5972842ae384ea4288ff34/ci/test/05_before_script.sh#L28 caused problems for building the library libevent (resulting in a Makefile with no shell set (`SHELL=`)), that's why I set it explicitely to `/bin/bash` if we have a CentOS Docker container. A Travis output of this 32-bit CentOS build can be seen here: https://travis-ci.org/theStack/bitcoin/jobs/634472394 (has been restarted once due to too long build time and appearance of the `CACHE_ERR_MSG`). For anyone wanting to verify the outputs, I found these instructions useful to reproduce a Travis build locally: https://github.com/erdc/proteus/wiki/Replicating-the-TravisCI-Environment-on-your-Local-Machine (steps 1-3). In this case it's a bit tricky since you run Docker inside Docker -- within the Travis Docker container, the CentOS Docker container is created. To make this possible, the Docker socket has to be exposed to the Travis container via bind-mounting (`docker run -v /var/run/docker.sock:/var/run/docker.sock ...`), as suggested in https://stackoverflow.com/a/33003273. Top commit has no ACKs. Tree-SHA512: af508241cec3a10a66c37673d56691717b78375340e910fcdd3fb3870741eba623a436e1e85b26b54f013375611896f5411c5a7fec2437d367d27172230129fe
Combines the CentOS build with the 32-bit (i686) build to avoid Travis bottlenecks, as suggested in #17757 by MarcoFalke. This keeps most of the properties of the 32-bit build (dash as config shell, building QT5 GUI) and just builds it with depends inside the CentOS docker container.
Making the depends in
05_before_script.sh
with unset config shell (CONFIG_SHELL=
)bitcoin/ci/test/05_before_script.sh
Line 28 in 6196e93
caused problems for building the library libevent (resulting in a Makefile with no shell set (
SHELL=
)), that's why I set it explicitely to/bin/bash
if we have a CentOS Docker container.A Travis output of this 32-bit CentOS build can be seen here: https://travis-ci.org/theStack/bitcoin/jobs/634472394 (has been restarted once due to too long build time and appearance of the
CACHE_ERR_MSG
).For anyone wanting to verify the outputs, I found these instructions useful to reproduce a Travis build locally: https://github.com/erdc/proteus/wiki/Replicating-the-TravisCI-Environment-on-your-Local-Machine (steps 1-3). In this case it's a bit tricky since you run Docker inside Docker -- within the Travis Docker container, the CentOS Docker container is created. To make this possible, the Docker socket has to be exposed to the Travis container via bind-mounting (
docker run -v /var/run/docker.sock:/var/run/docker.sock ...
), as suggested in https://stackoverflow.com/a/33003273.