ruby-sig September 2024

ruby-sig@lists.fedoraproject.org

3 participants
5 discussions

mass prebuild
by Vít Ondruch 10 Jun '25

10 Jun '25

Looking at the failures reported by Koschei after last rubygem-minitest rebase, I'd like to suggest everybody to use the mass-prebuild tool: https://gitlab.com/fedora/packager-tools/mass-prebuild This tool allows to rebuild all reverse dependencies in copr, preventing breakages. This would be the minimal config required for minitest: ~~~ $ cat mpb.config archs: x86_64 chroot: fedora-rawhide name: mpb packages: rubygem-minitest: src_type: file src: /home/vondruch/fedora-scm/own/rubygem-minitest/rubygem-minitest-5.19.0-200.fc39.src.rpm verbose: 1 retry: 2 ~~~ Which is then executed via simple `mpb` command. Because I'd like to start from scratch, I also like to clean the results of prior run: ~~~ $ mpb --clean --buildid 1 $ rm -rf ~/.mpb/ ~~~ This should delete the copr `mpb` repository as well as the mass-prebuild database. But feel free to experiment with the tool. It provides more knobs which allows you to tune the experience to your needs. HTH Vít

1 5

SPDX Status for Rubygems in Fedora as of 2024-09-19
by Jarek Prokop 19 Sep '24

19 Sep '24

Hi, Here's the recent report. Newly, licenses contain LicenseRef-Callaway-*. I have therefore split package report to 2 parts, 1st part are packages that need attention due to the License field in RPMs is not valid in neither the legacy Callaway or the "new" SPDX format, IOW they could not be converted into the LicenseRef-Callaway. "Action required" field reflects this, as from the comment above the changed license from Miroslav who comitted change LicenseRef-Callaway-* license identifiers are from my understanding not recommended to keep around forever and it is heavily recommended to review these packages to fix the license so they will be mentioned in these reports from here on out. Regards Jarek * Total rubygems in Fedora: 446 * Excluded gems: rubygem-krb5-auth rubygem-rgen rubygem-net-irc * Total rubygems checked: 440 * Fedora License field and gem2rpm license match and license-validate succeeds: 298/440 * license-validate says they are OK SPDX, but licenses may or may not match between Fedora and upstream: 414/440 * license-validate with converted conjunctions: 414/440 * Action required: 3/440 Packages that need to convert to valid SPDX: rubygem-, fedora_license rubygem-rdoc, GPL-2.0 AND Ruby AND BSD-3-Clause AND CC-BY-2.5 AND OFL-1.1-RFN rubygem-ruby-shadow,Public Domain rubygem-xmlparser, GPLv2+ and ( Ruby or GPLv2+ or MIT ) and ( GPLv2+ or Artistic ) Packages that contain LicenseRef-Callaway-.* (and should be reviewed and converted to SPDX): rubygem-, fedora_license rubygem-ansi, LicenseRef-Callaway-BSD rubygem-bcrypt, LicenseRef-Callaway-MIT AND LicenseRef-Callaway-Public-Domain AND ISC rubygem-bcrypt_pbkdf,LicenseRef-Callaway-MIT AND LicenseRef-Callaway-BSD AND ISC rubygem-cookiejar, LicenseRef-Callaway-BSD rubygem-ffi, LicenseRef-Callaway-BSD rubygem-hashery, LicenseRef-Callaway-BSD rubygem-hiredis, LicenseRef-Callaway-BSD rubygem-httpclient, (Ruby OR LicenseRef-Callaway-BSD) AND LicenseRef-Callaway-Public-Domain rubygem-idn, Apache-2.0 AND LicenseRef-Callaway-LGPLv2+ rubygem-macaddr, Ruby OR LicenseRef-Callaway-BSD rubygem-marcel, LicenseRef-Callaway-MIT AND Apache-2.0 rubygem-narray, LicenseRef-Callaway-BSD AND Ruby rubygem-ncursesw, LicenseRef-Callaway-LGPLv2+ rubygem-open4, LicenseRef-Callaway-BSD OR Ruby rubygem-rack, LicenseRef-Callaway-MIT AND LicenseRef-Callaway-BSD rubygem-rchardet, LicenseRef-Callaway-LGPLv2 rubygem-rmail, LicenseRef-Callaway-BSD rubygem-ruby-libvirt,LicenseRef-Callaway-LGPLv2+ rubygem-sassc-rails, LicenseRef-Callaway-MIT AND LicenseRef-Callaway-OFL 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: vondruch, ruby-packagers-sig rubygem-bcrypt_pbkdf: pvalena rubygem-cookiejar: pvalena, ruby-packagers-sig rubygem-ffi: vondruch, ruby-packagers-sig, tdawson rubygem-hashery: pvalena, ruby-packagers-sig rubygem-hiredis: pvalena, tdawson rubygem-httpclient: tdawson, brandfbb, maxamillion, rcallicotte rubygem-idn: spstarr, tdawson rubygem-macaddr: valtri rubygem-marcel: pvalena, ruby-packagers-sig rubygem-narray: besser82 rubygem-ncursesw: dcallagh rubygem-open4: vondruch, tdawson rubygem-rack: pvalena, ruby-packagers-sig, vondruch, tdawson rubygem-rchardet: stevetraylen rubygem-rdoc: vondruch, ruby-packagers-sig rubygem-rmail: dcallagh rubygem-ruby-libvirt: vondruch, ruby-packagers-sig, clalance, tdawson rubygem-ruby-shadow: terjeros, ignatenkobrain rubygem-sassc-rails: pvalena rubygem-scanf: ekohl, brandfbb rubygem-uuid: valtri rubygem-xmlparser: schwicke rubygem-xmlrpc: pvalena

1 0

Recent build failures of gem-based packages
by Mamoru TASAKA 12 Sep '24

12 Sep '24

Hello, ruby-sig folks: Recently I wanted to update packages I maintain, so I tried rebuilding gem-based packages, and now I see some gem-based packages began to FTBFS newly, and it seems that they are not related to the packages I was going to update. Also koschei shows they began to FTBFS recently. Some pickups: ===================================================== * rubygem-prawn-svg https://koschei.fedoraproject.org/package/rubygem-prawn-svg Failures: 1) Prawn::SVG::Document#initialize when unparsable XML is provided raises an exception Failure/Error: expect do Prawn::SVG::Document.new(svg, bounds, options) end.to raise_error Prawn::SVG::Document::InvalidSVGData, 'The data supplied is not a valid SVG document.' expected Prawn::SVG::Document::InvalidSVGData with "The data supplied is not a valid SVG document.", got #<REXML::ParseException:"Malformed XML: Content at the start of the document (got 'this isn't SVG data')\nLine: 1\nPosition: 19\nLast 80 unconsumed characters:\n"> with backtrace: I've reported this to the upstream: https://github.com/mogest/prawn-svg/pull/171 This is because of rubygem-rexml update (in ruby.src): v3.2.8 -> 3.3.6 , especially: https://github.com/ruby/rexml/commit/2bca7bd84a5cf13af8f5633dd7d3d519fc990d… (Add support for detecting invalid XML that has unsupported content before root element) ===================================================== * rubygem-railties https://koschei.fedoraproject.org/package/rubygem-railties + find test -type f -name '*_test.rb' -print0 + sort -z + xargs -0 -n1 -i sh -c 'echo '\''* Test file: {}'\''; env -u NOTIFY_SOCKET bundle exec ruby -Itest -- '\''{}'\'' || exit 255' F Failure: ApplicationTests::BinSetupTest#test_bin_setup_output [test/application/bin_setup_test.rb:51]: --- expected +++ actual @@ -2,10 +2,16 @@ The Gemfile's dependencies are satisfied == Preparing database == +/usr/share/gems/gems/concurrent-ruby-1.1.9/lib/concurrent-ruby/concurrent/concern/deprecation.rb:1: warning: logger was loaded from the standard library, but will no longer be part of the default gems starting from Ruby 3.5.0. +You can add logger to your Gemfile or gemspec to silence this warning. Created database 'app_development' Created database 'app_test' Most probably due to ruby 3.3.4 -> 3.3.5 change, expecially: https://github.com/ruby/ruby/commit/9ae91eb2aa8a82315026e72fb58d89bc23432335 The following change to rubygem-railties.spec seems to workaround this: diff --git a/rubygem-railties.spec b/rubygem-railties.spec index 90b5037..9a8adf6 100644 --- a/rubygem-railties.spec +++ b/rubygem-railties.spec @@ -160,6 +160,7 @@ echo 'gem "dalli"' >> ../Gemfile echo 'gem "importmap-rails"' >> ../Gemfile echo 'gem "irb"' >> ../Gemfile echo 'gem "listen"' >> ../Gemfile +echo 'gem "logger"' >> ../Gemfile echo 'gem "method_source"' >> ../Gemfile echo 'gem "mysql2"' >> ../Gemfile echo 'gem "pg"' >> ../Gemfile ===================================================== * rubygem-shoulda-matchers https://koschei.fedoraproject.org/package/rubygem-shoulda-matchers + bundle exec rspec spec/unit An error occurred while loading ./spec/unit/shoulda/matchers/action_controller/callback_matcher_spec.rb. Failure/Error: require 'unit_spec_helper' NoMethodError: undefined method `join' for nil # /builddir/build/BUILD/rubygem-shoulda-matchers-5.1.0-build/spec/support/tests/command_runner.rb:165:in `ensure in run' # /builddir/build/BUILD/rubygem-shoulda-matchers-5.1.0-build/spec/support/tests/command_runner.rb:165:in `run' .... .... spec/support/tests/command_runner.rb reads: 149 def run 150 pid = spawn(env, *command, options) 151 t = Thread.new do 152 loop do 153 @command_output += reader.read_nonblock(4096) 154 rescue IO::WaitReadable 155 IO.select([reader]) 156 retry 157 rescue EOFError 158 break 159 end 160 end 161 Process.waitpid(pid) 162 @status = $? 163 ensure 164 writer.close unless writer.closed? 165 t.join <===================== 166 end So Thread.join is now failing. I think this is related to ruby.src 3.3.4 -> 3.3.5 change (looking at koschei changelog), however I have no idea why this is now failing... (BTW now I saw that Vít has posted another mail about rubygem-shoulda-matchers failure, not sure if this is related to bundler issue) ===================================================== * rubygem-shoulda-context https://koschei.fedoraproject.org/package/rubygem-shoulda-context + BUNDLE_GEMFILE=gemfiles/test.gemfile + bundle install --local Resolving dependencies... .... .... In test.gemfile: mocha was resolved to 2.1.0, which depends on ruby2_keywords error: Bad exit status from /var/tmp/rpm-tmp.vi0IhZ (%check) Maybe related to rubygem-bundler update (in ruby.src): v2.5.11 -> 2.5.16 , not knowing for now how to fix this. ===================================================== * rubygem-webmock https://koschei.fedoraproject.org/package/rubygem-webmock 1) WebMock::RequestPattern when matching when matching requests with body when body in pattern is declared as a hash for request with xml body and content type is set to xml standard application/xml behaves like a xml body should not match when body is not xml Failure/Error: Crack::XML.parse(body) REXML::ParseException: Malformed XML: Content at the start of the document (got 'foo bar') Line: 1 Position: 7 Last 80 unconsumed characters: Shared Example Group: "a xml body" called from ./spec/unit/request_pattern_spec.rb:630 # /usr/share/gems/gems/rexml-3.3.6/lib/rexml/parsers/baseparser.rb:511:in `pull_event' # /usr/share/gems/gems/rexml-3.3.6/lib/rexml/parsers/baseparser.rb:237:in `pull' # /usr/share/gems/gems/crack-1.0.0/lib/crack/xml.rb:203:in `parse' # /usr/share/gems/gems/crack-1.0.0/lib/crack/xml.rb:235:in `parse' # ./lib/webmock/request_pattern.rb:306:in `body_as_hash' # ./lib/webmock/request_pattern.rb:283:in `matches?' # ./lib/webmock/request_pattern.rb:38:in `matches?' # ./spec/unit/request_pattern_spec.rb:68:in `match' # ./spec/unit/request_pattern_spec.rb:615:in `block (7 levels) in <top (required)>' # ./lib/webmock/rspec.rb:37:in `block (2 levels) in <top (required)>' This also seems related to rubygem-rexml update as written in rubygem-prawn-svg . The problem here is that I have no idea currently where to fix error (that is, fix in crack library / fix in webmock library / or fix in webmock test code??) ===================================================== I would appreciate it if some would investigate these FTBFS issues. Regards, Mamoru

2 2

Bundler 2.5.16
by Vít Ondruch 12 Sep '24

12 Sep '24

Hi, With Ruby 3.3.5, there have landed also Bundler 2.5.16 and it seems it breaks rubygem-shoulda-matchers test suite [1] in very interesting way. Despite Bundler being executed with `--local` flag, it tries to reach internet, which of course is not possible in Koji. I have reported this upstream [2] and this [3] is the culprit so far. The problem here seems to be that Bundler now tries to handle default gems the same as regular gems, but that e.g. means cached .gem available, which is never the case for default gems nor it is case for our packaged gems. So please be careful if you are using Bundler especially in combination with packaged gems. Vít [1] https://bugzilla.redhat.com/show_bug.cgi?id=2311898 [2] https://github.com/rubygems/rubygems/issues/8025 [3] https://github.com/rubygems/rubygems/pull/7673

1 0

Future of -doc subpackages
by Vít Ondruch 02 Sep '24

02 Sep '24

Today, I had a discussion with Mikolaj Izdebsky, maintainer of various Java pacakges including Ant / Maven. At the beginning, he mentioned possible license issues he is dealing with in -javadoc subpackages, then he mentioned bundled jQuery, etc. All these issues are very familiar to me with the rubygem-*-doc subpackages. During the brainstorming, one of the proposed solutions was dropping the doc subpackages altogether. And I wonder, does anybody have use case for the -doc subpackages. I used to use RI, but I have not used it for ages. Is the RDoc HTML documentation useful for anybody? I personally always use online documentation, so I would not necessarily miss those. But does anybody else use it? This is more just to measure the sentiment, than that I would plan any action. OTOH, I would not mind if I would not need to close my eyes because of the unresolved bundling / licensing issues. Thanks. Vít

3 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

ruby-sig September 2024