Attempting to build an SCL that uses rh-ruby25, I have noticed that a few paths are wrong and result in builds failing. First, the SCL appears to be setting the bindir incorrectly. When the gem install step is run the following can be seen: WARNING: You build with buildroot. Build root: /builddir/build/BUILD/rubygem-nokogiri-1.8.4 Bin dir: /builddir/build/BUILD/rubygem-nokogiri-1.8.4/opt/rh/rh-ruby25/root/usr/bin Gem home: /builddir/build/BUILD/rubygem-nokogiri-1.8.4/opt/theforeman/tfm-ror52/root/usr/share/gems Note the "Bin dir" path that is pointing at rh-ruby25 when it should be pointing at tfm-ror52. This causes builds to fail and is incorrect since bin files for tfm-ror52 should end up in it's namespace. Second, the SCL appears to internally be setting GEM_PATH incorrectly. While trying to build nokogiri, this error can be seen in the output: /opt/rh/rh-ruby25/root/usr/share/rubygems/rubygems/dependency.rb:310:in `to_specs': Could not find 'mini_portile2' (~> 2.3.0) among 23 total gem(s) (Gem::MissingSpecError) Checked in 'GEM_PATH=/builddir/.gem/ruby:/opt/rh/rh-ruby25/root/usr/share/gems:/opt/rh/rh-ruby25/root/usr/local/share/gems:/opt/theforeman/tfm-ror52/root/usr/share/gems', execute `gem env` for more information Note that nowhere in GEM_PATH does it reference tfm-ror52 paths. The tfm-ror52 paths are where mini_portfile2 are installed due to having built that package in the tfm-ror52 SCL. This all worked with rh-ruby24 previously. In my digging I noticed that the patched operating_system.rb file had changed between rh-ruby24 and rh-ruby25. Digging around in mock shell showed that these changes seemed to cause the issue. This breaks and largely blocks the ability to build any dependent SCLs that have packages with native extensions or bin files.
Hi Eric, thank you for the reporting. I am sorry for the issue. Let me check the build. By the way, what is the "tfm-ror52"? Is it software collection for Ruby on Rails 5.2?
I could find it. https://github.com/theforeman/rails-packaging/tree/tfm-ror52
Yes, since RH dropped making Rails SCLs, we now build our own based on the RH ruby collections.
If you set somewhere as a common setting, you might avoid the error the 2nd issue. Maybe. ``` export GEM_HOME="$(ruby -e 'print Gem.user_dir')" ``` There is also another issue from maybe same reason. https://bugzilla.redhat.com/show_bug.cgi?id=1574594 Let me check and dig the reason and your situation for better solution.
> This all worked with rh-ruby24 previously. In my digging I noticed that the patched operating_system.rb file had changed between rh-ruby24 and rh-ruby25. Digging around in mock shell showed that these changes seemed to cause the issue. This breaks and largely blocks the ability to build any dependent SCLs that have packages with native extensions or bin files. This is related to Ruby 2.5 started to do package stdlib as a gem. On rh-ruby25 (RPM ruby 2.5), the configuration "gem" was added. It was not on rh-ruby24. Possibly, it seems that this item causes the issue. rh-ruby25 with root user ``` [root@84ce05c3fe014146a038877c1e00b4d1 /]# which gem /opt/rh/rh-ruby25/root/usr/bin/gem [root@84ce05c3fe014146a038877c1e00b4d1 /]# gem env RubyGems Environment: ... - GEM CONFIGURATION: ... - "gem" => "--install-dir=/opt/rh/rh-ruby25/root/usr/local/share/gems --bindir /opt/rh/rh-ruby25/root/usr/local/bin" ... ``` rh-ruby25 with normal user ``` [mockbuild@303fd8665b094fdba648557165daa879 ~]$ gem env ... - GEM CONFIGURATION: ... - "gem" => "--user-install --bindir /builddir/bin" ... ```
Eric, I found that you did hack to pass your builds. Override gem_install macro https://github.com/theforeman/rails-packaging/commit/fb825522b8dfe5865ba5b71648ccf643e58deabc Add GEM_HOME to tfm-ror52 to fix documentation generation https://github.com/theforeman/rails-packaging/commit/6e4c170d7fd74f1c58607e1c73b40b0d9cd39d5a
Good find, I was planning to post that back to the BZ (that being my hacks) once I had them nailed down. Setting GEM_HOME doesn't feel as hacky but we previously did not have to set that. The overriding gem_install does feely hacky though. Note I refined the hack slightly to drop using --install-dir because specifying that causes documentation not to get generated. So look at [1] additionally. [1] https://github.com/theforeman/rails-packaging/commit/6e4c170d7fd74f1c58607e1c73b40b0d9cd39d5a
I see. All right. Thank you for the working. I am doing debug on my copr repository. https://copr.fedorainfracloud.org/coprs/jaruga/tfm-ror52/packages/
Eric, I might be able to suggest a thing. About tfm-ror52-rubygem-nokogiri.spec, I might be able to recommend use "export NOKOGIRI_USE_SYSTEM_LIBRARIES=yes" that is a option to build nokogiri with system library. And when using the option, you can remove mini_portile from the dependency. This is the way used on rh-ror50 SCL [1] Here is my debug code [2]. You might be able to refer it. In this option, to use below system libraries, you need to set "-I/usr/include" somewhere. ``` BuildRequires: libxml2-devel BuildRequires: libxslt-devel ``` Also you might be able to refer Fedora's rubygem-nokogiri spec file [3]. [1] https://www.softwarecollections.org/en/scls/rhscl/rh-ror50/ [2] https://github.com/junaruga/rails-packaging/commit/135da8dd912a84ea47675f54719ebcfb8c12786d [3] https://src.fedoraproject.org/rpms/rubygem-nokogiri/blob/master/f/rubygem-nokogiri.spec
What is the benefit to avoiding miniportile as a dependency and using system libraries?
Eric, the benefits are IMHO same as with all system dependencies- using system dependency you will get a supported library, prebuilt, tested, and reviewed by security; that will be updated (and/or patched) by someone else when needed. Compared of code downloaded from rubygems.org (which can be modified) and it needs to be built (patched and rebuilt in case of CVE) by you(and additionally you need to pull more build dependencies to be able build it). HIH.
Eric, Honestly I do not know clear benefit. Maybe we can use system libraries which has already been built on the system? Actually you are adding below lines in tfm-ror52-rubygem-nokogiri.spec to use the system libraries. ``` BuildRequires: libxml2-devel BuildRequires: libxslt-devel ``` By the way, if you enable "export NOKOGIRI_USE_SYSTEM_LIBRARIES=yes", you might be asked to use rubygem-pkg-config when building nokogiri. But this is a bug. You do not need to package rubygem-pkg-config. Maybe on your build environment, pkg-config command is installed. That's good enough. Here is how to avoid using rubygem-pkg-config. https://src.fedoraproject.org/rpms/rubygem-nokogiri/pull-request/3
Eric, did you succeed to build current tfm-ror52-rubygem-nokogiri.spec ? Today I tried to build tfm-ror52.spec then tfm-ror52-rubygem-nokogiri.spec. https://copr.fedorainfracloud.org/coprs/jaruga/tfm-ror52/build/790693/ I was failed to build it with below error message. ``` + CONFIGURE_ARGS='--with-cflags='\''-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic'\'' ' + gem install -V --local --build-root . --force --document=ri,rdoc nokogiri-1.8.4.gem ... /usr/bin/install -c -m 0755 nokogiri.so ./.gem.20180824-89-hyyy30/nokogiri BUILDSTDERR: ERROR: While executing gem ... (Errno::ENOENT) BUILDSTDERR: No such file or directory @ dir_s_mkdir - /builddir/build/BUILD/nokogiri-1.8.4/opt/rh/rh-ruby25/root/usr/bin ```
Eric, do you remember what is the current status for this issue? Was the issue fixed?
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.