ruby-sig February 2020

ruby-sig@lists.fedoraproject.org

5 participants
9 discussions

Ruby 2.2
by Vít Ondruch 22 Sep '23

22 Sep '23

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 19

Ruby 2.8
by Vít Ondruch 04 Jan '21

04 Jan '21

Hi everybody, I started early this time and therefore, there is already PR with changes for upcoming Ruby version: https://src.fedoraproject.org/rpms/ruby/pull-request/55 and the build should be available (if succeeds) here: https://koji.fedoraproject.org/koji/taskinfo?taskID=41848663 So far, there are changes in bundled gems. The RSS and REXML gems are not bundled gems, therefore I extracted them into separate subpackages, while Net::Telnet and XMLRPC were dropped from Ruby and therefore ruby-libs now obsoletes these two packages. As always, any feedback is welcome. Vít

6 51

Two stage Ruby compilation / Bootstrapping
by Vít Ondruch 19 Nov '20

19 Nov '20

Hi all, Ruby upstream is implementing more and more stuff directly in Ruby. We already had issues, that build of Ruby required Ruby when we did some modifications [1]. In subsequent ticket, one of Ruby committers said [2]: > ... snip ... > BASERUBY is already a build requirement > ... snip ... > I would like to implement more of Ruby using Ruby, so miniruby may depend on prelude one day. With recent changes, such as [3], I am afraid that the day has come. Previously, if you wanted to patch lets say "gem_prelude.rb", it was enough to patch it. But now you *need* Ruby to process it into miniprelude.c. There are possibly 4 ways out of this. 1) Build Ruby in two stages. a) build (mini)ruby, apply patches b) build Ruby using the previously built (mini)ruby. 2) Use previous version of Ruby available in Fedora to bootstrap Ruby. But this does not work ATM, at least when RubyGems are installed. And upstream is doing what they can to make RubyGems inseparable [4]. 3) Prepare patches locally and apply the required changes also to the pregenerated files. But the problem here is, that the patches might unpredictably fail between updates. I don't think that they keep any API/ABI promises for the tools used to generate those files. 4) Don't use the upstream tarball, but generate it from sources with patches integrated. I think we should probably start to take look at 1), specifically into the *miniruby* variant if that is enough. If that is done, the 2) could optionally blend in. And in the mean time use 3) because otherwise I really don't know how to integrate the ABRT hook support. I don't like 4) at all, unless we have some Fedora standardized way of doing so. On the positive side, 1(2) would allow us to stay better in line with "Pregenerated code" guidelines [5], because there is already quite a lot of pre-generated code shipped in Ruby release tarball. Thoughts? Vít [1] https://src.fedoraproject.org/rpms/ruby/c/c0513dfb8c81a228619c6142195c5117a… [2] https://bugs.ruby-lang.org/issues/15306#note-1 [3] https://github.com/ruby/ruby/pull/2655 [4] https://bugs.ruby-lang.org/issues/16431 [5] https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packa…

3 7

Retired "rubygems" package
by Vít Ondruch 15 May '20

15 May '20

Hi all, The independent "rubygems" package was retired, because it FTBFS already for some while: https://src.fedoraproject.org/rpms/rubygems/c/366607586d95b505277165fce54d9… Now I wonder, do we care? Should I unretire it while there is a chance to do it without review or we don't care and we are fine with the bundled version shipped in Ruby? Obviously if I was convinced we really need it, I'd did that without asking. So what are your opinions? Vít

3 3

FTBFS's: cannot load such file - racc/*
by Pavel Valena 31 Mar '20

31 Mar '20

Hello, as you probably know with Ruby 2.7, there came some incompatible changes. One of them is that `racc` was gemified and is not installed by default into a buildroot. From my brief investigations of build failures (the list may not be complete or a bit outdated), I've encountered these: rubygem-shoulda.log: LoadError: cannot load such file -- racc/parser.rb ^ require from actionpack rubygem-shoulda-matchers.log: cannot load such file -- racc/parser.rb ^ require from activesupport rubygem-i18n.log:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:92:in `require': cannot load such file -- racc/parser (LoadError) ^ require from i18n/lib rubygem-nokogiri.log:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:92:in `require': cannot load such file -- racc/parser.rb (LoadError) rubygem-sass-rails.log:/usr/share/gems/gems/nokogiri-1.10.7/lib/nokogiri/css/parser.rb:7:in `require': cannot load such file -- racc/parser.rb (LoadError) rubygem-shoulda-context.log:<["/usr/share/gems/gems/nokogiri-1.10.7/lib/nokogiri/css/parser.rb:7:in `require': cannot load such file -- racc/parser.rb (LoadError)"]> ^ nokogiri What would be the best solution? Add the require to Ruby, or add it to respective gems+spec files (nokogiri issue: [0])? Regards, Pavel [0] https://github.com/sparklemotion/nokogiri/issues/1988

2 4

Unexpected files included in rubygem doc packages
by Breno Brand Fernandes 25 Feb '20

25 Feb '20

Hi all, I had an issue today with a package I submitted to code review [1]. The reviewer pointed out that I was shipping font files instead of requiring them. And, I was also not shipping their license. After that, Trevor and I started to investigate and we realized that some other packages had the same issue. We wrote a few scripts and came to the conclusion that almost every rubygem doc package pushed to Fedora Rawhide right now has those files. We also investigated the gems, and it seems that by default they do not include those files [2]. A list of the mentioned files is attached to this email. There are fonts, CSS, Javascripts, and others. In one of the rubygem packages (rubygem-nifti) we found that those files could be excluded [3]. Is this expected? Should we just use the exclude [3] even though the files were downloaded? I mean, removing the files at a build stage is enough if they have licensing issues? What is the right direction the reviewer or the maintainer should be pointed to? Thanks. - B 1 - https://bugzilla.redhat.com/show_bug.cgi?id=1803276 2 - e.g. https://rubygems.org/gems/cane-3.0.0.gem 3 - %files doc section, they have "%exclude %{gem_docdir}/rdoc"

3 4

ruby-sig Introduction email
by David Kirwan 18 Feb '20

18 Feb '20

Hi all, My name is David Kirwan, I'm a software engineer in Red Hat based out of Waterford in the South East of Ireland. So far in Red Hat I've worked in releng/ops/devops and more recently now engineering teams. Ruby is my go to language for fun/personal projects, I think it might be fun to get involved in improving the experience for Ruby developers on Fedora! I don't know exactly how I could be useful until I learn more about what kind of work is actually performed in this group, but I'd like to join and learn! cheers, David -- David Kirwan SOFTWARE ENGINEER Red Hat Cloud Services Communications House Cork Road, Waterford dkirwan(a)redhat.com T: +(353) 86-8624108 IM: @dkirwan

2 2

Empty %files debugsourcefiles.list rpmbuild rubygem packages
by Breno Brand Fernandes 12 Feb '20

12 Feb '20

Hi all, I had issues building some rubygem packages with rpmbuild. E.g. rubygem-redcarpet[1]. During my tests, I am using the spec file from the master branch. Using mock instead (of rpmbuild), the issue doesn't happen. Do you know why it happens? Am I missing something obvious? Thank you, 1 - RPM build errors: Downloading https://rubygems.org/gems/redcarpet-3.3.2.gem to /home/mockbuild/rpmbuild/SOURCES/redcarpet-3.3.2.gem Empty %files file /home/mockbuild/rpmbuild/BUILD/rubygem-redcarpet-3.3.2/debugsourcefiles.list - Breno

2 2

Question about rubyforge related packages
by Troy Dawson 12 Feb '20

12 Feb '20

Hi, rubygem-rubyforge was dropped back in November with "rubyforge is dead long ago, retiring (mtasaka, 20191105)" I'm ok with that. I have a package that was part of rubyforge, rubygem-ci_reporter. Looking at it's codebase, it hasn't been touched for 5 years. I was debating on just dropping/retiring it, or orphaning it. I don't use it anymore, so I'm at least orphaning it. But do people think I should just completely drop it, like rubyforge, since we don't really want it in fedora anymore? Troy

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

ruby-sig February 2020