Bug #21028
closedrocky8 package build failures
Description
Ever since #20862 got merged, build-packages-rocky8 has been failing like this:
Step 24/26 : RUN git clone --depth 1 git://git.arvados.org/arvados.git /tmp/arvados && cd /tmp/arvados && if [[ -n "${BRANCH}" ]]; then git checkout ${BRANCH}; fi && cd /tmp/arvados/services/api && /usr/local/rvm/bin/rvm-exec default bundle install && cd /tmp/arvados/apps/workbench && /usr/local/rvm/bin/rvm-exec default bundle install && cd /tmp/arvados && go mod download ---> Running in 5329834079d0 Cloning into '/tmp/arvados'... Don't run Bundler as root. Bundler can ask for sudo if it is needed, and installing your bundle as root will break this application for all non-root users on this machine. Fetching gem metadata from https://rubygems.org/ Fetching gem metadata from https://rubygems.org/......... Fetching https://github.com/arvados/themes_for_rails Fetching rake 13.0.6 Installing rake 13.0.6 […] Fetching zlib 3.0.0 Installing zlib 3.0.0 with native extensions Gem::Ext::BuildError: ERROR: Failed to build gem native extension. current directory: /usr/local/rvm/gems/ruby-2.7.2/gems/zlib-3.0.0/ext/zlib /usr/local/rvm/rubies/ruby-2.7.2/bin/ruby -I /usr/local/rvm/rubies/ruby-2.7.2/lib/ruby/2.7.0 -r ./siteconf20230925-12-jc2n06.rb extconf.rb checking for deflateReset() in -lz... yes checking for zlib.h... yes checking for crc32_combine() in zlib.h... yes checking for adler32_combine() in zlib.h... yes checking for z_crc_t in zlib.h... yes checking for z_size_t in zlib.h... yes creating Makefile current directory: /usr/local/rvm/gems/ruby-2.7.2/gems/zlib-3.0.0/ext/zlib make --jobs $(grep -c processor /proc/cpuinfo) "DESTDIR=" clean current directory: /usr/local/rvm/gems/ruby-2.7.2/gems/zlib-3.0.0/ext/zlib make --jobs $(grep -c processor /proc/cpuinfo) "DESTDIR=" compiling zlib.c zlib.c:16:11: fatal error: valgrind/memcheck.h: No such file or directory # include <valgrind/memcheck.h> ^~~~~~~~~~~~~~~~~~~~~ compilation terminated. make: *** [Makefile:245: zlib.o] Error 1 make failed, exit code 2 Gem files will remain installed in /usr/local/rvm/gems/ruby-2.7.2/gems/zlib-3.0.0 for inspection. Results logged to /usr/local/rvm/gems/ruby-2.7.2/extensions/x86_64-linux/2.7.0/zlib-3.0.0/gem_make.out An error occurred while installing zlib (3.0.0), and Bundler cannot continue. Make sure that `gem install zlib -v '3.0.0' --source 'https://rubygems.org/'` succeeds before bundling. In Gemfile: arvados was resolved to 2.7.0.rc2, which depends on arvados-google-api-client was resolved to 0.8.7.5, which depends on faraday-gzip was resolved to 2.0.0, which depends on zlib The command '/bin/sh -c git clone --depth 1 git://git.arvados.org/arvados.git /tmp/arvados && cd /tmp/arvados && if [[ -n "${BRANCH}" ]]; then git checkout ${BRANCH}; fi && cd /tmp/arvados/services/api && /usr/local/rvm/bin/rvm-exec default bundle install && cd /tmp/arvados/apps/workbench && /usr/local/rvm/bin/rvm-exec default bundle install && cd /tmp/arvados && go mod download' returned a non-zero code: 5 real 2m44.603s user 0m0.092s sys 0m0.152s ======= build packages -- FAILED ======= End of build packages (167s)
Updated by Brett Smith about 1 year ago
- Related to Bug #20862: Deal with our google api client fork in the arvados ruby sdk added
Updated by Brett Smith about 1 year ago
The last successful build used faraday 0.15.4, and it doesn't pull in the zlib gem at all.
The current build uses faraday 2.7.10, which pulls in faraday-gzip 2.0.0, which pulls in zlib 3.0.0, and that's what's failing to build.
Updated by Brett Smith about 1 year ago
Brett Smith wrote in #note-2:
The last successful build used faraday 0.15.4, and it doesn't pull in the zlib gem at all.
The current build uses faraday 2.7.10, which pulls in faraday-gzip 2.0.0, which pulls in zlib 3.0.0, and that's what's failing to build.
These differences come from f361c2439d0b2a9b8ac839b62a868884261e7897.
Updated by Peter Amstutz about 1 year ago
So what happened is that we un-pinned faraday and don't have the -dev packages to build it.
And zlib apparently needs valgrind now? 🙄
Updated by Brett Smith about 1 year ago
#include <valgrind/memcheck.h>
is conditional in the zlib gem, and this code hasn't been touched in over a decade. So there's something specific to rocky8 and/or our Docker image that sets up a disconnect between the #ifdef
and the #include
.
Updated by Brett Smith about 1 year ago
Brett Smith wrote in #note-5:
#include <valgrind/memcheck.h>
is conditional in the zlib gem, and this code hasn't been touched in over a decade. So there's something specific to rocky8 and/or our Docker image that sets up a disconnect between the#ifdef
and the#include
.
The Ruby we build with RVM defines it:
bash-4.4# strings /usr/local/rvm/rubies/ruby-2.7.2/bin/ruby | grep -i valgrind HAVE_VALGRIND_MEMCHECK_H 1
Updated by Brett Smith about 1 year ago
On rocky8 RVM downloads and installs a binary Ruby which I guess is built with Valgrind support. So one possible way out (I think, testing it now) is to build Ruby from source so its configuration matches the Docker image.
Updated by Brett Smith about 1 year ago
- % Done changed from 0 to 100
- Status changed from New to Resolved
Applied in changeset arvados|fe8da34676be7c6fbb1042fcfcabee19bfa424d0.