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 over 2 years ago
- Related to Bug #20862: Deal with our google api client fork in the arvados ruby sdk added
Updated by Brett Smith over 2 years 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 over 2 years 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 over 2 years 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 over 2 years 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 over 2 years 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#ifdefand 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 over 2 years 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 over 2 years ago
- % Done changed from 0 to 100
- Status changed from New to Resolved
Applied in changeset arvados|fe8da34676be7c6fbb1042fcfcabee19bfa424d0.