Hi everybody,
It is the time of the year to look at upcoming version of Ruby. Therefore I have opened PR with the changes:
https://src.fedoraproject.org/rpms/ruby/pull-request/196
and here is the (running) scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=125191137
As already done previously, the PR is opened from my fork, so I'll be able to rebase it and pick some interesting bits into stable branches. I'll also push this branch into the official repo right before merge back into Rawhide to preserve the history.
And here are some interesting bits I have noticed:
* By far the biggest change are the unbundled default gems. While they are mostly kept in the `bundled-gems` subpackage, it grown significantly. I try to keep the file lists very similar to what would be the gem2rpm output.
* The other thing is that Ruby upstream for some unknown reason decide to put ruby executable into `libexec` directory, but not only that. There is also `bin` directory nested under. That is quite non-standard place IMHO, therefore I have reverted the change back to the previous location and I hope that upstream will change their mind (or at least provide some reasoning).
* From other changes, please note that the Prism parser is now used by default. I hope it won't have any compatibility impact, but who knows.
I am not aware of anything else.
As always, please give the Ruby 3.4 some testing and looking forward to your feedback.
Cheers,
Vít
Dne 25. 10. 24 v 14:09 Vít Ondruch napsal(a):
Hi everybody,
It is the time of the year to look at upcoming version of Ruby. Therefore I have opened PR with the changes:
https://src.fedoraproject.org/rpms/ruby/pull-request/196
and here is the (running) scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=125191137
There was failure on aarch64 due to hardening test. New build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=125192840
Vít
As already done previously, the PR is opened from my fork, so I'll be able to rebase it and pick some interesting bits into stable branches. I'll also push this branch into the official repo right before merge back into Rawhide to preserve the history.
And here are some interesting bits I have noticed:
- By far the biggest change are the unbundled default gems. While they
are mostly kept in the `bundled-gems` subpackage, it grown significantly. I try to keep the file lists very similar to what would be the gem2rpm output.
- The other thing is that Ruby upstream for some unknown reason decide
to put ruby executable into `libexec` directory, but not only that. There is also `bin` directory nested under. That is quite non-standard place IMHO, therefore I have reverted the change back to the previous location and I hope that upstream will change their mind (or at least provide some reasoning).
- From other changes, please note that the Prism parser is now used by
default. I hope it won't have any compatibility impact, but who knows.
I am not aware of anything else.
As always, please give the Ruby 3.4 some testing and looking forward to your feedback.
Cheers,
Vít
As its turn out, the Psych prerelease caused issues with installation. I did some changes in the spec file, extracting `%gem_versions` and `%gem_prerelease` macros. Now the installation works and the mass rebuild runs here:
https://copr.fedorainfracloud.org/coprs/vondruch/mpb/
One thing I have noticed so far is the extraction of gems from standard library, e.g. rubygem-asciidoctor [1] errors like:
~~~
3) Error: Minitest::Test::TestBlocks::TestImages#test_embeds_base64_encoded_data_uri_for_remote_image_when_imagesdir_is_a_URI_and_data_uri_attribute_is_set: LoadError: cannot load such file -- base64
~~~
And speaking of rubygem-asciidoctor, this also looks suspicious:
~~~
1) Failure: Minitest::Test::TestExtensions::TestIntegration#test_should_assign_captures_correctly_for_inline_macros [test/extensions_test.rb:1382]: --- expected +++ actual @@ -1,9 +1,9 @@ "target="", attributes={} -target="value,key=val", attributes={1=>"value", "key"=>"val", "name"=>"value"} -target="", attributes={"text"=>""} -target="[text]", attributes={"text"=>"[text]"} +target="value,key=val", attributes={1 => "value", "key" => "val", "name" => "value"} +target="", attributes={"text" => ""} +target="[text]", attributes={"text" => "[text]"} target="target", attributes={} -target="target", attributes={1=>"value", "key"=>"val", "name"=>"value"} -target="target", attributes={"text"=>""} -target="target", attributes={"text"=>"[text]"} +target="target", attributes={1 => "value", "key" => "val", "name" => "value"} +target="target", attributes={"text" => ""} +target="target", attributes={"text" => "[text]"} target="target", attributes={}"
~~~
That suggest there were added spaces around hash rocket in `#inspect` output. That might be annoying.
Vít
[1]: https://download.copr.fedorainfracloud.org/results/vondruch/mpb/fedora-rawhi...
Dne 25. 10. 24 v 14:57 Vít Ondruch napsal(a):
Dne 25. 10. 24 v 14:09 Vít Ondruch napsal(a):
Hi everybody,
It is the time of the year to look at upcoming version of Ruby. Therefore I have opened PR with the changes:
https://src.fedoraproject.org/rpms/ruby/pull-request/196
and here is the (running) scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=125191137
There was failure on aarch64 due to hardening test. New build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=125192840
Vít
As already done previously, the PR is opened from my fork, so I'll be able to rebase it and pick some interesting bits into stable branches. I'll also push this branch into the official repo right before merge back into Rawhide to preserve the history.
And here are some interesting bits I have noticed:
- By far the biggest change are the unbundled default gems. While
they are mostly kept in the `bundled-gems` subpackage, it grown significantly. I try to keep the file lists very similar to what would be the gem2rpm output.
- The other thing is that Ruby upstream for some unknown reason
decide to put ruby executable into `libexec` directory, but not only that. There is also `bin` directory nested under. That is quite non-standard place IMHO, therefore I have reverted the change back to the previous location and I hope that upstream will change their mind (or at least provide some reasoning).
- From other changes, please note that the Prism parser is now used
by default. I hope it won't have any compatibility impact, but who knows.
I am not aware of anything else.
As always, please give the Ruby 3.4 some testing and looking forward to your feedback.
Cheers,
Vít
Dne 31. 10. 24 v 10:56 Vít Ondruch napsal(a):
As its turn out, the Psych prerelease caused issues with installation. I did some changes in the spec file, extracting `%gem_versions` and `%gem_prerelease` macros. Now the installation works and the mass rebuild runs here:
https://copr.fedorainfracloud.org/coprs/vondruch/mpb/
One thing I have noticed so far is the extraction of gems from standard library, e.g. rubygem-asciidoctor [1] errors like:
3) Error: Minitest::Test::TestBlocks::TestImages#test_embeds_base64_encoded_data_uri_for_remote_image_when_imagesdir_is_a_URI_and_data_uri_attribute_is_set: LoadError: cannot load such file -- base64And speaking of rubygem-asciidoctor, this also looks suspicious:
1) Failure: Minitest::Test::TestExtensions::TestIntegration#test_should_assign_captures_correctly_for_inline_macros [test/extensions_test.rb:1382]: --- expected +++ actual @@ -1,9 +1,9 @@ "target=\"\", attributes={} -target=\"value,key=val\", attributes={1=>\"value\", \"key\"=>\"val\", \"name\"=>\"value\"} -target=\"\", attributes={\"text\"=>\"\"} -target=\"[text]\", attributes={\"text\"=>\"[text]\"} +target=\"value,key=val\", attributes={1 => \"value\", \"key\" => \"val\", \"name\" => \"value\"} +target=\"\", attributes={\"text\" => \"\"} +target=\"[text]\", attributes={\"text\" => \"[text]\"} target=\"target\", attributes={} -target=\"target\", attributes={1=>\"value\", \"key\"=>\"val\", \"name\"=>\"value\"} -target=\"target\", attributes={\"text\"=>\"\"} -target=\"target\", attributes={\"text\"=>\"[text]\"} +target=\"target\", attributes={1 => \"value\", \"key\" => \"val\", \"name\" => \"value\"} +target=\"target\", attributes={\"text\" => \"\"} +target=\"target\", attributes={\"text\" => \"[text]\"} target=\"target\", attributes={}"That suggest there were added spaces around hash rocket in `#inspect` output. That might be annoying.
Both reported here:
https://github.com/asciidoctor/asciidoctor/issues/4634
although the first will likely need to be fixed also on our side by `BR: rubygem(base64)`
Vít
Vít
Dne 25. 10. 24 v 14:57 Vít Ondruch napsal(a):
Dne 25. 10. 24 v 14:09 Vít Ondruch napsal(a):
Hi everybody,
It is the time of the year to look at upcoming version of Ruby. Therefore I have opened PR with the changes:
https://src.fedoraproject.org/rpms/ruby/pull-request/196
and here is the (running) scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=125191137
There was failure on aarch64 due to hardening test. New build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=125192840
Vít
As already done previously, the PR is opened from my fork, so I'll be able to rebase it and pick some interesting bits into stable branches. I'll also push this branch into the official repo right before merge back into Rawhide to preserve the history.
And here are some interesting bits I have noticed:
- By far the biggest change are the unbundled default gems. While
they are mostly kept in the `bundled-gems` subpackage, it grown significantly. I try to keep the file lists very similar to what would be the gem2rpm output.
- The other thing is that Ruby upstream for some unknown reason
decide to put ruby executable into `libexec` directory, but not only that. There is also `bin` directory nested under. That is quite non-standard place IMHO, therefore I have reverted the change back to the previous location and I hope that upstream will change their mind (or at least provide some reasoning).
- From other changes, please note that the Prism parser is now used
by default. I hope it won't have any compatibility impact, but who knows.
I am not aware of anything else.
As always, please give the Ruby 3.4 some testing and looking forward to your feedback.
Cheers,
Vít
although the first will likely need to be fixed also on our side by `BR:
rubygem(base64)`
No, that should not be necessary. Asciidoctor no longer uses base64. The package must be using an out of date version of Asciidoctor. See https://github.com/asciidoctor/asciidoctor/blob/main/CHANGELOG.adoc#2022-202...
The first issue seems to be related to a change in behavior in the inspect method. I'm willing to normalize the comparison strings in this case since this isn't really what the test is testing for.
Best Regards,
-Dan
On Thu, Oct 31, 2024 at 4:08 AM Vít Ondruch via ruby-sig < ruby-sig@lists.fedoraproject.org> wrote:
Dne 31. 10. 24 v 10:56 Vít Ondruch napsal(a):
As its turn out, the Psych prerelease caused issues with installation. I did some changes in the spec file, extracting `%gem_versions` and `%gem_prerelease` macros. Now the installation works and the mass rebuild runs here:
https://copr.fedorainfracloud.org/coprs/vondruch/mpb/
One thing I have noticed so far is the extraction of gems from standard library, e.g. rubygem-asciidoctor [1] errors like:
3) Error:Minitest::Test::TestBlocks::TestImages#test_embeds_base64_encoded_data_uri_for_remote_image_when_imagesdir_is_a_URI_and_data_uri_attribute_is_set:
LoadError: cannot load such file -- base64
And speaking of rubygem-asciidoctor, this also looks suspicious:
- Failure:
Minitest::Test::TestExtensions::TestIntegration#test_should_assign_captures_correctly_for_inline_macros
[test/extensions_test.rb:1382]: --- expected +++ actual @@ -1,9 +1,9 @@ "target="", attributes={} -target="value,key=val", attributes={1=>"value", "key"=>"val", "name"=>"value"} -target="", attributes={"text"=>""} -target="[text]", attributes={"text"=>"[text]"} +target="value,key=val", attributes={1 => "value", "key" => "val", "name" => "value"} +target="", attributes={"text" => ""} +target="[text]", attributes={"text" => "[text]"} target="target", attributes={} -target="target", attributes={1=>"value", "key"=>"val", "name"=>"value"} -target="target", attributes={"text"=>""} -target="target", attributes={"text"=>"[text]"} +target="target", attributes={1 => "value", "key" => "val", "name" => "value"} +target="target", attributes={"text" => ""} +target="target", attributes={"text" => "[text]"} target="target", attributes={}"
That suggest there were added spaces around hash rocket in `#inspect` output. That might be annoying.Both reported here:
https://github.com/asciidoctor/asciidoctor/issues/4634
although the first will likely need to be fixed also on our side by `BR: rubygem(base64)`
Vít
Vít
[1]:
https://download.copr.fedorainfracloud.org/results/vondruch/mpb/fedora-rawhi...
Dne 25. 10. 24 v 14:57 Vít Ondruch napsal(a):
Dne 25. 10. 24 v 14:09 Vít Ondruch napsal(a):
Hi everybody,
It is the time of the year to look at upcoming version of Ruby. Therefore I have opened PR with the changes:
https://src.fedoraproject.org/rpms/ruby/pull-request/196
and here is the (running) scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=125191137
There was failure on aarch64 due to hardening test. New build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=125192840
Vít
As already done previously, the PR is opened from my fork, so I'll be able to rebase it and pick some interesting bits into stable branches. I'll also push this branch into the official repo right before merge back into Rawhide to preserve the history.
And here are some interesting bits I have noticed:
- By far the biggest change are the unbundled default gems. While
they are mostly kept in the `bundled-gems` subpackage, it grown significantly. I try to keep the file lists very similar to what would be the gem2rpm output.
- The other thing is that Ruby upstream for some unknown reason
decide to put ruby executable into `libexec` directory, but not only that. There is also `bin` directory nested under. That is quite non-standard place IMHO, therefore I have reverted the change back to the previous location and I hope that upstream will change their mind (or at least provide some reasoning).
- From other changes, please note that the Prism parser is now used
by default. I hope it won't have any compatibility impact, but who knows.
I am not aware of anything else.
As always, please give the Ruby 3.4 some testing and looking forward to your feedback.
Cheers,
Vít
-- _______________________________________________ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@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.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Dne 31. 10. 24 v 11:26 Dan Allen napsal(a):
although the first will likely need to be fixed also on our side by `BR:
rubygem(base64)`
No, that should not be necessary. Asciidoctor no longer uses base64. The package must be using an out of date version of Asciidoctor. See https://github.com/asciidoctor/asciidoctor/blob/main/CHANGELOG.adoc#2022-202...
Right. We have rubygem-asciidoctor-2.0.20-7.fc41, so update should help to address this.
The first issue seems to be related to a change in behavior in the inspect method. I'm willing to normalize the comparison strings in this case since this isn't really what the test is testing for.
Thx 👍
BTW I have opened upstream `Hash#inspect` ticket here:
https://bugs.ruby-lang.org/issues/20857
Of course there are good points such as:
"But I don't think the "compatibility" argument is sound, because it doesn't make sense to assume that an API that is meant for debugging (#inspect) would guarantee a stable output forever. Otherwise that means we can't ever improve user experience related to it."
Unfortunately, we are not always able to keep with upstreams. OTOH, it is also good reminder that we could update some packages, despite they being "good enough".
Vít
Best Regards,
-Dan
On Thu, Oct 31, 2024 at 4:08 AM Vít Ondruch via ruby-sig ruby-sig@lists.fedoraproject.org wrote:
Dne 31. 10. 24 v 10:56 Vít Ondruch napsal(a): > As its turn out, the Psych prerelease caused issues with installation. > I did some changes in the spec file, extracting `%gem_versions` and > `%gem_prerelease` macros. Now the installation works and the mass > rebuild runs here: > > https://copr.fedorainfracloud.org/coprs/vondruch/mpb/ > > One thing I have noticed so far is the extraction of gems from > standard library, e.g. rubygem-asciidoctor [1] errors like: > > ~~~ > > 3) Error: > Minitest::Test::TestBlocks::TestImages#test_embeds_base64_encoded_data_uri_for_remote_image_when_imagesdir_is_a_URI_and_data_uri_attribute_is_set: > > LoadError: cannot load such file -- base64 > > ~~~ > > > And speaking of rubygem-asciidoctor, this also looks suspicious: > > > ~~~ > > 1) Failure: > Minitest::Test::TestExtensions::TestIntegration#test_should_assign_captures_correctly_for_inline_macros > [test/extensions_test.rb:1382]: > --- expected > +++ actual > @@ -1,9 +1,9 @@ > "target=\"\", attributes={} > -target=\"value,key=val\", attributes={1=>\"value\", \"key\"=>\"val\", > \"name\"=>\"value\"} > -target=\"\", attributes={\"text\"=>\"\"} > -target=\"[text]\", attributes={\"text\"=>\"[text]\"} > +target=\"value,key=val\", attributes={1 => \"value\", \"key\" => > \"val\", \"name\" => \"value\"} > +target=\"\", attributes={\"text\" => \"\"} > +target=\"[text]\", attributes={\"text\" => \"[text]\"} > target=\"target\", attributes={} > -target=\"target\", attributes={1=>\"value\", \"key\"=>\"val\", > \"name\"=>\"value\"} > -target=\"target\", attributes={\"text\"=>\"\"} > -target=\"target\", attributes={\"text\"=>\"[text]\"} > +target=\"target\", attributes={1 => \"value\", \"key\" => \"val\", > \"name\" => \"value\"} > +target=\"target\", attributes={\"text\" => \"\"} > +target=\"target\", attributes={\"text\" => \"[text]\"} > target=\"target\", attributes={}" > > ~~~ > > That suggest there were added spaces around hash rocket in `#inspect` > output. That might be annoying. Both reported here: https://github.com/asciidoctor/asciidoctor/issues/4634 although the first will likely need to be fixed also on our side by `BR: rubygem(base64)` Vít > > > Vít > > > > [1]: > https://download.copr.fedorainfracloud.org/results/vondruch/mpb/fedora-rawhide-x86_64/08193141-rubygem-asciidoctor/builder-live.log.gz > > > Dne 25. 10. 24 v 14:57 Vít Ondruch napsal(a): >> >> Dne 25. 10. 24 v 14:09 Vít Ondruch napsal(a): >>> Hi everybody, >>> >>> It is the time of the year to look at upcoming version of Ruby. >>> Therefore I have opened PR with the changes: >>> >>> https://src.fedoraproject.org/rpms/ruby/pull-request/196 >>> >>> and here is the (running) scratch build: >>> >>> https://koji.fedoraproject.org/koji/taskinfo?taskID=125191137 >> >> >> There was failure on aarch64 due to hardening test. New build is >> running here: >> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=125192840 >> >> >> Vít >> >> >> >>> >>> >>> As already done previously, the PR is opened from my fork, so I'll >>> be able to rebase it and pick some interesting bits into stable >>> branches. I'll also push this branch into the official repo right >>> before merge back into Rawhide to preserve the history. >>> >>> >>> And here are some interesting bits I have noticed: >>> >>> * By far the biggest change are the unbundled default gems. While >>> they are mostly kept in the `bundled-gems` subpackage, it grown >>> significantly. I try to keep the file lists very similar to what >>> would be the gem2rpm output. >>> >>> * The other thing is that Ruby upstream for some unknown reason >>> decide to put ruby executable into `libexec` directory, but not only >>> that. There is also `bin` directory nested under. That is quite >>> non-standard place IMHO, therefore I have reverted the change back >>> to the previous location and I hope that upstream will change their >>> mind (or at least provide some reasoning). >>> >>> * From other changes, please note that the Prism parser is now used >>> by default. I hope it won't have any compatibility impact, but who >>> knows. >>> >>> >>> I am not aware of anything else. >>> >>> As always, please give the Ruby 3.4 some testing and looking forward >>> to your feedback. >>> >>> >>> Cheers, >>> >>> >>> >>> Vít >>> -- _______________________________________________ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@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-- Dan Allen (he, him, his) | @mojavelinux | https://twitter.com/mojavelinux
Vít Ondruch via ruby-sig wrote on 2024/10/25 21:09:
Hi everybody,
It is the time of the year to look at upcoming version of Ruby. Therefore I have opened PR with the changes:
As always, please give the Ruby 3.4 some testing and looking forward to your feedback.
Cheers,
Vít
Hello, Vít. Thank you for your great work for ruby 3.4.
Now I tested with commit:24f7829abfd29fc226e38829caaecaa76885afbf: https://github.com/ruby/ruby/commit/24f7829abfd29fc226e38829caaecaa76885afbf
and looks like for rubygem-foo pkgs in Fedora, (from my trial build on copr) currently roughly 110 pkgs FTBFS among roughly 480 pkgs, which looks ..... so large.
I have not investigated the cause in detail yet. I will do my best but I fear if we can get in time by Christmas.
Regards, Mamoru
Dne 03. 11. 24 v 12:31 Mamoru TASAKA via ruby-sig napsal(a):
Vít Ondruch via ruby-sig wrote on 2024/10/25 21:09:
Hi everybody,
It is the time of the year to look at upcoming version of Ruby. Therefore I have opened PR with the changes:
As always, please give the Ruby 3.4 some testing and looking forward to your feedback.
Cheers,
Vít
Hello, Vít. Thank you for your great work for ruby 3.4.
You are welcome.
Now I tested with commit:24f7829abfd29fc226e38829caaecaa76885afbf: https://github.com/ruby/ruby/commit/24f7829abfd29fc226e38829caaecaa76885afbf
and looks like for rubygem-foo pkgs in Fedora, (from my trial build on copr) currently roughly 110 pkgs FTBFS among roughly 480 pkgs, which looks ..... so large.
There was analysis done by upstream ;)
https://bugs.ruby-lang.org/issues/20857#note-12
The biggest offenders are the newly unbundled parts of StdLib. The unbundling of base64 was proposed to be reverted, but who knows how it turns out, given that many projects already added the dependency.
I have not investigated the cause in detail yet. I will do my best but I fear if we can get in time by Christmas.
We'll see. So far, I use the breakages as an opportunity to update some of the packages (e.g. update would help to AsciiDoctor). And I think that e.g. fog-core or cucumber updates/fixes unblocks some of the dependencies.
There are also several orphaned packages, which are currently failing. Their removal in ~5 weeks will also help a bit.
Vít
Regards, Mamoru
Vít Ondruch via ruby-sig wrote on 2024/11/04 17:46:
Dne 03. 11. 24 v 12:31 Mamoru TASAKA via ruby-sig napsal(a):
Vít Ondruch via ruby-sig wrote on 2024/10/25 21:09:
Hi everybody,
It is the time of the year to look at upcoming version of Ruby. Therefore I have opened PR with the changes:
As always, please give the Ruby 3.4 some testing and looking forward to your feedback.
Cheers,
Vít
Hello, Vít. Thank you for your great work for ruby 3.4.
You are welcome.
Now I tested with commit:24f7829abfd29fc226e38829caaecaa76885afbf: https://github.com/ruby/ruby/commit/24f7829abfd29fc226e38829caaecaa76885afbf
and looks like for rubygem-foo pkgs in Fedora, (from my trial build on copr) currently roughly 110 pkgs FTBFS among roughly 480 pkgs, which looks ..... so large.
There was analysis done by upstream ;)
https://bugs.ruby-lang.org/issues/20857#note-12
The biggest offenders are the newly unbundled parts of StdLib. The unbundling of base64 was proposed to be reverted, but who knows how it turns out, given that many projects already added the dependency.
Just want to put comment that your scratch was using https://github.com/ruby/ruby/commit/3da3cabf982eaa4d2c9732651f6a9e18ffd0aba3
and the later commit https://github.com/ruby/ruby/commit/ed993b5bcc4fcae661dd022d3211dcc770425218 is now causing a lot of rubygems-foo pkgs raise errors with generating rdoc, reported:
https://bugs.ruby-lang.org/issues/20862
Mamoru
I have not investigated the cause in detail yet. I will do my best but I fear if we can get in time by Christmas.
We'll see. So far, I use the breakages as an opportunity to update some of the packages (e.g. update would help to AsciiDoctor). And I think that e.g. fog-core or cucumber updates/fixes unblocks some of the dependencies.
There are also several orphaned packages, which are currently failing. Their removal in ~5 weeks will also help a bit.
Vít
Regards, Mamoru
No I am looking into rubygem-activesupport build issue. I have locally applied patches to remove `mutex_m` dependency. However now the build fails with error such as:
~~~
+ ruby -Ilib:test -e 'Dir.glob "./test/**/*_test.rb", &method(:require)' /usr/share/gems/gems/minitest-5.25.1/lib/minitest/mock.rb:33: warning: redefining 'object_id' may cause serious problems /usr/share/ruby/did_you_mean/core_ext/name_error.rb:11: warning: drb is not part of the default gems starting from Ruby 3.4.0. Install drb from RubyGems. internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:136:in 'Kernel#require': cannot load such file -- drb (LoadError) Did you mean? erb from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:136:in 'Kernel#require' from /builddir/build/BUILD/rubygem-activesupport-7.0.8-build/activesupport-7.0.8/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/testing/parallelization.rb:3:in '<top (required)>' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:136:in 'Kernel#require' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:136:in 'Kernel#require' from /builddir/build/BUILD/rubygem-activesupport-7.0.8-build/activesupport-7.0.8/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/test_case.rb:14:in '<top (required)>' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:136:in 'Kernel#require' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:136:in 'Kernel#require' from /builddir/build/BUILD/rubygem-activesupport-7.0.8-build/activesupport-7.0.8/usr/share/gems/gems/activesupport-7.0.8/test/abstract_unit.rb:30:in '<top (required)>' from /builddir/build/BUILD/rubygem-activesupport-7.0.8-build/activesupport-7.0.8/usr/share/gems/gems/activesupport-7.0.8/test/actionable_error_test.rb:3:in 'Kernel#require_relative' from /builddir/build/BUILD/rubygem-activesupport-7.0.8-build/activesupport-7.0.8/usr/share/gems/gems/activesupport-7.0.8/test/actionable_error_test.rb:3:in '<top (required)>' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:136:in 'Kernel#require' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:136:in 'Kernel#require' from internal:dir:412:in 'Dir.glob' from -e:1:in '<main>'
~~~
The issue is actually here:
~~~
... snip ...
Package Arch Version Repository Size Installing: memcached x86_64 1.6.32-1.fc42 fedora 475.3 KiB ruby x86_64 3.4.0~20241016git3da3cabf98-15.fc42 copr_base 84.4 KiB ruby-default-gems noarch 3.3.5-15.fc42 fedora 76.3 KiB ruby-libs x86_64 3.4.0~20241016git3da3cabf98-15.fc42 copr_base 14.7 MiB rubygem-bigdecimal x86_64 3.1.8-15.fc42 copr_base 134.8 KiB rubygem-builder noarch 3.3.0-1.fc42 copr_base 27.5 KiB rubygem-concurrent-ruby noarch 1.1.9-7.fc42 copr_base 693.0 KiB rubygem-connection_pool noarch 2.2.5-9.fc42 copr_base 18.5 KiB rubygem-dalli noarch 3.2.0-7.fc42 copr_base 111.4 KiB rubygem-i18n noarch 1.14.1-6.fc41 fedora 158.5 KiB rubygem-listen noarch 3.7.1-6.fc42 copr_base 64.6 KiB rubygem-minitest noarch 5.25.1-100.fc42 copr_base 149.5 KiB rubygem-rack noarch 1:2.2.4-6.fc41 fedora 306.0 KiB rubygem-redis noarch 5.2.0-1.fc42 copr_base 181.9 KiB rubygem-rexml noarch 3.3.8-15.fc42 copr_base 455.4 KiB rubygem-tzinfo noarch 2.0.6-4.fc42 copr_base 278.5 KiB rubygems-devel noarch 3.6.0.dev-15.fc42 copr_base 13.4 KiB tzdata noarch 2024a-9.fc41 fedora 1.7 MiB Installing dependencies:
... snip ...
rubygem-ffi x86_64 1.17.0-1.fc42 copr_base 577.6 KiB rubygem-io-console x86_64 0.7.2-15.fc42 copr_base 33.3 KiB rubygem-json x86_64 2.7.5-201.fc42 copr_base 167.8 KiB rubygem-psych x86_64 5.2.0~beta1-15.fc42 copr_base 132.8 KiB rubygem-rb-inotify noarch 0.10.1-10.fc42 copr_base 25.0 KiB rubygem-rdoc noarch 6.7.0-15.fc42 copr_base 1.8 MiB rubygem-redis-client noarch 0.22.2-1.fc41 fedora 61.6 KiB rubygems noarch 3.6.0.dev-15.fc42 copr_base 1.4 MiB rubypick noarch 1.1.1-21.fc42 copr_base 4.4 KiB systemd x86_64 256.7-1.fc42 fedora 17.0 MiB systemd-pam x86_64 256.7-1.fc42 fedora 1.1 MiB systemd-rpm-macros noarch 256.7-1.fc42 fedora 10.7 KiB
... snip ...
~~~
If you have not spotted it, then `ruby-default-gems noarch 3.3.5-15.fc42 fedora 76.3 KiB` is wrong version, coming from Ruby 3.3, which provides `rubygem(drb)`, where newly is provided by `rubygem-bundled-gems`. I think that DNF miniminzes the dependency chain and `ruby-default-gems` is enough to satisfy the dependency.
The question is how to workaround this, because neither `ruby-default-gems` nor `rubygem-bundled-gems` are installed explicitly. Does anybody have any idea? Could e.g. `Suggests: rubygem-bundled-gems
= 3.4` help? Or some `Obsolete` somewhere?
Vít
Vít Ondruch via ruby-sig wrote on 2024/11/05 19:01:
No I am looking into rubygem-activesupport build issue. I have locally applied patches to remove `mutex_m` dependency. However now the build fails with error such as:
+ ruby -Ilib:test -e 'Dir.glob "./test/**/*_test.rb", &method(:require)' /usr/share/gems/gems/minitest-5.25.1/lib/minitest/mock.rb:33: warning: redefining 'object_id' may cause serious problems /usr/share/ruby/did_you_mean/core_ext/name_error.rb:11: warning: drb is not part of the default gems starting from Ruby 3.4.0. Install drb from RubyGems. <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require': cannot load such file -- drb (LoadError) Did you mean? erb from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require' from /builddir/build/BUILD/rubygem-activesupport-7.0.8-build/activesupport-7.0.8/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/testing/parallelization.rb:3:in '<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require' from /builddir/build/BUILD/rubygem-activesupport-7.0.8-build/activesupport-7.0.8/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/test_case.rb:14:in '<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require' from /builddir/build/BUILD/rubygem-activesupport-7.0.8-build/activesupport-7.0.8/usr/share/gems/gems/activesupport-7.0.8/test/abstract_unit.rb:30:in '<top (required)>' from /builddir/build/BUILD/rubygem-activesupport-7.0.8-build/activesupport-7.0.8/usr/share/gems/gems/activesupport-7.0.8/test/actionable_error_test.rb:3:in 'Kernel#require_relative' from /builddir/build/BUILD/rubygem-activesupport-7.0.8-build/activesupport-7.0.8/usr/share/gems/gems/activesupport-7.0.8/test/actionable_error_test.rb:3:in '<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require' from <internal:dir>:412:in 'Dir.glob' from -e:1:in '<main>'The issue is actually here:
... snip ... Package Arch Version Repository Size Installing: memcached x86_64 1.6.32-1.fc42 fedora 475.3 KiB ruby x86_64 3.4.0~20241016git3da3cabf98-15.fc42 copr_base 84.4 KiB ruby-default-gems noarch 3.3.5-15.fc42 fedora 76.3 KiB ruby-libs x86_64 3.4.0~20241016git3da3cabf98-15.fc42 copr_base 14.7 MiB rubygem-bigdecimal x86_64 3.1.8-15.fc42 copr_base 134.8 KiB rubygem-builder noarch 3.3.0-1.fc42 copr_base 27.5 KiB rubygem-concurrent-ruby noarch 1.1.9-7.fc42 copr_base 693.0 KiB rubygem-connection_pool noarch 2.2.5-9.fc42 copr_base 18.5 KiB rubygem-dalli noarch 3.2.0-7.fc42 copr_base 111.4 KiB rubygem-i18n noarch 1.14.1-6.fc41 fedora 158.5 KiB rubygem-listen noarch 3.7.1-6.fc42 copr_base 64.6 KiB rubygem-minitest noarch 5.25.1-100.fc42 copr_base 149.5 KiB rubygem-rack noarch 1:2.2.4-6.fc41 fedora 306.0 KiB rubygem-redis noarch 5.2.0-1.fc42 copr_base 181.9 KiB rubygem-rexml noarch 3.3.8-15.fc42 copr_base 455.4 KiB rubygem-tzinfo noarch 2.0.6-4.fc42 copr_base 278.5 KiB rubygems-devel noarch 3.6.0.dev-15.fc42 copr_base 13.4 KiB tzdata noarch 2024a-9.fc41 fedora 1.7 MiB Installing dependencies: ... snip ... rubygem-ffi x86_64 1.17.0-1.fc42 copr_base 577.6 KiB rubygem-io-console x86_64 0.7.2-15.fc42 copr_base 33.3 KiB rubygem-json x86_64 2.7.5-201.fc42 copr_base 167.8 KiB rubygem-psych x86_64 5.2.0~beta1-15.fc42 copr_base 132.8 KiB rubygem-rb-inotify noarch 0.10.1-10.fc42 copr_base 25.0 KiB rubygem-rdoc noarch 6.7.0-15.fc42 copr_base 1.8 MiB rubygem-redis-client noarch 0.22.2-1.fc41 fedora 61.6 KiB rubygems noarch 3.6.0.dev-15.fc42 copr_base 1.4 MiB rubypick noarch 1.1.1-21.fc42 copr_base 4.4 KiB systemd x86_64 256.7-1.fc42 fedora 17.0 MiB systemd-pam x86_64 256.7-1.fc42 fedora 1.1 MiB systemd-rpm-macros noarch 256.7-1.fc42 fedora 10.7 KiB ... snip ...If you have not spotted it, then `ruby-default-gems noarch 3.3.5-15.fc42 fedora 76.3 KiB` is wrong version, coming from Ruby 3.3, which provides `rubygem(drb)`, where newly is provided by `rubygem-bundled-gems`. I think that DNF miniminzes the dependency chain and `ruby-default-gems` is enough to satisfy the dependency.
The question is how to workaround this, because neither `ruby-default-gems` nor `rubygem-bundled-gems` are installed explicitly. Does anybody have any idea? Could e.g. `Suggests: rubygem-bundled-gems >= 3.4` help? Or some `Obsolete` somewhere?
Making ruby-libs have "Obsoletes: ruby-default-gems < 3.3.999" and "Obsoletes: rubygem-bundled-gems < 3.3.999" helps here (because ruby-libs will be always installed when building rubygem-foo pkgs) (My scratch build already added this workaround.)
Regards, Mamoru
Vít
Dne 05. 11. 24 v 11:15 Mamoru TASAKA via ruby-sig napsal(a):
Vít Ondruch via ruby-sig wrote on 2024/11/05 19:01:
No I am looking into rubygem-activesupport build issue. I have locally applied patches to remove `mutex_m` dependency. However now the build fails with error such as:
+ ruby -Ilib:test -e 'Dir.glob "./test/**/*_test.rb", &method(:require)' /usr/share/gems/gems/minitest-5.25.1/lib/minitest/mock.rb:33: warning: redefining 'object_id' may cause serious problems /usr/share/ruby/did_you_mean/core_ext/name_error.rb:11: warning: drb is not part of the default gems starting from Ruby 3.4.0. Install drb from RubyGems. <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require': cannot load such file -- drb (LoadError) Did you mean? erb from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require' from /builddir/build/BUILD/rubygem-activesupport-7.0.8-build/activesupport-7.0.8/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/testing/parallelization.rb:3:in '<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require' from /builddir/build/BUILD/rubygem-activesupport-7.0.8-build/activesupport-7.0.8/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/test_case.rb:14:in '<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require' from /builddir/build/BUILD/rubygem-activesupport-7.0.8-build/activesupport-7.0.8/usr/share/gems/gems/activesupport-7.0.8/test/abstract_unit.rb:30:in '<top (required)>' from /builddir/build/BUILD/rubygem-activesupport-7.0.8-build/activesupport-7.0.8/usr/share/gems/gems/activesupport-7.0.8/test/actionable_error_test.rb:3:in 'Kernel#require_relative' from /builddir/build/BUILD/rubygem-activesupport-7.0.8-build/activesupport-7.0.8/usr/share/gems/gems/activesupport-7.0.8/test/actionable_error_test.rb:3:in '<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require' from <internal:dir>:412:in 'Dir.glob' from -e:1:in '<main>'The issue is actually here:
... snip ... Package Arch Version Repository Size Installing: memcached x86_64 1.6.32-1.fc42 fedora 475.3 KiB ruby x86_64 3.4.0~20241016git3da3cabf98-15.fc42 copr_base 84.4 KiB ruby-default-gems noarch 3.3.5-15.fc42 fedora 76.3 KiB ruby-libs x86_64 3.4.0~20241016git3da3cabf98-15.fc42 copr_base 14.7 MiB rubygem-bigdecimal x86_64 3.1.8-15.fc42 copr_base 134.8 KiB rubygem-builder noarch 3.3.0-1.fc42 copr_base 27.5 KiB rubygem-concurrent-ruby noarch 1.1.9-7.fc42 copr_base 693.0 KiB rubygem-connection_pool noarch 2.2.5-9.fc42 copr_base 18.5 KiB rubygem-dalli noarch 3.2.0-7.fc42 copr_base 111.4 KiB rubygem-i18n noarch 1.14.1-6.fc41 fedora 158.5 KiB rubygem-listen noarch 3.7.1-6.fc42 copr_base 64.6 KiB rubygem-minitest noarch 5.25.1-100.fc42 copr_base 149.5 KiB rubygem-rack noarch 1:2.2.4-6.fc41 fedora 306.0 KiB rubygem-redis noarch 5.2.0-1.fc42 copr_base 181.9 KiB rubygem-rexml noarch 3.3.8-15.fc42 copr_base 455.4 KiB rubygem-tzinfo noarch 2.0.6-4.fc42 copr_base 278.5 KiB rubygems-devel noarch 3.6.0.dev-15.fc42 copr_base 13.4 KiB tzdata noarch 2024a-9.fc41 fedora 1.7 MiB Installing dependencies: ... snip ... rubygem-ffi x86_64 1.17.0-1.fc42 copr_base 577.6 KiB rubygem-io-console x86_64 0.7.2-15.fc42 copr_base 33.3 KiB rubygem-json x86_64 2.7.5-201.fc42 copr_base 167.8 KiB rubygem-psych x86_64 5.2.0~beta1-15.fc42 copr_base 132.8 KiB rubygem-rb-inotify noarch 0.10.1-10.fc42 copr_base 25.0 KiB rubygem-rdoc noarch 6.7.0-15.fc42 copr_base 1.8 MiB rubygem-redis-client noarch 0.22.2-1.fc41 fedora 61.6 KiB rubygems noarch 3.6.0.dev-15.fc42 copr_base 1.4 MiB rubypick noarch 1.1.1-21.fc42 copr_base 4.4 KiB systemd x86_64 256.7-1.fc42 fedora 17.0 MiB systemd-pam x86_64 256.7-1.fc42 fedora 1.1 MiB systemd-rpm-macros noarch 256.7-1.fc42 fedora 10.7 KiB ... snip ...If you have not spotted it, then `ruby-default-gems noarch 3.3.5-15.fc42 fedora 76.3 KiB` is wrong version, coming from Ruby 3.3, which provides `rubygem(drb)`, where newly is provided by `rubygem-bundled-gems`. I think that DNF miniminzes the dependency chain and `ruby-default-gems` is enough to satisfy the dependency.
The question is how to workaround this, because neither `ruby-default-gems` nor `rubygem-bundled-gems` are installed explicitly. Does anybody have any idea? Could e.g. `Suggests: rubygem-bundled-gems >= 3.4` help? Or some `Obsolete` somewhere?
Making ruby-libs have "Obsoletes: ruby-default-gems < 3.3.999" and "Obsoletes: rubygem-bundled-gems < 3.3.999" helps here
Right, that might be one option. Thaks 👍 Other might be rubygem-bundled-gems obsoleting the `rubygem(drb)` and other similar.
(because ruby-libs will be always installed when building rubygem-foo pkgs) (My scratch build already added this workaround.)
I actually consider this change:
~~~
$ git show commit 43ee23809d26d8e1050cf1ff20f8a1139c1fe677 (HEAD -> ruby-3.4) Author: Vít Ondruch vondruch@redhat.com Date: Tue Nov 5 11:47:24 2024 +0100
Include ruby-{default,bundled}-gems by default.
Users are expecting to have them available, because that is what upstream does.
diff --git a/ruby.spec b/ruby.spec index 704900e..e75b370 100644 --- a/ruby.spec +++ b/ruby.spec @@ -284,6 +284,8 @@ Patch9: ruby-3.3.0-Disable-syntax-suggest-test-case.patch Requires: %{name}-libs%{?_isa} = %{version}-%{release} %{?with_rubypick:Suggests: rubypick} Recommends: ruby(rubygems) >= %{rubygems_version} +Recommends: ruby-default-gems >= %{version}-%{release} +Recommends: ruby-bundled-gems >= %{version}-%{release} Recommends: rubygem(bigdecimal) >= %{bigdecimal_version}
# Build dependencies
~~~
I think this is probably good idea to include the `ruby-{default,bundled}-gems` when `ruby` package installed no matter if it helps to this specific case. Because this will provide more upstream like experience.
In my limited testing, this could help to address the issue, despite weak dependencies not being installed in the build root. Going to give it a try in Copr.
Vít
Regards, Mamoru
Vít
Dne 05. 11. 24 v 11:57 Vít Ondruch napsal(a):
Dne 05. 11. 24 v 11:15 Mamoru TASAKA via ruby-sig napsal(a):
Vít Ondruch via ruby-sig wrote on 2024/11/05 19:01:
No I am looking into rubygem-activesupport build issue. I have locally applied patches to remove `mutex_m` dependency. However now the build fails with error such as:
+ ruby -Ilib:test -e 'Dir.glob "./test/**/*_test.rb", &method(:require)' /usr/share/gems/gems/minitest-5.25.1/lib/minitest/mock.rb:33: warning: redefining 'object_id' may cause serious problems /usr/share/ruby/did_you_mean/core_ext/name_error.rb:11: warning: drb is not part of the default gems starting from Ruby 3.4.0. Install drb from RubyGems. <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require': cannot load such file -- drb (LoadError) Did you mean? erb from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require' from /builddir/build/BUILD/rubygem-activesupport-7.0.8-build/activesupport-7.0.8/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/testing/parallelization.rb:3:in '<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require' from /builddir/build/BUILD/rubygem-activesupport-7.0.8-build/activesupport-7.0.8/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/test_case.rb:14:in '<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require' from /builddir/build/BUILD/rubygem-activesupport-7.0.8-build/activesupport-7.0.8/usr/share/gems/gems/activesupport-7.0.8/test/abstract_unit.rb:30:in '<top (required)>' from /builddir/build/BUILD/rubygem-activesupport-7.0.8-build/activesupport-7.0.8/usr/share/gems/gems/activesupport-7.0.8/test/actionable_error_test.rb:3:in 'Kernel#require_relative' from /builddir/build/BUILD/rubygem-activesupport-7.0.8-build/activesupport-7.0.8/usr/share/gems/gems/activesupport-7.0.8/test/actionable_error_test.rb:3:in '<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require' from <internal:dir>:412:in 'Dir.glob' from -e:1:in '<main>'The issue is actually here:
... snip ... Package Arch Version Repository Size Installing: memcached x86_64 1.6.32-1.fc42 fedora 475.3 KiB ruby x86_64 3.4.0~20241016git3da3cabf98-15.fc42 copr_base 84.4 KiB ruby-default-gems noarch 3.3.5-15.fc42 fedora 76.3 KiB ruby-libs x86_64 3.4.0~20241016git3da3cabf98-15.fc42 copr_base 14.7 MiB rubygem-bigdecimal x86_64 3.1.8-15.fc42 copr_base 134.8 KiB rubygem-builder noarch 3.3.0-1.fc42 copr_base 27.5 KiB rubygem-concurrent-ruby noarch 1.1.9-7.fc42 copr_base 693.0 KiB rubygem-connection_pool noarch 2.2.5-9.fc42 copr_base 18.5 KiB rubygem-dalli noarch 3.2.0-7.fc42 copr_base 111.4 KiB rubygem-i18n noarch 1.14.1-6.fc41 fedora 158.5 KiB rubygem-listen noarch 3.7.1-6.fc42 copr_base 64.6 KiB rubygem-minitest noarch 5.25.1-100.fc42 copr_base 149.5 KiB rubygem-rack noarch 1:2.2.4-6.fc41 fedora 306.0 KiB rubygem-redis noarch 5.2.0-1.fc42 copr_base 181.9 KiB rubygem-rexml noarch 3.3.8-15.fc42 copr_base 455.4 KiB rubygem-tzinfo noarch 2.0.6-4.fc42 copr_base 278.5 KiB rubygems-devel noarch 3.6.0.dev-15.fc42 copr_base 13.4 KiB tzdata noarch 2024a-9.fc41 fedora 1.7 MiB Installing dependencies: ... snip ... rubygem-ffi x86_64 1.17.0-1.fc42 copr_base 577.6 KiB rubygem-io-console x86_64 0.7.2-15.fc42 copr_base 33.3 KiB rubygem-json x86_64 2.7.5-201.fc42 copr_base 167.8 KiB rubygem-psych x86_64 5.2.0~beta1-15.fc42 copr_base 132.8 KiB rubygem-rb-inotify noarch 0.10.1-10.fc42 copr_base 25.0 KiB rubygem-rdoc noarch 6.7.0-15.fc42 copr_base 1.8 MiB rubygem-redis-client noarch 0.22.2-1.fc41 fedora 61.6 KiB rubygems noarch 3.6.0.dev-15.fc42 copr_base 1.4 MiB rubypick noarch 1.1.1-21.fc42 copr_base 4.4 KiB systemd x86_64 256.7-1.fc42 fedora 17.0 MiB systemd-pam x86_64 256.7-1.fc42 fedora 1.1 MiB systemd-rpm-macros noarch 256.7-1.fc42 fedora 10.7 KiB ... snip ...If you have not spotted it, then `ruby-default-gems noarch 3.3.5-15.fc42 fedora 76.3 KiB` is wrong version, coming from Ruby 3.3, which provides `rubygem(drb)`, where newly is provided by `rubygem-bundled-gems`. I think that DNF miniminzes the dependency chain and `ruby-default-gems` is enough to satisfy the dependency.
The question is how to workaround this, because neither `ruby-default-gems` nor `rubygem-bundled-gems` are installed explicitly. Does anybody have any idea? Could e.g. `Suggests: rubygem-bundled-gems >= 3.4` help? Or some `Obsolete` somewhere?
Making ruby-libs have "Obsoletes: ruby-default-gems < 3.3.999" and "Obsoletes: rubygem-bundled-gems < 3.3.999" helps here
Right, that might be one option. Thaks 👍 Other might be rubygem-bundled-gems obsoleting the `rubygem(drb)` and other similar.
(because ruby-libs will be always installed when building rubygem-foo pkgs) (My scratch build already added this workaround.)
I actually consider this change:
$ git show commit 43ee23809d26d8e1050cf1ff20f8a1139c1fe677 (HEAD -> ruby-3.4) Author: Vít Ondruch <vondruch@redhat.com> Date: Tue Nov 5 11:47:24 2024 +0100 Include ruby-{default,bundled}-gems by default. Users are expecting to have them available, because that is what upstream does. diff --git a/ruby.spec b/ruby.spec index 704900e..e75b370 100644 --- a/ruby.spec +++ b/ruby.spec @@ -284,6 +284,8 @@ Patch9: ruby-3.3.0-Disable-syntax-suggest-test-case.patch Requires: %{name}-libs%{?_isa} = %{version}-%{release} %{?with_rubypick:Suggests: rubypick} Recommends: ruby(rubygems) >= %{rubygems_version} +Recommends: ruby-default-gems >= %{version}-%{release} +Recommends: ruby-bundled-gems >= %{version}-%{release} Recommends: rubygem(bigdecimal) >= %{bigdecimal_version} # Build dependenciesI think this is probably good idea to include the `ruby-{default,bundled}-gems` when `ruby` package installed no matter if it helps to this specific case. Because this will provide more upstream like experience.
In my limited testing, this could help to address the issue, despite weak dependencies not being installed in the build root. Going to give it a try in Copr.
It seems it works (apart of the other failures, which are unrelated):
https://download.copr.fedorainfracloud.org/results/vondruch/mpb/fedora-rawhi...
Pushed the change into my PR.
Vít
Vít
Regards, Mamoru
Vít
Should anybody try to take a look at rubygem-pg, I have already did that:
https://bugzilla.redhat.com/show_bug.cgi?id=2324182
and moved the ticket to PostgreSQL for the moment. Please take the ticket as a good starting point, because the funny thing is that the issue seems to be related to kernel version. Any help with debugging this further is greatly appreciated.
Vít
Hi all,
I have updated my branch to 4074c6b427 and the build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=125892327
You can check the results of mini mass rebuild in my Copr:
https://copr.fedorainfracloud.org/coprs/vondruch/mpb/
Notably, the build includes the RDoc path mentioned in this thread a few days ago by Mamoru. Another change is that the `ruby-{default,bundled}-gems` packages are now Recommended by Ruby package. I don't think there is anything else what would caught my attention.
As always, please give it a try and let me know your feedback.
Thanks a lot
Vít
Dne 15. 11. 24 v 16:04 Vít Ondruch napsal(a):
Hi all,
I have updated my branch to 4074c6b427 and the build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=125892327
This didn't really workout the best. Therefore, I have pushed update to 0f75ac8380 and the (successful) scratch build is here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=125982819
Vít
You can check the results of mini mass rebuild in my Copr:
https://copr.fedorainfracloud.org/coprs/vondruch/mpb/
Notably, the build includes the RDoc path mentioned in this thread a few days ago by Mamoru. Another change is that the `ruby-{default,bundled}-gems` packages are now Recommended by Ruby package. I don't think there is anything else what would caught my attention.
As always, please give it a try and let me know your feedback.
Thanks a lot
Vít
Hi everybody.
Yet another update of Ruby 3.4, this time to 4d8c793bc3 and the build is here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=126242984
Nothing really outstanding. The only change worth noting that the RDoc issue mentioned earlier by Mamoru was fixed.
Please give it try and as always, please let me know your findings.
BTW it seems that were are not less then 50 packages which needs to get fixed for Ruby 3.4 and from those 13 have been FTBFS already. So thanks everybody for helping.
Vít
Vít Ondruch via ruby-sig wrote on 2024/11/26 17:35:
Hi everybody.
Yet another update of Ruby 3.4, this time to 4d8c793bc3 and the build is here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=126242984
Nothing really outstanding. The only change worth noting that the RDoc issue mentioned earlier by Mamoru was fixed.
Please give it try and as always, please let me know your findings.
BTW it seems that were are not less then 50 packages which needs to get fixed for Ruby 3.4 and from those 13 have been FTBFS already. So thanks everybody for helping.
Vít
Hello Vít, and ruby-sig folks:
I think (not sure most but at least) many of the failures are due to ruby 3.4 Hash#inspect formatting change: for those failures maybe we can just patch out them as a last resort.
Currently the failures I feel difficult to fix are:
* rubygem-websocket https://copr.fedorainfracloud.org/coprs/vondruch/mpb/build/8312136/
Due to https://bugs.ruby-lang.org/issues/20265 change, NEWOBJ macro is removed, then currently rubygem-websocket really fails to compile. For now I have no idea how to replace this macro.
* rubygem-mysql2 * rubygem-clockwork
These 2 packages hang up at %check , rpmbuild cannot finish currently. I guess Timeout.#timeout behavior somewhat changed, but don't know currently how to fix.
Regards, Mamoru
Dne 26. 11. 24 v 15:00 Mamoru TASAKA via ruby-sig napsal(a):
Vít Ondruch via ruby-sig wrote on 2024/11/26 17:35:
Hi everybody.
Yet another update of Ruby 3.4, this time to 4d8c793bc3 and the build is here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=126242984
Nothing really outstanding. The only change worth noting that the RDoc issue mentioned earlier by Mamoru was fixed.
Please give it try and as always, please let me know your findings.
BTW it seems that were are not less then 50 packages which needs to get fixed for Ruby 3.4 and from those 13 have been FTBFS already. So thanks everybody for helping.
Vít
Hello Vít, and ruby-sig folks:
I think (not sure most but at least) many of the failures are due to ruby 3.4 Hash#inspect formatting change: for those failures maybe we can just patch out them as a last resort.
These are unfortunate, but as long as we can build all arch dependent packages, we might consider them non-blocking. These are typically only test suite problems, so we can fix those later. Of course with Ruby 3.4 release, there is change these will be fixed by communities (while old RoR we have in Fedora ATM blocks updates of some packages, such as Rack 🤷).
Currently the failures I feel difficult to fix are:
- rubygem-websocket
https://copr.fedorainfracloud.org/coprs/vondruch/mpb/build/8312136/
Due to https://bugs.ruby-lang.org/issues/20265 change, NEWOBJ macro is removed, then currently rubygem-websocket really fails to compile. For now I have no idea how to replace this macro.
I can see just the `base64` issue. Does the NEWOBJ thing pops up once the `base64` issue is fixed?
- rubygem-mysql2
I have disabled the offending test cases today, because this blocks rubygem-railties. The issue is tracked here:
https://bugzilla.redhat.com/show_bug.cgi?id=2323148
and I have also opened upstream ticket today:
https://github.com/brianmario/mysql2/issues/1382
Overall, the failures such as `#<Mysql2::Error::ConnectionError: TLS/SSL error: unexpected eof while reading>` reminds me this rubygem-pg issue a bit:
https://src.fedoraproject.org/rpms/rubygem-pg/c/73df744331e064436ef3e6503f66...
But I might be completely wrong.
- rubygem-clockwork
I hope this will get removed prior it gets problematic. Ignoring this one for the time being.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
Vít
These 2 packages hang up at %check , rpmbuild cannot finish currently. I guess Timeout.#timeout behavior somewhat changed, but don't know currently how to fix.
Regards, Mamoru
Vít Ondruch via ruby-sig wrote on 2024/11/27 0:48:
Currently the failures I feel difficult to fix are:
- rubygem-websocket
https://copr.fedorainfracloud.org/coprs/vondruch/mpb/build/8312136/
Due to https://bugs.ruby-lang.org/issues/20265 change, NEWOBJ macro is removed, then currently rubygem-websocket really fails to compile. For now I have no idea how to replace this macro.
I can see just the `base64` issue. Does the NEWOBJ thing pops up once the `base64` issue is fixed?
Sorry, I was completely confused. Actually this is rubygem-serialport . https://copr.fedorainfracloud.org/coprs/vondruch/mpb/build/8312122/
Regards, Mamoru
Dne 27. 11. 24 v 1:07 Mamoru TASAKA via ruby-sig napsal(a):
Vít Ondruch via ruby-sig wrote on 2024/11/27 0:48:
Currently the failures I feel difficult to fix are:
- rubygem-websocket
https://copr.fedorainfracloud.org/coprs/vondruch/mpb/build/8312136/
Due to https://bugs.ruby-lang.org/issues/20265 change, NEWOBJ macro is removed, then currently rubygem-websocket really fails to compile. For now I have no idea how to replace this macro.
I can see just the `base64` issue. Does the NEWOBJ thing pops up once the `base64` issue is fixed?
Sorry, I was completely confused. Actually this is rubygem-serialport . https://copr.fedorainfracloud.org/coprs/vondruch/mpb/build/8312122/
1) I have asked upstream for migration path:
https://bugs.ruby-lang.org/issues/20265#note-5
2) The question is if there is future in this project:
https://github.com/hparra/ruby-serialport/discussions/77
We have rubygem-serialport in Fedora due to rubygem-icaro dependency. However, this also seems to be dead. Maybe the most meaningful step ATM is to open ticket against rubygem-serialport with all the information and warning we are going to break the packages.
Thoughts?
Vít
Regards, Mamoru
Vít Ondruch via ruby-sig wrote on 2024/11/28 18:10:
Dne 27. 11. 24 v 1:07 Mamoru TASAKA via ruby-sig napsal(a):
Vít Ondruch via ruby-sig wrote on 2024/11/27 0:48:
Currently the failures I feel difficult to fix are:
- rubygem-websocket
https://copr.fedorainfracloud.org/coprs/vondruch/mpb/build/8312136/
Due to https://bugs.ruby-lang.org/issues/20265 change, NEWOBJ macro is removed, then currently rubygem-websocket really fails to compile. For now I have no idea how to replace this macro.
I can see just the `base64` issue. Does the NEWOBJ thing pops up once the `base64` issue is fixed?
Sorry, I was completely confused. Actually this is rubygem-serialport . https://copr.fedorainfracloud.org/coprs/vondruch/mpb/build/8312122/
- I have asked upstream for migration path:
https://bugs.ruby-lang.org/issues/20265#note-5
- The question is if there is future in this project:
https://github.com/hparra/ruby-serialport/discussions/77
We have rubygem-serialport in Fedora due to rubygem-icaro dependency. However, this also seems to be dead. Maybe the most meaningful step ATM is to open ticket against rubygem-serialport with all the information and warning we are going to break the packages.
I think opening a ticket against rubygem-serialport (on bugzilla) can be the first step for the time being. For now "me" have no idea how to fix rubygem-serialport srpm (even if I have read the above ruby-lang issue/ticket...)
Regards, Mamoru
Thoughts?
Vít
Regards, Mamoru
Dne 28. 11. 24 v 15:01 Mamoru TASAKA via ruby-sig napsal(a):
Vít Ondruch via ruby-sig wrote on 2024/11/28 18:10:
Dne 27. 11. 24 v 1:07 Mamoru TASAKA via ruby-sig napsal(a):
Vít Ondruch via ruby-sig wrote on 2024/11/27 0:48:
Currently the failures I feel difficult to fix are:
- rubygem-websocket
https://copr.fedorainfracloud.org/coprs/vondruch/mpb/build/8312136/
Due to https://bugs.ruby-lang.org/issues/20265 change, NEWOBJ macro is removed, then currently rubygem-websocket really fails to compile. For now I have no idea how to replace this macro.
I can see just the `base64` issue. Does the NEWOBJ thing pops up once the `base64` issue is fixed?
Sorry, I was completely confused. Actually this is rubygem-serialport . https://copr.fedorainfracloud.org/coprs/vondruch/mpb/build/8312122/
- I have asked upstream for migration path:
https://bugs.ruby-lang.org/issues/20265#note-5
- The question is if there is future in this project:
https://github.com/hparra/ruby-serialport/discussions/77
We have rubygem-serialport in Fedora due to rubygem-icaro dependency. However, this also seems to be dead. Maybe the most meaningful step ATM is to open ticket against rubygem-serialport with all the information and warning we are going to break the packages.
I think opening a ticket against rubygem-serialport (on bugzilla) can be the first step for the time being. For now "me" have no idea how to fix rubygem-serialport srpm (even if I have read the above ruby-lang issue/ticket...)
This is patch which I came up with. It builds, but I have no idea if it works, most likely it doesn't 😇
~~~
diff --git a/ext/native/posix_serialport_impl.c b/ext/native/posix_serialport_impl.c index 2f9325e..1afba51 100644 --- a/ext/native/posix_serialport_impl.c +++ b/ext/native/posix_serialport_impl.c @@ -80,12 +80,6 @@ int get_fd_helper(obj) VALUE sp_create_impl(class, _port) VALUE class, _port; { -#ifdef HAVE_RUBY_IO_H - rb_io_t *fp; -#else - OpenFile *fp; -#endif - int fd; int num_port; char *port; @@ -109,10 +103,6 @@ VALUE sp_create_impl(class, _port) }; struct termios params;
- NEWOBJ(sp, struct RFile); - OBJSETUP((VALUE) sp, class, T_FILE); - MakeOpenFile((VALUE) sp, fp); - switch(TYPE(_port)) { case T_FIXNUM: @@ -166,12 +156,7 @@ VALUE sp_create_impl(class, _port) rb_sys_fail(sTcsetattr); }
-#ifdef HAVE_RUBY_IO_H - fp->fd = fd; -#else - fp->f = rb_fdopen(fd, "r+"); -#endif - fp->mode = FMODE_READWRITE | FMODE_SYNC; + VALUE sp = rb_io_open_descriptor(class, fd, FMODE_READWRITE | FMODE_SYNC, rb_str_new(port, 1), Qnil, NULL);
return (VALUE) sp; }
~~~
Vít
Regards, Mamoru
Thoughts?
Vít
Regards, Mamoru
Dne 28. 11. 24 v 16:12 Vít Ondruch napsal(a):
Dne 28. 11. 24 v 15:01 Mamoru TASAKA via ruby-sig napsal(a):
Vít Ondruch via ruby-sig wrote on 2024/11/28 18:10:
Dne 27. 11. 24 v 1:07 Mamoru TASAKA via ruby-sig napsal(a):
Vít Ondruch via ruby-sig wrote on 2024/11/27 0:48:
Currently the failures I feel difficult to fix are:
- rubygem-websocket
https://copr.fedorainfracloud.org/coprs/vondruch/mpb/build/8312136/
Due to https://bugs.ruby-lang.org/issues/20265 change, NEWOBJ macro is removed, then currently rubygem-websocket really fails to compile. For now I have no idea how to replace this macro.
I can see just the `base64` issue. Does the NEWOBJ thing pops up once the `base64` issue is fixed?
Sorry, I was completely confused. Actually this is rubygem-serialport . https://copr.fedorainfracloud.org/coprs/vondruch/mpb/build/8312122/
- I have asked upstream for migration path:
https://bugs.ruby-lang.org/issues/20265#note-5
- The question is if there is future in this project:
https://github.com/hparra/ruby-serialport/discussions/77
We have rubygem-serialport in Fedora due to rubygem-icaro dependency. However, this also seems to be dead. Maybe the most meaningful step ATM is to open ticket against rubygem-serialport with all the information and warning we are going to break the packages.
I think opening a ticket against rubygem-serialport (on bugzilla) can be the first step for the time being.
https://bugzilla.redhat.com/show_bug.cgi?id=2329359
Vít
For now "me" have no idea how to fix rubygem-serialport srpm (even if I have read the above ruby-lang issue/ticket...)
This is patch which I came up with. It builds, but I have no idea if it works, most likely it doesn't 😇
diff --git a/ext/native/posix_serialport_impl.c b/ext/native/posix_serialport_impl.c index 2f9325e..1afba51 100644 --- a/ext/native/posix_serialport_impl.c +++ b/ext/native/posix_serialport_impl.c @@ -80,12 +80,6 @@ int get_fd_helper(obj) VALUE sp_create_impl(class, _port) VALUE class, _port; { -#ifdef HAVE_RUBY_IO_H - rb_io_t *fp; -#else - OpenFile *fp; -#endif - int fd; int num_port; char *port; @@ -109,10 +103,6 @@ VALUE sp_create_impl(class, _port) }; struct termios params; - NEWOBJ(sp, struct RFile); - OBJSETUP((VALUE) sp, class, T_FILE); - MakeOpenFile((VALUE) sp, fp); - switch(TYPE(_port)) { case T_FIXNUM: @@ -166,12 +156,7 @@ VALUE sp_create_impl(class, _port) rb_sys_fail(sTcsetattr); } -#ifdef HAVE_RUBY_IO_H - fp->fd = fd; -#else - fp->f = rb_fdopen(fd, "r+"); -#endif - fp->mode = FMODE_READWRITE | FMODE_SYNC; + VALUE sp = rb_io_open_descriptor(class, fd, FMODE_READWRITE | FMODE_SYNC, rb_str_new(port, 1), Qnil, NULL); return (VALUE) sp; }Vít
Regards, Mamoru
Thoughts?
Vít
Regards, Mamoru
Hi,
I am back with yet another update, this time to 5067a46502. The build is here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=126363642
And the package rebuilds are churning in Copr:
https://copr.fedorainfracloud.org/coprs/vondruch/mpb.1
Nothing particularly interesting. The only thing which stands our are a quite some warning for the Rust code. Not sure if that is due to change in Ruby or in Rust.
As always, please test your packages and your feedback via usual channels is appreciated.
Vít
Hi,
I'm back with new update, this time to 3901df708d. The build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=126573527
Nothing really caught my attention this time. But the good news that we are slowly getting to reasonable shape. According to my mini mass rebuild [1], there is less then 30 package remaining broken and out of them, there are like 15 which are already FTBFS.
Thanks to all who updated (not just) their packages, especially to Mamoru.
Vít
Hi everybody,
I am back with yet another update, this time to rev 335bba0fde. The changes are in PR and the build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=127019099
and the mini mass rebuild is running here:
https://copr.fedorainfracloud.org/coprs/vondruch/mpb.24
There is nothing what would really caught my attention, apart form several .dev dependencies being updated to stable versions.
Also, there have been some news about custom GC support. I yet have to find some cycles (no promises) to explore what does it mean for us. If somebody has some experience already, please let me know.
And as always, looking forward for your feedback.
Cheers,
Vít
Dear Rubyists,
This is likely my last update prior official Ruby 3.4 release. So here I am with update to a11bb36316. The build is available here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=127139135
While the mini mass rebuild is churning here:
https://copr.fedorainfracloud.org/coprs/vondruch/mpb.30/builds/
What I find a bit unfortunate that FESCo was not able to approve the change. But I hope they'll approve in the ticket and we will be able to start with the mass rebuild with the new year. Until then, please give it a try or better, enjoy some well deserve rest.
See you in new year.
Vít
Vít Ondruch via ruby-sig wrote on 2024/12/24 2:09:
Dear Rubyists,
This is likely my last update prior official Ruby 3.4 release. So here I am with update to a11bb36316. The build is available here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=127139135
While the mini mass rebuild is churning here:
https://copr.fedorainfracloud.org/coprs/vondruch/mpb.30/builds/
What I find a bit unfortunate that FESCo was not able to approve the change. But I hope they'll approve in the ticket and we will be able to start with the mass rebuild with the new year. Until then, please give it a try or better, enjoy some well deserve rest.
See you in new year.
Vít
Well, looks like after https://github.com/ruby/ruby/commit/9e0eb9778d557ef59a541a65be658040951de5be... (this is from: https://github.com/rubygems/rubygems/pull/8340 )
it seems that $ gem install --document=rdoc,ri (in %gem_install) no longer generates rdoc/ri documentation even if the above option is explicitly specified...
(The above commit is after the commit you checked: a11bb36316)
So... how should we handle this? Revert the above change (in lib/rubygems/rdoc.rb) or report rubygems upstream?
Regards, Mamoru
Dne 25. 12. 24 v 13:57 Mamoru TASAKA via ruby-sig napsal(a):
Vít Ondruch via ruby-sig wrote on 2024/12/24 2:09:
Dear Rubyists,
This is likely my last update prior official Ruby 3.4 release. So here I am with update to a11bb36316. The build is available here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=127139135
While the mini mass rebuild is churning here:
https://copr.fedorainfracloud.org/coprs/vondruch/mpb.30/builds/
What I find a bit unfortunate that FESCo was not able to approve the change. But I hope they'll approve in the ticket and we will be able to start with the mass rebuild with the new year. Until then, please give it a try or better, enjoy some well deserve rest.
See you in new year.
Vít
Well, looks like after https://github.com/ruby/ruby/commit/9e0eb9778d557ef59a541a65be658040951de5be...
(this is from: https://github.com/rubygems/rubygems/pull/8340 )
it seems that $ gem install --document=rdoc,ri (in %gem_install) no longer generates rdoc/ri documentation even if the above option is explicitly specified...
(The above commit is after the commit you checked: a11bb36316)
So... how should we handle this? Revert the above change (in lib/rubygems/rdoc.rb) or report rubygems upstream?
Just quickly checking, isn't this the root cause?
https://github.com/ruby/rdoc/pull/1171
The question is if we have everything in the right place? And if the `--document` option works correctly, because it it should not be defined or report some error if e.g. the plugin would not be loaded.
Vít
Regards, Mamoru
Dne 30. 12. 24 v 11:16 Vít Ondruch napsal(a):
Dne 25. 12. 24 v 13:57 Mamoru TASAKA via ruby-sig napsal(a):
Vít Ondruch via ruby-sig wrote on 2024/12/24 2:09:
Dear Rubyists,
This is likely my last update prior official Ruby 3.4 release. So here I am with update to a11bb36316. The build is available here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=127139135
While the mini mass rebuild is churning here:
https://copr.fedorainfracloud.org/coprs/vondruch/mpb.30/builds/
What I find a bit unfortunate that FESCo was not able to approve the change. But I hope they'll approve in the ticket and we will be able to start with the mass rebuild with the new year. Until then, please give it a try or better, enjoy some well deserve rest.
See you in new year.
Vít
Well, looks like after https://github.com/ruby/ruby/commit/9e0eb9778d557ef59a541a65be658040951de5be...
(this is from: https://github.com/rubygems/rubygems/pull/8340 )
it seems that $ gem install --document=rdoc,ri (in %gem_install) no longer generates rdoc/ri documentation even if the above option is explicitly specified...
(The above commit is after the commit you checked: a11bb36316)
So... how should we handle this? Revert the above change (in lib/rubygems/rdoc.rb) or report rubygems upstream?
Just quickly checking, isn't this the root cause?
https://github.com/ruby/rdoc/pull/1171
The question is if we have everything in the right place? And if the `--document` option works correctly, because it it should not be defined or report some error if e.g. the plugin would not be loaded.
There is some discussion on this topic here:
https://github.com/ruby/rdoc/pull/1171#issuecomment-2426562156
Vít
Vít
Regards, Mamoru
Just for your information, the following article looks nice to understand the Ruby 3.4 news. https://dev.to/ko1/reading-the-ruby-34-news-with-professionals-english-trans...
And as you may know, Ruby 3.4.1 was released. https://www.ruby-lang.org/en/news/2024/12/25/ruby-3-4-1-released/ https://www.ruby-lang.org/en/news/2024/12/25/ruby-3-4-0-released/
Dne 25. 12. 24 v 13:57 Mamoru TASAKA via ruby-sig napsal(a):
Vít Ondruch via ruby-sig wrote on 2024/12/24 2:09:
Dear Rubyists,
This is likely my last update prior official Ruby 3.4 release. So here I am with update to a11bb36316. The build is available here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=127139135
While the mini mass rebuild is churning here:
https://copr.fedorainfracloud.org/coprs/vondruch/mpb.30/builds/
What I find a bit unfortunate that FESCo was not able to approve the change. But I hope they'll approve in the ticket and we will be able to start with the mass rebuild with the new year. Until then, please give it a try or better, enjoy some well deserve rest.
See you in new year.
Vít
Well, looks like after https://github.com/ruby/ruby/commit/9e0eb9778d557ef59a541a65be658040951de5be...
(this is from: https://github.com/rubygems/rubygems/pull/8340 )
it seems that $ gem install --document=rdoc,ri (in %gem_install) no longer generates rdoc/ri documentation even if the above option is explicitly specified...
(The above commit is after the commit you checked: a11bb36316)
So... how should we handle this? Revert the above change (in lib/rubygems/rdoc.rb) or report rubygems upstream
Looking closer, this is ugly :/ There are exceptions all over the place. Already looking toward Ruby 3.5, which should help to clear up the RDoc situation. Anyway, I see two options forward.
1) Since we are basically doing bundled gem from default gem, it could make sense to include the lib/rubygems_plugin.rb file, which is missing in from the Ruby source repository (+ the plugin loading stub).
2) The other is to "revert" the patch above. What we would essentially need is the have the `Gem.done_installing(&Gem::RDoc.method(:generation_hook))` executed unconditionally, while I believe the tests still needs to be disabled.
There is also third option, update the independent rubygem-rdoc and that should also help. However this would be problematic for ELN, etc.
I'll try to go with the first option, which is a bit cleaner IMHO, while we might face issues should the file change upstream. But if we do, then we can try something else, right? :)
Vít
Regards, Mamoru
Happy new year to everybody,
During the Christmas break, upstream indeed release Ruby 3.4.0 and actually also Ruby 3.4.1. As always, I am back with the updated packages. The scratch build succeeded here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=127496631
The changes are in my PR and the mini mass rebuild is churning here:
https://copr.fedorainfracloud.org/coprs/vondruch/mpb.32
Nothing really notable happened, except the RDoc documentation issue reported in this thread earlier.
My next steps will be to check if I am able to drop the release back to 1, squash the commits and we should follow with mass rebuild. However, the change proposal was not approved yet. I'd like to finish our mass rebuild prior the Fedora mass rebuild, but we will see. There are a few outstanding FTBFS packages, but there should not be any showstopper.
As always please give the Ruby 3.4.1 try and any feedback will be appreciated.
Cheers
Vít
Vít Ondruch via ruby-sig wrote on 2025/01/03 6:07:
Happy new year to everybody,
During the Christmas break, upstream indeed release Ruby 3.4.0 and actually also Ruby 3.4.1. As always, I am back with the updated packages. The scratch build succeeded here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=127496631
The changes are in my PR and the mini mass rebuild is churning here:
https://copr.fedorainfracloud.org/coprs/vondruch/mpb.32
Nothing really notable happened, except the RDoc documentation issue reported in this thread earlier.
My next steps will be to check if I am able to drop the release back to 1, squash the commits and we should follow with mass rebuild. However, the change proposal was not approved yet. I'd like to finish our mass rebuild prior the Fedora mass rebuild, but we will see. There are a few outstanding FTBFS packages, but there should not be any showstopper.
As always please give the Ruby 3.4.1 try and any feedback will be appreciated.
Cheers
Vít
Looks like now (after a very small window) now the srpm you provided began to FTBFS: https://koji.fedoraproject.org/koji/taskinfo?taskID=127506468
Most likely this is due to openssl change: openssl-3.2.2-8.fc42 -> openssl-3.2.2-10.fc42
-9 only adds plans/pq-container.fmf (so I don't think this affects koji build) so most likely due to -10 change: https://src.fedoraproject.org/rpms/openssl/c/3e4eea28e54d0550f621d087a90b82d...
Regards, Mamoru
Dne 03. 01. 25 v 10:29 Mamoru TASAKA via ruby-sig napsal(a):
Vít Ondruch via ruby-sig wrote on 2025/01/03 6:07:
Happy new year to everybody,
During the Christmas break, upstream indeed release Ruby 3.4.0 and actually also Ruby 3.4.1. As always, I am back with the updated packages. The scratch build succeeded here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=127496631
The changes are in my PR and the mini mass rebuild is churning here:
https://copr.fedorainfracloud.org/coprs/vondruch/mpb.32
Nothing really notable happened, except the RDoc documentation issue reported in this thread earlier.
My next steps will be to check if I am able to drop the release back to 1, squash the commits and we should follow with mass rebuild. However, the change proposal was not approved yet. I'd like to finish our mass rebuild prior the Fedora mass rebuild, but we will see. There are a few outstanding FTBFS packages, but there should not be any showstopper.
As always please give the Ruby 3.4.1 try and any feedback will be appreciated.
Cheers
Vít
Looks like now (after a very small window) now the srpm you provided began to FTBFS: https://koji.fedoraproject.org/koji/taskinfo?taskID=127506468
Most likely this is due to openssl change: openssl-3.2.2-8.fc42 -> openssl-3.2.2-10.fc42
-9 only adds plans/pq-container.fmf (so I don't think this affects koji build) so most likely due to -10 change: https://src.fedoraproject.org/rpms/openssl/c/3e4eea28e54d0550f621d087a90b82d...
Regards, Mamoru
Reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=2335414
Vít
Vít Ondruch via ruby-sig wrote on 2025/01/03 23:24:
Dne 03. 01. 25 v 10:29 Mamoru TASAKA via ruby-sig napsal(a):
Vít Ondruch via ruby-sig wrote on 2025/01/03 6:07:
Happy new year to everybody,
During the Christmas break, upstream indeed release Ruby 3.4.0 and actually also Ruby 3.4.1. As always, I am back with the updated packages. The scratch build succeeded here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=127496631
The changes are in my PR and the mini mass rebuild is churning here:
https://copr.fedorainfracloud.org/coprs/vondruch/mpb.32
Nothing really notable happened, except the RDoc documentation issue reported in this thread earlier.
My next steps will be to check if I am able to drop the release back to 1, squash the commits and we should follow with mass rebuild. However, the change proposal was not approved yet. I'd like to finish our mass rebuild prior the Fedora mass rebuild, but we will see. There are a few outstanding FTBFS packages, but there should not be any showstopper.
As always please give the Ruby 3.4.1 try and any feedback will be appreciated.
Cheers
Vít
Looks like now (after a very small window) now the srpm you provided began to FTBFS: https://koji.fedoraproject.org/koji/taskinfo?taskID=127506468
Most likely this is due to openssl change: openssl-3.2.2-8.fc42 -> openssl-3.2.2-10.fc42
-9 only adds plans/pq-container.fmf (so I don't think this affects koji build) so most likely due to -10 change: https://src.fedoraproject.org/rpms/openssl/c/3e4eea28e54d0550f621d087a90b82d...
Regards, Mamoru
Reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=2335414
Vít
Now looking at this, the above test failure seems to be happening at the very first stage of openssl initialization with OPENSSL_FORCE_FIPS_MODE is enabled:
So in ruby.src.rpm Source15 test_openssl_fips.rb : this sets ENV['OPENSSL_FORCE_FIPS_MODE'] = '1', then the above test seems to be failing just after
"require 'openssl'" and error message suggests OPENSSL_init_ssl is failing.
I've noted the very small reproducer, so now I believe this is not ruby fault.
Regards, Mamoru
Dne 03. 01. 25 v 15:35 Mamoru TASAKA via ruby-sig napsal(a):
Vít Ondruch via ruby-sig wrote on 2025/01/03 23:24:
Dne 03. 01. 25 v 10:29 Mamoru TASAKA via ruby-sig napsal(a):
Vít Ondruch via ruby-sig wrote on 2025/01/03 6:07:
Happy new year to everybody,
During the Christmas break, upstream indeed release Ruby 3.4.0 and actually also Ruby 3.4.1. As always, I am back with the updated packages. The scratch build succeeded here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=127496631
The changes are in my PR and the mini mass rebuild is churning here:
https://copr.fedorainfracloud.org/coprs/vondruch/mpb.32
Nothing really notable happened, except the RDoc documentation issue reported in this thread earlier.
My next steps will be to check if I am able to drop the release back to 1, squash the commits and we should follow with mass rebuild. However, the change proposal was not approved yet. I'd like to finish our mass rebuild prior the Fedora mass rebuild, but we will see. There are a few outstanding FTBFS packages, but there should not be any showstopper.
As always please give the Ruby 3.4.1 try and any feedback will be appreciated.
Cheers
Vít
Looks like now (after a very small window) now the srpm you provided began to FTBFS: https://koji.fedoraproject.org/koji/taskinfo?taskID=127506468
Most likely this is due to openssl change: openssl-3.2.2-8.fc42 -> openssl-3.2.2-10.fc42
-9 only adds plans/pq-container.fmf (so I don't think this affects koji build) so most likely due to -10 change: https://src.fedoraproject.org/rpms/openssl/c/3e4eea28e54d0550f621d087a90b82d...
Regards, Mamoru
Reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=2335414
Vít
Now looking at this, the above test failure seems to be happening at the very first stage of openssl initialization with OPENSSL_FORCE_FIPS_MODE is enabled:
So in ruby.src.rpm Source15 test_openssl_fips.rb : this sets ENV['OPENSSL_FORCE_FIPS_MODE'] = '1', then the above test seems to be failing just after
"require 'openssl'" and error message suggests OPENSSL_init_ssl is failing.
I've noted the very small reproducer, so now I believe this is not ruby fault.
Very nice reduction indeed 👍
Vít
Regards, Mamoru
Dne 02. 01. 25 v 22:07 Vít Ondruch napsal(a):
Happy new year to everybody,
During the Christmas break, upstream indeed release Ruby 3.4.0 and actually also Ruby 3.4.1. As always, I am back with the updated packages. The scratch build succeeded here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=127496631
The changes are in my PR and the mini mass rebuild is churning here:
https://copr.fedorainfracloud.org/coprs/vondruch/mpb.32
Nothing really notable happened, except the RDoc documentation issue reported in this thread earlier.
My next steps will be to check if I am able to drop the release back to 1
So this ^^ is not doable, mainly due to rubygem-rss but also due to rubygem-racc.
Vít
, squash the commits and we should follow with mass rebuild. However, the change proposal was not approved yet. I'd like to finish our mass rebuild prior the Fedora mass rebuild, but we will see. There are a few outstanding FTBFS packages, but there should not be any showstopper.
As always please give the Ruby 3.4.1 try and any feedback will be appreciated.
Cheers
Vít
ruby-sig@lists.fedoraproject.org
-
Dan Allen -
Jun Aruga -
Mamoru TASAKA -
Vít Ondruch