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/9904439/
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/9904435/

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/9904415/

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/9904379/

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/9904313/

No match for argument: rubygem(coveralls)
rubygem-coveralls is retired

-------------------------------------
[6] rubygem-pathspec
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-all-02/build/9904291/

No match for argument: rubygem(fakefs)
rubygem-fakefs is retired

-------------------------------------
[7] rubygem-rdoc
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-all-02/build/9904241/

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/[email protected]/message/AYPBLU5H42GPFGZCBBPCOXOKGVVUQ42G/

-------------------------------------
[8] rubygem-sinatra-cross_origin
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygems-40-all-02/build/9904175/

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/9904112/

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/build/9904618/

[ 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/build/9904657/

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/build/9904661/

/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
--
_______________________________________________
ruby-sig mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to