ruby-sig September 2021

ruby-sig@lists.fedoraproject.org

5 participants
4 discussions

Ruby 2.2
by Vít Ondruch 25 Jan '22

25 Jan '22

Hi everybody, Since Ruby 2.2 is going to be released during Christmas and -preview1 release is imminent (this Wednesday?), it is probably time to start looking into its packaging. So here is the updated .spec file [1] and scratch build [2], which can be finally build on all platforms. Sorry, no Copr for you, since Ruby's build fails there due to old RHEL kernel :/. What has changed from packaging point of view? Luckily, not much, but here are a few bullets which comes to my mind: * RPM 4.12 introduces new %load function, which is used to load RPM macros during RPM build. This allowed to drop my custom RPM macro [3]. On the other hand, you'll be able to build the Ruby only on F21+ (luckily, you should be able to build SRPM everywhere). * The RubyGems filesystem was not explicit enough, so there might be something accidentally packages. This is now more explicit, so we should be safer. * Ruby now ships with MiniTest and Test::Unit. The very good news is that they are installed so far as a regular gems. This means that you have to always specify them in your Gemfile, if you are using Bundler, but this is generally step in good direction. I hope that upstream will not change their mind :) Due to this change, we have new subpackages rubygem-test-unit (and rubygem-power_assert, which is now Test::Unit's dependency). No more %{_bindir}/testrb (but nobody is using it these days anyway, right? ;) * Some prevailing test failures were resolved, some others introduced, but hopefully they'll get resolved prior stable release. Generally, I'd say that not much has changed since 2.1, which is good news. Please test the packaging if you can and let me know about any issues you encountered. Also, if you have any other suggestions about Ruby packaging in general, what we could improve etc, this is probably good time to share. It seems that OpenSUSE guys are improving their packaging, so you might want to get some inspiration there [4, 5, 6] ;) Vít [1] http://pkgs.fedoraproject.org/cgit/ruby.git/log/?h=private-ruby-2.2 [2] http://koji.fedoraproject.org/koji/taskinfo?taskID=7578843 [3] http://pkgs.fedoraproject.org/cgit/ruby.git/commit/?h=private-ruby-2.2&id=8… [4] https://build.opensuse.org/package/show/home:darix:ruby/ruby-common [5] https://build.opensuse.org/package/show/home:darix:ruby/ruby2.2 [6] https://github.com/openSUSE/gem2rpm/commits/master

4 18

rpms/ruby FTBFS with autoconf 2.71
by Jun Aruga 30 Sep '21

30 Sep '21

Just FYI It seems the rpms/ruby rawhide started to fail to build from the following build. https://koschei.fedoraproject.org/build/11069282 autoconf: 2.69-37.fc35 => 2.71-1.fc36 I noticed this when I also saw the build started to fail on the stream-ruby-2.6 branch too. -- Jun | He - Him

3 6

CRLF line ends in a rubygem
by Otto Urpelainen 30 Sep '21

30 Sep '21

Hello Ruby SIG, Jekyll 4.2.1 was recently released [1]. Consequently, I am working on updating the Fedora rubygem-jekyll package. Even though the update is a small bugfix release, various parts of the specfile that worked for 4.2.0 now fail. I have determined the reason for those changes is that the files inside jekyll 4.2.1 gem have CRLF line endings. I can fix the problems by converting selected files to LF as follows: BuildRequires: dos2unix %prep ... dos2unix lib/jekyll/commands/new.rb dos2unix exe/jekyll However, I am unsure if this is a good way to proceed. Should I convert *all* the files inside the gem, so that no CRLF files are installed to user systems, potentially causing more problems later? Or should I try to convince the upstream to move back to publishing their gem with LF? Any advice is welcome. Otto [1]: https://rubygems.org/gems/jekyll/versions/4.2.1

2 4

RubyGems / VagrantPlugins macros
by Pavel Valena 15 Sep '21

15 Sep '21

Hello, I've encountered an issue while doing an update to vagrant-libvirt 0.5.3. ``` DEBUG: + echo 'gemspec_file = '\''../vagrant-libvirt-0.5.3.gemspec'\'' DEBUG: DEBUG: name = '\''rexml'\'' DEBUG: requirements = nil DEBUG: DEBUG: type = :runtime DEBUG: DEBUG: spec = Gem::Specification.load(gemspec_file) DEBUG: abort("#{gemspec_file} is not accessible.") unless spec DEBUG: DEBUG: dep = spec.dependencies.detect { |d| d.type == type && d.name == name } DEBUG: if dep DEBUG: dep.requirement.concat requirements DEBUG: else DEBUG: spec.public_send "add_#{type}_dependency", name, requirements DEBUG: end DEBUG: File.write gemspec_file, spec.to_ruby' DEBUG: + ruby DEBUG: /usr/share/rubygems/rubygems/requirement.rb:146:in `concat': undefined method `flatten' for nil:NilClass (NoMethodError) DEBUG: from -:13:in `<main>' ``` This is caused by (I've already removed it; and it works now): ``` -# Rexml needs to be required since Ruby 3.0. -# https://github.com/vagrant-libvirt/vagrant-libvirt/pull/1277 -%gemspec_add_dep -g rexml -s ../%{vagrant_plugin_name}-%{version}.gemspec ``` As this would be an empty change (rexml was already added), and `requirements` is `nil`, this is not expected use. Should we enhance the macros to cover this case with a proper error message? Regards, Pavel Additional notes: https://github.com/rubygems/rubygems/blob/3387dbf66d3721f1a25ea60d6bab8fdda… https://src.fedoraproject.org/rpms/vagrant-libvirt/pull-request/7

2 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

ruby-sig September 2021