Project

General

Profile

Actions

Bug #21028

closed

rocky8 package build failures

Added by Brett Smith 10 months ago. Updated 8 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 10 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 10 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 10 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 10 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 10 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 10 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 10 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 10 months ago

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

Updated by Peter Amstutz 8 months ago

  • Release set to 67
Actions

Also available in: Atom PDF