Hi,
It is time of the year when new version of Ruby was released upstream and we should land it in Fedora. Unfortunately, the change proposal was approved just last Thursday and on top of that, rebase of libffi broke Ruby (I am going to disable the failing test cases for the moment and hope for the best). So this brings us into situation, where won't have enough time prior Fedora Mass rebuild. I have discussed this a bit with relengs and one of the options would be to build Ruby early during the mass rebuild and fix the outfall later. I shared the proposal in the Fedora Mass rebuild ticket [2]. One downside would be that in case of problems, we could not trigger our contingency plan, which is "drop our side tag". But I hope we won't need that.
Any thoughts?
My fist concern is that maybe we should build more then just Ruby. rubygem-json comes to my mind and possibly rubygem-nokogiri?
Vít
Dne 17. 01. 22 v 16:15 Vít Ondruch napsal(a):
Hi,
It is time of the year when new version of Ruby was released upstream and we should land it in Fedora. Unfortunately, the change proposal was approved just last Thursday and on top of that, rebase of libffi broke Ruby (I am going to disable the failing test cases for the moment and hope for the best). So this brings us into situation, where won't have enough time prior Fedora Mass rebuild. I have discussed this a bit with relengs and one of the options would be to build Ruby early during the mass rebuild and fix the outfall later. I shared the proposal in the Fedora Mass rebuild ticket [2]. One downside would be that in case of problems, we could not trigger our contingency plan, which is "drop our side tag". But I hope we won't need that.
Any thoughts?
My fist concern is that maybe we should build more then just Ruby. rubygem-json
Hm, I should probably really bump the Release of rubygem-json, otherwise we'll be in troubles. Previously, we were typically lucky that the independent package had lower NVR, this time, it wins.
comes to my mind and possibly rubygem-nokogiri?
And Nokogiri is RSpec dependency, that is the reason to prioritize it.
Vít
Vít
Dne 17. 01. 22 v 16:26 Vít Ondruch napsal(a):
Dne 17. 01. 22 v 16:15 Vít Ondruch napsal(a):
Hi,
It is time of the year when new version of Ruby was released upstream and we should land it in Fedora. Unfortunately, the change proposal was approved just last Thursday and on top of that, rebase of libffi broke Ruby (I am going to disable the failing test cases for the moment and hope for the best). So this brings us into situation, where won't have enough time prior Fedora Mass rebuild. I have discussed this a bit with relengs and one of the options would be to build Ruby early during the mass rebuild and fix the outfall later. I shared the proposal in the Fedora Mass rebuild ticket [2]. One downside would be that in case of problems, we could not trigger our contingency plan, which is "drop our side tag". But I hope we won't need that.
Any thoughts?
My fist concern is that maybe we should build more then just Ruby. rubygem-json
Hm, I should probably really bump the Release of rubygem-json, otherwise we'll be in troubles. Previously, we were typically lucky that the independent package had lower NVR, this time, it wins.
comes to my mind and possibly rubygem-nokogiri?
Ha, it is not nokogiri but thread_order :facepalm:
V.
And Nokogiri is RSpec dependency, that is the reason to prioritize it.
Vít
Vít
And RubyGems does not generate documentation. Oh my:
https://github.com/rubygems/rubygems/issues/5295
Vít
Dne 17. 01. 22 v 16:45 Vít Ondruch napsal(a):
Dne 17. 01. 22 v 16:26 Vít Ondruch napsal(a):
Dne 17. 01. 22 v 16:15 Vít Ondruch napsal(a):
Hi,
It is time of the year when new version of Ruby was released upstream and we should land it in Fedora. Unfortunately, the change proposal was approved just last Thursday and on top of that, rebase of libffi broke Ruby (I am going to disable the failing test cases for the moment and hope for the best). So this brings us into situation, where won't have enough time prior Fedora Mass rebuild. I have discussed this a bit with relengs and one of the options would be to build Ruby early during the mass rebuild and fix the outfall later. I shared the proposal in the Fedora Mass rebuild ticket [2]. One downside would be that in case of problems, we could not trigger our contingency plan, which is "drop our side tag". But I hope we won't need that.
Any thoughts?
My fist concern is that maybe we should build more then just Ruby. rubygem-json
Hm, I should probably really bump the Release of rubygem-json, otherwise we'll be in troubles. Previously, we were typically lucky that the independent package had lower NVR, this time, it wins.
comes to my mind and possibly rubygem-nokogiri?
Ha, it is not nokogiri but thread_order :facepalm:
V.
And Nokogiri is RSpec dependency, that is the reason to prioritize it.
Vít
Vít
So this was (my) fault of missing dependencies on our side:
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/f0b9944594f3ec768320...
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/a81f20ad712c29df4c84...
Handling of default gems should be generally improved to prevent such issues in the future. Not sure if and when I should phase out the independent default gems, that could also improve the situation at least a bit.
But it still leaves bitter taste behind, because the issue was not properly reported IMO. This line [1] completely hides the issue. Not sure how to properly handle such situations. I have just left a few notes behind [2].
Vít
[1] https://github.com/rubygems/rubygems/blob/12aeef6ba9a3be0022be9934c1a3e4c46a...
[2] https://github.com/rubygems/rubygems/issues/5295#issuecomment-1015329337
Dne 17. 01. 22 v 18:27 Vít Ondruch napsal(a):
And RubyGems does not generate documentation. Oh my:
https://github.com/rubygems/rubygems/issues/5295
Vít
Dne 17. 01. 22 v 16:45 Vít Ondruch napsal(a):
Dne 17. 01. 22 v 16:26 Vít Ondruch napsal(a):
Dne 17. 01. 22 v 16:15 Vít Ondruch napsal(a):
Hi,
It is time of the year when new version of Ruby was released upstream and we should land it in Fedora. Unfortunately, the change proposal was approved just last Thursday and on top of that, rebase of libffi broke Ruby (I am going to disable the failing test cases for the moment and hope for the best). So this brings us into situation, where won't have enough time prior Fedora Mass rebuild. I have discussed this a bit with relengs and one of the options would be to build Ruby early during the mass rebuild and fix the outfall later. I shared the proposal in the Fedora Mass rebuild ticket [2]. One downside would be that in case of problems, we could not trigger our contingency plan, which is "drop our side tag". But I hope we won't need that.
Any thoughts?
My fist concern is that maybe we should build more then just Ruby. rubygem-json
Hm, I should probably really bump the Release of rubygem-json, otherwise we'll be in troubles. Previously, we were typically lucky that the independent package had lower NVR, this time, it wins.
comes to my mind and possibly rubygem-nokogiri?
Ha, it is not nokogiri but thread_order :facepalm:
V.
And Nokogiri is RSpec dependency, that is the reason to prioritize it.
Vít
Vít
Also, latest changes for Ruby 3.1 PR (106; commit a81f20ad712c29df4c847919cc46bb7bc19ca455) fail to build for me: https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/builds/
Failures like: ``` Expected #<Process::Status: pid 89350 SIGABRT (signal 6) (core dumped)> to be success?. ```
Not sure what's the cause. Pavel
On Tue, Jan 18, 2022 at 12:53 PM Vít Ondruch vondruch@redhat.com wrote:
So this was (my) fault of missing dependencies on our side:
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/f0b9944594f3ec768320...
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/a81f20ad712c29df4c84...
Handling of default gems should be generally improved to prevent such issues in the future. Not sure if and when I should phase out the independent default gems, that could also improve the situation at least a bit.
But it still leaves bitter taste behind, because the issue was not properly reported IMO. This line [1] completely hides the issue. Not sure how to properly handle such situations. I have just left a few notes behind [2].
Vít
[1] https://github.com/rubygems/rubygems/blob/12aeef6ba9a3be0022be9934c1a3e4c46a...
[2] https://github.com/rubygems/rubygems/issues/5295#issuecomment-1015329337
Dne 17. 01. 22 v 18:27 Vít Ondruch napsal(a):
And RubyGems does not generate documentation. Oh my:
https://github.com/rubygems/rubygems/issues/5295
Vít
Dne 17. 01. 22 v 16:45 Vít Ondruch napsal(a):
Dne 17. 01. 22 v 16:26 Vít Ondruch napsal(a):
Dne 17. 01. 22 v 16:15 Vít Ondruch napsal(a):
Hi,
It is time of the year when new version of Ruby was released upstream and we should land it in Fedora. Unfortunately, the change proposal was approved just last Thursday and on top of that, rebase of libffi broke Ruby (I am going to disable the failing test cases for the moment and hope for the best). So this brings us into situation, where won't have enough time prior Fedora Mass rebuild. I have discussed this a bit with relengs and one of the options would be to build Ruby early during the mass rebuild and fix the outfall later. I shared the proposal in the Fedora Mass rebuild ticket [2]. One downside would be that in case of problems, we could not trigger our contingency plan, which is "drop our side tag". But I hope we won't need that.
Any thoughts?
My fist concern is that maybe we should build more then just Ruby. rubygem-json
Hm, I should probably really bump the Release of rubygem-json, otherwise we'll be in troubles. Previously, we were typically lucky that the independent package had lower NVR, this time, it wins.
comes to my mind and possibly rubygem-nokogiri?
Ha, it is not nokogiri but thread_order :facepalm:
V.
And Nokogiri is RSpec dependency, that is the reason to prioritize it.
Vít
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 on the list, report it: https://pagure.io/fedora-infrastructure
This is the build which should be ready for mass rebuild:
https://koji.fedoraproject.org/koji/taskinfo?taskID=81407116
Dne 18. 01. 22 v 16:45 Pavel Valena napsal(a):
Also, latest changes for Ruby 3.1 PR (106; commit a81f20ad712c29df4c847919cc46bb7bc19ca455) fail to build for me: https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/builds/
Failures like:
Expected #<Process::Status: pid 89350 SIGABRT (signal 6) (core dumped)> to be success?.
This is, I believe, the FFI issue I have mentioned somewhere.
Vít
Not sure what's the cause. Pavel
On Tue, Jan 18, 2022 at 12:53 PM Vít Ondruch vondruch@redhat.com wrote:
So this was (my) fault of missing dependencies on our side:
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/f0b9944594f3ec768320...
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/a81f20ad712c29df4c84...
Handling of default gems should be generally improved to prevent such issues in the future. Not sure if and when I should phase out the independent default gems, that could also improve the situation at least a bit.
But it still leaves bitter taste behind, because the issue was not properly reported IMO. This line [1] completely hides the issue. Not sure how to properly handle such situations. I have just left a few notes behind [2].
Vít
[1] https://github.com/rubygems/rubygems/blob/12aeef6ba9a3be0022be9934c1a3e4c46a...
[2] https://github.com/rubygems/rubygems/issues/5295#issuecomment-1015329337
Dne 17. 01. 22 v 18:27 Vít Ondruch napsal(a):
And RubyGems does not generate documentation. Oh my:
https://github.com/rubygems/rubygems/issues/5295
Vít
Dne 17. 01. 22 v 16:45 Vít Ondruch napsal(a):
Dne 17. 01. 22 v 16:26 Vít Ondruch napsal(a):
Dne 17. 01. 22 v 16:15 Vít Ondruch napsal(a):
Hi,
It is time of the year when new version of Ruby was released upstream and we should land it in Fedora. Unfortunately, the change proposal was approved just last Thursday and on top of that, rebase of libffi broke Ruby (I am going to disable the failing test cases for the moment and hope for the best). So this brings us into situation, where won't have enough time prior Fedora Mass rebuild. I have discussed this a bit with relengs and one of the options would be to build Ruby early during the mass rebuild and fix the outfall later. I shared the proposal in the Fedora Mass rebuild ticket [2]. One downside would be that in case of problems, we could not trigger our contingency plan, which is "drop our side tag". But I hope we won't need that.
Any thoughts?
My fist concern is that maybe we should build more then just Ruby. rubygem-json
Hm, I should probably really bump the Release of rubygem-json, otherwise we'll be in troubles. Previously, we were typically lucky that the independent package had lower NVR, this time, it wins.
comes to my mind and possibly rubygem-nokogiri?
Ha, it is not nokogiri but thread_order :facepalm:
V.
And Nokogiri is RSpec dependency, that is the reason to prioritize it.
Vít
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 on the list, report it: https://pagure.io/fedora-infrastructure
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 on the list, report it: https://pagure.io/fedora-infrastructure
Except I have bumped Psych release instead of Json :facepalm: Here is another attempt:
https://koji.fedoraproject.org/koji/taskinfo?taskID=81413346
Vít
Dne 18. 01. 22 v 17:29 Vít Ondruch napsal(a):
This is the build which should be ready for mass rebuild:
https://koji.fedoraproject.org/koji/taskinfo?taskID=81407116
Dne 18. 01. 22 v 16:45 Pavel Valena napsal(a):
Also, latest changes for Ruby 3.1 PR (106; commit a81f20ad712c29df4c847919cc46bb7bc19ca455) fail to build for me: https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/builds/
Failures like:
Expected #<Process::Status: pid 89350 SIGABRT (signal 6) (core dumped)> to be success?.
This is, I believe, the FFI issue I have mentioned somewhere.
Vít
Not sure what's the cause. Pavel
On Tue, Jan 18, 2022 at 12:53 PM Vít Ondruch vondruch@redhat.com wrote:
So this was (my) fault of missing dependencies on our side:
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/f0b9944594f3ec768320...
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/a81f20ad712c29df4c84...
Handling of default gems should be generally improved to prevent such issues in the future. Not sure if and when I should phase out the independent default gems, that could also improve the situation at least a bit.
But it still leaves bitter taste behind, because the issue was not properly reported IMO. This line [1] completely hides the issue. Not sure how to properly handle such situations. I have just left a few notes behind [2].
Vít
[1] https://github.com/rubygems/rubygems/blob/12aeef6ba9a3be0022be9934c1a3e4c46a...
[2] https://github.com/rubygems/rubygems/issues/5295#issuecomment-1015329337
Dne 17. 01. 22 v 18:27 Vít Ondruch napsal(a):
And RubyGems does not generate documentation. Oh my:
https://github.com/rubygems/rubygems/issues/5295
Vít
Dne 17. 01. 22 v 16:45 Vít Ondruch napsal(a):
Dne 17. 01. 22 v 16:26 Vít Ondruch napsal(a):
Dne 17. 01. 22 v 16:15 Vít Ondruch napsal(a): > Hi, > > It is time of the year when new version of Ruby was released > upstream and we should land it in Fedora. Unfortunately, the change > proposal was approved just last Thursday and on top of that, rebase > of libffi broke Ruby (I am going to disable the failing test cases > for the moment and hope for the best). So this brings us into > situation, where won't have enough time prior Fedora Mass rebuild. > I have discussed this a bit with relengs and one of the options > would be to build Ruby early during the mass rebuild and fix the > outfall later. I shared the proposal in the Fedora Mass rebuild > ticket [2]. One downside would be that in case of problems, we > could not trigger our contingency plan, which is "drop our side > tag". But I hope we won't need that. > > Any thoughts? > > My fist concern is that maybe we should build more then just Ruby. > rubygem-json
Hm, I should probably really bump the Release of rubygem-json, otherwise we'll be in troubles. Previously, we were typically lucky that the independent package had lower NVR, this time, it wins.
> comes to my mind and possibly rubygem-nokogiri?
Ha, it is not nokogiri but thread_order :facepalm:
V.
And Nokogiri is RSpec dependency, that is the reason to prioritize it.
Vít
> > Vít > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=2040380 > > [2] https://pagure.io/releng/issue/10538#comment-775197 >
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 on the list, report it: https://pagure.io/fedora-infrastructure
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 on the list, report it: https://pagure.io/fedora-infrastructure
On Mon, Jan 17, 2022 at 4:27 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 17. 01. 22 v 16:15 Vít Ondruch napsal(a):
Hi,
It is time of the year when new version of Ruby was released upstream and we should land it in Fedora. Unfortunately, the change proposal was approved just last Thursday and on top of that, rebase of libffi broke Ruby (I am going to disable the failing test cases for the moment and hope for the best). So this brings us into situation, where won't have enough time prior Fedora Mass rebuild. I have discussed this a bit with relengs and one of the options would be to build Ruby early during the mass rebuild and fix the outfall later. I shared the proposal in the Fedora Mass rebuild ticket [2]. One downside would be that in case of problems, we could not trigger our contingency plan, which is "drop our side tag". But I hope we won't need that.
Any thoughts?
My fist concern is that maybe we should build more then just Ruby. rubygem-json
Hello,
I've run the rebuilds of previously failing packages in my COPR (probably with a little older Ruby 3.1 build), and here are the results:
https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/builds/ removed other buildroots, so failure marks rawhide buildroot.
From that what stands out: 1) ``` cannot load such file -- net/smtp ``` several packages - e.g.: https://copr.fedorainfracloud.org/coprs/build/3190889
2) ``` Tried to load unspecified class: BSON::Document # /usr/share/gems/gems/psych-4.0.2/lib/psych/class_loader.rb:99:in `find' # /usr/share/gems/gems/psych-4.0.2/lib/psych/class_loader.rb:28:in `load' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:424:in `resolve_class' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:288:in `visit_Psych_Nodes_Mapping' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:30:in `visit' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:6:in `accept' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:35:in `accept' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:318:in `visit_Psych_Nodes_Document' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:30:in `visit' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:6:in `accept' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:35:in `accept' # ./spec/bson/document_spec.rb:487:in `block (5 levels) in <top (required)>' # ./spec/bson/document_spec.rb:491:in `block (5 levels) in <top (required)>'
``` https://copr.fedorainfracloud.org/coprs/build/3190892
3) ``` + rspec -rspec_helper -fd --exclude-pattern 'spec/concurrent/{actor_spec.rb,channel_spec.rb,lazy_register_spec.rb,channel/**/*,e> internal:timev:310:in `initialize': no implicit conversion of Hash into Integer (TypeError) from /usr/share/gems/gems/timecop-0.9.2/lib/timecop/time_extensions.rb:22:in `new' from /usr/share/gems/gems/timecop-0.9.2/lib/timecop/time_extensions.rb:22:in `new_with_mock_time' from internal:timev:224:in `now' from /usr/share/gems/gems/rspec-core-3.10.1/lib/rspec/core/reporter.rb:89:in `start' from /usr/share/gems/gems/rspec-core-3.10.1/lib/rspec/core/reporter.rb:72:in `report' from /usr/share/gems/gems/rspec-core-3.10.1/lib/rspec/core/runner.rb:115:in `run_specs' from /usr/share/gems/gems/rspec-core-3.10.1/lib/rspec/core/runner.rb:89:in `run' from /usr/share/gems/gems/rspec-core-3.10.1/lib/rspec/core/runner.rb:71:in `run' from /usr/share/gems/gems/rspec-core-3.10.1/lib/rspec/core/runner.rb:45:in `invoke' from /usr/share/gems/gems/rspec-core-3.10.1/exe/rspec:4:in `<top (required)>' from /usr/bin/rspec:23:in `load' from /usr/bin/rspec:23:in `<main>' Run options: exclude {:stress=>true}
``` https://copr.fedorainfracloud.org/coprs/build/3190932
4) ``` + ruby -rrubygems -Ilib:test:ext/gio2 test/run-test.rb glib-compile-resources ruby-gio2.gresource.xml cd resource glib-compile-schemas . cd - cd schema/default glib-compile-schemas . cd - cd schema/source cd - Loaded suite test Started ............../usr/share/gems/gems/gobject-introspection-3.4.9/lib/gobject-introspection/loader.rb:616: [BUG] Segmentation fault at 0x00000> ruby 3.1.0dev (2021-12-07 master ec878dac90) [x86_64-linux]
``` https://copr.fedorainfracloud.org/coprs/build/3190970
5) ``` + ruby -Ilib:test -rforwardable -e 'Dir.glob '''./test/cases/*test.rb''', &method(:require)' /builddir/build/BUILD/globalid-0.4.2/usr/share/gems/gems/globalid-0.4.2/lib/global_id/uri/gid.rb:176:in `module:URI': uninitia> Did you mean? scheme_list from /builddir/build/BUILD/globalid-0.4.2/usr/share/gems/gems/globalid-0.4.2/lib/global_id/uri/gid.rb:6:in `<top (requir> from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:85:in `require' from /builddir/build/BUILD/globalid-0.4.2/usr/share/gems/gems/globalid-0.4.2/lib/global_id/global_id.rb:6:in `<top (requ> from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:85:in `require' from /builddir/build/BUILD/globalid-0.4.2/usr/share/gems/gems/globalid-0.4.2/lib/global_id.rb:1:in `<top (required)>' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:85:in `require' from /builddir/build/BUILD/test/helper.rb:5:in `<top (required)>' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:85:in `require' from /builddir/build/BUILD/globalid-0.4.2/usr/share/gems/gems/globalid-0.4.2/test/cases/global_id_test.rb:1:in `<top (re> from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:85:in `require' from internal:dir:220:in `glob' from -e:1:in `<main>' error: Bad exit status from /var/tmp/rpm-tmp.bOvWxr (%check) Bad exit status from /var/tmp/rpm-tmp.bOvWxr (%check) ``` https://copr.fedorainfracloud.org/coprs/build/3190974
6) ``` 1) Error: MIME::Types::Loader#test_0001_loads YAML files correctly: Psych::DisallowedClass: Tried to load unspecified class: MIME::Type /usr/share/gems/gems/psych-4.0.2/lib/psych/class_loader.rb:99:in `find' /usr/share/gems/gems/psych-4.0.2/lib/psych/class_loader.rb:28:in `load' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:424:in `resolve_class' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:213:in `visit_Psych_Nodes_Mapping' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:30:in `visit' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:6:in `accept' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:35:in `accept' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:338:in `block in register_empty' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:338:in `each' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:338:in `register_empty' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:146:in `visit_Psych_Nodes_Sequence' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:30:in `visit' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:6:in `accept' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:35:in `accept' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:318:in `visit_Psych_Nodes_Document' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:30:in `visit' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:6:in `accept' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:35:in `accept' /usr/share/ruby/psych.rb:335:in `safe_load' /usr/share/ruby/psych.rb:370:in `load' /builddir/build/BUILD/rubygem-mime-types-3.3.1/usr/share/gems/gems/mime-types-3.3.1/lib/mime/types/loader.rb:113:in `load_fr> /builddir/build/BUILD/rubygem-mime-types-3.3.1/usr/share/gems/gems/mime-types-3.3.1/lib/mime/types/loader.rb:49:in `block in> /builddir/build/BUILD/rubygem-mime-types-3.3.1/usr/share/gems/gems/mime-types-3.3.1/lib/mime/types/loader.rb:48:in `each' /builddir/build/BUILD/rubygem-mime-types-3.3.1/usr/share/gems/gems/mime-types-3.3.1/lib/mime/types/loader.rb:48:in `load_yam> /builddir/build/BUILD/rubygem-mime-types-3.3.1/usr/share/gems/gems/mime-types-3.3.1/test/test_mime_types_loader.rb:26:in `bl> ``` https://copr.fedorainfracloud.org/coprs/build/3191613
7) ```
Failures:
1) Mysql2::Result should raise a TypeError exception when it doesn't wrap a result set Failure/Error: r = Mysql2::Result.new
TypeError: allocator undefined for Mysql2::Result # ./spec/mysql2/result_spec.rb:9:in `new' # ./spec/mysql2/result_spec.rb:9:in `block (2 levels) in <top (required)>' ``` https://copr.fedorainfracloud.org/coprs/build/3191628
8) ``` --binPsych::DisallowedClass: Tried to load unspecified class: Rack::Lint::ErrorWrapper
``` https://copr.fedorainfracloud.org/coprs/build/3191833
9) ``` 1) Error: TestMBoxParsing#test_from_line_splitting: NoMethodError: undefined method `encode' for URI:Module
uri = URI(prefix + URI.encode(@path, URI_ENCODE_CHARS)) ^^^^^^^ /builddir/build/BUILD/sup-1.0/lib/sup/mbox.rb:26:in `initialize' /builddir/build/BUILD/sup-1.0/test/test_header_parsing.rb:113:in `new' /builddir/build/BUILD/sup-1.0/test/test_header_parsing.rb:113:in `test_from_line_splitting' ``` https://copr.fedorainfracloud.org/coprs/build/3191877
10) ``` + ruby -I.:lib -e 'Dir.glob "test/**/*_test.rb", &method(:require)' internal:timev:310:in `initialize': no implicit conversion of Hash into Integer (TypeError) from /builddir/build/BUILD/timecop-0.9.2/usr/share/gems/gems/timecop-0.9.2/lib/timecop/time_extensions.rb:22:in `new' from /builddir/build/BUILD/timecop-0.9.2/usr/share/gems/gems/timecop-0.9.2/lib/timecop/time_extensions.rb:22:in `new_wit> from internal:timev:224:in `now' from /builddir/build/BUILD/timecop-0.9.2/usr/share/gems/gems/timecop-0.9.2/lib/timecop/time_extensions.rb:14:in `now_wit> from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent/utility/monotonic_time.rb:7:in `initialize' from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent/synchronization/object.rb:59:in `new' from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent/utility/monotonic_time.rb:42:in `module:Concurrent' from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent/utility/monotonic_time.rb:3:in `<top (required)>' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:85:in `require' from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent/executor/ruby_thread_pool_executor.rb:5:in `<top (require> from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:85:in `require' from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent/executor/thread_pool_executor.rb:2:in `<top (required)>' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:85:in `require' from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent/executor/cached_thread_pool.rb:2:in `<top (required)>' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:85:in `require' from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent/configuration.rb:7:in `<top (required)>' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:85:in `require' from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent.rb:4:in `<top (required)>' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:85:in `require' from /usr/share/gems/gems/activesupport-6.1.4.1/lib/active_support/logger_thread_safe_level.rb:5:in `<top (required)>' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:85:in `require' from /usr/share/gems/gems/activesupport-6.1.4.1/lib/active_support/logger_silence.rb:5:in `<top (required)>' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:85:in `require' from /usr/share/gems/gems/activesupport-6.1.4.1/lib/active_support/logger.rb:3:in `<top (required)>' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:85:in `require' from /usr/share/gems/gems/activesupport-6.1.4.1/lib/active_support.rb:29:in `<top (required)>' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:85:in `require' from /usr/share/gems/gems/activesupport-6.1.4.1/lib/active_support/all.rb:3:in `<top (required)>' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:160:in `require' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:160:in `rescue in require' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:149:in `require' from /builddir/build/BUILD/timecop-0.9.2/usr/share/gems/gems/timecop-0.9.2/test/time_stack_item_test.rb:5:in `<top (requ> from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:85:in `require' from internal:dir:220:in `glob' from -e:1:in `<main>' internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:85:in `require': cannot load such file -- active_support/all > from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:85:in `require' from /builddir/build/BUILD/timecop-0.9.2/usr/share/gems/gems/timecop-0.9.2/test/time_stack_item_test.rb:5:in `<top (requ> from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:85:in `require' from internal:dir:220:in `glob' from -e:1:in `<main>' ``` https://copr.fedorainfracloud.org/coprs/build/3191885
I'm also running some more rebuilds of the failures (I've fixed some dependencies now), and with newer Ruby 3.1.
Please ignore the Rails stuff, as I'm going to fix that separately with the upgrade to RoR 7.0.
Sorry for long email, HIH,
Pavel
Hm, I should probably really bump the Release of rubygem-json, otherwise we'll be in troubles. Previously, we were typically lucky that the independent package had lower NVR, this time, it wins.
comes to my mind and possibly rubygem-nokogiri?
And Nokogiri is RSpec dependency, that is the reason to prioritize it.
Vít
Vít
On Tue, Jan 18, 2022 at 12:00 PM Pavel Valena pvalena@redhat.com wrote:
On Mon, Jan 17, 2022 at 4:27 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 17. 01. 22 v 16:15 Vít Ondruch napsal(a):
Hi,
It is time of the year when new version of Ruby was released upstream and we should land it in Fedora. Unfortunately, the change proposal was approved just last Thursday and on top of that, rebase of libffi broke Ruby (I am going to disable the failing test cases for the moment and hope for the best). So this brings us into situation, where won't have enough time prior Fedora Mass rebuild. I have discussed this a bit with relengs and one of the options would be to build Ruby early during the mass rebuild and fix the outfall later. I shared the proposal in the Fedora Mass rebuild ticket [2]. One downside would be that in case of problems, we could not trigger our contingency plan, which is "drop our side tag". But I hope we won't need that.
Any thoughts?
My fist concern is that maybe we should build more then just Ruby. rubygem-json
Hello,
I've run the rebuilds of previously failing packages in my COPR (probably with a little older Ruby 3.1 build), and here are the results:
https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/builds/ removed other buildroots, so failure marks rawhide buildroot.
From that what stands out:
cannot load such file -- net/smtp
several packages - e.g.: https://copr.fedorainfracloud.org/coprs/build/3190889
Tried to load unspecified class: BSON::Document # /usr/share/gems/gems/psych-4.0.2/lib/psych/class_loader.rb:99:in `find' # /usr/share/gems/gems/psych-4.0.2/lib/psych/class_loader.rb:28:in `load' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:424:in `resolve_class' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:288:in `visit_Psych_Nodes_Mapping' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:30:in `visit' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:6:in `accept' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:35:in `accept' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:318:in `visit_Psych_Nodes_Document' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:30:in `visit' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:6:in `accept' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:35:in `accept' # ./spec/bson/document_spec.rb:487:in `block (5 levels) in <top (required)>' # ./spec/bson/document_spec.rb:491:in `block (5 levels) in <top (required)>'
https://copr.fedorainfracloud.org/coprs/build/3190892
+ rspec -rspec_helper -fd --exclude-pattern 'spec/concurrent/{actor_spec.rb,channel_spec.rb,lazy_register_spec.rb,channel/**/*,e> <internal:timev>:310:in `initialize': no implicit conversion of Hash into Integer (TypeError) from /usr/share/gems/gems/timecop-0.9.2/lib/timecop/time_extensions.rb:22:in `new' from /usr/share/gems/gems/timecop-0.9.2/lib/timecop/time_extensions.rb:22:in `new_with_mock_time' from <internal:timev>:224:in `now' from /usr/share/gems/gems/rspec-core-3.10.1/lib/rspec/core/reporter.rb:89:in `start' from /usr/share/gems/gems/rspec-core-3.10.1/lib/rspec/core/reporter.rb:72:in `report' from /usr/share/gems/gems/rspec-core-3.10.1/lib/rspec/core/runner.rb:115:in `run_specs' from /usr/share/gems/gems/rspec-core-3.10.1/lib/rspec/core/runner.rb:89:in `run' from /usr/share/gems/gems/rspec-core-3.10.1/lib/rspec/core/runner.rb:71:in `run' from /usr/share/gems/gems/rspec-core-3.10.1/lib/rspec/core/runner.rb:45:in `invoke' from /usr/share/gems/gems/rspec-core-3.10.1/exe/rspec:4:in `<top (required)>' from /usr/bin/rspec:23:in `load' from /usr/bin/rspec:23:in `<main>' Run options: exclude {:stress=>true}
https://copr.fedorainfracloud.org/coprs/build/3190932
+ ruby -rrubygems -Ilib:test:ext/gio2 test/run-test.rb glib-compile-resources ruby-gio2.gresource.xml cd resource glib-compile-schemas . cd - cd schema/default glib-compile-schemas . cd - cd schema/source cd - Loaded suite test Started ............../usr/share/gems/gems/gobject-introspection-3.4.9/lib/gobject-introspection/loader.rb:616: [BUG] Segmentation fault at 0x00000> ruby 3.1.0dev (2021-12-07 master ec878dac90) [x86_64-linux]
https://copr.fedorainfracloud.org/coprs/build/3190970
+ ruby -Ilib:test -rforwardable -e 'Dir.glob '\''./test/cases/*test.rb'\'', &method(:require)' /builddir/build/BUILD/globalid-0.4.2/usr/share/gems/gems/globalid-0.4.2/lib/global_id/uri/gid.rb:176:in `<module:URI>': uninitia> Did you mean? scheme_list from /builddir/build/BUILD/globalid-0.4.2/usr/share/gems/gems/globalid-0.4.2/lib/global_id/uri/gid.rb:6:in `<top (requir> from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /builddir/build/BUILD/globalid-0.4.2/usr/share/gems/gems/globalid-0.4.2/lib/global_id/global_id.rb:6:in `<top (requ> from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /builddir/build/BUILD/globalid-0.4.2/usr/share/gems/gems/globalid-0.4.2/lib/global_id.rb:1:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /builddir/build/BUILD/test/helper.rb:5:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /builddir/build/BUILD/globalid-0.4.2/usr/share/gems/gems/globalid-0.4.2/test/cases/global_id_test.rb:1:in `<top (re> from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from <internal:dir>:220:in `glob' from -e:1:in `<main>' error: Bad exit status from /var/tmp/rpm-tmp.bOvWxr (%check) Bad exit status from /var/tmp/rpm-tmp.bOvWxr (%check)
https://copr.fedorainfracloud.org/coprs/build/3190974
1) Error: MIME::Types::Loader#test_0001_loads YAML files correctly: Psych::DisallowedClass: Tried to load unspecified class: MIME::Type /usr/share/gems/gems/psych-4.0.2/lib/psych/class_loader.rb:99:in `find' /usr/share/gems/gems/psych-4.0.2/lib/psych/class_loader.rb:28:in `load' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:424:in `resolve_class' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:213:in `visit_Psych_Nodes_Mapping' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:30:in `visit' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:6:in `accept' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:35:in `accept' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:338:in `block in register_empty' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:338:in `each' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:338:in `register_empty' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:146:in `visit_Psych_Nodes_Sequence' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:30:in `visit' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:6:in `accept' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:35:in `accept' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:318:in `visit_Psych_Nodes_Document' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:30:in `visit' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:6:in `accept' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:35:in `accept' /usr/share/ruby/psych.rb:335:in `safe_load' /usr/share/ruby/psych.rb:370:in `load' /builddir/build/BUILD/rubygem-mime-types-3.3.1/usr/share/gems/gems/mime-types-3.3.1/lib/mime/types/loader.rb:113:in `load_fr> /builddir/build/BUILD/rubygem-mime-types-3.3.1/usr/share/gems/gems/mime-types-3.3.1/lib/mime/types/loader.rb:49:in `block in> /builddir/build/BUILD/rubygem-mime-types-3.3.1/usr/share/gems/gems/mime-types-3.3.1/lib/mime/types/loader.rb:48:in `each' /builddir/build/BUILD/rubygem-mime-types-3.3.1/usr/share/gems/gems/mime-types-3.3.1/lib/mime/types/loader.rb:48:in `load_yam> /builddir/build/BUILD/rubygem-mime-types-3.3.1/usr/share/gems/gems/mime-types-3.3.1/test/test_mime_types_loader.rb:26:in `bl>
https://copr.fedorainfracloud.org/coprs/build/3191613
Failures: 1) Mysql2::Result should raise a TypeError exception when it doesn't wrap a result set Failure/Error: r = Mysql2::Result.new TypeError: allocator undefined for Mysql2::Result # ./spec/mysql2/result_spec.rb:9:in `new' # ./spec/mysql2/result_spec.rb:9:in `block (2 levels) in <top (required)>'
https://copr.fedorainfracloud.org/coprs/build/3191628
--binPsych::DisallowedClass: Tried to load unspecified class: Rack::Lint::ErrorWrapper
https://copr.fedorainfracloud.org/coprs/build/3191833
1) Error: TestMBoxParsing#test_from_line_splitting: NoMethodError: undefined method `encode' for URI:Module uri = URI(prefix + URI.encode(@path, URI_ENCODE_CHARS)) ^^^^^^^ /builddir/build/BUILD/sup-1.0/lib/sup/mbox.rb:26:in `initialize' /builddir/build/BUILD/sup-1.0/test/test_header_parsing.rb:113:in `new' /builddir/build/BUILD/sup-1.0/test/test_header_parsing.rb:113:in `test_from_line_splitting'
https://copr.fedorainfracloud.org/coprs/build/3191877
+ ruby -I.:lib -e 'Dir.glob "test/**/*_test.rb", &method(:require)' <internal:timev>:310:in `initialize': no implicit conversion of Hash into Integer (TypeError) from /builddir/build/BUILD/timecop-0.9.2/usr/share/gems/gems/timecop-0.9.2/lib/timecop/time_extensions.rb:22:in `new' from /builddir/build/BUILD/timecop-0.9.2/usr/share/gems/gems/timecop-0.9.2/lib/timecop/time_extensions.rb:22:in `new_wit> from <internal:timev>:224:in `now' from /builddir/build/BUILD/timecop-0.9.2/usr/share/gems/gems/timecop-0.9.2/lib/timecop/time_extensions.rb:14:in `now_wit> from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent/utility/monotonic_time.rb:7:in `initialize' from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent/synchronization/object.rb:59:in `new' from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent/utility/monotonic_time.rb:42:in `<module:Concurrent>' from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent/utility/monotonic_time.rb:3:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent/executor/ruby_thread_pool_executor.rb:5:in `<top (require> from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent/executor/thread_pool_executor.rb:2:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent/executor/cached_thread_pool.rb:2:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent/configuration.rb:7:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent.rb:4:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /usr/share/gems/gems/activesupport-6.1.4.1/lib/active_support/logger_thread_safe_level.rb:5:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /usr/share/gems/gems/activesupport-6.1.4.1/lib/active_support/logger_silence.rb:5:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /usr/share/gems/gems/activesupport-6.1.4.1/lib/active_support/logger.rb:3:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /usr/share/gems/gems/activesupport-6.1.4.1/lib/active_support.rb:29:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /usr/share/gems/gems/activesupport-6.1.4.1/lib/active_support/all.rb:3:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:160:in `require' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:160:in `rescue in require' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:149:in `require' from /builddir/build/BUILD/timecop-0.9.2/usr/share/gems/gems/timecop-0.9.2/test/time_stack_item_test.rb:5:in `<top (requ> from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from <internal:dir>:220:in `glob' from -e:1:in `<main>' <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require': cannot load such file -- active_support/all > from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /builddir/build/BUILD/timecop-0.9.2/usr/share/gems/gems/timecop-0.9.2/test/time_stack_item_test.rb:5:in `<top (requ> from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from <internal:dir>:220:in `glob' from -e:1:in `<main>'
https://copr.fedorainfracloud.org/coprs/build/3191885
I'm also running some more rebuilds of the failures (I've fixed some dependencies now), and with newer Ruby 3.1.
Please ignore the Rails stuff, as I'm going to fix that separately with the upgrade to RoR 7.0.
Sorry for long email,
As a side note, I'd like to ask anyone interested to take a look at my pending PRs (hopefully they're up to date), in case it's something that would be nice-to-have in F36:
rubygem-diffy: https://bugzilla.redhat.com/show_bug.cgi?id=1867210 Update to diffy 3.4.0. https://src.fedoraproject.org/rpms/rubygem-diffy/pull-request/1
rubygem-docile: https://bugzilla.redhat.com/show_bug.cgi?id=1533680 Update to docile 1.3.2 https://src.fedoraproject.org/rpms/rubygem-docile/pull-request/1
rubygem-ffi: https://bugzilla.redhat.com/show_bug.cgi?id=2038923 Update to ffi 1.15.5. https://src.fedoraproject.org/rpms/rubygem-ffi/pull-request/6
rubygem-font-awesome-rails: https://bugzilla.redhat.com/show_bug.cgi?id=2034416 Update to font-awesome-rails 4.7.0.7. https://src.fedoraproject.org/rpms/rubygem-font-awesome-rails/pull-request/2
rubygem-httparty: https://bugzilla.redhat.com/show_bug.cgi?id=2002749 Update to httparty 0.20.0. https://src.fedoraproject.org/rpms/rubygem-httparty/pull-request/1
rubygem-i18n: https://bugzilla.redhat.com/show_bug.cgi?id=1923812 Update to i18n 1.8.10. https://src.fedoraproject.org/rpms/rubygem-i18n/pull-request/8
rubygem-launchy: https://bugzilla.redhat.com/show_bug.cgi?id=1808186 Update to launchy 2.5.0. https://src.fedoraproject.org/rpms/rubygem-launchy/pull-request/1
rubygem-listen: https://bugzilla.redhat.com/show_bug.cgi?id=2040523 Update to listen 3.7.1. https://src.fedoraproject.org/rpms/rubygem-listen/pull-request/10
rubygem-mimemagic: Update to mimemagic 0.4.3. https://src.fedoraproject.org/rpms/rubygem-mimemagic/pull-request/1
rubygem-mini_mime: Update to mini_mime 1.1.2. https://src.fedoraproject.org/rpms/rubygem-mini_mime/pull-request/2
rubygem-minitest-around: Update to minitest-around 0.5.0. https://src.fedoraproject.org/rpms/rubygem-minitest-around/pull-request/1
rubygem-minitest-reporters: https://bugzilla.redhat.com/show_bug.cgi?id=1765797 Update to minitest-reporters 1.4.3. https://src.fedoraproject.org/rpms/rubygem-minitest-reporters/pull-request/1
rubygem-msgpack: https://bugzilla.redhat.com/show_bug.cgi?id=1533462 Update to msgpack 1.3.3 https://src.fedoraproject.org/rpms/rubygem-msgpack/pull-request/1
rubygem-pathutil: https://bugzilla.redhat.com/show_bug.cgi?id=1504400 Update to pathutil 0.16.2. https://src.fedoraproject.org/rpms/rubygem-pathutil/pull-request/1
rubygem-pry-byebug: Update to pry-byebug 3.9.0. https://src.fedoraproject.org/rpms/rubygem-pry-byebug/pull-request/1
rubygem-rake-compiler: Update to rake-compiler 1.1.8. https://src.fedoraproject.org/rpms/rubygem-rake-compiler/pull-request/1
rubygem-redcarpet: https://bugzilla.redhat.com/show_bug.cgi?id=1266895 Update to redcarpet 3.5.1. https://src.fedoraproject.org/rpms/rubygem-redcarpet/pull-request/1
rubygem-rspec-pending_for: Update to rspec-pending_for 0.1.13. https://src.fedoraproject.org/rpms/rubygem-rspec-pending_for/pull-request/1
rubygem-selenium-webdriver: https://bugzilla.redhat.com/show_bug.cgi?id=2013663 Update to selenium-webdriver 4.1.0. https://src.fedoraproject.org/rpms/rubygem-selenium-webdriver/pull-request/2
rubygem-session: https://bugzilla.redhat.com/show_bug.cgi?id=1066943 Update to session 3.2.0 https://src.fedoraproject.org/rpms/rubygem-session/pull-request/1
rubygem-sexp_processor: https://bugzilla.redhat.com/show_bug.cgi?id=1874297 Update to sexp_processor 4.15.2. https://src.fedoraproject.org/rpms/rubygem-sexp_processor/pull-request/1
rubygem-spring: https://bugzilla.redhat.com/show_bug.cgi?id=2002484 Update to spring 3.1.1 https://src.fedoraproject.org/rpms/rubygem-spring/pull-request/1
rubygem-sprockets-rails: https://bugzilla.redhat.com/show_bug.cgi?id=2022436 Update to sprockets-rails 3.4.1. https://src.fedoraproject.org/rpms/rubygem-sprockets-rails/pull-request/3
rubygem-state_machine: https://bugzilla.redhat.com/show_bug.cgi?id=946894 Update to state_machine 1.2.0. https://src.fedoraproject.org/rpms/rubygem-state_machine/pull-request/1
rubygem-timecop: https://bugzilla.redhat.com/show_bug.cgi?id=1925958 Update to timecop 0.9.4. https://src.fedoraproject.org/rpms/rubygem-timecop/pull-request/3
rubygem-vcr: https://bugzilla.redhat.com/show_bug.cgi?id=1060075 Update to vcr 6.0.0. https://src.fedoraproject.org/rpms/rubygem-vcr/pull-request/1
I'm sorry, some of those might be WIP.
Pavel
HIH,
Pavel
Hm, I should probably really bump the Release of rubygem-json, otherwise we'll be in troubles. Previously, we were typically lucky that the independent package had lower NVR, this time, it wins.
comes to my mind and possibly rubygem-nokogiri?
And Nokogiri is RSpec dependency, that is the reason to prioritize it.
Vít
Vít
Dne 18. 01. 22 v 12:00 Pavel Valena napsal(a):
On Mon, Jan 17, 2022 at 4:27 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 17. 01. 22 v 16:15 Vít Ondruch napsal(a):
Hi,
It is time of the year when new version of Ruby was released upstream and we should land it in Fedora. Unfortunately, the change proposal was approved just last Thursday and on top of that, rebase of libffi broke Ruby (I am going to disable the failing test cases for the moment and hope for the best). So this brings us into situation, where won't have enough time prior Fedora Mass rebuild. I have discussed this a bit with relengs and one of the options would be to build Ruby early during the mass rebuild and fix the outfall later. I shared the proposal in the Fedora Mass rebuild ticket [2]. One downside would be that in case of problems, we could not trigger our contingency plan, which is "drop our side tag". But I hope we won't need that.
Any thoughts?
My fist concern is that maybe we should build more then just Ruby. rubygem-json
Hello,
I've run the rebuilds of previously failing packages in my COPR (probably with a little older Ruby 3.1 build), and here are the results:
https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/builds/ removed other buildroots, so failure marks rawhide buildroot.
From that what stands out:
cannot load such file -- net/smtp
several packages - e.g.: https://copr.fedorainfracloud.org/coprs/build/3190889
Not much we can do about it, since this was extracted into bundled gem. The correct fix is to report such issue to upstream. The workaround is to add `BR: rubygem-net-smpt`
In this specific case, it seems to be rubygem-mail issue. There is related report here:
https://github.com/mikel/mail/issues/1461
Do you have list of such packages? It all might be due to mail.
Tried to load unspecified class: BSON::Document # /usr/share/gems/gems/psych-4.0.2/lib/psych/class_loader.rb:99:in `find' # /usr/share/gems/gems/psych-4.0.2/lib/psych/class_loader.rb:28:in `load' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:424:in `resolve_class' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:288:in `visit_Psych_Nodes_Mapping' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:30:in `visit' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:6:in `accept' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:35:in `accept' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:318:in `visit_Psych_Nodes_Document' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:30:in `visit' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:6:in `accept' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:35:in `accept' # ./spec/bson/document_spec.rb:487:in `block (5 levels) in <top (required)>' # ./spec/bson/document_spec.rb:491:in `block (5 levels) in <top (required)>'
This very likely:
https://github.com/mongodb/bson-ruby/commit/652533da2dc7fbf011686678f434878b...
+ rspec -rspec_helper -fd --exclude-pattern 'spec/concurrent/{actor_spec.rb,channel_spec.rb,lazy_register_spec.rb,channel/**/*,e> <internal:timev>:310:in `initialize': no implicit conversion of Hash into Integer (TypeError) from /usr/share/gems/gems/timecop-0.9.2/lib/timecop/time_extensions.rb:22:in `new' from /usr/share/gems/gems/timecop-0.9.2/lib/timecop/time_extensions.rb:22:in `new_with_mock_time' from <internal:timev>:224:in `now' from /usr/share/gems/gems/rspec-core-3.10.1/lib/rspec/core/reporter.rb:89:in `start' from /usr/share/gems/gems/rspec-core-3.10.1/lib/rspec/core/reporter.rb:72:in `report' from /usr/share/gems/gems/rspec-core-3.10.1/lib/rspec/core/runner.rb:115:in `run_specs' from /usr/share/gems/gems/rspec-core-3.10.1/lib/rspec/core/runner.rb:89:in `run' from /usr/share/gems/gems/rspec-core-3.10.1/lib/rspec/core/runner.rb:71:in `run' from /usr/share/gems/gems/rspec-core-3.10.1/lib/rspec/core/runner.rb:45:in `invoke' from /usr/share/gems/gems/rspec-core-3.10.1/exe/rspec:4:in `<top (required)>' from /usr/bin/rspec:23:in `load' from /usr/bin/rspec:23:in `<main>' Run options: exclude {:stress=>true}
https://github.com/travisjeffery/timecop/pull/279
Or the linked issues.
+ ruby -rrubygems -Ilib:test:ext/gio2 test/run-test.rb glib-compile-resources ruby-gio2.gresource.xml cd resource glib-compile-schemas . cd - cd schema/default glib-compile-schemas . cd - cd schema/source cd - Loaded suite test Started ............../usr/share/gems/gems/gobject-introspection-3.4.9/lib/gobject-introspection/loader.rb:616: [BUG] Segmentation fault at 0x00000> ruby 3.1.0dev (2021-12-07 master ec878dac90) [x86_64-linux]
I hope this is not related to FFI, because gobject-introspection was mentioned in that context.
+ ruby -Ilib:test -rforwardable -e 'Dir.glob '\''./test/cases/*test.rb'\'', &method(:require)' /builddir/build/BUILD/globalid-0.4.2/usr/share/gems/gems/globalid-0.4.2/lib/global_id/uri/gid.rb:176:in `<module:URI>': uninitia> Did you mean? scheme_list from /builddir/build/BUILD/globalid-0.4.2/usr/share/gems/gems/globalid-0.4.2/lib/global_id/uri/gid.rb:6:in `<top (requir> from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /builddir/build/BUILD/globalid-0.4.2/usr/share/gems/gems/globalid-0.4.2/lib/global_id/global_id.rb:6:in `<top (requ> from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /builddir/build/BUILD/globalid-0.4.2/usr/share/gems/gems/globalid-0.4.2/lib/global_id.rb:1:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /builddir/build/BUILD/test/helper.rb:5:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /builddir/build/BUILD/globalid-0.4.2/usr/share/gems/gems/globalid-0.4.2/test/cases/global_id_test.rb:1:in `<top (re> from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from <internal:dir>:220:in `glob' from -e:1:in `<main>' error: Bad exit status from /var/tmp/rpm-tmp.bOvWxr (%check) Bad exit status from /var/tmp/rpm-tmp.bOvWxr (%check)
https://github.com/rails/globalid/pull/132
1) Error: MIME::Types::Loader#test_0001_loads YAML files correctly: Psych::DisallowedClass: Tried to load unspecified class: MIME::Type /usr/share/gems/gems/psych-4.0.2/lib/psych/class_loader.rb:99:in `find' /usr/share/gems/gems/psych-4.0.2/lib/psych/class_loader.rb:28:in `load' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:424:in `resolve_class' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:213:in `visit_Psych_Nodes_Mapping' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:30:in `visit' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:6:in `accept' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:35:in `accept' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:338:in `block in register_empty' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:338:in `each' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:338:in `register_empty' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:146:in `visit_Psych_Nodes_Sequence' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:30:in `visit' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:6:in `accept' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:35:in `accept' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:318:in `visit_Psych_Nodes_Document' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:30:in `visit' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:6:in `accept' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:35:in `accept' /usr/share/ruby/psych.rb:335:in `safe_load' /usr/share/ruby/psych.rb:370:in `load' /builddir/build/BUILD/rubygem-mime-types-3.3.1/usr/share/gems/gems/mime-types-3.3.1/lib/mime/types/loader.rb:113:in `load_fr> /builddir/build/BUILD/rubygem-mime-types-3.3.1/usr/share/gems/gems/mime-types-3.3.1/lib/mime/types/loader.rb:49:in `block in> /builddir/build/BUILD/rubygem-mime-types-3.3.1/usr/share/gems/gems/mime-types-3.3.1/lib/mime/types/loader.rb:48:in `each' /builddir/build/BUILD/rubygem-mime-types-3.3.1/usr/share/gems/gems/mime-types-3.3.1/lib/mime/types/loader.rb:48:in `load_yam> /builddir/build/BUILD/rubygem-mime-types-3.3.1/usr/share/gems/gems/mime-types-3.3.1/test/test_mime_types_loader.rb:26:in `bl>
This probably?
https://github.com/mime-types/ruby-mime-types/commit/6c8324d2396e7698296bbec...
But it includes quite a lot of unrelated changes.
Failures: 1) Mysql2::Result should raise a TypeError exception when it doesn't wrap a result set Failure/Error: r = Mysql2::Result.new TypeError: allocator undefined for Mysql2::Result # ./spec/mysql2/result_spec.rb:9:in `new' # ./spec/mysql2/result_spec.rb:9:in `block (2 levels) in <top (required)>'
https://github.com/brianmario/mysql2/commit/4dce466f3ff1c90099d3dc1bf610bfab...
But there is also
https://github.com/brianmario/mysql2/commit/23106c0af77e0e5bdd8e44e784fb77c3...
--binPsych::DisallowedClass: Tried to load unspecified class: Rack::Lint::ErrorWrapper
https://github.com/rack/rack/commit/ddfb0fde294905bd9c4858cfc1193a0698f253d9
1) Error: TestMBoxParsing#test_from_line_splitting: NoMethodError: undefined method `encode' for URI:Module uri = URI(prefix + URI.encode(@path, URI_ENCODE_CHARS)) ^^^^^^^ /builddir/build/BUILD/sup-1.0/lib/sup/mbox.rb:26:in `initialize' /builddir/build/BUILD/sup-1.0/test/test_header_parsing.rb:113:in `new' /builddir/build/BUILD/sup-1.0/test/test_header_parsing.rb:113:in `test_from_line_splitting'
This has been broken for a while already:
https://koschei.fedoraproject.org/package/rubygem-sup
+ ruby -I.:lib -e 'Dir.glob "test/**/*_test.rb", &method(:require)' <internal:timev>:310:in `initialize': no implicit conversion of Hash into Integer (TypeError) from /builddir/build/BUILD/timecop-0.9.2/usr/share/gems/gems/timecop-0.9.2/lib/timecop/time_extensions.rb:22:in `new' from /builddir/build/BUILD/timecop-0.9.2/usr/share/gems/gems/timecop-0.9.2/lib/timecop/time_extensions.rb:22:in `new_wit> from <internal:timev>:224:in `now' from /builddir/build/BUILD/timecop-0.9.2/usr/share/gems/gems/timecop-0.9.2/lib/timecop/time_extensions.rb:14:in `now_wit> from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent/utility/monotonic_time.rb:7:in `initialize' from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent/synchronization/object.rb:59:in `new' from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent/utility/monotonic_time.rb:42:in `<module:Concurrent>' from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent/utility/monotonic_time.rb:3:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent/executor/ruby_thread_pool_executor.rb:5:in `<top (require> from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent/executor/thread_pool_executor.rb:2:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent/executor/cached_thread_pool.rb:2:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent/configuration.rb:7:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent.rb:4:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /usr/share/gems/gems/activesupport-6.1.4.1/lib/active_support/logger_thread_safe_level.rb:5:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /usr/share/gems/gems/activesupport-6.1.4.1/lib/active_support/logger_silence.rb:5:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /usr/share/gems/gems/activesupport-6.1.4.1/lib/active_support/logger.rb:3:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /usr/share/gems/gems/activesupport-6.1.4.1/lib/active_support.rb:29:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /usr/share/gems/gems/activesupport-6.1.4.1/lib/active_support/all.rb:3:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:160:in `require' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:160:in `rescue in require' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:149:in `require' from /builddir/build/BUILD/timecop-0.9.2/usr/share/gems/gems/timecop-0.9.2/test/time_stack_item_test.rb:5:in `<top (requ> from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from <internal:dir>:220:in `glob' from -e:1:in `<main>' <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require': cannot load such file -- active_support/all > from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /builddir/build/BUILD/timecop-0.9.2/usr/share/gems/gems/timecop-0.9.2/test/time_stack_item_test.rb:5:in `<top (requ> from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from <internal:dir>:220:in `glob' from -e:1:in `<main>'
timecop again? Same as the concurrent-ruby above?
So probably no blocker, just some backports ....
Thx for looking into this issues.
Vít
I'm also running some more rebuilds of the failures (I've fixed some dependencies now), and with newer Ruby 3.1.
Please ignore the Rails stuff, as I'm going to fix that separately with the upgrade to RoR 7.0.
Sorry for long email, HIH,
Pavel
Hm, I should probably really bump the Release of rubygem-json, otherwise we'll be in troubles. Previously, we were typically lucky that the independent package had lower NVR, this time, it wins.
comes to my mind and possibly rubygem-nokogiri?
And Nokogiri is RSpec dependency, that is the reason to prioritize it.
Vít
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 on the list, report it: https://pagure.io/fedora-infrastructure
Dne 18. 01. 22 v 18:09 Vít Ondruch napsal(a):
Dne 18. 01. 22 v 12:00 Pavel Valena napsal(a): 3)
+ rspec -rspec_helper -fd --exclude-pattern 'spec/concurrent/{actor_spec.rb,channel_spec.rb,lazy_register_spec.rb,channel/**/*,e> <internal:timev>:310:in `initialize': no implicit conversion of Hash into Integer (TypeError) from /usr/share/gems/gems/timecop-0.9.2/lib/timecop/time_extensions.rb:22:in `new' from /usr/share/gems/gems/timecop-0.9.2/lib/timecop/time_extensions.rb:22:in `new_with_mock_time' from <internal:timev>:224:in `now' from /usr/share/gems/gems/rspec-core-3.10.1/lib/rspec/core/reporter.rb:89:in `start' from /usr/share/gems/gems/rspec-core-3.10.1/lib/rspec/core/reporter.rb:72:in `report' from /usr/share/gems/gems/rspec-core-3.10.1/lib/rspec/core/runner.rb:115:in `run_specs' from /usr/share/gems/gems/rspec-core-3.10.1/lib/rspec/core/runner.rb:89:in `run' from /usr/share/gems/gems/rspec-core-3.10.1/lib/rspec/core/runner.rb:71:in `run' from /usr/share/gems/gems/rspec-core-3.10.1/lib/rspec/core/runner.rb:45:in `invoke' from /usr/share/gems/gems/rspec-core-3.10.1/exe/rspec:4:in `<top (required)>' from /usr/bin/rspec:23:in `load' from /usr/bin/rspec:23:in `<main>' Run options: exclude {:stress=>true}
https://github.com/travisjeffery/timecop/pull/279
Or the linked issues.
Actually, there is already different fix in 0.9.4:
https://github.com/travisjeffery/timecop/pull/288
While the PR above is probably superior. Anyway, I have pushed update to 0.9.4 (including fix of test suite), so this should be resolved.
Vít
On Tue, Jan 18, 2022 at 6:39 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 18. 01. 22 v 12:00 Pavel Valena napsal(a):
On Mon, Jan 17, 2022 at 4:27 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 17. 01. 22 v 16:15 Vít Ondruch napsal(a):
Hi,
It is time of the year when new version of Ruby was released upstream and we should land it in Fedora. Unfortunately, the change proposal was approved just last Thursday and on top of that, rebase of libffi broke Ruby (I am going to disable the failing test cases for the moment and hope for the best). So this brings us into situation, where won't have enough time prior Fedora Mass rebuild. I have discussed this a bit with relengs and one of the options would be to build Ruby early during the mass rebuild and fix the outfall later. I shared the proposal in the Fedora Mass rebuild ticket [2]. One downside would be that in case of problems, we could not trigger our contingency plan, which is "drop our side tag". But I hope we won't need that.
Any thoughts?
My fist concern is that maybe we should build more then just Ruby. rubygem-json
Hello,
I've run the rebuilds of previously failing packages in my COPR (probably with a little older Ruby 3.1 build), and here are the results:
https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/builds/ removed other buildroots, so failure marks rawhide buildroot.
From that what stands out:
cannot load such file -- net/smtp
several packages - e.g.: https://copr.fedorainfracloud.org/coprs/build/3190889
The other two are rails -related:
rubygem-apipie-rails rubygem-actionmailbox rubygem-mail
Not much we can do about it, since this was extracted into bundled gem. The correct fix is to report such issue to upstream. The workaround is to add `BR: rubygem-net-smpt`
In this specific case, it seems to be rubygem-mail issue. There is related report here:
https://github.com/mikel/mail/issues/1461
Do you have list of such packages? It all might be due to mail.
Tried to load unspecified class: BSON::Document # /usr/share/gems/gems/psych-4.0.2/lib/psych/class_loader.rb:99:in `find' # /usr/share/gems/gems/psych-4.0.2/lib/psych/class_loader.rb:28:in `load' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:424:in `resolve_class' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:288:in `visit_Psych_Nodes_Mapping' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:30:in `visit' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:6:in `accept' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:35:in `accept' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:318:in `visit_Psych_Nodes_Document' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:30:in `visit' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:6:in `accept' # /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:35:in `accept' # ./spec/bson/document_spec.rb:487:in `block (5 levels) in <top (required)>' # ./spec/bson/document_spec.rb:491:in `block (5 levels) in <top (required)>'
This very likely:
https://github.com/mongodb/bson-ruby/commit/652533da2dc7fbf011686678f434878b...
+ rspec -rspec_helper -fd --exclude-pattern 'spec/concurrent/{actor_spec.rb,channel_spec.rb,lazy_register_spec.rb,channel/**/*,e> <internal:timev>:310:in `initialize': no implicit conversion of Hash into Integer (TypeError) from /usr/share/gems/gems/timecop-0.9.2/lib/timecop/time_extensions.rb:22:in `new' from /usr/share/gems/gems/timecop-0.9.2/lib/timecop/time_extensions.rb:22:in `new_with_mock_time' from <internal:timev>:224:in `now' from /usr/share/gems/gems/rspec-core-3.10.1/lib/rspec/core/reporter.rb:89:in `start' from /usr/share/gems/gems/rspec-core-3.10.1/lib/rspec/core/reporter.rb:72:in `report' from /usr/share/gems/gems/rspec-core-3.10.1/lib/rspec/core/runner.rb:115:in `run_specs' from /usr/share/gems/gems/rspec-core-3.10.1/lib/rspec/core/runner.rb:89:in `run' from /usr/share/gems/gems/rspec-core-3.10.1/lib/rspec/core/runner.rb:71:in `run' from /usr/share/gems/gems/rspec-core-3.10.1/lib/rspec/core/runner.rb:45:in `invoke' from /usr/share/gems/gems/rspec-core-3.10.1/exe/rspec:4:in `<top (required)>' from /usr/bin/rspec:23:in `load' from /usr/bin/rspec:23:in `<main>' Run options: exclude {:stress=>true}
https://github.com/travisjeffery/timecop/pull/279
Or the linked issues.
+ ruby -rrubygems -Ilib:test:ext/gio2 test/run-test.rb glib-compile-resources ruby-gio2.gresource.xml cd resource glib-compile-schemas . cd - cd schema/default glib-compile-schemas . cd - cd schema/source cd - Loaded suite test Started ............../usr/share/gems/gems/gobject-introspection-3.4.9/lib/gobject-introspection/loader.rb:616: [BUG] Segmentation fault at 0x00000> ruby 3.1.0dev (2021-12-07 master ec878dac90) [x86_64-linux]
I hope this is not related to FFI, because gobject-introspection was mentioned in that context.
I was not able to rebuilt dependent packages due to this, so the
+ ruby -Ilib:test -rforwardable -e 'Dir.glob '\''./test/cases/*test.rb'\'', &method(:require)' /builddir/build/BUILD/globalid-0.4.2/usr/share/gems/gems/globalid-0.4.2/lib/global_id/uri/gid.rb:176:in `<module:URI>': uninitia> Did you mean? scheme_list from /builddir/build/BUILD/globalid-0.4.2/usr/share/gems/gems/globalid-0.4.2/lib/global_id/uri/gid.rb:6:in `<top (requir> from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /builddir/build/BUILD/globalid-0.4.2/usr/share/gems/gems/globalid-0.4.2/lib/global_id/global_id.rb:6:in `<top (requ> from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /builddir/build/BUILD/globalid-0.4.2/usr/share/gems/gems/globalid-0.4.2/lib/global_id.rb:1:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /builddir/build/BUILD/test/helper.rb:5:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /builddir/build/BUILD/globalid-0.4.2/usr/share/gems/gems/globalid-0.4.2/test/cases/global_id_test.rb:1:in `<top (re> from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from <internal:dir>:220:in `glob' from -e:1:in `<main>' error: Bad exit status from /var/tmp/rpm-tmp.bOvWxr (%check) Bad exit status from /var/tmp/rpm-tmp.bOvWxr (%check)
https://github.com/rails/globalid/pull/132
1) Error: MIME::Types::Loader#test_0001_loads YAML files correctly: Psych::DisallowedClass: Tried to load unspecified class: MIME::Type /usr/share/gems/gems/psych-4.0.2/lib/psych/class_loader.rb:99:in `find' /usr/share/gems/gems/psych-4.0.2/lib/psych/class_loader.rb:28:in `load' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:424:in `resolve_class' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:213:in `visit_Psych_Nodes_Mapping' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:30:in `visit' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:6:in `accept' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:35:in `accept' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:338:in `block in register_empty' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:338:in `each' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:338:in `register_empty' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:146:in `visit_Psych_Nodes_Sequence' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:30:in `visit' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:6:in `accept' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:35:in `accept' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:318:in `visit_Psych_Nodes_Document' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:30:in `visit' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/visitor.rb:6:in `accept' /usr/share/gems/gems/psych-4.0.2/lib/psych/visitors/to_ruby.rb:35:in `accept' /usr/share/ruby/psych.rb:335:in `safe_load' /usr/share/ruby/psych.rb:370:in `load' /builddir/build/BUILD/rubygem-mime-types-3.3.1/usr/share/gems/gems/mime-types-3.3.1/lib/mime/types/loader.rb:113:in `load_fr> /builddir/build/BUILD/rubygem-mime-types-3.3.1/usr/share/gems/gems/mime-types-3.3.1/lib/mime/types/loader.rb:49:in `block in> /builddir/build/BUILD/rubygem-mime-types-3.3.1/usr/share/gems/gems/mime-types-3.3.1/lib/mime/types/loader.rb:48:in `each' /builddir/build/BUILD/rubygem-mime-types-3.3.1/usr/share/gems/gems/mime-types-3.3.1/lib/mime/types/loader.rb:48:in `load_yam> /builddir/build/BUILD/rubygem-mime-types-3.3.1/usr/share/gems/gems/mime-types-3.3.1/test/test_mime_types_loader.rb:26:in `bl>
This probably?
https://github.com/mime-types/ruby-mime-types/commit/6c8324d2396e7698296bbec...
But it includes quite a lot of unrelated changes.
Failures: 1) Mysql2::Result should raise a TypeError exception when it doesn't wrap a result set Failure/Error: r = Mysql2::Result.new TypeError: allocator undefined for Mysql2::Result # ./spec/mysql2/result_spec.rb:9:in `new' # ./spec/mysql2/result_spec.rb:9:in `block (2 levels) in <top (required)>'
https://github.com/brianmario/mysql2/commit/4dce466f3ff1c90099d3dc1bf610bfab...
But there is also
https://github.com/brianmario/mysql2/commit/23106c0af77e0e5bdd8e44e784fb77c3...
--binPsych::DisallowedClass: Tried to load unspecified class: Rack::Lint::ErrorWrapper
https://github.com/rack/rack/commit/ddfb0fde294905bd9c4858cfc1193a0698f253d9
1) Error: TestMBoxParsing#test_from_line_splitting: NoMethodError: undefined method `encode' for URI:Module uri = URI(prefix + URI.encode(@path, URI_ENCODE_CHARS)) ^^^^^^^ /builddir/build/BUILD/sup-1.0/lib/sup/mbox.rb:26:in `initialize' /builddir/build/BUILD/sup-1.0/test/test_header_parsing.rb:113:in `new' /builddir/build/BUILD/sup-1.0/test/test_header_parsing.rb:113:in `test_from_line_splitting'
This has been broken for a while already:
https://koschei.fedoraproject.org/package/rubygem-sup
+ ruby -I.:lib -e 'Dir.glob "test/**/*_test.rb", &method(:require)' <internal:timev>:310:in `initialize': no implicit conversion of Hash into Integer (TypeError) from /builddir/build/BUILD/timecop-0.9.2/usr/share/gems/gems/timecop-0.9.2/lib/timecop/time_extensions.rb:22:in `new' from /builddir/build/BUILD/timecop-0.9.2/usr/share/gems/gems/timecop-0.9.2/lib/timecop/time_extensions.rb:22:in `new_wit> from <internal:timev>:224:in `now' from /builddir/build/BUILD/timecop-0.9.2/usr/share/gems/gems/timecop-0.9.2/lib/timecop/time_extensions.rb:14:in `now_wit> from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent/utility/monotonic_time.rb:7:in `initialize' from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent/synchronization/object.rb:59:in `new' from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent/utility/monotonic_time.rb:42:in `<module:Concurrent>' from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent/utility/monotonic_time.rb:3:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent/executor/ruby_thread_pool_executor.rb:5:in `<top (require> from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent/executor/thread_pool_executor.rb:2:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent/executor/cached_thread_pool.rb:2:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent/configuration.rb:7:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /usr/share/gems/gems/concurrent-ruby-1.1.5/lib/concurrent.rb:4:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /usr/share/gems/gems/activesupport-6.1.4.1/lib/active_support/logger_thread_safe_level.rb:5:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /usr/share/gems/gems/activesupport-6.1.4.1/lib/active_support/logger_silence.rb:5:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /usr/share/gems/gems/activesupport-6.1.4.1/lib/active_support/logger.rb:3:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /usr/share/gems/gems/activesupport-6.1.4.1/lib/active_support.rb:29:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /usr/share/gems/gems/activesupport-6.1.4.1/lib/active_support/all.rb:3:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:160:in `require' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:160:in `rescue in require' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:149:in `require' from /builddir/build/BUILD/timecop-0.9.2/usr/share/gems/gems/timecop-0.9.2/test/time_stack_item_test.rb:5:in `<top (requ> from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from <internal:dir>:220:in `glob' from -e:1:in `<main>' <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require': cannot load such file -- active_support/all > from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /builddir/build/BUILD/timecop-0.9.2/usr/share/gems/gems/timecop-0.9.2/test/time_stack_item_test.rb:5:in `<top (requ> from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from <internal:dir>:220:in `glob' from -e:1:in `<main>'
timecop again? Same as the concurrent-ruby above?
So probably no blocker, just some backports ....
Agreed. I was checking the build errors randomly from time to time, so we could hopefully catch those right away :). I won't have time to fix those failures in the near future though.
What worries me is that I can't rebuild your Ruby PR, still. Do you have any newer scratch build?
Thx for looking into this issues.
YAW,
Pavel
Vít
I'm also running some more rebuilds of the failures (I've fixed some dependencies now), and with newer Ruby 3.1.
Please ignore the Rails stuff, as I'm going to fix that separately with the upgrade to RoR 7.0.
Sorry for long email, HIH,
Pavel
Hm, I should probably really bump the Release of rubygem-json, otherwise we'll be in troubles. Previously, we were typically lucky that the independent package had lower NVR, this time, it wins.
comes to my mind and possibly rubygem-nokogiri?
And Nokogiri is RSpec dependency, that is the reason to prioritize it.
Vít
Vít
Dne 19. 01. 22 v 9:08 Pavel Valena napsal(a):
On Tue, Jan 18, 2022 at 6:39 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 18. 01. 22 v 12:00 Pavel Valena napsal(a):
On Mon, Jan 17, 2022 at 4:27 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 17. 01. 22 v 16:15 Vít Ondruch napsal(a):
Hi,
It is time of the year when new version of Ruby was released upstream and we should land it in Fedora. Unfortunately, the change proposal was approved just last Thursday and on top of that, rebase of libffi broke Ruby (I am going to disable the failing test cases for the moment and hope for the best). So this brings us into situation, where won't have enough time prior Fedora Mass rebuild. I have discussed this a bit with relengs and one of the options would be to build Ruby early during the mass rebuild and fix the outfall later. I shared the proposal in the Fedora Mass rebuild ticket [2]. One downside would be that in case of problems, we could not trigger our contingency plan, which is "drop our side tag". But I hope we won't need that.
Any thoughts?
My fist concern is that maybe we should build more then just Ruby. rubygem-json
Hello,
I've run the rebuilds of previously failing packages in my COPR (probably with a little older Ruby 3.1 build), and here are the results:
https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/builds/ removed other buildroots, so failure marks rawhide buildroot.
From that what stands out:
cannot load such file -- net/smtp
several packages - e.g.: https://copr.fedorainfracloud.org/coprs/build/3190889
The other two are rails -related:
rubygem-apipie-rails rubygem-actionmailbox rubygem-mail
Thx.
+ ruby -rrubygems -Ilib:test:ext/gio2 test/run-test.rb glib-compile-resources ruby-gio2.gresource.xml cd resource glib-compile-schemas . cd - cd schema/default glib-compile-schemas . cd - cd schema/source cd - Loaded suite test Started ............../usr/share/gems/gems/gobject-introspection-3.4.9/lib/gobject-introspection/loader.rb:616: [BUG] Segmentation fault at 0x00000> ruby 3.1.0dev (2021-12-07 master ec878dac90) [x86_64-linux]
I hope this is not related to FFI, because gobject-introspection was mentioned in that context.
I was not able to rebuilt dependent packages due to this, so the
Could you please finish your thoughts? :)
@Mamoru PTAL, I think that Pavel wanted to say that this is precondition to build other GTK stuff.
So probably no blocker, just some backports ....
Agreed. I was checking the build errors randomly from time to time, so we could hopefully catch those right away :). I won't have time to fix those failures in the near future though.
What worries me is that I can't rebuild your Ruby PR, still. Do you have any newer scratch build?
Yes, I sent a link in other subthread:
https://koji.fedoraproject.org/koji/taskinfo?taskID=81413346
In my repo, there is missing this change:
~~~
$ git show 4f6a504c2e9980688763e2164ad0a12c8fdcb9b7 commit 4f6a504c2e9980688763e2164ad0a12c8fdcb9b7 Author: Vít Ondruch vondruch@redhat.com Date: Mon Jan 17 17:34:57 2022 +0100
Disable some Fiddle test by libffi-3.4.2.
diff --git a/ruby.spec b/ruby.spec index bed0ad0..145791c 100644 --- a/ruby.spec +++ b/ruby.spec @@ -921,6 +921,11 @@ DISABLE_TESTS="$DISABLE_TESTS -n !/TestAddressResolve#test_socket_getnameinfo_do DISABLE_TESTS="$DISABLE_TESTS -n !/TestReadline#test_interrupt_in_other_thread/" %endif
+# Several test broken by libffi-3.4.2. There should be fix in libffi, once +# other components are fixed. +# https://bugzilla.redhat.com/show_bug.cgi?id=2040380 +mv test/fiddle/test_import.rb{,.disable} + # Give an option to increase the timeout in tests. # https://bugs.ruby-lang.org/issues/16921 %{?test_timeout_scale:RUBY_TEST_TIMEOUT_SCALE="%{test_timeout_scale}"} \
~~~
I still have not decided where to push this. Maybe I should push this even to Rawhide, because otherwise the mass rebuild is going to fail. I have hoped that this could be already resolved, but it is not :/
Vít
On Wed, Jan 19, 2022 at 11:55 AM Vít Ondruch vondruch@redhat.com wrote:
Dne 19. 01. 22 v 9:08 Pavel Valena napsal(a):
On Tue, Jan 18, 2022 at 6:39 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 18. 01. 22 v 12:00 Pavel Valena napsal(a):
On Mon, Jan 17, 2022 at 4:27 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 17. 01. 22 v 16:15 Vít Ondruch napsal(a):
Hi,
It is time of the year when new version of Ruby was released upstream and we should land it in Fedora. Unfortunately, the change proposal was approved just last Thursday and on top of that, rebase of libffi broke Ruby (I am going to disable the failing test cases for the moment and hope for the best). So this brings us into situation, where won't have enough time prior Fedora Mass rebuild. I have discussed this a bit with relengs and one of the options would be to build Ruby early during the mass rebuild and fix the outfall later. I shared the proposal in the Fedora Mass rebuild ticket [2]. One downside would be that in case of problems, we could not trigger our contingency plan, which is "drop our side tag". But I hope we won't need that.
Any thoughts?
My fist concern is that maybe we should build more then just Ruby. rubygem-json
Hello,
I've run the rebuilds of previously failing packages in my COPR (probably with a little older Ruby 3.1 build), and here are the results:
https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/builds/ removed other buildroots, so failure marks rawhide buildroot.
From that what stands out:
cannot load such file -- net/smtp
several packages - e.g.: https://copr.fedorainfracloud.org/coprs/build/3190889
The other two are rails -related:
rubygem-apipie-rails rubygem-actionmailbox rubygem-mail
Thx.
+ ruby -rrubygems -Ilib:test:ext/gio2 test/run-test.rb glib-compile-resources ruby-gio2.gresource.xml cd resource glib-compile-schemas . cd - cd schema/default glib-compile-schemas . cd - cd schema/source cd - Loaded suite test Started ............../usr/share/gems/gems/gobject-introspection-3.4.9/lib/gobject-introspection/loader.rb:616: [BUG] Segmentation fault at 0x00000> ruby 3.1.0dev (2021-12-07 master ec878dac90) [x86_64-linux]
I hope this is not related to FFI, because gobject-introspection was mentioned in that context.
I was not able to rebuilt dependent packages due to this, so the
Could you please finish your thoughts? :)
Sorry, I thought I wrote it and just hit send when the meeting started :).
Intended message was: Some packages were not tested, as the dependencies were broken... I've only managed to build Puma (5.2.2, in PR) on N-th try, with some tests disabled, same as gobject-introspection; their dependent packages are not tested. Same for some rails-dependent packages.
@Mamoru PTAL, I think that Pavel wanted to say that this is precondition to build other GTK stuff.
Correct.
So probably no blocker, just some backports ....
Agreed. I was checking the build errors randomly from time to time, so we could hopefully catch those right away :). I won't have time to fix those failures in the near future though.
What worries me is that I can't rebuild your Ruby PR, still. Do you have any newer scratch build?
Yes, I sent a link in other subthread:
https://koji.fedoraproject.org/koji/taskinfo?taskID=81413346
(I didn't unpack SRPM for changes just this-one-time :) and I hit a missing commit... =myluck=)
In my repo, there is missing this change:
$ git show 4f6a504c2e9980688763e2164ad0a12c8fdcb9b7 commit 4f6a504c2e9980688763e2164ad0a12c8fdcb9b7 Author: Vít Ondruch <vondruch@redhat.com> Date: Mon Jan 17 17:34:57 2022 +0100 Disable some Fiddle test by libffi-3.4.2. diff --git a/ruby.spec b/ruby.spec index bed0ad0..145791c 100644 --- a/ruby.spec +++ b/ruby.spec @@ -921,6 +921,11 @@ DISABLE_TESTS="$DISABLE_TESTS -n !/TestAddressResolve#test_socket_getnameinfo_do DISABLE_TESTS="$DISABLE_TESTS -n !/TestReadline#test_interrupt_in_other_thread/" %endif +# Several test broken by libffi-3.4.2. There should be fix in libffi, once +# other components are fixed. +# https://bugzilla.redhat.com/show_bug.cgi?id=2040380 +mv test/fiddle/test_import.rb{,.disable} + # Give an option to increase the timeout in tests. # https://bugs.ruby-lang.org/issues/16921 %{?test_timeout_scale:RUBY_TEST_TIMEOUT_SCALE="%{test_timeout_scale}"} \
I still have not decided where to push this. Maybe I should push this even to Rawhide, because otherwise the mass rebuild is going to fail. I have hoped that this could be already resolved, but it is not :/
Well, +1 for disabling the test. I'd rather have Ruby build.
Pavel
Vít
Dne 19. 01. 22 v 13:08 Pavel Valena napsal(a):
On Wed, Jan 19, 2022 at 11:55 AM Vít Ondruch vondruch@redhat.com wrote:
In my repo, there is missing this change:
$ git show 4f6a504c2e9980688763e2164ad0a12c8fdcb9b7 commit 4f6a504c2e9980688763e2164ad0a12c8fdcb9b7 Author: Vít Ondruch <vondruch@redhat.com> Date: Mon Jan 17 17:34:57 2022 +0100 Disable some Fiddle test by libffi-3.4.2. diff --git a/ruby.spec b/ruby.spec index bed0ad0..145791c 100644 --- a/ruby.spec +++ b/ruby.spec @@ -921,6 +921,11 @@ DISABLE_TESTS="$DISABLE_TESTS -n !/TestAddressResolve#test_socket_getnameinfo_do DISABLE_TESTS="$DISABLE_TESTS -n !/TestReadline#test_interrupt_in_other_thread/" %endif +# Several test broken by libffi-3.4.2. There should be fix in libffi, once +# other components are fixed. +# https://bugzilla.redhat.com/show_bug.cgi?id=2040380 +mv test/fiddle/test_import.rb{,.disable} + # Give an option to increase the timeout in tests. # https://bugs.ruby-lang.org/issues/16921 %{?test_timeout_scale:RUBY_TEST_TIMEOUT_SCALE="%{test_timeout_scale}"} \
I still have not decided where to push this. Maybe I should push this even to Rawhide, because otherwise the mass rebuild is going to fail. I have hoped that this could be already resolved, but it is not :/
Well, +1 for disabling the test. I'd rather have Ruby build.
Changes pushed and build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=81461258
If nothing else, we should have build against the new FFI ready (although scratch build strangely failed on s390x).
BTW I have pushed all changes for Ruby 3.1.to my fork:
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/commits/rawhide
Vít
Dne 19. 01. 22 v 19:19 Vít Ondruch napsal(a):
Dne 19. 01. 22 v 13:08 Pavel Valena napsal(a):
On Wed, Jan 19, 2022 at 11:55 AM Vít Ondruch vondruch@redhat.com wrote:
In my repo, there is missing this change:
$ git show 4f6a504c2e9980688763e2164ad0a12c8fdcb9b7 commit 4f6a504c2e9980688763e2164ad0a12c8fdcb9b7 Author: Vít Ondruch <vondruch@redhat.com> Date: Mon Jan 17 17:34:57 2022 +0100 Disable some Fiddle test by libffi-3.4.2. diff --git a/ruby.spec b/ruby.spec index bed0ad0..145791c 100644 --- a/ruby.spec +++ b/ruby.spec @@ -921,6 +921,11 @@ DISABLE_TESTS="$DISABLE_TESTS -n !/TestAddressResolve#test_socket_getnameinfo_do DISABLE_TESTS="$DISABLE_TESTS -n !/TestReadline#test_interrupt_in_other_thread/" %endif +# Several test broken by libffi-3.4.2. There should be fix in libffi, once +# other components are fixed. +# https://bugzilla.redhat.com/show_bug.cgi?id=2040380 +mv test/fiddle/test_import.rb{,.disable} + # Give an option to increase the timeout in tests. # https://bugs.ruby-lang.org/issues/16921 %{?test_timeout_scale:RUBY_TEST_TIMEOUT_SCALE="%{test_timeout_scale}"} \
I still have not decided where to push this. Maybe I should push this even to Rawhide, because otherwise the mass rebuild is going to fail. I have hoped that this could be already resolved, but it is not :/
Well, +1 for disabling the test. I'd rather have Ruby build.
Changes pushed and build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=81461258
If nothing else, we should have build against the new FFI ready (although scratch build strangely failed on s390x).
That was naive. The s390x issue real and it seems to be related to GCC 12. However, since Ruby 3.1.0 builds just fine, it seems that backporting patch [1] should do the job. Scratch build passed, now the official build (fingers crossed):
https://koji.fedoraproject.org/koji/taskinfo?taskID=81517915
Vít
Dne 20. 01. 22 v 12:41 Vít Ondruch napsal(a):
Dne 19. 01. 22 v 19:19 Vít Ondruch napsal(a):
Dne 19. 01. 22 v 13:08 Pavel Valena napsal(a):
On Wed, Jan 19, 2022 at 11:55 AM Vít Ondruch vondruch@redhat.com wrote:
In my repo, there is missing this change:
$ git show 4f6a504c2e9980688763e2164ad0a12c8fdcb9b7 commit 4f6a504c2e9980688763e2164ad0a12c8fdcb9b7 Author: Vít Ondruch <vondruch@redhat.com> Date: Mon Jan 17 17:34:57 2022 +0100 Disable some Fiddle test by libffi-3.4.2. diff --git a/ruby.spec b/ruby.spec index bed0ad0..145791c 100644 --- a/ruby.spec +++ b/ruby.spec @@ -921,6 +921,11 @@ DISABLE_TESTS="$DISABLE_TESTS -n !/TestAddressResolve#test_socket_getnameinfo_do DISABLE_TESTS="$DISABLE_TESTS -n !/TestReadline#test_interrupt_in_other_thread/" %endif +# Several test broken by libffi-3.4.2. There should be fix in libffi, once +# other components are fixed. +# https://bugzilla.redhat.com/show_bug.cgi?id=2040380 +mv test/fiddle/test_import.rb{,.disable} + # Give an option to increase the timeout in tests. # https://bugs.ruby-lang.org/issues/16921 %{?test_timeout_scale:RUBY_TEST_TIMEOUT_SCALE="%{test_timeout_scale}"} \
I still have not decided where to push this. Maybe I should push this even to Rawhide, because otherwise the mass rebuild is going to fail. I have hoped that this could be already resolved, but it is not :/
Well, +1 for disabling the test. I'd rather have Ruby build.
Changes pushed and build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=81461258
If nothing else, we should have build against the new FFI ready (although scratch build strangely failed on s390x).
That was naive. The s390x issue real and it seems to be related to GCC 12. However, since Ruby 3.1.0 builds just fine, it seems that backporting patch [1] should do the job. Scratch build passed, now the official build (fingers crossed):
https://koji.fedoraproject.org/koji/taskinfo?taskID=81517915
Oh no, this build is going to break every rubygem- with binary extension :facepalm:
https://bugzilla.redhat.com/show_bug.cgi?id=2043092
Vít
Dne 20. 01. 22 v 16:53 Vít Ondruch napsal(a):
Dne 20. 01. 22 v 12:41 Vít Ondruch napsal(a):
Dne 19. 01. 22 v 19:19 Vít Ondruch napsal(a):
Dne 19. 01. 22 v 13:08 Pavel Valena napsal(a):
On Wed, Jan 19, 2022 at 11:55 AM Vít Ondruch vondruch@redhat.com wrote:
In my repo, there is missing this change:
$ git show 4f6a504c2e9980688763e2164ad0a12c8fdcb9b7 commit 4f6a504c2e9980688763e2164ad0a12c8fdcb9b7 Author: Vít Ondruch <vondruch@redhat.com> Date: Mon Jan 17 17:34:57 2022 +0100 Disable some Fiddle test by libffi-3.4.2. diff --git a/ruby.spec b/ruby.spec index bed0ad0..145791c 100644 --- a/ruby.spec +++ b/ruby.spec @@ -921,6 +921,11 @@ DISABLE_TESTS="$DISABLE_TESTS -n !/TestAddressResolve#test_socket_getnameinfo_do DISABLE_TESTS="$DISABLE_TESTS -n !/TestReadline#test_interrupt_in_other_thread/" %endif +# Several test broken by libffi-3.4.2. There should be fix in libffi, once +# other components are fixed. +# https://bugzilla.redhat.com/show_bug.cgi?id=2040380 +mv test/fiddle/test_import.rb{,.disable} + # Give an option to increase the timeout in tests. # https://bugs.ruby-lang.org/issues/16921 %{?test_timeout_scale:RUBY_TEST_TIMEOUT_SCALE="%{test_timeout_scale}"} \
I still have not decided where to push this. Maybe I should push this even to Rawhide, because otherwise the mass rebuild is going to fail. I have hoped that this could be already resolved, but it is not :/
Well, +1 for disabling the test. I'd rather have Ruby build.
Changes pushed and build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=81461258
If nothing else, we should have build against the new FFI ready (although scratch build strangely failed on s390x).
That was naive. The s390x issue real and it seems to be related to GCC 12. However, since Ruby 3.1.0 builds just fine, it seems that backporting patch [1] should do the job. Scratch build passed, now the official build (fingers crossed):
https://koji.fedoraproject.org/koji/taskinfo?taskID=81517915
Oh no, this build is going to break every rubygem- with binary extension :facepalm:
Workaround:
https://src.fedoraproject.org/rpms/ruby/c/a0bcb33eaa666d3e1d08ca45e77161ca05...
and build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=81534724
Third external breakage in less than two weeks. I hope there won't be any more.
Vít
Vít Ondruch wrote on 2022/01/19 19:54:
Dne 19. 01. 22 v 9:08 Pavel Valena napsal(a):
On Tue, Jan 18, 2022 at 6:39 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 18. 01. 22 v 12:00 Pavel Valena napsal(a):
On Mon, Jan 17, 2022 at 4:27 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 17. 01. 22 v 16:15 Vít Ondruch napsal(a):
Hi,
+ ruby -rrubygems -Ilib:test:ext/gio2 test/run-test.rb glib-compile-resources ruby-gio2.gresource.xml cd resource glib-compile-schemas . cd - cd schema/default glib-compile-schemas . cd - cd schema/source cd - Loaded suite test Started ............../usr/share/gems/gems/gobject-introspection-3.4.9/lib/gobject-introspection/loader.rb:616: [BUG] Segmentation fault at 0x00000> ruby 3.1.0dev (2021-12-07 master ec878dac90) [x86_64-linux]
I hope this is not related to FFI, because gobject-introspection was mentioned in that context.
I was not able to rebuilt dependent packages due to this, so the
Could you please finish your thoughts? :)
@Mamoru PTAL, I think that Pavel wanted to say that this is precondition to build other GTK stuff.
ruby-gnome 3.5.1 "suite" is already released, which will (perhaps) fix this issue as the upstream tests 3.5.1 with ruby31 on github ci, however as ruby-gnome (on Fedora) has ~20 gems, I just suspend updating ruby-gnome gems until ruby31 rebuild actually starts.
Regards, Mamoru
Mamoru TASAKA wrote on 2022/01/19 22:27:
Vít Ondruch wrote on 2022/01/19 19:54:
Dne 19. 01. 22 v 9:08 Pavel Valena napsal(a):
On Tue, Jan 18, 2022 at 6:39 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 18. 01. 22 v 12:00 Pavel Valena napsal(a):
On Mon, Jan 17, 2022 at 4:27 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 17. 01. 22 v 16:15 Vít Ondruch napsal(a): > Hi, >
+ ruby -rrubygems -Ilib:test:ext/gio2 test/run-test.rb glib-compile-resources ruby-gio2.gresource.xml cd resource glib-compile-schemas . cd - cd schema/default glib-compile-schemas . cd - cd schema/source cd - Loaded suite test Started ............../usr/share/gems/gems/gobject-introspection-3.4.9/lib/gobject-introspection/loader.rb:616: [BUG] Segmentation fault at 0x00000> ruby 3.1.0dev (2021-12-07 master ec878dac90) [x86_64-linux]
I hope this is not related to FFI, because gobject-introspection was mentioned in that context.
I was not able to rebuilt dependent packages due to this, so the
Could you please finish your thoughts? :)
@Mamoru PTAL, I think that Pavel wanted to say that this is precondition to build other GTK stuff.
ruby-gnome 3.5.1 "suite" is already released, which will (perhaps) fix this issue as the upstream tests 3.5.1 with ruby31 on github ci, however as ruby-gnome (on Fedora) has ~20 gems, I just suspend updating ruby-gnome gems until ruby31 rebuild actually starts.
Just note that now I am preparing ruby-gnome 3.5.1 suite for ruby3.1: https://copr.fedorainfracloud.org/coprs/mtasaka/ruby310-test/builds/
Regards, Mamoru
Vít Ondruch wrote on 2022/01/18 0:15:
Hi,
It is time of the year when new version of Ruby was released upstream and we should land it in Fedora. Unfortunately, the change proposal was approved just last Thursday and on top of that, rebase of libffi broke Ruby (I am going to disable the failing test cases for the moment and hope for the best). So this brings us into situation, where won't have enough time prior Fedora Mass rebuild. I have discussed this a bit with relengs and one of the options would be to build Ruby early during the mass rebuild and fix the outfall later. I shared the proposal in the Fedora Mass rebuild ticket [2]. One downside would be that in case of problems, we could not trigger our contingency plan, which is "drop our side tag". But I hope we won't need that.
Any thoughts?
My fist concern is that maybe we should build more then just Ruby. rubygem-json comes to my mind and possibly rubygem-nokogiri?
Vít
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2040380 [2] https://pagure.io/releng/issue/10538#comment-775197
My light idea is that as "Change Checkpoint" and "Branch Fedora Linux 36 from Rawhide" happends on 2022/Feb/08 (Tue), I think we have enough time even if we start rebuilding with ruby31 beginning at, say, 2022/Jan/24 (Mon) or Jan/25 (if mass rebuild "really" begins tomorrow).
Regards, Mamoru
Dne 18. 01. 22 v 8:44 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/01/18 0:15:
Hi,
It is time of the year when new version of Ruby was released upstream and we should land it in Fedora. Unfortunately, the change proposal was approved just last Thursday and on top of that, rebase of libffi broke Ruby (I am going to disable the failing test cases for the moment and hope for the best). So this brings us into situation, where won't have enough time prior Fedora Mass rebuild. I have discussed this a bit with relengs and one of the options would be to build Ruby early during the mass rebuild and fix the outfall later. I shared the proposal in the Fedora Mass rebuild ticket [2]. One downside would be that in case of problems, we could not trigger our contingency plan, which is "drop our side tag". But I hope we won't need that.
Any thoughts?
My fist concern is that maybe we should build more then just Ruby. rubygem-json comes to my mind and possibly rubygem-nokogiri?
Vít
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2040380 [2] https://pagure.io/releng/issue/10538#comment-775197
My light idea is that as "Change Checkpoint" and "Branch Fedora Linux 36 from Rawhide" happends on 2022/Feb/08 (Tue),
Please note that this also marks end of mass rebuild phase.
I think we have enough time even if we start rebuilding with ruby31 beginning at, say, 2022/Jan/24 (Mon) or Jan/25
Right, I agree.
(if mass rebuild "really" begins tomorrow).
Yeah, this worries me, because I think that there used to be delays for past several occasions.
BTW Is your preference based on your availability or is that just considering the schedule and processes or what not?
Thx
Vít
Regards, Mamoru
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 on the list, report it: https://pagure.io/fedora-infrastructure
Vít Ondruch wrote on 2022/01/18 17:15:
Dne 18. 01. 22 v 8:44 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/01/18 0:15:
Hi,
It is time of the year when new version of Ruby was released upstream and we should land it in Fedora. Unfortunately, the change proposal was approved just last Thursday and on top of that, rebase of libffi broke Ruby (I am going to disable the failing test cases for the moment and hope for the best). So this brings us into situation, where won't have enough time prior Fedora Mass rebuild. I have discussed this a bit with relengs and one of the options would be to build Ruby early during the mass rebuild and fix the outfall later. I shared the proposal in the Fedora Mass rebuild ticket [2]. One downside would be that in case of problems, we could not trigger our contingency plan, which is "drop our side tag". But I hope we won't need that.
Any thoughts?
My fist concern is that maybe we should build more then just Ruby. rubygem-json comes to my mind and possibly rubygem-nokogiri?
Vít
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2040380 [2] https://pagure.io/releng/issue/10538#comment-775197
My light idea is that as "Change Checkpoint" and "Branch Fedora Linux 36 from Rawhide" happends on 2022/Feb/08 (Tue),
Please note that this also marks end of mass rebuild phase.
I think we have enough time even if we start rebuilding with ruby31 beginning at, say, 2022/Jan/24 (Mon) or Jan/25
Right, I agree.
(if mass rebuild "really" begins tomorrow).
Yeah, this worries me, because I think that there used to be delays for past several occasions.
Or, once we can determine we wait rebuild until 2022/Jan/24 (Mon) or so on, and if mass rebuild doesn't go well by that day, we will force ruby rebuild anyway, for example.
One note: At least side-tag build can be done (queued) from the branch other than rawhide/main, (by specifying --release explicitly, like $ fedpkg --release f36 build --target f36-build-side-XXXXXX )
So you can - push ruby 3.1 change to ruby.git other than rawhide branch (say ruby31-temp branch) - create side-tag for ruby rebuild, build ruby3.1 on that side-tag from ruby.git ruby31-temp branch - At this time, mass rebuild can happen, but mass rebuild will happen using rawhide/main branch, so mass rebuild will be done using ruby3.0 - If that happen, merge rawhide and ruby31-temp (anyway), rebuild again on ruby31 side-tag - Then later, push bodhi to merge side-tag builds into rawhide
BTW Is your preference based on your availability or is that just considering the schedule and processes or what not?
Well, for my availability, although I cannot spare full time on ruby work (as I have my "daily" work), currently I have no worry for this and I can do rebuild of ruby related srpms at my own pace for the time being. So I am just considering the schedule for now.
Thx Vít
Regards, Mamoru
Dne 18. 01. 22 v 9:57 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/01/18 17:15:
Dne 18. 01. 22 v 8:44 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/01/18 0:15:
Hi,
It is time of the year when new version of Ruby was released upstream and we should land it in Fedora. Unfortunately, the change proposal was approved just last Thursday and on top of that, rebase of libffi broke Ruby (I am going to disable the failing test cases for the moment and hope for the best). So this brings us into situation, where won't have enough time prior Fedora Mass rebuild. I have discussed this a bit with relengs and one of the options would be to build Ruby early during the mass rebuild and fix the outfall later. I shared the proposal in the Fedora Mass rebuild ticket [2]. One downside would be that in case of problems, we could not trigger our contingency plan, which is "drop our side tag". But I hope we won't need that.
Any thoughts?
My fist concern is that maybe we should build more then just Ruby. rubygem-json comes to my mind and possibly rubygem-nokogiri?
Vít
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2040380 [2] https://pagure.io/releng/issue/10538#comment-775197
My light idea is that as "Change Checkpoint" and "Branch Fedora Linux 36 from Rawhide" happends on 2022/Feb/08 (Tue),
Please note that this also marks end of mass rebuild phase.
I think we have enough time even if we start rebuilding with ruby31 beginning at, say, 2022/Jan/24 (Mon) or Jan/25
Right, I agree.
(if mass rebuild "really" begins tomorrow).
Yeah, this worries me, because I think that there used to be delays for past several occasions.
Or, once we can determine we wait rebuild until 2022/Jan/24 (Mon) or so on, and if mass rebuild doesn't go well by that day, we will force ruby rebuild anyway, for example.
The agreement with relengs is that we will follow the Fedora mass rebuild:
https://meetbot-raw.fedoraproject.org/fedora-meeting-3/2022-01-18/releng.202...
Vít
One note: At least side-tag build can be done (queued) from the branch other than rawhide/main, (by specifying --release explicitly, like $ fedpkg --release f36 build --target f36-build-side-XXXXXX )
So you can
- push ruby 3.1 change to ruby.git other than rawhide branch (say
ruby31-temp branch)
- create side-tag for ruby rebuild, build ruby3.1 on that side-tag
from ruby.git ruby31-temp branch
- At this time, mass rebuild can happen, but mass rebuild will happen
using rawhide/main branch, so mass rebuild will be done using ruby3.0
- If that happen, merge rawhide and ruby31-temp (anyway), rebuild
again on ruby31 side-tag
- Then later, push bodhi to merge side-tag builds into rawhide
BTW Is your preference based on your availability or is that just considering the schedule and processes or what not?
Well, for my availability, although I cannot spare full time on ruby work (as I have my "daily" work), currently I have no worry for this and I can do rebuild of ruby related srpms at my own pace for the time being. So I am just considering the schedule for now.
Thx Vít
Regards, Mamoru _______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
So Fedora mass rebuild has finished (although I am not sure how does it look with the signing of the packages), therefore we should be good to go. I have requested side tag:
~~~
$ fedpkg request-side-tag Side tag 'f36-build-side-49941' (id 49941) created. Use 'fedpkg build --target=f36-build-side-49941' to use it. Use 'koji wait-repo f36-build-side-49941' to wait for the build repo to be generated.
~~~
and Ruby 3.1 is already built there as you can see at:
https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=49941&o...
or using:
~~~ $ koji list-tagged f36-build-side-49941 ~~~
Now this is a list of packages, which very likely needs rebuild:
~~~ $ dnf repoquery --disablerepo=* --enablerepo=rawhide --enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' | sort | uniq ~~~
You can take the package and just fire rebuild, but please ensure that you are using f36-build-side-49941 build target, i.e. the build command should look like:
~~~ $ fedpkg build --target f36-build-side-49941 ~~~
Please be careful, because if you, by a chance, omit the f36-build-side-49941 target, you'll be building against Ruby 3.0 which is not what you want.
If you won't do it by yourself, I'll be rebuilding all packages after I am finished with my packages. I'll be using fermig [1] to help me with that. If you don't want me to touch your packages for whatever reason, please let me know.
As always, any help/testing/feedback is welcome.
Vít
On Wed, Jan 26, 2022 at 2:00 PM Vít Ondruch vondruch@redhat.com wrote:
So Fedora mass rebuild has finished (although I am not sure how does it look with the signing of the packages), therefore we should be good to go. I have requested side tag:
$ fedpkg request-side-tag Side tag 'f36-build-side-49941' (id 49941) created. Use 'fedpkg build --target=f36-build-side-49941' to use it. Use 'koji wait-repo f36-build-side-49941' to wait for the build repo to be generated.
and Ruby 3.1 is already built there as you can see at:
https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=49941&o...
or using:
$ koji list-tagged f36-build-side-49941
Now this is a list of packages, which very likely needs rebuild:
$ dnf repoquery --disablerepo=* --enablerepo=rawhide --enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' | sort | uniq
You can take the package and just fire rebuild, but please ensure that you are using f36-build-side-49941 build target, i.e. the build command should look like:
$ fedpkg build --target f36-build-side-49941
Please be careful, because if you, by a chance, omit the f36-build-side-49941 target, you'll be building against Ruby 3.0 which is not what you want.
If you won't do it by yourself, I'll be rebuilding all packages after I am finished with my packages. I'll be using fermig [1] to help me with that. If you don't want me to touch your packages for whatever reason, please let me know.
As always, any help/testing/feedback is welcome.
Hellom
I've started my mass rebuild script[1] which will build all the packages in the ruby-packagers-sig [2] and also which I own [3]. The scratch build, along with other checks[*] is done prior to that, of course.
Here [4] is the list of currently targeted packages, with dependency on `libruby.so.3.0()`. Please let me know if you want me to skip some packages.
[*] Previous git entries are checked for changelog entries I've encountered in previous years (see script above). The builds will retry on failure, as well as the scratch-builds will retry in another pass (in case there are dependency loops). Example builds[5][6].
[1] https://gist.github.com/154a9f1863cfdadae46c7d7ead359613 [2] https://github.com/pvalena/theprototype/blob/main/fedora/list_group_packages... [3] https://github.com/pvalena/theprototype/blob/main/fedora/list_owned_packages... [4] https://gist.github.com/pvalena/f48bce8c0e54b6222d51ecafdc421654 [5] https://koji.fedoraproject.org/koji/taskinfo?taskID=81946328 [6] https://koji.fedoraproject.org/koji/taskinfo?taskID=81946627
Regards, Pavel
Vít
Pavel Valena wrote on 2022/01/27 1:12:
I've started my mass rebuild script[1] which will build all the packages in the ruby-packagers-sig [2] and also which I own [3]. The scratch build, along with other checks[*] is done prior to that, of course.
Here [4] is the list of currently targeted packages, with dependency on `libruby.so.3.0()`. Please let me know if you want me to skip some packages.
Really? At least rubygem-ZenTest is noarch. And directly executing $ dnf repoquery --whatrequires "libruby.so.3.0()(64bit)" does not show such packages. Would you recheck your script?
Currently:
$ dnf repoquery --quiet --repo=koji-f36-build-side-49941 --qf '%{sourcerpm}' --whatrequires "libruby.so.3.0()(64bit)" | cat -n 1 clearsilver-0.10.5-66.fc36.src.rpm 2 dislocker-0.7.3-6.fc36.src.rpm 3 graphviz-2.50.0-3.fc36.src.rpm 4 hivex-1.3.21-4.fc36.src.rpm 5 hyperestraier-1.4.13-45.fc35.src.rpm 6 kf5-kross-interpreters-21.12.1-2.fc36.src.rpm 7 libcaca-0.99-0.57.beta20.fc36.src.rpm 8 libguestfs-1.47.2-2.fc36.src.rpm 9 libprelude-5.2.0-10.fc36.src.rpm 10 libsbml-5.19.0-10.fc36.src.rpm 11 libselinux-3.3-3.fc36.src.rpm 12 libyui-bindings-2.0.2-7.fc36.src.rpm 13 mapserver-7.6.4-9.fc36.src.rpm 14 marisa-0.2.4-53.fc36.src.rpm 15 mlt-6.26.1-5.fc36.src.rpm 16 nbdkit-1.29.14-1.fc36.src.rpm 17 notmuch-0.34.3-2.fc36.src.rpm 18 openbabel-3.1.1-5.fc36.src.rpm 19 openwsman-2.7.1-2.fc36.src.rpm 20 pcs-0.10.11-2.fc36.src.rpm 21 player-3.1.0-37.fc36.src.rpm 22 qdbm-1.8.78-48.fc36.src.rpm 23 qpid-proton-0.36.0-2.fc36.src.rpm 24 remctl-3.17-5.fc36.src.rpm 25 rrdtool-1.7.2-22.fc36.src.rpm 26 ruby-augeas-0.5.0-29.fc36.src.rpm 27 ruby-gnome2-0.90.4-9.fc36.8.src.rpm 28 ruby-mecab-0.996-6.fc36.20.src.rpm 29 ruby-ncurses-1.3.1-38.fc36.src.rpm 30 rubygem-atomic-1.1.101-10.fc35.src.rpm 31 rubygem-bootsnap-1.4.7-5.fc36.src.rpm 32 rubygem-bson-4.10.0-5.fc36.src.rpm 33 rubygem-byebug-11.1.3-3.fc36.2.src.rpm 34 rubygem-ffi-1.15.5-1.fc36.src.rpm 35 rubygem-glu-8.3.0-19.fc36.src.rpm 36 rubygem-glut-8.3.0-18.fc36.src.rpm 37 rubygem-goocanvas1-1.2.6-29.fc36.src.rpm 38 rubygem-gtk2-3.4.3-5.fc36.src.rpm 39 rubygem-gtksourceview2-3.4.3-5.fc36.src.rpm 40 rubygem-hiredis-0.6.3-9.fc35.src.rpm 41 rubygem-http_parser.rb-0.6.0-22.fc35.src.rpm 42 rubygem-krb5-auth-0.8.3-16.gita86ddf2.fc36.src.rpm 43 rubygem-msgpack-1.1.0-17.fc36.src.rpm 44 rubygem-mysql2-0.5.3-9.fc36.src.rpm 45 rubygem-narray-0.6.1.1-22.fc35.src.rpm 46 rubygem-ncursesw-1.4.10-6.fc36.src.rpm 47 rubygem-nokogiri-1.13.1-1.fc36.1.src.rpm 48 rubygem-opengl-0.10.0-18.fc36.src.rpm 49 rubygem-ox-2.14.4-3.fc36.src.rpm 50 rubygem-pg-1.2.3-6.fc35.src.rpm 51 rubygem-posix-spawn-0.3.15-5.fc36.src.rpm 52 rubygem-puma-5.5.2-1.fc36.src.rpm 53 rubygem-rdiscount-2.2.0.2-5.fc36.src.rpm 54 rubygem-redcarpet-3.3.2-20.fc35.src.rpm 55 rubygem-regexp_property_values-1.0.0-5.fc36.src.rpm 56 rubygem-ruby-libvirt-0.7.1-13.fc35.src.rpm 57 rubygem-ruby-shadow-2.5.0-17.fc36.src.rpm 58 rubygem-vte-3.4.3-5.fc36.src.rpm 59 rubygem-websocket-driver-0.7.5-3.fc36.src.rpm 60 simspark-0.3.2-4.fc36.src.rpm 61 skf-2.10.14-4.fc36.2.src.rpm 62 subversion-1.14.1-9.fc36.src.rpm 63 vim-command-t-5.0.3-3.fc36.src.rpm 64 weechat-3.4-4.fc36.src.rpm 65 xmms2-0.8-79.fc36.src.rpm
[*] Previous git entries are checked for changelog entries I've encountered in previous years (see script above). The builds will retry on failure, as well as the scratch-builds will retry in another pass (in case there are dependency loops). Example builds[5][6].
[1] https://gist.github.com/154a9f1863cfdadae46c7d7ead359613 [2] https://github.com/pvalena/theprototype/blob/main/fedora/list_group_packages... [3] https://github.com/pvalena/theprototype/blob/main/fedora/list_owned_packages... [4] https://gist.github.com/pvalena/f48bce8c0e54b6222d51ecafdc421654 [5] https://koji.fedoraproject.org/koji/taskinfo?taskID=81946328 [6] https://koji.fedoraproject.org/koji/taskinfo?taskID=81946627
Regards, Pavel
Mamoru
On Wed, Jan 26, 2022 at 5:25 PM Mamoru TASAKA mtasaka@fedoraproject.org wrote:
Pavel Valena wrote on 2022/01/27 1:12:
I've started my mass rebuild script[1] which will build all the packages in the ruby-packagers-sig [2] and also which I own [3]. The scratch build, along with other checks[*] is done prior to that, of course.
Here [4] is the list of currently targeted packages, with dependency on `libruby.so.3.0()`. Please let me know if you want me to skip some packages.
Really? At least rubygem-ZenTest is noarch. And directly executing $ dnf repoquery --whatrequires "libruby.so.3.0()(64bit)" does not show such packages. Would you recheck your script?
Currently:
$ dnf repoquery --quiet --repo=koji-f36-build-side-49941 --qf '%{sourcerpm}' --whatrequires "libruby.so.3.0()(64bit)" | cat -n 1 clearsilver-0.10.5-66.fc36.src.rpm 2 dislocker-0.7.3-6.fc36.src.rpm 3 graphviz-2.50.0-3.fc36.src.rpm 4 hivex-1.3.21-4.fc36.src.rpm 5 hyperestraier-1.4.13-45.fc35.src.rpm 6 kf5-kross-interpreters-21.12.1-2.fc36.src.rpm 7 libcaca-0.99-0.57.beta20.fc36.src.rpm 8 libguestfs-1.47.2-2.fc36.src.rpm 9 libprelude-5.2.0-10.fc36.src.rpm 10 libsbml-5.19.0-10.fc36.src.rpm 11 libselinux-3.3-3.fc36.src.rpm 12 libyui-bindings-2.0.2-7.fc36.src.rpm 13 mapserver-7.6.4-9.fc36.src.rpm 14 marisa-0.2.4-53.fc36.src.rpm 15 mlt-6.26.1-5.fc36.src.rpm 16 nbdkit-1.29.14-1.fc36.src.rpm 17 notmuch-0.34.3-2.fc36.src.rpm 18 openbabel-3.1.1-5.fc36.src.rpm 19 openwsman-2.7.1-2.fc36.src.rpm 20 pcs-0.10.11-2.fc36.src.rpm 21 player-3.1.0-37.fc36.src.rpm 22 qdbm-1.8.78-48.fc36.src.rpm 23 qpid-proton-0.36.0-2.fc36.src.rpm 24 remctl-3.17-5.fc36.src.rpm 25 rrdtool-1.7.2-22.fc36.src.rpm 26 ruby-augeas-0.5.0-29.fc36.src.rpm 27 ruby-gnome2-0.90.4-9.fc36.8.src.rpm 28 ruby-mecab-0.996-6.fc36.20.src.rpm 29 ruby-ncurses-1.3.1-38.fc36.src.rpm 30 rubygem-atomic-1.1.101-10.fc35.src.rpm 31 rubygem-bootsnap-1.4.7-5.fc36.src.rpm 32 rubygem-bson-4.10.0-5.fc36.src.rpm 33 rubygem-byebug-11.1.3-3.fc36.2.src.rpm 34 rubygem-ffi-1.15.5-1.fc36.src.rpm 35 rubygem-glu-8.3.0-19.fc36.src.rpm 36 rubygem-glut-8.3.0-18.fc36.src.rpm 37 rubygem-goocanvas1-1.2.6-29.fc36.src.rpm 38 rubygem-gtk2-3.4.3-5.fc36.src.rpm 39 rubygem-gtksourceview2-3.4.3-5.fc36.src.rpm 40 rubygem-hiredis-0.6.3-9.fc35.src.rpm 41 rubygem-http_parser.rb-0.6.0-22.fc35.src.rpm 42 rubygem-krb5-auth-0.8.3-16.gita86ddf2.fc36.src.rpm 43 rubygem-msgpack-1.1.0-17.fc36.src.rpm 44 rubygem-mysql2-0.5.3-9.fc36.src.rpm 45 rubygem-narray-0.6.1.1-22.fc35.src.rpm 46 rubygem-ncursesw-1.4.10-6.fc36.src.rpm 47 rubygem-nokogiri-1.13.1-1.fc36.1.src.rpm 48 rubygem-opengl-0.10.0-18.fc36.src.rpm 49 rubygem-ox-2.14.4-3.fc36.src.rpm 50 rubygem-pg-1.2.3-6.fc35.src.rpm 51 rubygem-posix-spawn-0.3.15-5.fc36.src.rpm 52 rubygem-puma-5.5.2-1.fc36.src.rpm 53 rubygem-rdiscount-2.2.0.2-5.fc36.src.rpm 54 rubygem-redcarpet-3.3.2-20.fc35.src.rpm 55 rubygem-regexp_property_values-1.0.0-5.fc36.src.rpm 56 rubygem-ruby-libvirt-0.7.1-13.fc35.src.rpm 57 rubygem-ruby-shadow-2.5.0-17.fc36.src.rpm 58 rubygem-vte-3.4.3-5.fc36.src.rpm 59 rubygem-websocket-driver-0.7.5-3.fc36.src.rpm 60 simspark-0.3.2-4.fc36.src.rpm 61 skf-2.10.14-4.fc36.2.src.rpm 62 subversion-1.14.1-9.fc36.src.rpm 63 vim-command-t-5.0.3-3.fc36.src.rpm 64 weechat-3.4-4.fc36.src.rpm 65 xmms2-0.8-79.fc36.src.rpm
Yes, you're right, I've spotted it right after sending as well. I'm not sure what happened. I've fixed the script now. Updating the links I've sent.
Thanks, Pavel
[*] Previous git entries are checked for changelog entries I've encountered in previous years (see script above). The builds will retry on failure, as well as the scratch-builds will retry in another pass (in case there are dependency loops). Example builds[5][6].
[1] https://gist.github.com/154a9f1863cfdadae46c7d7ead359613 [2] https://github.com/pvalena/theprototype/blob/main/fedora/list_group_packages... [3] https://github.com/pvalena/theprototype/blob/main/fedora/list_owned_packages... [4] https://gist.github.com/pvalena/f48bce8c0e54b6222d51ecafdc421654 [5] https://koji.fedoraproject.org/koji/taskinfo?taskID=81946328 [6] https://koji.fedoraproject.org/koji/taskinfo?taskID=81946627
Regards, Pavel
Mamoru _______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Vít Ondruch wrote on 2022/01/26 21:59:
So Fedora mass rebuild has finished (although I am not sure how does it look with the signing of the packages), therefore we should be good to go. I have requested side tag:
$ fedpkg request-side-tag Side tag 'f36-build-side-49941' (id 49941) created. Use 'fedpkg build --target=f36-build-side-49941' to use it. Use 'koji wait-repo f36-build-side-49941' to wait for the build repo to be generated.
and Ruby 3.1 is already built there as you can see at: https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=49941&o... or using:
$ koji list-tagged f36-build-side-49941
Now this is a list of packages, which very likely needs rebuild:
$ dnf repoquery --disablerepo=* --enablerepo=rawhide --enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' | sort | uniq
You can take the package and just fire rebuild, but please ensure that you are using f36-build-side-49941 build target, i.e. the build command should look like:
$ fedpkg build --target f36-build-side-49941
Please be careful, because if you, by a chance, omit the f36-build-side-49941 target, you'll be building against Ruby 3.0 which is not what you want.
If you won't do it by yourself, I'll be rebuilding all packages after I am finished with my packages. I'll be using fermig [1] to help me with that. If you don't want me to touch your packages for whatever reason, please let me know.
As always, any help/testing/feedback is welcome.
Vít
Now I am going to bed.. Just note that due to package-notes injecting some flags to %build_ldflags , now executing %gem_install on %prep (instead of %build) section containing C extension will fail because
- creating package_notes is done at the begininning of %build - %buildsubdir is not defined at %prep (so package_notes file name is wrong at %prep)
so for most cases now we have to move %gem_install to %build (from %prep)
Regards, Mamoru
Vít Ondruch wrote on 2022/01/26 21:59:
So Fedora mass rebuild has finished (although I am not sure how does it look with the signing of the packages), therefore we should be good to go. I have requested side tag:
$ fedpkg request-side-tag Side tag 'f36-build-side-49941' (id 49941) created. Use 'fedpkg build --target=f36-build-side-49941' to use it. Use 'koji wait-repo f36-build-side-49941' to wait for the build repo to be generated.
and Ruby 3.1 is already built there as you can see at: https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=49941&o... or using:
$ koji list-tagged f36-build-side-49941
Now this is a list of packages, which very likely needs rebuild:
$ dnf repoquery --disablerepo=* --enablerepo=rawhide --enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' | sort | uniq
You can take the package and just fire rebuild, but please ensure that you are using f36-build-side-49941 build target, i.e. the build command should look like:
$ fedpkg build --target f36-build-side-49941
Please be careful, because if you, by a chance, omit the f36-build-side-49941 target, you'll be building against Ruby 3.0 which is not what you want.
If you won't do it by yourself, I'll be rebuilding all packages after I am finished with my packages. I'll be using fermig [1] to help me with that. If you don't want me to touch your packages for whatever reason, please let me know.
As always, any help/testing/feedback is welcome.
Current status $ dnf repoquery --quiet --repo=koji-f36-build-side-49941 --qf '%{sourcerpm}' --whatrequires "libruby.so.3.0()(64bit)" | cat -n 1 libguestfs-1.47.2-2.fc36.src.rpm https://koji.fedoraproject.org/koji/taskinfo?taskID=81990276 On x86_64, %check fails with kernel oops. On ppc64le there is unsatisfied BuildRequires dependency.
2 mlt-6.26.1-5.fc36.src.rpm even $ fedpkg sources fails, for now I don't want to proceed further..
3 nbdkit-1.29.14-1.fc36.src.rpm https://koji.fedoraproject.org/koji/taskinfo?taskID=81983055 Looked at x86_64 failure, %configure is failing with some questionable reason, reported against gcc for now: https://bugzilla.redhat.com/show_bug.cgi?id=2046640
4 openbabel-3.1.1-5.fc36.src.rpm https://koji.fedoraproject.org/koji/taskinfo?taskID=81981066 Even build for rawhide fails, but mass rebuild was successful. During mass rebuild and now, cmake is updated and build failure seems related to cmake update.
5 pcs-0.10.11-2.fc36.src.rpm https://koji.fedoraproject.org/koji/taskinfo?taskID=81980259 BuildRequires rubygem-ffi
6 qpid-proton-0.36.0-2.fc36.src.rpm https://koji.fedoraproject.org/koji/taskinfo?taskID=81978394 Maybe same issue as nbdkit
7 rubygem-ffi-1.15.5-1.fc36.src.rpm https://koji.fedoraproject.org/koji/taskinfo?taskID=81980984 %check stage fails with SIGABRT. Even build for rawhide now fails.
I would apprecite it if someone looks at what is happening here. This affects lots of packages - rubygem-cucumber indirectly depends on this, for example
8 rubygem-hiredis-0.6.3-9.fc35.src.rpm https://koji.fedoraproject.org/koji/taskinfo?taskID=81994532 hiredis is updated from 0.13.3 to 1.0.2, and there seems some API change.
9 rubygem-pg-1.2.3-6.fc35.src.rpm https://koji.fedoraproject.org/koji/taskinfo?taskID=81994559 Not looked at this in detail yet
10 rubygem-websocket-driver-0.7.5-3.fc36.src.rpm https://koji.fedoraproject.org/koji/taskinfo?taskID=81945124 %check fails with something looking like some minor output change.
Regards, Mamoru
Mamoru,
First of all, thx a lot for all the rebuilds!
Dne 27. 01. 22 v 11:14 Mamoru TASAKA napsal(a):
Current status
2 mlt-6.26.1-5.fc36.src.rpm even $ fedpkg sources fails, for now I don't want to proceed further..
This seems to be half finished update to mlt-7.4, without uploaded sources. I have already discussed status of this repo with relengs (pending their investigation), because I suspect it was also silently missed by mass rebuild (however, the FTBFS bugs are not reported yet ....)
7 rubygem-ffi-1.15.5-1.fc36.src.rpm https://koji.fedoraproject.org/koji/taskinfo?taskID=81980984 %check stage fails with SIGABRT. Even build for rawhide now fails.
I would apprecite it if someone looks at what is happening here. This affects lots of packages - rubygem-cucumber indirectly depends on this, for example
Yes, this is a bummer. I suspect this is the same issue as the Fiddle failures:
https://src.fedoraproject.org/rpms/ruby/c/b6d9b2acd19c1f6f98468e667ec9f5b829...
If I am correct, I think we should disable the failing test case and hope that the apps using FFI are not using fork ATM.
Vít
Dne 27. 01. 22 v 11:50 Vít Ondruch napsal(a):
Dne 27. 01. 22 v 11:14 Mamoru TASAKA napsal(a):
7 rubygem-ffi-1.15.5-1.fc36.src.rpm https://koji.fedoraproject.org/koji/taskinfo?taskID=81980984 %check stage fails with SIGABRT. Even build for rawhide now fails.
I would apprecite it if someone looks at what is happening here. This affects lots of packages - rubygem-cucumber indirectly depends on this, for example
Yes, this is a bummer. I suspect this is the same issue as the Fiddle failures:
https://src.fedoraproject.org/rpms/ruby/c/b6d9b2acd19c1f6f98468e667ec9f5b829...
If I am correct, I think we should disable the failing test case and hope that the apps using FFI are not using fork ATM.
I have pushed workaround here:
https://src.fedoraproject.org/rpms/rubygem-ffi/c/19f6fee2f1f21ffd437018849a9...
And the build is running:
https://koji.fedoraproject.org/koji/taskinfo?taskID=82006114
Vít
Vít Ondruch wrote on 2022/01/27 21:37:
Dne 27. 01. 22 v 11:50 Vít Ondruch napsal(a):
Dne 27. 01. 22 v 11:14 Mamoru TASAKA napsal(a):
7 rubygem-ffi-1.15.5-1.fc36.src.rpm https://koji.fedoraproject.org/koji/taskinfo?taskID=81980984 %check stage fails with SIGABRT. Even build for rawhide now fails.
I would apprecite it if someone looks at what is happening here. This affects lots of packages - rubygem-cucumber indirectly depends on this, for example
Yes, this is a bummer. I suspect this is the same issue as the Fiddle failures:
https://src.fedoraproject.org/rpms/ruby/c/b6d9b2acd19c1f6f98468e667ec9f5b829...
If I am correct, I think we should disable the failing test case and hope that the apps using FFI are not using fork ATM.
I have pushed workaround here: https://src.fedoraproject.org/rpms/rubygem-ffi/c/19f6fee2f1f21ffd437018849a9...
And the build is running:
https://koji.fedoraproject.org/koji/taskinfo?taskID=82006114
Looks like this is built for rawhide (f36).
Vít
Mamoru
Dne 27. 01. 22 v 13:50 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/01/27 21:37:
Dne 27. 01. 22 v 11:50 Vít Ondruch napsal(a):
Dne 27. 01. 22 v 11:14 Mamoru TASAKA napsal(a):
7 rubygem-ffi-1.15.5-1.fc36.src.rpm https://koji.fedoraproject.org/koji/taskinfo?taskID=81980984 %check stage fails with SIGABRT. Even build for rawhide now fails.
I would apprecite it if someone looks at what is happening here. This affects lots of packages - rubygem-cucumber indirectly depends on this, for example
Yes, this is a bummer. I suspect this is the same issue as the Fiddle failures:
https://src.fedoraproject.org/rpms/ruby/c/b6d9b2acd19c1f6f98468e667ec9f5b829...
If I am correct, I think we should disable the failing test case and hope that the apps using FFI are not using fork ATM.
I have pushed workaround here: https://src.fedoraproject.org/rpms/rubygem-ffi/c/19f6fee2f1f21ffd437018849a9...
And the build is running:
https://koji.fedoraproject.org/koji/taskinfo?taskID=82006114
Looks like this is built for rawhide (f36).
Ouch 😬 thx for spotting this. Luckily it won't hurt anything except my ego 😁 Here should be the right one:
https://koji.fedoraproject.org/koji/taskinfo?taskID=82007038
Vít
Vít Ondruch wrote on 2022/01/27 22:05:
Dne 27. 01. 22 v 13:50 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/01/27 21:37:
Dne 27. 01. 22 v 11:50 Vít Ondruch napsal(a):
Dne 27. 01. 22 v 11:14 Mamoru TASAKA napsal(a):
7 rubygem-ffi-1.15.5-1.fc36.src.rpm https://koji.fedoraproject.org/koji/taskinfo?taskID=81980984 %check stage fails with SIGABRT. Even build for rawhide now fails.
I would apprecite it if someone looks at what is happening here. This affects lots of packages - rubygem-cucumber indirectly depends on this, for example
Yes, this is a bummer. I suspect this is the same issue as the Fiddle failures:
https://src.fedoraproject.org/rpms/ruby/c/b6d9b2acd19c1f6f98468e667ec9f5b829...
If I am correct, I think we should disable the failing test case and hope that the apps using FFI are not using fork ATM.
I have pushed workaround here: https://src.fedoraproject.org/rpms/rubygem-ffi/c/19f6fee2f1f21ffd437018849a9...
And the build is running:
https://koji.fedoraproject.org/koji/taskinfo?taskID=82006114
Looks like this is built for rawhide (f36).
Ouch 😬 thx for spotting this. Luckily it won't hurt anything except my ego 😁 Here should be the right one:
https://koji.fedoraproject.org/koji/taskinfo?taskID=82007038
Vít
Thank you! Now I vote for merging into f36 buildroot.
Mamoru
Dne 27. 01. 22 v 14:23 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/01/27 22:05:
Dne 27. 01. 22 v 13:50 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/01/27 21:37:
Dne 27. 01. 22 v 11:50 Vít Ondruch napsal(a):
Dne 27. 01. 22 v 11:14 Mamoru TASAKA napsal(a):
7 rubygem-ffi-1.15.5-1.fc36.src.rpm https://koji.fedoraproject.org/koji/taskinfo?taskID=81980984 %check stage fails with SIGABRT. Even build for rawhide now fails.
I would apprecite it if someone looks at what is happening here. This affects lots of packages - rubygem-cucumber indirectly depends on this, for example
Yes, this is a bummer. I suspect this is the same issue as the Fiddle failures:
https://src.fedoraproject.org/rpms/ruby/c/b6d9b2acd19c1f6f98468e667ec9f5b829...
If I am correct, I think we should disable the failing test case and hope that the apps using FFI are not using fork ATM.
I have pushed workaround here: https://src.fedoraproject.org/rpms/rubygem-ffi/c/19f6fee2f1f21ffd437018849a9...
And the build is running:
https://koji.fedoraproject.org/koji/taskinfo?taskID=82006114
Looks like this is built for rawhide (f36).
Ouch 😬 thx for spotting this. Luckily it won't hurt anything except my ego 😁 Here should be the right one:
https://koji.fedoraproject.org/koji/taskinfo?taskID=82007038
Vít
Thank you! Now I vote for merging into f36 buildroot.
Should be done now:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-5a660a2215
With exception of player, but relengs will hopefully take care about that.
Thx everybody once again!
Vít
Mamoru _______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Vít Ondruch wrote on 2022/01/28 5:12:
Dne 27. 01. 22 v 14:23 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/01/27 22:05:
Thank you! Now I vote for merging into f36 buildroot.
Should be done now: https://bodhi.fedoraproject.org/updates/FEDORA-2022-5a660a2215 With exception of player, but relengs will hopefully take care about that.
Thx everybody once again!
Vít
A. Note that Koschei shows that not a few package now fail to build due to psych 4 change on YAML.load now default to YAML.safe_load, build.log looks like
Psych::DisallowedClass: Tried to load unspecified class: MIME::Type
The easiest fix is to change YAML.load to YAML.unsafe_load .
B. Another not a few errors are now some packages need BR: rubygem(matrix) .
I will submit PRs to fix these when I have my free time.
Regards, Mamoru
Dne 06. 02. 22 v 7:38 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/01/28 5:12:
Dne 27. 01. 22 v 14:23 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/01/27 22:05:
Thank you! Now I vote for merging into f36 buildroot.
Should be done now: https://bodhi.fedoraproject.org/updates/FEDORA-2022-5a660a2215 With exception of player, but relengs will hopefully take care about that.
Thx everybody once again!
Vít
A. Note that Koschei shows that not a few package now fail to build due to psych 4 change on YAML.load now default to YAML.safe_load, build.log looks like
Psych::DisallowedClass: Tried to load unspecified class: MIME::Type
The easiest fix is to change YAML.load to YAML.unsafe_load .
B. Another not a few errors are now some packages need BR: rubygem(matrix) .
Just discussion this with Pavel, this might be due to matrix being extracted into bunded gem and it seems that Capybara might be the package needing update.
Vít
I will submit PRs to fix these when I have my free time.
Regards, Mamoru _______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
On Mon, Feb 7, 2022 at 12:45 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 06. 02. 22 v 7:38 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/01/28 5:12:
Dne 27. 01. 22 v 14:23 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/01/27 22:05:
Thank you! Now I vote for merging into f36 buildroot.
Should be done now: https://bodhi.fedoraproject.org/updates/FEDORA-2022-5a660a2215 With exception of player, but relengs will hopefully take care about that.
Thx everybody once again!
Vít
A. Note that Koschei shows that not a few package now fail to build due to psych 4 change on YAML.load now default to YAML.safe_load, build.log looks like
Psych::DisallowedClass: Tried to load unspecified class: MIME::Type
The easiest fix is to change YAML.load to YAML.unsafe_load .
B. Another not a few errors are now some packages need BR: rubygem(matrix) .
Just discussion this with Pavel, this might be due to matrix being extracted into bunded gem and it seems that Capybara might be the package needing update.
I'm looking into this now.
Pavel
Vít
I will submit PRs to fix these when I have my free time.
Regards, Mamoru
Dne 27. 01. 22 v 11:14 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/01/26 21:59:
9 rubygem-pg-1.2.3-6.fc35.src.rpm https://koji.fedoraproject.org/koji/taskinfo?taskID=81994559 Not looked at this in detail yet
This was broken by PG update AFAIK, it probably needs some patch or rebase.
Vít
ruby-sig@lists.fedoraproject.org