ruby-sig

ruby-sig@lists.fedoraproject.org

1 participants
706 discussions

Ruby on Rails 8.1 has landed
by Vít Ondruch 05 Aug '26

05 Aug '26

Hi, I have not talked a lot about this here, but you might be aware that I was working on upgrading Rails to the recent version: https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_8.1 and the change has landed today: https://bodhi.fedoraproject.org/updates/FEDORA-2026-e5899537d7 Currently, there are Rails 8.1.2 and today (I think) was released 8.1.3.1. I'll try to make the update soonish, because I didn't want to delay the work due to change deadline. Anyway, please let me know if there are any issues. I could have certainly done more testing. OTOH, from packaging POV, there were not significant changes (with exception of Trix being extracted into new package), so I hope the 8.1 won't broke a lot of things. Cheers, Vít

1 1

Re: Status of JRuby package, reviving it
by Jarek Prokop 13 May '26

13 May '26

On 5/12/26 7:59 PM, Charles Oliver Nutter wrote: > On Tue, May 12, 2026 at 12:43 PM Fabio Valentini > <decathorpe(a)gmail.com> wrote: > > I think just "unpacking a tarball" won't be appropriate for an > official package, assuming that this includes pre-built JAR files? > Those would all need to get built from source during the package > build, but this should be a solveable problem. More concrete feedback > will probably happen once you can share a working package / RPM spec > file and / or submit that for package review. > For some context for approaching packaging JRuby itself (meaning engine sans bundled gems) FTR there are guidelines that must be upheld for packages (unless exception is given by FESCo). Since JRuby is mainly Java, in addition to general guidelines [0], the Java guidelines [1] could apply, similarly to how C guidelines apply to CRuby. > Oh sure, I understand that. I just provide the example of "unpacking" > to show that there's not much as far as native dependencies required > once a JDK is available. > > JRuby itself is published to Maven, of course, but the "dist" package > most people install is distributed as a a tarball or zip containing: > > * pre-built jar(s) for JRuby itself > * a set of bin scripts to launch JRuby and provided tools > * a whole bunch of Ruby sources and additional jar files to provide > the Ruby standard library (most of the pure-Ruby is the same code as > in standard Ruby). Pure-Ruby can be shared across ruby implementations and pure-ruby packages should be packaged (and are required to by guidelines) such that you can for example `dnf install rubygem-webrick` and the just run that with JRuby via rubypick or other means. As I mention on other places in this email, guidelines and our packaging is done with alternative Ruby runtimes in mind (such as JRuby), but there wasn't much of a request and time for alternative runtimes, so it has been just CRuby since the JRuby in Fedora was retired. > > We also publish the entire dist to Maven: > https://central.sonatype.com/artifact/org.jruby/jruby-dist. The main > jar file we ship is largely equivalent to the `jruby-core` Maven > artifact, with all third-party JVM libraries bundled into the same file. > > I'm not sure how finely the JRuby dist would need to be sliced up to > become an acceptable Fedora package. Looking at standard Ruby packages > from https://packages.fedoraproject.org/pkgs/ruby/ it doesn't appear > that each individual standard library is split off into its own > package, and there's some aggregate packages for "bundled" > (preinstalled) and "default" (in stdlib but upgradable) gems. JRuby > has the same basic split and roughly the same layout of how we ship > the standard library. I can provide some context here. We had tried to keep each library in its own separate, but later (around ~ Ruby 3.0 timeframe I think?) defaulted to providing them in the ruby-bundled-gems and ruby-default-gems collections and the rest of the gems that were split before this are just standalone (for example: rubygem-rexml). > > Perhaps someone who maintains the existing Ruby packages could help me > figure out what needs to change to support the same packages for JRuby? I am not sure here at the full scope that JRuby would require adjusting. There are things, such as rubygems-devel containing various macros for help with rubygems packaging that are more or less standardized. I am not sure of interoperability of gems with CRuby extensions with JRuby, how would rubygems behave in that case, whether it'd recognize that there is no Java compat and would just say it doesn't exist or what would happen. Though this is problem (or maybe isn't?) for packaged gem libraries, user-installed libraries in $HOME should not get intermixed between engines. I'd mention a project "rubypick" that is here from when JRuby was packaged in Fedora years ago and allows switching which Ruby engine is running with ease https://src.fedoraproject.org/rpms/rubypick . rubygems-* packages are packaged (and Ruby Fedora packaging guidelines [2] ). There is also custom operating_system.rb we inject into rubygems during build that generates our paths for gems that are consistent with Fedora guidelines. [3] I also recommend the %configure section of the ruby.spec [4] which could offer further inspiration and prevent gotcha's, such as shared rubygems path `/usr/share/rubygems`, and shared system(dnf)-installed gem path `/usr/share/gems`. Regards, Jarek [0] https://docs.fedoraproject.org/en-US/packaging-guidelines/ [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Java [2] https://docs.fedoraproject.org/en-US/packaging-guidelines/Ruby/ [3] https://src.fedoraproject.org/rpms/ruby/blob/62e62cae3c177ad600f659dda5765f… [4] https://src.fedoraproject.org/rpms/ruby/blob/62e62cae3c177ad600f659dda5765f…

1 0

Re: Status of JRuby package, reviving it
by Jarek Prokop 13 May '26

13 May '26

Welcome! I am one of the Ruby Fedora packagers, I am happy to see interest for extending Ruby engines offerings in Fedora. On 5/12/26 7:37 PM, Charles Oliver Nutter wrote: > Disclaimer: I am a JRuby developer and currently leading the project. > > JRuby has been seeing a big burst of development recently and we have > been getting requests from users for there to be official packages on > their Linux of choice. Today that Linux is Fedora (or downstream > derivatives like Bazzite). > > We are interested in helping to revive the JRuby package for Fedora. > JRuby today runs on JDK 21+ and installation requires little more than > unpacking a tarball (plus appropriate path tweaks etc). There's not > much to do to get it into a package, but I am unfamiliar with the > testing done for the standard Ruby package and how much of that > applies to JRuby. There are 2 sets of tests, 1) Upstream that run during build, those discover issues on their own, and 2) our Fedora tests. And I'd say a significant amount of CRuby configurations apply to JRuby as well, we have shared rubygems, shared gems, ... between Ruby engines. But a lot of it ran on just CRuby for some time, so we might discover some edge cases along the way. For Fedora tests, there is https://src.fedoraproject.org/tests/ruby , though I'd like to see many more tests that could test the integration into the Fedora ecosystem, but there have not been much time to give it. We could share some portion of tests in that repo, TMT is quite flexible. So, there isn't "much" testing outside of reviews when package is introduced so that it has all the required things necessitated by general and ruby-specific Fedora Guidelines. One way to test changes with CRuby's integration is build the package, install it in mock or on a test machine and try to build in that environment some ruby package and run it, which excersizes paths, loading and other "basics" that have to be right for things to work together. There is some support for multiple Ruby runtimes in Fedora, even going as far as being able to interchangeably run with pure-ruby Fedora packaged gems via rubypick (for more see the deeper in-thread response). > > If this is not the correct place to discuss it, please let me know. I > ended up here by following instructions at > https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Packag… This is correct place and I'd mention also that we have ruby-sig https://fedoraproject.org/wiki/SIGs/Ruby (mailing list cc'd) where we discuss Rub(y|ies) in Fedora. Thanks, Jarek > > *Charles Oliver Nutter* > /Architect and Technologist/ > Headius Enterprises > https://www.headius.com > headius(a)headius.com >

1 0

FPC: Building rubygem-cucumber-messages as a subpackage of cucumber-messages?
by Benjamin Beasley 17 Apr '26

17 Apr '26

I am considering a PR by Vít Ondruch for cucumber-messages[1] that would build rubygem-cucumber-messages as a subpackage rather than maintaining it as a separate source package. I am generally inclined to favor the proposal, but it seems to me that it represents an exception to the “MUST” requirement to package RubyGem libraries from the released gem archives. I’ve therefore raised the issue on the Fedora Packaging Committee tracker[3]. The purpose of this email is to raise visibility of that issue among Ruby packagers, and to solicit input from knowledgeable and interested parties. [1] https://src.fedoraproject.org/rpms/cucumber-messages/pull-request/2 [2] https://docs.fedoraproject.org/en-US/packaging-guidelines/Ruby/#_rubygems [3] https://pagure.io/packaging-committee/issue/1512

3 3

Fwd: List of long term FTBFS packages to be retired in March
by Mamoru TASAKA 16 Feb '26

16 Feb '26

Hello, ruby-sig folks: -------- Forwarded Message -------- Subject: List of long term FTBFS packages to be retired in March Date: Tue, 10 Feb 2026 12:42:12 +0100 From: Miro Hrončok <mhroncok(a)redhat.com> Reply-To: Development discussions related to Fedora <devel(a)lists.fedoraproject.org> To: Development discussions related to Fedora <devel(a)lists.fedoraproject.org>, devel-announce(a)lists.fedoraproject.org Dear maintainers. Based on the current fail to build from source policy, the following packages will be retired frrom rawhide cca on 2026-03-03. This is the third reminder. Policy: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails… The packages in rawhide were not successfully built at least since Fedora 41. This report is based on dist tags. Packages collected via: https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbf… If you see a package that was built, please let me know. If you see a package that should be exempted from the process, please let me know and we can work together to get a FESCo approval for that. If you see a package that can be rebuilt, please do so. Package (co)maintainers ================================================================================ rubygems @ruby-packagers-sig, mtasaka, vondruch How will we handle this? Although fixing rubygems.src FTBFS may not strictly needed (which means rubygems.src is to be retired on 2026-Mar), I think it is good (or not bad) that keeping rubygems.src alone buildable so that when desired we can update rubygems.src alone. For now I've prepared for updating rubygems.src to 4.0.6: https://src.fedoraproject.org/rpms/rubygems/pull-request/5 Mass rebuild for the above rubygems seems in good state: https://src.fedoraproject.org/rpms/rubygems/pull-request/5 Note that 2026-Feb-17 is Fedora 44 beta freeze, and if possible I want to put in rubygems 4.0.6 into Fedora 44 before the above day. Regards, Mamoru

2 3

Ruby 4.0 - Mass rebuild
by Jarek Prokop 12 Jan '26

12 Jan '26

Hi everybody, Ruby 4.0 is out and it is time for Ruby mass rebuild. First of all, I'd like to thank to Mamoru for the preparation and lot of work all around. I really appreciate that. From what I have been observing and discussing with Vít, I think we are well prepared for the rebuild, therefore I have requested side-tag: ~~~ $ fedpkg request-side-tag Side tag 'f44-build-side-125767' (id 125767) created. Use 'fedpkg build --target=f44-build-side-125767' to use it. Use 'koji wait-repo f44-build-side-125767' to wait for the build repo to be generated. ~~~ Ruby 4.0 was merged [1] and the build is in progress: https://koji.fedoraproject.org/koji/taskinfo?taskID=140833816 You can see the tag rebuild progress in: https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=125767&order=-… You can alternatively also use: ~~~ $ koji list-tagged f44-build-side-125767 ~~~ Now this is a list of packages, which very likely needs rebuild: ~~~ $ dnf repoquery --disablerepo=* --enablerepo=rawhide --enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' | sort | uniq ~~~ You can take such package, bump the release and just fire rebuild, but please ensure that you are using f44-build-side-125767 build target, i.e. the build command should look like: ~~~ $ fedpkg build --target f44-build-side-125767 ~~~ Please be careful, because if you, by a chance, omit the f42-build-side-103200 target, you'll be building against Ruby 3.4 which is not what you want. The side tag might not get autorefreshed, it can be requested like: ~~~ $ koji wait-repo f44-build-side-125767 --build ruby-4.0.0-30.fc44 The --request option is recommended for faster results This tag is not configured for automatic regeneration $ koji wait-repo f44-build-side-125767 --build ruby-4.0.0-30.fc44 --request ~~~ If you won't do it by yourself, I'll be rebuilding all packages after I am finished with my packages. I'll try to use fermig [2] to help me with that. If you don't want me to touch your packages for whatever reason, please let me know. Any help/testing/feedback is welcome. Jarek [1] https://src.fedoraproject.org/rpms/ruby/pull-request/222 [2] https://github.com/fedora-ruby/fermig

4 4

Current FTBFS status for ruby4.0.0dev (2025-12-12)
by Mamoru TASAKA 29 Dec '25

29 Dec '25

Hello, ruby-sig folks Again I tried rebuilding rubygem-XXX packages with 4.0.0dev (2025-12-12 master 2f151e76b5) . Currently (ignoring rubygem-jekyll related packages) 9 packages FTBFS, which is in better state than before. ------------------------------------- [1] rubygem-em-websocket https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-all-02/build/99… No match for argument: rubygem(em-spec) rubygem-em-spec is retired ------------------------------------- [2] rubygem-ethon https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-all-02/build/99… Failures: 1) Ethon::Multi::Options socket_action mode #timerfunction callbacks allows multi_code return values Failure/Error: expect(calls.last).to eq(-1) # cancels the timer expected: -1 got: 0 (compared using ==) # ./spec/ethon/multi/options_spec.rb:103:in 'block (4 levels) in <top (required)>' # /usr/share/rubygems/rubygems.rb:303:in 'Kernel#load' # /usr/share/rubygems/rubygems.rb:303:in 'Gem.activate_and_load_bin_path' Currently discussed on: https://github.com/typhoeus/ethon/issues/269 This failure begins with curl 8.16.0, not sure which side (curl or rubygem-ethon) should be fixed. ------------------------------------- [3] rubygem-gem2rpm https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-all-02/build/99… As I said previously, ostruct dep is needed + some backports from the upstream git is needed ref: https://github.com/fedora-ruby/gem2rpm/issues/127 ------------------------------------- [4] rubygem-image_processing https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-all-02/build/99… Note that the below error happens only on s390x (although rubygem-image_processing itself is noarch) 1) Failure: ImageProcessing::Vips::#resize_and_pad#test_0007_accepts sharpening options [test/vips_test.rb:318]: Expected sharpened thumbnail to have bigger filesize than not sharpened thumbnail 2) Failure: ImageProcessing::Vips::#resize_to_fit#test_0007_accepts sharpening options [test/vips_test.rb:228]: Expected sharpened thumbnail to have bigger filesize than not sharpened thumbnail 3) Failure: ImageProcessing::Vips::#resize_to_limit#test_0007_accepts sharpening options [test/vips_test.rb:180]: Expected sharpened thumbnail to have bigger filesize than not sharpened thumbnail 4) Failure: ImageProcessing::Vips::#resize_to_fill#test_0005_accepts sharpening options [test/vips_test.rb:264]: Expected sharpened thumbnail to have bigger filesize than not sharpened thumbnail 5) Failure: ImageProcessing::Vips::#resize_to_cover#test_0012_accepts sharpening options [test/vips_test.rb:385]: Expected sharpened thumbnail to have bigger filesize than not sharpened thumbnail 178 runs, 247 assertions, 5 failures, 0 errors, 41 skips Perhaps something is wrong on vips (libvips), maybe data size v.s. read size mismatch (as s390x is big endian) because libvips uses variable argument, but not sure ------------------------------------- (ignoring rubygem-jekyll-XXX packages) ------------------------------------- [5] rubygem-nenv https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-all-02/build/99… No match for argument: rubygem(coveralls) rubygem-coveralls is retired ------------------------------------- [6] rubygem-pathspec https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-all-02/build/99… No match for argument: rubygem(fakefs) rubygem-fakefs is retired ------------------------------------- [7] rubygem-rdoc https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-all-02/build/99… Processing files: rubygem-rdoc-6.14.2-201.fc44.251212.23.noarch error: File not found: /builddir/build/BUILD/rubygem-rdoc-6.14.2-build/BUILDROOT/usr/share/gems/plugins/rdoc_plugin.rb So rdoc_plugin.rb is now not generated, as I said in previous report. https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.… ------------------------------------- [8] rubygem-sinatra-cross_origin https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-all-02/build/99… Something like F =============================================================================== Failure: test_allow_any_origin(AllRoutesTest): <false> is not true. /builddir/build/BUILD/rubygem-sinatra-cross_origin-0.4.0-build/sinatra-cross_origin-0.4.0/usr/share/gems/gems/sinatra-cross_origin-0.4.0/test/test_all.rb:115:in 'AllRoutesTest#test_allow_any_origin' 112: 113: def test_allow_any_origin 114: get '/', {}, {'HTTP_ORIGIN' => 'http://localhost'} => 115: assert last_response.ok? 116: assert_equal 'http://localhost', last_response.headers['Access-Control-Allow-Origin'] 117: end 118: =============================================================================== Perhaps due to not supporting rubygem-rack 3: perhaps uppercase header name is rejected or so. ------------------------------------- [9] rubygem-yard https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-all-02/build/99… Something like 3) YARD::Handlers::Ruby::Base#valid_handler? handles #method_call(:methname) on a valid AST Failure/Error: ast = Parser::Ruby::RubyParser.parse(<<-"eof").ast meth # 0 meth() # 1 meth(1,2,3) # 2 meth 1,2,3 # 3 NotMeth.meth # 4 NotMeth.meth { } # 5 NotMeth.meth do end # 6 NotMeth.meth 1, 2, 3 # 7 NotMeth.meth(1, 2, 3) # 8 NameError: uninitialized constant YARD::Tags::TypesExplainer::Parser::Ruby # ./spec/handlers/ruby/base_spec.rb:78:in 'block (2 levels) in <top (required)>' # ./spec/spec_helper.rb:133:in 'block (2 levels) in <top (required)>' # /usr/share/rubygems/rubygems.rb:303:in 'Kernel#load' # /usr/share/rubygems/rubygems.rb:303:in 'Gem.activate_and_load_bin_path' I repoted this as https://github.com/lsegal/yard/issues/1635 Currently no idea how to fix this...... ============================================= And aside from the above rubygem-XXXX packages: ------------------------------------- ○ openwsman https://copr.fedorainfracloud.org/coprs/mtasaka/rubydep-heavypkg-40-01/buil… [ 71%] Generating html cd /builddir/build/BUILD/openwsman-2.8.1-build/openwsman-2.8.1/bindings/ruby && /usr/bin/cmake -E echo_append Creating\ rdoc\ documentation\ ... Creating rdoc documentation ...cd /builddir/build/BUILD/openwsman-2.8.1-build/openwsman-2.8.1/bindings/ruby && rm -rf /builddir/build/BUILD/openwsman-2.8.1-build/openwsman-2.8.1/build/bindings/ruby/html cd /builddir/build/BUILD/openwsman-2.8.1-build/openwsman-2.8.1/bindings/ruby && ./rdoc 4.0 -o /builddir/build/BUILD/openwsman-2.8.1-build/openwsman-2.8.1/build/bindings/ruby/html -t Openwsman\ -\ WS-Management\ for\ all -m README.rdoc README.rdoc ../openwsman.i ../*.i openwsman/*.rb Parsing sources... 7% [ 1/13] ../openwsman.i Before reporting this, could you check that the file you're documenting has proper syntax: /usr/bin/ruby -c ../openwsman.i RDoc is not a full Ruby parser and will fail when fed invalid ruby programs. The internal error was: (ArgumentError) wrong number of arguments (given 0, expected 1) uh-oh! RDoc had a problem: wrong number of arguments (given 0, expected 1) Already reported: https://bugzilla.redhat.com/show_bug.cgi?id=2417699 This is due to rdoc side change, fix proposal provided. ------------------------------------- ○ vagrant-libvirt https://copr.fedorainfracloud.org/coprs/mtasaka/rubydep-heavypkg-40-01/buil… Several failures, but many (or all) of these looks like Failures: 1) VagrantPlugins::ProviderLibvirt::Config#finalize! @uri should handle inputs {uri: "qemu+libssh2://user@remote/system?known_hosts=/home/user/.ssh/known_hosts"} with env () Failure/Error: params = CGI.parse(uri.query) NoMethodError: undefined method 'parse' for class CGI # ./lib/vagrant-libvirt/config.rb:1330:in 'VagrantPlugins::ProviderLibvirt::Config#finalize_from_uri' # ./lib/vagrant-libvirt/config.rb:939:in 'VagrantPlugins::ProviderLibvirt::Config#finalize!' # ./spec/unit/config_spec.rb:317:in 'block (5 levels) in <top (required)>' # ./spec/support/unit_context.rb:51:in 'block (3 levels) in <top (required)>' # ./spec/support/unit_context.rb:43:in 'block (2 levels) in <top (required)>' # /usr/share/rubygems/rubygems.rb:303:in 'Kernel#load' # /usr/share/rubygems/rubygems.rb:303:in 'Gem.activate_and_load_bin_path' # /usr/share/rubygems/rubygems.rb:303:in 'Kernel#load' # /usr/share/rubygems/rubygems.rb:303:in 'Gem.activate_and_load_bin_path' So this is CGI deprecation for ruby4.0.0dev (maybe I have already written this before) ------------------------------------- ○ vim https://copr.fedorainfracloud.org/coprs/mtasaka/rubydep-heavypkg-40-01/buil… /usr/bin/ld: /tmp/ccf8xpkK.ltrans71.ltrans.o: in function `get_buf': /usr/include/ruby/internal/core/rtypeddata.h:624:(.text+0x190b): undefined reference to `rb_check_typeddata' /usr/bin/ld: /tmp/ccf8xpkK.ltrans71.ltrans.o: in function `get_win': /usr/include/ruby/internal/core/rtypeddata.h:624:(.text+0x1a8b): undefined reference to `rb_check_typeddata' collect2: error: ld returned 1 exit status This is reported as https://github.com/vim/vim/issues/18884 vim does not directly linked against libruby.so: it tried to dlopen this so vim defines some wrapper function internally for functions provided by ruby header. But with https://github.com/ruby/ruby/pull/15387 one inline function gets used, and vim side trick is not working for this inline function now. Regards, Mamoru

4 13

Enabling Packit CI for rpms/ruby
by Vít Ondruch 16 Dec '25

16 Dec '25

Hi, just saw recently multiple references to Packit CI [1] on fedora-devel, looked around and decided to give it a try. So here is a PR requesting enabling Packit for `ruby` package: https://github.com/packit/deployment/pull/678 Feel free to object here or there. Vít [1]: https://fedoraproject.org/wiki/Changes/PackitDistgitCI

1 1

Current FTBFS status of rubygem-XXX packages for ruby4.0.0dev
by Mamoru TASAKA 12 Dec '25

12 Dec '25

Hello, ruby-sig folks: Trying with ruby 4.0.0dev (2025-11-27 master bee02c41bc) +PRISM [x86_64-linux]: https://github.com/ruby/ruby/commit/bee02c41bc15780a45f47986ef638e17ca323ec3 out of ~407 rubygem-XXXX packages, currently 22 packages FTBFS. 9 of them are due to dependencies for already retired packages. ------------------------------------- [ 1] rubygem-em-websocket https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-all-01/build/97… No match for argument: rubygem(em-spec) Perhaps needed dependency has already retired. ------------------------------------- [ 2] rubygem-ethon https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-all-01/build/98… Failures: 1) Ethon::Multi::Options socket_action mode #timerfunction callbacks allows multi_code return values Failure/Error: expect(calls.last).to eq(-1) # cancels the timer expected: -1 got: 0 (compared using ==) # ./spec/ethon/multi/options_spec.rb:103:in 'block (4 levels) in <top (required)>' Not investigated yet ------------------------------------- [ 3] rubygem-faraday https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-all-01/build/98… So many errors: 2265 examples, 119 failures, 1 pending Many of them looks like below, perhaps incompatibility with rack3 NoMethodError: undefined method 'read' for nil # ./spec/support/webmock_rack_app.rb:52:in 'WebmockRackApp#req_body' # ./spec/support/webmock_rack_app.rb:11:in 'WebmockRackApp#call' # /usr/share/gems/gems/rack-test-2.2.0/lib/rack/test.rb:360:in 'Rack::Test::Session#process_request' # /usr/share/gems/gems/rack-test-2.2.0/lib/rack/test.rb:153:in 'Rack::Test::Session#request' # ./lib/faraday/adapter/rack.rb:63:in 'Faraday::Adapter::Rack#execute_request' # ./lib/faraday/adapter/rack.rb:47:in 'Faraday::Adapter::Rack#call' # ./lib/faraday/response.rb:11:in 'Faraday::Response::Middleware#call' # ./lib/faraday/request/url_encoded.rb:25:in 'Faraday::Request::UrlEncoded#call' # ./lib/faraday/request/multipart.rb:25:in 'Faraday::Request::Multipart#call' # ./lib/faraday/rack_builder.rb:153:in 'Faraday::RackBuilder#build_response' ------------------------------------- [ 4] rubygem-gem2rpm https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-all-01/build/98… /builddir/build/BUILD/rubygem-gem2rpm-1.0.2-build/gem2rpm-1.0.2/usr/share/gems/gems/gem2rpm-1.0.2/lib/gem2rpm/gem/spec_fetcher.rb:2:in 'Kernel#require': cannot load such file -- ostruct (LoadError) ostruct dep is needed + some backports from the upstream git is needed ref: https://github.com/fedora-ruby/gem2rpm/issues/127 ------------------------------------- [ 5] rubygem-jekyll https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-all-01/build/98… [ 6] rubygem-jekyll-asciidoc https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-all-01/build/98… [ 7] rubygem-jekyll-feed https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-all-01/build/98… [ 8] rubygem-jekyll-git-authors https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-all-01/build/98… [ 9] rubygem-jekyll-sass-converter https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-all-01/build/98… [10] rubygem-jekyll-toc https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-all-01/build/98… No match for argument: rubygem(terminal-table) Needed dependency is retired ------------------------------------- [11] rubygem-mini_magick https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-all-01/build/98… Failures: 1) MiniMagick::Image#composite yields an optional block Failure/Error: yield composite if block_given? TypeError: wrong argument type MiniMagick::Tool (expected Array) # ./lib/mini_magick/image.rb:515:in 'block in MiniMagick::Image#composite' # ./lib/mini_magick/tool.rb:34:in 'MiniMagick::Tool.new' # ./lib/mini_magick.rb:28:in 'block (2 levels) in <module:MiniMagick>' # ./lib/mini_magick/image.rb:514:in 'MiniMagick::Image#composite' # ./spec/lib/mini_magick/image_spec.rb:609:in 'block (4 levels) in <top (required)>' # ./spec/lib/mini_magick/image_spec.rb:610:in 'block (3 levels) in <top (required)>' Not knowing what this means. Reported to the upstream: https://github.com/minimagick/minimagick/issues/599 No response so far. Note that vagrant-libvirt is failing in the similar way at the first glance (note investigated in detail): https://copr.fedorainfracloud.org/coprs/mtasaka/rubydep-heavypkg-40-01/buil… 340) VagrantPlugins::ProviderLibvirt::Util::NetworkUtil #libvirt_networks should retrieve the list of networks Failure/Error: let(:machine) { iso_env.machine(:test, :libvirt) } TypeError: wrong argument type Vagrant::Config::V2::DummyConfig (expected Array) # /usr/share/vagrant/gems/gems/vagrant-2.3.4/plugins/kernel_v2/config/vm.rb:713:in 'Kernel#inspect' # /usr/share/vagrant/gems/gems/vagrant-2.3.4/plugins/kernel_v2/config/vm.rb:713:in 'VagrantPlugins::Kernel_V2::VMConfig#get_provider_config' # /usr/share/vagrant/gems/gems/vagrant-2.3.4/lib/vagrant/vagrantfile.rb:75:in 'Vagrant::Vagrantfile#machine' # /usr/share/vagrant/gems/gems/vagrant-2.3.4/lib/vagrant/environment.rb:740:in 'Vagrant::Environment#machine' # ./spec/support/unit_context.rb:26:in 'block (2 levels) in <top (required)>' # ./spec/support/unit_context.rb:37:in 'block (2 levels) in <top (required)>' # ./spec/support/unit_context.rb:51:in 'block (3 levels) in <top (required)>' # ./spec/support/unit_context.rb:43:in 'block (2 levels) in <top (required)>' # /usr/share/rubygems/rubygems.rb:303:in 'Kernel#load' # /usr/share/rubygems/rubygems.rb:303:in 'Gem.activate_and_load_bin_path' ------------------------------------- [12] rubygem-nenv https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-all-01/build/98… No match for argument: rubygem(coveralls) ------------------------------------- [13] rubygem-pathspec https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-all-01/build/98… No match for argument: rubygem(fakefs) ------------------------------------- [14] rubygem-pry https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-all-01/build/98… So many errors, not have investigated yet. ------------------------------------- [15] rubygem-rdoc https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-all-01/build/98… error: File not found: /builddir/build/BUILD/rubygem-rdoc-6.14.2-build/BUILDROOT/usr/share/gems/plugins/rdoc_plugin.rb This rdoc is 6.14.2, so first upgrading to the latest is bettter. ------------------------------------- [16] rubygem-redis-client https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-all-01/build/98… /usr/share/ruby/did_you_mean/core_ext/name_error.rb:24: warning: benchmark is not part of the default gems since Ruby 4.0.0. Install benchmark from RubyGems. But even if adding "BR: rubygem(benchmark)", build still fails like: https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-trybuild-01/bui… 375 runs, 204 assertions, 0 failures, 320 errors, 0 skips All looks like 320) Error: RedisClientTest#test_measure_round_trip_delay: RedisClient::CannotConnectError: Connection refused - connect(2) for 127.0.0.1:16380 (redis://127.0.0.1:16380) /usr/share/ruby/socket.rb:1661:in 'Socket#__connect_nonblock' /usr/share/ruby/socket.rb:1661:in 'Socket#connect_nonblock' /usr/share/ruby/socket.rb:60:in 'Addrinfo#connect_internal' /usr/share/ruby/socket.rb:141:in 'Addrinfo#connect' /usr/share/ruby/socket.rb:954:in 'block in Socket.tcp_without_fast_fallback' /usr/share/ruby/socket.rb:231:in 'Array#each' /usr/share/ruby/socket.rb:231:in 'Addrinfo.foreach' /usr/share/ruby/socket.rb:943:in 'Socket.tcp_without_fast_fallback' /usr/share/ruby/socket.rb:671:in 'Socket.tcp' lib/redis_client/ruby_connection.rb:119:in 'RedisClient::RubyConnection#connect' lib/redis_client/ruby_connection.rb:51:in 'RedisClient::RubyConnection#initialize' lib/redis_client.rb:746:in 'block in RedisClient#connect' lib/redis_client/middlewares.rb:12:in 'RedisClient::BasicMiddleware#connect' lib/redis_client.rb:745:in 'RedisClient#connect' lib/redis_client.rb:732:in 'RedisClient#raw_connection' lib/redis_client.rb:697:in 'RedisClient#ensure_connected' lib/redis_client.rb:277:in 'RedisClient#call' test/support/client_test_helper.rb:43:in 'ClientTestHelper#setup' ------------------------------------- [17] rubygem-rspec-core https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-all-01/build/98… Failed examples: rspec ./spec/rspec/core/shared_example_group_spec.rb[1:3:8] # RSpec::Core::SharedExampleGroup shared_examples_for displays a helpful message when you define a shared example group in *_spec.rb file rspec ./spec/rspec/core/shared_example_group_spec.rb[1:2:8] # RSpec::Core::SharedExampleGroup shared_examples displays a helpful message when you define a shared example group in *_spec.rb file rspec ./spec/rspec/core/shared_example_group_spec.rb[1:4:8] # RSpec::Core::SharedExampleGroup shared_context displays a helpful message when you define a shared example group in *_spec.rb file rspec ./spec/rspec/core/hooks_spec.rb:187 # RSpec::Core::Hooks#around when it does not run the example indicates which around hook did not run the example in the pending message Not having investigated yet, however perhaps error message format changed. ------------------------------------- [18] rubygem-rspec-expectations https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-all-01/build/98… Many errors: 2441 examples, 28 failures, 8 pending Not having investigated yet, however perhaps error message format changed. ------------------------------------- [19] rubygem-rspec-mocks https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-all-01/build/98… Failures: 1) RSpec::Mocks::Matchers::Receive expect(...).to receive ordered with receive counts does not result in infinite recursion when `respond_to?` is stubbed Failure/Error: expect { obj = Object.new expect(obj).to receive(:respond_to?).with('something highly unlikely') obj.respond_to?(:not_what_we_wanted) }.to raise_error(/received :respond_to\? with unexpected arguments/) expected Exception with message matching /received :respond_to\? with unexpected arguments/, got #<SystemStackError: stack level too deep> with backtrace: # ./spec/rspec/mocks/matchers/receive_spec.rb:673:in 'block (5 levels) in <module:Mocks>' # ./spec/rspec/mocks/matchers/receive_spec.rb:674:in 'block (4 levels) in <module:Mocks>' # /usr/share/gems/gems/aruba-2.3.2/lib/aruba/rspec.rb:40:in 'block (2 levels) in <top (required)>' # /usr/share/gems/gems/aruba-2.3.2/lib/aruba/rspec.rb:27:in 'block (2 levels) in <top (required)>' # ./spec/rspec/mocks/matchers/receive_spec.rb:674:in 'block (4 levels) in <module:Mocks>' # /usr/share/gems/gems/aruba-2.3.2/lib/aruba/rspec.rb:40:in 'block (2 levels) in <top (required)>' # /usr/share/gems/gems/aruba-2.3.2/lib/aruba/rspec.rb:27:in 'block (2 levels) in <top (required)>' Not having investigated yet, anyway will have to report to the upstream ------------------------------------- [20] rubygem-sinatra https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-all-01/build/98… 1) Failure: RdocTest#test_renders_rdoc_files_in_views_path_0 [test/rdoc_test.rb:25]: Expected /<h1[^>]*>Hello From RDoc(<span><a href=\"#label-Hello\+From\+RDoc\">¶<\/a> <a href=\"#(documentation|top)\">↑<\/a><\/span>)?<\/h1>/ to match # encoding: ASCII-8BIT # valid: true "\n<h1 id=\"label-Hello+From+RDoc\"><a href=\"#label-Hello+From+RDoc\">Hello From RDoc</a></h1>\n". 2) Failure: RdocTest#test_renders_inline_rdoc_strings_0 [test/rdoc_test.rb:19]: Expected /<h1[^>]*>Hiya(<span><a href=\"#label-Hiya\">¶<\/a> <a href=\"#(documentation|top)\">↑<\/a><\/span>)?<\/h1>/ to match # encoding: ASCII-8BIT # valid: true "\n<h1 id=\"label-Hiya\"><a href=\"#label-Hiya\">Hiya</a></h1>\n". 1036 runs, 2332 assertions, 2 failures, 0 errors, 3 skips Recently rdoc is upgraded to 2.16.0 and perhaps some output from rdoc changed. ------------------------------------- [21] rubygem-sinatra-cross_origin https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-all-01/build/98… 13 tests, 13 assertions, 13 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications Maybe incompatibility with rack3 which rejects upper case in header. ------------------------------------- [22] rubygem-yard https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-all-01/build/98… rspec ./spec/handlers/ruby/base_spec.rb:35 # YARD::Handlers::Ruby::Base#valid_handler? handles string input (matches AstNode#source) rspec ./spec/handlers/ruby/base_spec.rb:54 # YARD::Handlers::Ruby::Base#valid_handler? handles regex input (matches AstNode#source) rspec ./spec/handlers/ruby/base_spec.rb:73 # YARD::Handlers::Ruby::Base#valid_handler? handles #method_call(:methname) on a valid AST All of these contains: NameError: uninitialized constant YARD::Tags::TypesExplainer::Parser::Ruby # ./spec/handlers/ruby/base_spec.rb:59:in 'block (2 levels) in <top (required)>' # ./spec/spec_helper.rb:129:in 'block (2 levels) in <top (required)>' I don't know what the above means so far. Reported: https://github.com/lsegal/yard/issues/1635 No response so far Regards, Mamoru

4 13

SPDX Status for Rubygems in Fedora as of 2025-05-12
by Jarek Prokop 05 Dec '25

05 Dec '25

Hi all, recent SPDX status for RubyGems. Jarek * Total rubygems in Fedora: 408 * Total rubygems checked: 406 * Fedora License field and gem2rpm license match and license-validate succeeds: 296/406 * license-validate says they are OK SPDX, but licenses may or may not match between Fedora and upstream: 390/406 * license-validate with converted conjunctions: 390/406 * Action required: 0/406 Packages that need to convert to valid SPDX: None! Packages that contain LicenseRef-Callaway-.* (and should be reviewed and converted to SPDX): rubygem-, fedora_license rubygem-ansi, LicenseRef-Callaway-BSD rubygem-bcrypt_pbkdf,LicenseRef-Callaway-MIT AND LicenseRef-Callaway-BSD AND ISC rubygem-cookiejar, LicenseRef-Callaway-BSD rubygem-hashery, LicenseRef-Callaway-BSD rubygem-idn, Apache-2.0 AND LicenseRef-Callaway-LGPLv2+ rubygem-macaddr, Ruby OR LicenseRef-Callaway-BSD rubygem-narray, LicenseRef-Callaway-BSD AND Ruby rubygem-ncursesw, LicenseRef-Callaway-LGPLv2+ rubygem-open4, LicenseRef-Callaway-BSD OR Ruby rubygem-rchardet, LicenseRef-Callaway-LGPLv2 rubygem-rmail, LicenseRef-Callaway-BSD rubygem-scanf, LicenseRef-Callaway-BSD rubygem-uuid, LicenseRef-Callaway-MIT OR LicenseRef-Callaway-CC-BY-SA rubygem-xmlrpc, Ruby OR LicenseRef-Callaway-BSD Package author list: package, owner(, other contributors) rubygem-ansi: stevetraylen rubygem-bcrypt_pbkdf: jackorp, pvalena rubygem-cookiejar: vondruch, ruby-packagers-sig, pvalena rubygem-hashery: vondruch, ruby-packagers-sig, pvalena rubygem-idn: spstarr, tdawson rubygem-macaddr: valtri rubygem-narray: besser82 rubygem-ncursesw: dcallagh rubygem-open4: vondruch, tdawson rubygem-rchardet: stevetraylen rubygem-rmail: dcallagh rubygem-scanf: ekohl, brandfbb rubygem-uuid: valtri rubygem-xmlrpc: jackorp, pvalena

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

ruby-sig