Project

General

Profile

Actions

Bug #21028

closed

rocky8 package build failures

Added by Brett Smith 7 months ago. Updated 5 months ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
Deployment
Story points:
-
Release relationship:
Auto

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)

Related issues

Related to Arvados - Bug #20862: Deal with our google api client fork in the arvados ruby sdkResolvedTom CleggActions
Actions #1

Updated by Brett Smith 7 months ago

  • Related to Bug #20862: Deal with our google api client fork in the arvados ruby sdk added
Actions #2

Updated by Brett Smith 7 months 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.

Actions #3

Updated by Brett Smith 7 months 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.

Actions #4

Updated by Peter Amstutz 7 months 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? 🙄

Actions #5

Updated by Brett Smith 7 months 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.

Actions #6

Updated by Brett Smith 7 months 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
Actions #7

Updated by Brett Smith 7 months 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.

Actions #8

Updated by Brett Smith 7 months ago

  • % Done changed from 0 to 100
  • Status changed from New to Resolved
Actions #9

Updated by Peter Amstutz 5 months ago

  • Release set to 67
Actions

Also available in: Atom PDF