Dne 17. 09. 23 v 15:42 Mamoru TASAKA napsal(a):
Mamoru TASAKA wrote on 2023/09/14 21:13:Hello, Vít:Thank you for initial work for ruby 3.3 . Vít Ondruch wrote on 2023/09/12 17:08:* `%gem_spec` macro with options:https://src.fedoraproject.org/fork/vondruch/rpms/ruby/blob/77c580dfa85f921d969a8da68eaf6e88987aab8a/f/macros.rubygems#_10This is my initial version, just to enable to use this macro in ruby.spec. I think I'll similarly modify all the related macros. While they'll be more complex, their use in ruby.spec will outweigh that. And I should add some documentation ...BTW there are several possibilities in choosing how complex/flexible this macro will be and I think this is one of the changes which could be backported to Ruby 3.2. So feedback is appreciated. Looking at the macro, this bit `%{?1:%{expand:%{%{1}_version}}}%{!?1:%{version}}` is probably not very good idea for possible use in rubygem-*.gemspec.I think this should be :%gem_spec(d) %{gem_dir}/specifications%{?-d:/default}/%{?1}%{!?1:%{gem_name}}-%{?1:%{expand:%{%{1}_version}}}%{!?1:%{version}}%{?prerelease}.gemspec(instead of %gem_spec(d) %{gem_dir}/specifications%{?-d:/default}/%{1}..... )Otherwise, for example trying to build rubygem-json fails like: ------------------------------------------- Processing files: rubygem-json-2.6.3-204.fc40.x86_64error: File not found: /builddir/build/BUILDROOT/rubygem-json-2.6.3-204.fc40.101.x86_64/usr/share/gems/specifications/%{1}json-2.6.3.gemspec File not found: /builddir/build/BUILDROOT/rubygem-json-2.6.3-204.fc40.101.x86_64/usr/share/gems/specifications/%{1}json-2.6.3.gemspec-------------------------------------------Now I am trying to rebuild gem related pkgs depending on libruby.3.2 (with using %{?1} for %gem_spec macro)Okay, so with my initial builds for rubygem-XXXX packages, among 456 packages,50 packages failed to build (1 just fixed one of them, so currently 49).https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/packages/Some types of errors (I noticed) which is affecting several packages are: * minitest 5.19 side change: MiniTest class support deprecated: example:test/test_async.rb:28:in `<main>': uninitialized constant MiniTest (NameError)https://github.com/minitest/minitest/commit/a2c6c18570f6f0a1bf6af70fe3b6d9599a13fdd6
While I am aware of this issue in rubygem-async_sinatra, I have let this package deliberately unfixed, because I don't think it is maintained. So either their maintainer will fix it or it will be later automatically removed from Fedora. I don't really intend to prolong life of such packages.
* ruby logger change. example: NoMethodError: undefined method `[]' for nil https://github.com/ruby/logger/pull/85 -> affects like https://github.com/resque/resque/issues/1856 * Regexp.new now rejects 3rd argument: example: wrong number of arguments (given 3, expected 1..2) https://github.com/ruby/ruby/pull/7039* mocha being updated from 1.15.0 to 2.1 - perhaps some adjustment is neededexample: `require': cannot load such file -- mocha/setup (LoadError)
Assuming this is about rubygem-rack-cors, this is similar case to the rubygem-async_sinatra. I have submitted fix upstream:
https://github.com/cyu/rack-cors/pull/266 and put @valtri on CC. So he should be aware.
* Some packages expect that there are no warnings, but now with ruby3.3 when trying to load default gems which are going to be gemified, warnings are generated like: $ ruby -e "require 'csv'"-e:1: warning: csv which will be not part of the default gems since Ruby 3.4.0
I think that this was reported here: https://bugs.ruby-lang.org/issues/19885
https://github.com/ruby/ruby/pull/8126 , and the above warnings cause some tests fail.So this may mean that we have to package those default gems into separatedrubygem-XXX srpm , at least before ruby 3.4 lands. * And, currently some tests segfault. * (Just note that there are some other reasons which cause test failure: I have not investigated them yet.) Some topics:* rubygem-nifti sees test failure on s390x, this is perhaps big endian issue.
Interesting. nifti failed during mass rebuild, but later it was update by its maintainer. So it would probably deserve bug report and maybe some `ExcludeArch`?
* rubygem-byebug fails to build (on test suite), however it seems this needs the undestanding of ruby internal change, and seems very difficult for me....
Is there any future in byebug? Wasn't it obsoleted/replaced by the `debug` gem which is shipped with Ruby?
I may post some detailed results (if I have time), however as I wrote abovethe results can be shown on:https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/packages/
Thank you for the initial tests. I'll look into your findings later in more detail. These were just quick notes mostly just from my memory :)
Vít
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org 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/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
