Hi everybody,
I think it is the highest time to kick of the Ruby 3.2 thread. So here we go. I have just pushed the first update to private-ruby-3.2 branch [1] and here is the scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=92083633
There is nothing what would stand out.
Nevertheless, I was testing the `--enable-mkmf-verbose` configure option submitted upstream by @jaruga (thx a bunch) with the ByeBug example just to find out that ByeBug is broken due to some upstream changes [3]. So just early heads up that there will be needed some changes for Ruby 3.2.
As always, feedback is appreciate via regular channels.
Vít
[1] https://src.fedoraproject.org/rpms/ruby/tree/private-ruby-3.2
[2] https://src.fedoraproject.org/rpms/ruby/c/6a98c151e6205b6d5774d0436f6492d97c...
On Fri, Sep 16, 2022 at 7:03 PM Vít Ondruch vondruch@redhat.com wrote:
Hi everybody,
I think it is the highest time to kick of the Ruby 3.2 thread. So here we go. I have just pushed the first update to private-ruby-3.2 branch [1] and here is the scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=92083633
There is nothing what would stand out.
Nevertheless, I was testing the `--enable-mkmf-verbose` configure option submitted upstream by @jaruga (thx a bunch) with the ByeBug example just to find out that ByeBug is broken due to some upstream changes [3]. So just early heads up that there will be needed some changes for Ruby 3.2.
As always, feedback is appreciate via regular channels.
Vít
Thanks for starting to prepare the new Ruby. It seems that this year, the preparation is earlier than before. I am not sure that the ByeBug issue is directly related to the `--enable-mkmf-verbose` option. I think the issue doesn't block adding the configuration option, right?
Seeing your commit: https://src.fedoraproject.org/rpms/ruby/c/6a98c151e6205b6d5774d0436f6492d97c... , I thought backporting the upstream commit to rawhide before releasing Ruby 3.2 would be good idea. And here is the pull-request I sent now. https://src.fedoraproject.org/rpms/ruby/pull-request/133
Dne 19. 09. 22 v 18:22 Jun Aruga (he / him) napsal(a):
On Fri, Sep 16, 2022 at 7:03 PM Vít Ondruch vondruch@redhat.com wrote:
Hi everybody,
I think it is the highest time to kick of the Ruby 3.2 thread. So here we go. I have just pushed the first update to private-ruby-3.2 branch [1] and here is the scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=92083633
There is nothing what would stand out.
Nevertheless, I was testing the `--enable-mkmf-verbose` configure option submitted upstream by @jaruga (thx a bunch) with the ByeBug example just to find out that ByeBug is broken due to some upstream changes [3]. So just early heads up that there will be needed some changes for Ruby 3.2.
As always, feedback is appreciate via regular channels.
Vít
Thanks for starting to prepare the new Ruby. It seems that this year, the preparation is earlier than before.
Eh, there were probably years when I started much earlier ;)
I am not sure that the ByeBug issue is directly related to the `--enable-mkmf-verbose` option.
Only indirectly. That is the package you were using for testing, so I used it as well. The issue itself is in Pry.
~~~
+ ruby bin/minitest Ignoring byebug-11.1.3 because its extensions are not built. Try: gem pristine byebug --version 11.1.3 /usr/share/gems/gems/pry-0.13.1/lib/pry/code.rb:342:in `class:Code': undefined method `=~' for class `Pry::Code' (NameError) from /usr/share/gems/gems/pry-0.13.1/lib/pry/code.rb:32:in `class:Pry' from /usr/share/gems/gems/pry-0.13.1/lib/pry/code.rb:5:in `<top (required)>' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:85:in `require' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:85:in `require' from /usr/share/gems/gems/pry-0.13.1/lib/pry.rb:70: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/byebug-11.1.3/test/commands/pry_test.rb:3:in `<top (required)>' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:85:in `require' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:85:in `require' from /builddir/build/BUILD/byebug-11.1.3/test/minitest_runner.rb:21:in `block in run' from /builddir/build/BUILD/byebug-11.1.3/test/minitest_runner.rb:21:in `each' from /builddir/build/BUILD/byebug-11.1.3/test/minitest_runner.rb:21:in `run' from bin/minitest:8:in `<main>' internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:85:in `require': cannot load such file -- pry (LoadError) Did you mean? pty from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:85:in `require' from /builddir/build/BUILD/byebug-11.1.3/test/commands/pry_test.rb:3:in `<top (required)>' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:85:in `require' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:85:in `require' from /builddir/build/BUILD/byebug-11.1.3/test/minitest_runner.rb:21:in `block in run' from /builddir/build/BUILD/byebug-11.1.3/test/minitest_runner.rb:21:in `each' from /builddir/build/BUILD/byebug-11.1.3/test/minitest_runner.rb:21:in `run' from bin/minitest:8:in `<main>' error: Bad exit status from /var/tmp/rpm-tmp.PS30hz (%check) Bad exit status from /var/tmp/rpm-tmp.PS30hz (%check)
~~~
https://github.com/pry/pry/pull/2149
I think the issue doesn't block adding the configuration option, right?
Right.
Seeing your commit: https://src.fedoraproject.org/rpms/ruby/c/6a98c151e6205b6d5774d0436f6492d97c... , I thought backporting the upstream commit to rawhide before releasing Ruby 3.2 would be good idea. And here is the pull-request I sent now. https://src.fedoraproject.org/rpms/ruby/pull-request/133
Thx. But frankly, it changes patch for longer patch, so I don't see this really beneficial. I left the change as a separate commit mainly for documentation purposes.
Vít
On Mon, Sep 19, 2022 at 6:42 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 19. 09. 22 v 18:22 Jun Aruga (he / him) napsal(a):
On Fri, Sep 16, 2022 at 7:03 PM Vít Ondruch vondruch@redhat.com wrote:
Hi everybody,
I think it is the highest time to kick of the Ruby 3.2 thread. So here we go. I have just pushed the first update to private-ruby-3.2 branch [1] and here is the scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=92083633
There is nothing what would stand out.
Nevertheless, I was testing the `--enable-mkmf-verbose` configure option submitted upstream by @jaruga (thx a bunch) with the ByeBug example just to find out that ByeBug is broken due to some upstream changes [3]. So just early heads up that there will be needed some changes for Ruby 3.2.
As always, feedback is appreciate via regular channels.
Hi! Thanks for the build.
I have tried to rebuild it in COPR, but I'm getting an error:
``` 1) Process.clock_gettime supports the platform clocks mentioned in the documentation CLOCK_REALTIME_ALARM ERROR Errno::EINVAL: Invalid argument - clock_gettime /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:143:in `clock_gettime' /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:143:in `block (4 levels) in <top (required)>' /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:4:in `<top (required)>'
2) Process.clock_gettime supports the platform clocks mentioned in the documentation CLOCK_BOOTTIME_ALARM ERROR Errno::EINVAL: Invalid argument - clock_gettime /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:148:in `clock_gettime' /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:148:in `block (4 levels) in <top (required)>' /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:4:in `<top (required)>'
``` Builds are available: https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/builds/
Once this succeeds I plan to rebuild all rubygems we have in Fedora in the rubygems-testing COPR repository.
Pavel
Vít
Thanks for starting to prepare the new Ruby. It seems that this year, the preparation is earlier than before.
Eh, there were probably years when I started much earlier ;)
I am not sure that the ByeBug issue is directly related to the `--enable-mkmf-verbose` option.
Only indirectly. That is the package you were using for testing, so I used it as well. The issue itself is in Pry.
+ ruby bin/minitest Ignoring byebug-11.1.3 because its extensions are not built. Try: gem pristine byebug --version 11.1.3 /usr/share/gems/gems/pry-0.13.1/lib/pry/code.rb:342:in `<class:Code>': undefined method `=~' for class `Pry::Code' (NameError) from /usr/share/gems/gems/pry-0.13.1/lib/pry/code.rb:32:in `<class:Pry>' from /usr/share/gems/gems/pry-0.13.1/lib/pry/code.rb:5:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /usr/share/gems/gems/pry-0.13.1/lib/pry.rb:70: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/byebug-11.1.3/test/commands/pry_test.rb:3:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /builddir/build/BUILD/byebug-11.1.3/test/minitest_runner.rb:21:in `block in run' from /builddir/build/BUILD/byebug-11.1.3/test/minitest_runner.rb:21:in `each' from /builddir/build/BUILD/byebug-11.1.3/test/minitest_runner.rb:21:in `run' from bin/minitest:8:in `<main>' <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require': cannot load such file -- pry (LoadError) Did you mean? pty from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /builddir/build/BUILD/byebug-11.1.3/test/commands/pry_test.rb:3:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /builddir/build/BUILD/byebug-11.1.3/test/minitest_runner.rb:21:in `block in run' from /builddir/build/BUILD/byebug-11.1.3/test/minitest_runner.rb:21:in `each' from /builddir/build/BUILD/byebug-11.1.3/test/minitest_runner.rb:21:in `run' from bin/minitest:8:in `<main>' error: Bad exit status from /var/tmp/rpm-tmp.PS30hz (%check) Bad exit status from /var/tmp/rpm-tmp.PS30hz (%check)
https://github.com/pry/pry/pull/2149
I think the issue doesn't block adding the configuration option, right?
Right.
Seeing your commit:
https://src.fedoraproject.org/rpms/ruby/c/6a98c151e6205b6d5774d0436f6492d97c...
, I thought backporting the upstream commit to rawhide before releasing Ruby 3.2 would be good idea. And here is the pull-request I sent now. https://src.fedoraproject.org/rpms/ruby/pull-request/133
Thx. But frankly, it changes patch for longer patch, so I don't see this really beneficial. I left the change as a separate commit mainly for documentation purposes.
Vít
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Thu, Sep 22, 2022 at 12:41 PM Pavel Valena pvalena@redhat.com wrote:
On Mon, Sep 19, 2022 at 6:42 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 19. 09. 22 v 18:22 Jun Aruga (he / him) napsal(a):
On Fri, Sep 16, 2022 at 7:03 PM Vít Ondruch vondruch@redhat.com
wrote:
Hi everybody,
I think it is the highest time to kick of the Ruby 3.2 thread. So here we go. I have just pushed the first update to private-ruby-3.2 branch [1] and here is the scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=92083633
There is nothing what would stand out.
Nevertheless, I was testing the `--enable-mkmf-verbose` configure
option
submitted upstream by @jaruga (thx a bunch) with the ByeBug example
just
to find out that ByeBug is broken due to some upstream changes [3]. So just early heads up that there will be needed some changes for Ruby
3.2.
As always, feedback is appreciate via regular channels.
Hi! Thanks for the build.
I have tried to rebuild it in COPR, but I'm getting an error:
1) Process.clock_gettime supports the platform clocks mentioned in the documentation CLOCK_REALTIME_ALARM ERROR Errno::EINVAL: Invalid argument - clock_gettime /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:143:in `clock_gettime' /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:143:in `block (4 levels) in <top (required)>' /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:4:in `<top (required)>' 2) Process.clock_gettime supports the platform clocks mentioned in the documentation CLOCK_BOOTTIME_ALARM ERROR Errno::EINVAL: Invalid argument - clock_gettime /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:148:in `clock_gettime' /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:148:in `block (4 levels) in <top (required)>' /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:4:in `<top (required)>'
Builds are available: https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/builds/
Once this succeeds I plan to rebuild all rubygems we have in Fedora in the rubygems-testing COPR repository.
Pavel
- subsequent build succeeded, at least on rawhide + centos-stream-8 ... both x86_64
I'll try some more builds e.g. for epel-9 and proceed (see my previous email) with those buildroots that succeed.
Pavel
Vít
Thanks for starting to prepare the new Ruby. It seems that this year, the preparation is earlier than before.
Eh, there were probably years when I started much earlier ;)
I am not sure that the ByeBug issue is directly related to the `--enable-mkmf-verbose` option.
Only indirectly. That is the package you were using for testing, so I used it as well. The issue itself is in Pry.
+ ruby bin/minitest Ignoring byebug-11.1.3 because its extensions are not built. Try: gem pristine byebug --version 11.1.3 /usr/share/gems/gems/pry-0.13.1/lib/pry/code.rb:342:in `<class:Code>': undefined method `=~' for class `Pry::Code' (NameError) from /usr/share/gems/gems/pry-0.13.1/lib/pry/code.rb:32:in `<class:Pry>' from /usr/share/gems/gems/pry-0.13.1/lib/pry/code.rb:5:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /usr/share/gems/gems/pry-0.13.1/lib/pry.rb:70: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/byebug-11.1.3/test/commands/pry_test.rb:3:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /builddir/build/BUILD/byebug-11.1.3/test/minitest_runner.rb:21:in `block in run' from /builddir/build/BUILD/byebug-11.1.3/test/minitest_runner.rb:21:in `each' from /builddir/build/BUILD/byebug-11.1.3/test/minitest_runner.rb:21:in `run' from bin/minitest:8:in `<main>' <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require': cannot load such file -- pry (LoadError) Did you mean? pty from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /builddir/build/BUILD/byebug-11.1.3/test/commands/pry_test.rb:3:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from /builddir/build/BUILD/byebug-11.1.3/test/minitest_runner.rb:21:in `block in run' from /builddir/build/BUILD/byebug-11.1.3/test/minitest_runner.rb:21:in `each' from /builddir/build/BUILD/byebug-11.1.3/test/minitest_runner.rb:21:in `run' from bin/minitest:8:in `<main>' error: Bad exit status from /var/tmp/rpm-tmp.PS30hz (%check) Bad exit status from /var/tmp/rpm-tmp.PS30hz (%check)
https://github.com/pry/pry/pull/2149
I think the issue doesn't block adding the configuration option, right?
Right.
Seeing your commit:
https://src.fedoraproject.org/rpms/ruby/c/6a98c151e6205b6d5774d0436f6492d97c...
, I thought backporting the upstream commit to rawhide before releasing Ruby 3.2 would be good idea. And here is the pull-request I sent now. https://src.fedoraproject.org/rpms/ruby/pull-request/133
Thx. But frankly, it changes patch for longer patch, so I don't see this really beneficial. I left the change as a separate commit mainly for documentation purposes.
Vít
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Dne 22. 09. 22 v 23:36 Pavel Valena napsal(a):
On Thu, Sep 22, 2022 at 12:41 PM Pavel Valena pvalena@redhat.com wrote:
On Mon, Sep 19, 2022 at 6:42 PM Vít Ondruch <vondruch@redhat.com> wrote: Dne 19. 09. 22 v 18:22 Jun Aruga (he / him) napsal(a): > On Fri, Sep 16, 2022 at 7:03 PM Vít Ondruch <vondruch@redhat.com> wrote: >> Hi everybody, >> >> I think it is the highest time to kick of the Ruby 3.2 thread. So here >> we go. I have just pushed the first update to private-ruby-3.2 branch >> [1] and here is the scratch build: >> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=92083633 >> >> There is nothing what would stand out. >> >> Nevertheless, I was testing the `--enable-mkmf-verbose` configure option >> submitted upstream by @jaruga (thx a bunch) with the ByeBug example just >> to find out that ByeBug is broken due to some upstream changes [3]. So >> just early heads up that there will be needed some changes for Ruby 3.2. >> >> As always, feedback is appreciate via regular channels. Hi! Thanks for the build. I have tried to rebuild it in COPR, but I'm getting an error: ``` 1) Process.clock_gettime supports the platform clocks mentioned in the documentation CLOCK_REALTIME_ALARM ERROR Errno::EINVAL: Invalid argument - clock_gettime /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:143:in `clock_gettime' /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:143:in `block (4 levels) in <top (required)>' /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:4:in `<top (required)>' 2) Process.clock_gettime supports the platform clocks mentioned in the documentation CLOCK_BOOTTIME_ALARM ERROR Errno::EINVAL: Invalid argument - clock_gettime /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:148:in `clock_gettime' /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:148:in `block (4 levels) in <top (required)>' /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:4:in `<top (required)>' ``` Builds are available: https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/builds/ Once this succeeds I plan to rebuild all rubygems we have in Fedora in the rubygems-testing COPR repository. Pavel
- subsequent build succeeded, at least on rawhide + centos-stream-8 ... both x86_64
Hm the only successful build for fedora-rawhide-x86_64 is this:
https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/4868339/
And the difference is in kernel. This successful build was built on `kernel version == 5.14.10-300.fc35.x86_64`. The failed attempts were using `kernel version == 5.17.7-200.fc35.x86_64`. And the original Koji build was build using `kernel version == 5.18.17-200.fc36.x86_64`. Not sure what should be the takeaway now. But maybe the `5.17.7-200.fc35.x86_64` kernel has some bug? It seems that the implementation as well as the specs are properly conditioned:
https://github.com/ruby/spec/blob/8d26c0c202d3c098478fe17067a12b803504187e/c...
https://github.com/ruby/ruby/blob/a78c733cc32cc3da3796cbf65da21cdd40c63230/p...
Or the kernel-headers used during build might be broken ...
Of course this might be something completely different :)
Vít
On Fri, Sep 23, 2022 at 1:02 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 22. 09. 22 v 23:36 Pavel Valena napsal(a):
On Thu, Sep 22, 2022 at 12:41 PM Pavel Valena pvalena@redhat.com wrote:
On Mon, Sep 19, 2022 at 6:42 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 19. 09. 22 v 18:22 Jun Aruga (he / him) napsal(a):
On Fri, Sep 16, 2022 at 7:03 PM Vít Ondruch vondruch@redhat.com
wrote:
Hi everybody,
I think it is the highest time to kick of the Ruby 3.2 thread. So here we go. I have just pushed the first update to private-ruby-3.2 branch [1] and here is the scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=92083633
There is nothing what would stand out.
Nevertheless, I was testing the `--enable-mkmf-verbose` configure
option
submitted upstream by @jaruga (thx a bunch) with the ByeBug example
just
to find out that ByeBug is broken due to some upstream changes [3]. So just early heads up that there will be needed some changes for Ruby
3.2.
As always, feedback is appreciate via regular channels.
Hi! Thanks for the build.
I have tried to rebuild it in COPR, but I'm getting an error:
1) Process.clock_gettime supports the platform clocks mentioned in the documentation CLOCK_REALTIME_ALARM ERROR Errno::EINVAL: Invalid argument - clock_gettime /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:143:in `clock_gettime' /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:143:in `block (4 levels) in <top (required)>' /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:4:in `<top (required)>' 2) Process.clock_gettime supports the platform clocks mentioned in the documentation CLOCK_BOOTTIME_ALARM ERROR Errno::EINVAL: Invalid argument - clock_gettime /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:148:in `clock_gettime' /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:148:in `block (4 levels) in <top (required)>' /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:4:in `<top (required)>'
Builds are available: https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/builds/
Once this succeeds I plan to rebuild all rubygems we have in Fedora in the rubygems-testing COPR repository.
Pavel
- subsequent build succeeded, at least on rawhide + centos-stream-8 ...
both x86_64
Hm the only successful build for fedora-rawhide-x86_64 is this:
https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/4868339/
And the difference is in kernel. This successful build was built on `kernel version == 5.14.10-300.fc35.x86_64`. The failed attempts were using `kernel version == 5.17.7-200.fc35.x86_64`. And the original Koji build was build using `kernel version == 5.18.17-200.fc36.x86_64`. Not sure what should be the takeaway now. But maybe the `5.17.7-200.fc35.x86_64` kernel has some bug? It seems that the implementation as well as the specs are properly conditioned:
https://github.com/ruby/spec/blob/8d26c0c202d3c098478fe17067a12b803504187e/c...
https://github.com/ruby/ruby/blob/a78c733cc32cc3da3796cbf65da21cdd40c63230/p...
Or the kernel-headers used during build might be broken ...
Of course this might be something completely different :)
Thanks for the investigation!
Yes, it's odd, I expected to get more successful builds, but that's the only one out of ~8 builds... oddly enough s390x and ppc64le have more success (approx every 2nd attempt). I will retry once more, and hopefully some stable kernel will propagate into COPR buildroots.
Oddly enough, I'm getting the same error on centos-stream-8 and fedora-37 ... so it might be a builder kernel version instead (capability missing).
Pavel
Vít
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Fri, Sep 23, 2022 at 5:12 PM Pavel Valena pvalena@redhat.com wrote:
On Fri, Sep 23, 2022 at 1:02 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 22. 09. 22 v 23:36 Pavel Valena napsal(a):
On Thu, Sep 22, 2022 at 12:41 PM Pavel Valena pvalena@redhat.com wrote:
On Mon, Sep 19, 2022 at 6:42 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 19. 09. 22 v 18:22 Jun Aruga (he / him) napsal(a):
On Fri, Sep 16, 2022 at 7:03 PM Vít Ondruch vondruch@redhat.com
wrote:
Hi everybody,
I think it is the highest time to kick of the Ruby 3.2 thread. So
here
we go. I have just pushed the first update to private-ruby-3.2 branch [1] and here is the scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=92083633
There is nothing what would stand out.
Nevertheless, I was testing the `--enable-mkmf-verbose` configure
option
submitted upstream by @jaruga (thx a bunch) with the ByeBug example
just
to find out that ByeBug is broken due to some upstream changes [3].
So
just early heads up that there will be needed some changes for Ruby
3.2.
As always, feedback is appreciate via regular channels.
Hi! Thanks for the build.
I have tried to rebuild it in COPR, but I'm getting an error:
1) Process.clock_gettime supports the platform clocks mentioned in the documentation CLOCK_REALTIME_ALARM ERROR Errno::EINVAL: Invalid argument - clock_gettime /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:143:in `clock_gettime' /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:143:in `block (4 levels) in <top (required)>' /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:4:in `<top (required)>' 2) Process.clock_gettime supports the platform clocks mentioned in the documentation CLOCK_BOOTTIME_ALARM ERROR Errno::EINVAL: Invalid argument - clock_gettime /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:148:in `clock_gettime' /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:148:in `block (4 levels) in <top (required)>' /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:4:in `<top (required)>'
Builds are available: https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/builds/
Once this succeeds I plan to rebuild all rubygems we have in Fedora in the rubygems-testing COPR repository.
Pavel
- subsequent build succeeded, at least on rawhide + centos-stream-8 ...
both x86_64
Hm the only successful build for fedora-rawhide-x86_64 is this:
https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/4868339/
And the difference is in kernel. This successful build was built on `kernel version == 5.14.10-300.fc35.x86_64`. The failed attempts were using `kernel version == 5.17.7-200.fc35.x86_64`. And the original Koji build was build using `kernel version == 5.18.17-200.fc36.x86_64`. Not sure what should be the takeaway now. But maybe the `5.17.7-200.fc35.x86_64` kernel has some bug? It seems that the implementation as well as the specs are properly conditioned:
https://github.com/ruby/spec/blob/8d26c0c202d3c098478fe17067a12b803504187e/c...
https://github.com/ruby/ruby/blob/a78c733cc32cc3da3796cbf65da21cdd40c63230/p...
Or the kernel-headers used during build might be broken ...
Of course this might be something completely different :)
Thanks for the investigation!
Yes, it's odd, I expected to get more successful builds, but that's the only one out of ~8 builds... oddly enough s390x and ppc64le have more success (approx every 2nd attempt). I will retry once more, and hopefully some stable kernel will propagate into COPR buildroots.
Oddly enough, I'm getting the same error on centos-stream-8 and fedora-37 ... so it might be a builder kernel version instead (capability missing).
In any case, I'm fine with the one successful build for fedora-rawhide. I'm proceeding with rebuilding all rubygems in Fedora in my COPR:
https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/builds/
P.
Pavel
Vít
Dne 23. 09. 22 v 17:30 Pavel Valena napsal(a):
On Fri, Sep 23, 2022 at 5:12 PM Pavel Valena pvalena@redhat.com wrote:
On Fri, Sep 23, 2022 at 1:02 PM Vít Ondruch <vondruch@redhat.com> wrote: Dne 22. 09. 22 v 23:36 Pavel Valena napsal(a):
On Thu, Sep 22, 2022 at 12:41 PM Pavel Valena <pvalena@redhat.com> wrote: On Mon, Sep 19, 2022 at 6:42 PM Vít Ondruch <vondruch@redhat.com> wrote: Dne 19. 09. 22 v 18:22 Jun Aruga (he / him) napsal(a): > On Fri, Sep 16, 2022 at 7:03 PM Vít Ondruch <vondruch@redhat.com> wrote: >> Hi everybody, >> >> I think it is the highest time to kick of the Ruby 3.2 thread. So here >> we go. I have just pushed the first update to private-ruby-3.2 branch >> [1] and here is the scratch build: >> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=92083633 >> >> There is nothing what would stand out. >> >> Nevertheless, I was testing the `--enable-mkmf-verbose` configure option >> submitted upstream by @jaruga (thx a bunch) with the ByeBug example just >> to find out that ByeBug is broken due to some upstream changes [3]. So >> just early heads up that there will be needed some changes for Ruby 3.2. >> >> As always, feedback is appreciate via regular channels. Hi! Thanks for the build. I have tried to rebuild it in COPR, but I'm getting an error: ``` 1) Process.clock_gettime supports the platform clocks mentioned in the documentation CLOCK_REALTIME_ALARM ERROR Errno::EINVAL: Invalid argument - clock_gettime /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:143:in `clock_gettime' /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:143:in `block (4 levels) in <top (required)>' /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:4:in `<top (required)>' 2) Process.clock_gettime supports the platform clocks mentioned in the documentation CLOCK_BOOTTIME_ALARM ERROR Errno::EINVAL: Invalid argument - clock_gettime /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:148:in `clock_gettime' /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:148:in `block (4 levels) in <top (required)>' /builddir/build/BUILD/ruby-3.2.0-6ad6994457/spec/ruby/core/process/clock_gettime_spec.rb:4:in `<top (required)>' ``` Builds are available: https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/builds/ Once this succeeds I plan to rebuild all rubygems we have in Fedora in the rubygems-testing COPR repository. Pavel - subsequent build succeeded, at least on rawhide + centos-stream-8 ... both x86_64
Hm the only successful build for fedora-rawhide-x86_64 is this: https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/4868339/ And the difference is in kernel. This successful build was built on `kernel version == 5.14.10-300.fc35.x86_64`. The failed attempts were using `kernel version == 5.17.7-200.fc35.x86_64`. And the original Koji build was build using `kernel version == 5.18.17-200.fc36.x86_64`. Not sure what should be the takeaway now. But maybe the `5.17.7-200.fc35.x86_64` kernel has some bug? It seems that the implementation as well as the specs are properly conditioned: https://github.com/ruby/spec/blob/8d26c0c202d3c098478fe17067a12b803504187e/core/process/fixtures/clocks.rb#L11 https://github.com/ruby/ruby/blob/a78c733cc32cc3da3796cbf65da21cdd40c63230/process.c#L9143-L9146 Or the kernel-headers used during build might be broken ... Of course this might be something completely different :) Thanks for the investigation! Yes, it's odd, I expected to get more successful builds, but that's the only one out of ~8 builds... oddly enough s390x and ppc64le have more success (approx every 2nd attempt). I will retry once more, and hopefully some stable kernel will propagate into COPR buildroots. Oddly enough, I'm getting the same error on centos-stream-8 and fedora-37 ... so it might be a builder kernel version instead (capability missing).
In any case, I'm fine with the one successful build for fedora-rawhide. I'm proceeding with rebuilding all rubygems in Fedora in my COPR:
https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/builds/
Thx.
Randomly looking at failing rubygem-xpath:
https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/build/48716...
It require updated Nokogiri:
https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/build/48711...
Which fails due to Racc:
https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/build/48711...
The issue seems to be fixed upstream:
https://github.com/ruby/racc/pull/191
It is unfortunate that such a minor bug might influence quite lot of the ecosystem. Hopefully we will be in better shape in few months. And if on, just remember we have to fix this one ;)
Vít
P.
Pavel Vít
ruby-sig mailing list --ruby-sig@lists.fedoraproject.org To unsubscribe send an email toruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o... Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue
Vít Ondruch wrote on 2022/09/26 19:57:
Which fails due to Racc:
https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/build/48711...
The issue seems to be fixed upstream:
https://github.com/ruby/racc/pull/191
It is unfortunate that such a minor bug might influence quite lot of the ecosystem. Hopefully we will be in better shape in few months. And if on, just remember we have to fix this one ;)
I've backported this. https://src.fedoraproject.org/rpms/rubygem-racc/c/3c4085f926366417a372f0ee6e...
Mamoru
Dne 26. 09. 22 v 15:36 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/09/26 19:57:
Which fails due to Racc:
https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/build/48711...
The issue seems to be fixed upstream:
https://github.com/ruby/racc/pull/191
It is unfortunate that such a minor bug might influence quite lot of the ecosystem. Hopefully we will be in better shape in few months. And if on, just remember we have to fix this one ;)
I've backported this. https://src.fedoraproject.org/rpms/rubygem-racc/c/3c4085f926366417a372f0ee6e...
Nice, thx.
Last build of Racc done 7h ago failed again:
https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/build/48747...
But this was still -204. Pavle, how is this updated? Does it need any intervention? Or successful Rawhide compose?
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, report it: https://pagure.io/fedora-infrastructure/new_issue
On Tue, Sep 27, 2022 at 4:42 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 26. 09. 22 v 15:36 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/09/26 19:57:
Which fails due to Racc:
https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/build/48711...
The issue seems to be fixed upstream:
https://github.com/ruby/racc/pull/191
It is unfortunate that such a minor bug might influence quite lot of the ecosystem. Hopefully we will be in better shape in few months. And if on, just remember we have to fix this one ;)
I've backported this.
https://src.fedoraproject.org/rpms/rubygem-racc/c/3c4085f926366417a372f0ee6e...
Nice, thx.
Last build of Racc done 7h ago failed again:
https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/build/48747...
But this was still -204. Pavle, how is this updated? Does it need any intervention? Or successful Rawhide compose?
Good point. I forgot to put git pull there.
Fixing now. Thanks!
Pavel
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, report it: https://pagure.io/fedora-infrastructure/new_issue
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Dne 27. 09. 22 v 19:28 Pavel Valena napsal(a):
On Tue, Sep 27, 2022 at 4:42 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 26. 09. 22 v 15:36 Mamoru TASAKA napsal(a): > Vít Ondruch wrote on 2022/09/26 19:57: >> >> Which fails due to Racc: >> >> https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/build/4871170/ >> >> >> The issue seems to be fixed upstream: >> >> https://github.com/ruby/racc/pull/191 >> >> >> It is unfortunate that such a minor bug might influence quite lot of >> the ecosystem. Hopefully we will be in better shape in few months. >> And if on, just remember we have to fix this one ;) >> > > I've backported this. > https://src.fedoraproject.org/rpms/rubygem-racc/c/3c4085f926366417a372f0ee6e9746f79ca46bb7 > Nice, thx. Last build of Racc done 7h ago failed again: https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/build/4874736/ But this was still -204. Pavle, how is this updated? Does it need any intervention? Or successful Rawhide compose?
Good point. I forgot to put git pull there.
Fixing now. Thanks!
Yep, that works.
And another issue for Mamoru, this time from rspec-core:
~~~
expected "\nAn error occurred while loading ./spec/example_spec.rb.\nFailure/Error:\n RSpec.describe Fixnum d...files took 0.05699 seconds to load)\n0 examples, 0 failures, 1 error occurred outside of examples\n" not to string includes: "0 examples" Diff: @@ -1,2 +1,22 @@ -0 examples + +An error occurred while loading ./spec/example_spec.rb. +Failure/Error: + RSpec.describe Fixnum do + describe 'inner' do + describe String do + it "is available as described_class" do + expect(described_class).to eq(String) + end + end + end + end + +NameError: + uninitialized constant Fixnum +# ./spec/example_spec.rb:1:in `<top (required)>' +No examples found. + + +Finished in 0.00003 seconds (files took 0.05699 seconds to load) +0 examples, 0 failures, 1 error occurred outside of examples
~~~
And here is the fix:
https://github.com/rspec/rspec-core/commit/bf49c78d7a92e253d557924a3f85fd699...
This is likely due to:
https://github.com/ruby/ruby/blob/28840d74c26189f4e730b906c2383e32ea6165fe/N...
In short, it seems to be due to removing deprecated `Fixnum` and `Bignum`. This might cause some troubles. Not in rspec-core.
Vít
Pavel
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.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue _______________________________________________ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
ruby-sig mailing list --ruby-sig@lists.fedoraproject.org To unsubscribe send an email toruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o... Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue
Vít Ondruch wrote on 2022/09/29 20:15:
And another issue for Mamoru, this time from rspec-core:
expected "\nAn error occurred while loading ./spec/example_spec.rb.\nFailure/Error:\n RSpec.describe Fixnum d...files took 0.05699 seconds to load)\n0 examples, 0 failures, 1 error occurred outside of examples\n" not to string includes: "0 examples" Diff: @@ -1,2 +1,22 @@ -0 examples + +An error occurred while loading ./spec/example_spec.rb. +Failure/Error: + RSpec.describe Fixnum do + describe 'inner' do + describe String do + it "is available as described_class" do + expect(described_class).to eq(String) + end + end + end + end + +NameError: + uninitialized constant Fixnum +# ./spec/example_spec.rb:1:in `<top (required)>' +No examples found. + + +Finished in 0.00003 seconds (files took 0.05699 seconds to load) +0 examples, 0 failures, 1 error occurred outside of examples
And here is the fix: https://github.com/rspec/rspec-core/commit/bf49c78d7a92e253d557924a3f85fd699...
This is likely due to: https://github.com/ruby/ruby/blob/28840d74c26189f4e730b906c2383e32ea6165fe/N...
In short, it seems to be due to removing deprecated `Fixnum` and `Bignum`. This might cause some troubles. Not in rspec-core.
Okay, backported (with minimum changes): https://src.fedoraproject.org/rpms/rubygem-rspec-core/c/e7531e5398dc0d81fbcd...
I guess removal of Fixnum / Bignum / tainted? and so on will affect many packages.
Mamoru.
Dne 29. 09. 22 v 16:23 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/09/29 20:15:
And another issue for Mamoru, this time from rspec-core:
expected "\nAn error occurred while loading ./spec/example_spec.rb.\nFailure/Error:\n RSpec.describe Fixnum d...files took 0.05699 seconds to load)\n0 examples, 0 failures, 1 error occurred outside of examples\n" not to string includes: "0 examples" Diff: @@ -1,2 +1,22 @@ -0 examples + +An error occurred while loading ./spec/example_spec.rb. +Failure/Error: + RSpec.describe Fixnum do + describe 'inner' do + describe String do + it "is available as described_class" do + expect(described_class).to eq(String) + end + end + end + end + +NameError: + uninitialized constant Fixnum +# ./spec/example_spec.rb:1:in `<top (required)>' +No examples found. + + +Finished in 0.00003 seconds (files took 0.05699 seconds to load) +0 examples, 0 failures, 1 error occurred outside of examples
And here is the fix: https://github.com/rspec/rspec-core/commit/bf49c78d7a92e253d557924a3f85fd699...
This is likely due to: https://github.com/ruby/ruby/blob/28840d74c26189f4e730b906c2383e32ea6165fe/N...
In short, it seems to be due to removing deprecated `Fixnum` and `Bignum`. This might cause some troubles. Not in rspec-core.
Okay, backported (with minimum changes): https://src.fedoraproject.org/rpms/rubygem-rspec-core/c/e7531e5398dc0d81fbcd...
Thx a lot.
And I should really update Pry, because I saw Pry related issues on more places.
I guess removal of Fixnum / Bignum / tainted? and so on will affect many packages.
Yes, that is my worry as well. Probably good idea to keep and eye on the Copr and report these upstream in advance.
BTW, Pavel, would there be a chance to collect the build logs of all the packages in one tarball? It would probably help to identify some patterns (that could be possibly also interesting RFE for Copr, rihgt? ;) ).
Vít
On Sat, Oct 1, 2022 at 10:11 AM Vít Ondruch vondruch@redhat.com wrote:
Dne 29. 09. 22 v 16:23 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/09/29 20:15:
And another issue for Mamoru, this time from rspec-core:
expected "\nAn error occurred while loading ./spec/example_spec.rb.\nFailure/Error:\n RSpec.describe Fixnum d...files took 0.05699 seconds to load)\n0 examples, 0 failures, 1 error occurred outside of examples\n" not to string includes: "0 examples" Diff: @@ -1,2 +1,22 @@ -0 examples + +An error occurred while loading ./spec/example_spec.rb. +Failure/Error: + RSpec.describe Fixnum do + describe 'inner' do + describe String do + it "is available as described_class" do + expect(described_class).to eq(String) + end + end + end + end + +NameError: + uninitialized constant Fixnum +# ./spec/example_spec.rb:1:in `<top (required)>' +No examples found. + + +Finished in 0.00003 seconds (files took 0.05699 seconds to load) +0 examples, 0 failures, 1 error occurred outside of examples
And here is the fix:
https://github.com/rspec/rspec-core/commit/bf49c78d7a92e253d557924a3f85fd699...
This is likely due to:
https://github.com/ruby/ruby/blob/28840d74c26189f4e730b906c2383e32ea6165fe/N...
In short, it seems to be due to removing deprecated `Fixnum` and `Bignum`. This might cause some troubles. Not in rspec-core.
Okay, backported (with minimum changes):
https://src.fedoraproject.org/rpms/rubygem-rspec-core/c/e7531e5398dc0d81fbcd...
Thx a lot.
And I should really update Pry, because I saw Pry related issues on more places.
I guess removal of Fixnum / Bignum / tainted? and so on will affect many packages.
Yes, that is my worry as well. Probably good idea to keep and eye on the Copr and report these upstream in advance.
BTW, Pavel, would there be a chance to collect the build logs of all the packages in one tarball? It would probably help to identify some patterns (that could be possibly also interesting RFE for Copr, rihgt? ;) ).
I already automatically collect all copr build logs via my automation, locally, using: https://github.com/pvalena/theprototype/blob/main/pkgs/cr-build.sh (documentation + demo TBD)
I do intend to go through the failed builds and identify / sort the causes (dependencies vs test suite etc.).
But in case you want to grep through them yourself - here're the failed builds & logs for those:
https://gist.github.com/pvalena/019f480cb6107d56bbb052e9fc9ceddd https://pvalena.fedorapeople.org/logs/rubygems-testing-logs-ruby-3.2.txz
Pavel
Vít
Hello, Vít:
Vít Ondruch wrote on 2022/10/01 17:10:
And I should really update Pry, because I saw Pry related issues on more places.
For now, may I just backport the below? https://github.com/pry/pry/commit/b548784b4a31b49026b69849430a9ec9072ae94a
At least the above change fixes rubygem-rmagick build issue.
Regards, Mamoru
Dne 04. 10. 22 v 16:31 Mamoru TASAKA napsal(a):
Hello, Vít:
Vít Ondruch wrote on 2022/10/01 17:10:
And I should really update Pry, because I saw Pry related issues on more places.
For now, may I just backport the below? https://github.com/pry/pry/commit/b548784b4a31b49026b69849430a9ec9072ae94a
Yep this is the change.
Thx for the kind offer, but I really meant to update Pry. And the update landed in Rawhide now.
Pavel, PTAL.
Vít
At least the above change fixes rubygem-rmagick build issue.
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, report it: https://pagure.io/fedora-infrastructure/new_issue
Hi again,
I have prepared update again. You can see the changes in the PR [1] I have opened (not intended to be merged, just to show the diff) and the scratch build is here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=92950720
I have not spot anything which would caught my attention. Please give it a try and let me know in case of issues.
Thx
Vít
[1] https://src.fedoraproject.org/rpms/ruby/pull-request/134
Vít Ondruch wrote on 2022/10/13 0:26:
Hi again,
I have prepared update again. You can see the changes in the PR [1] I have opened (not intended to be merged, just to show the diff) and the scratch build is here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=92950720
I have not spot anything which would caught my attention. Please give it a try and let me know in case of issues.
Thx
Vít
[1] https://src.fedoraproject.org/rpms/ruby/pull-request/134
Thank you for your work.
While Pavel is trying rebuilding rubygem- packages continuously, now I tried myself rebuilding.
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/ https://copr.fedorainfracloud.org/coprs/mtasaka/heavypkg-newruby-test/
So far * Out of 495 rubygem- packages: - ~447 packages built successfully - ~48 failed to build
* And out of other 58 packages which has "BR: ruby-devel" or "BR: pkgconfig(ruby)" - ~53 packages built successfully - ~5 failed to build
Just a quick glance at these (I have not checked all of these, just selected some of them)
* Removal of File.exists? / Object#=~ / "tainted"ness affects several pacakges * rubygem-jekyll seems to be affected by keywords / positional argument treatment change??
By the way, is it better to create "central" bugzilla ticket to keep track of ruby32 related issues for each package?
Regards, Mamoru
Thanks for the work, Mamoru.
- Removal of File.exists? / Object#=~ / "tainted"ness affects several pacakges
It seems the method was removed in Ruby 3.2.0. https://github.com/ruby/ruby/blob/v3_2_0_preview2/NEWS.md#removed-methods
The following deprecated methods are removed. ...
- `File.exists?` [[Feature #17391]]
...
- rubygem-jekyll seems to be affected by keywords / positional argument treatment change??
Not sure.
By the way, is it better to create "central" bugzilla ticket to keep track of ruby32 related issues for each package?
It sounds like a good idea.
Dne 13. 10. 22 v 13:49 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/10/13 0:26:
Hi again,
I have prepared update again. You can see the changes in the PR [1] I have opened (not intended to be merged, just to show the diff) and the scratch build is here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=92950720
I have not spot anything which would caught my attention. Please give it a try and let me know in case of issues.
Thx
Vít
[1] https://src.fedoraproject.org/rpms/ruby/pull-request/134
Thank you for your work.
While Pavel is trying rebuilding rubygem- packages continuously, now I tried myself rebuilding.
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/ https://copr.fedorainfracloud.org/coprs/mtasaka/heavypkg-newruby-test/
So far
- Out of 495 rubygem- packages:
- ~447 packages built successfully - ~48 failed to build
- And out of other 58 packages which has "BR: ruby-devel" or "BR:
pkgconfig(ruby)" - ~53 packages built successfully - ~5 failed to build
Just a quick glance at these (I have not checked all of these, just selected some of them)
- Removal of File.exists? / Object#=~ / "tainted"ness affects several
pacakges
- rubygem-jekyll seems to be affected by keywords / positional
argument treatment change??
By the way, is it better to create "central" bugzilla ticket to keep track of ruby32 related issues for each package?
There should be created the tracker as part of Ruby 3.2 change proposal process. So maybe I should prepare the change proposal early and we would get the tracker "for free".
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, report it: https://pagure.io/fedora-infrastructure/new_issue
Dne 14. 10. 22 v 19:56 Vít Ondruch napsal(a):
Dne 13. 10. 22 v 13:49 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/10/13 0:26:
Hi again,
I have prepared update again. You can see the changes in the PR [1] I have opened (not intended to be merged, just to show the diff) and the scratch build is here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=92950720
I have not spot anything which would caught my attention. Please give it a try and let me know in case of issues.
Thx
Vít
[1] https://src.fedoraproject.org/rpms/ruby/pull-request/134
Thank you for your work.
While Pavel is trying rebuilding rubygem- packages continuously, now I tried myself rebuilding.
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/ https://copr.fedorainfracloud.org/coprs/mtasaka/heavypkg-newruby-test/
So far
- Out of 495 rubygem- packages:
- ~447 packages built successfully - ~48 failed to build
- And out of other 58 packages which has "BR: ruby-devel" or "BR:
pkgconfig(ruby)" - ~53 packages built successfully - ~5 failed to build
Just a quick glance at these (I have not checked all of these, just selected some of them)
- Removal of File.exists? / Object#=~ / "tainted"ness affects several
pacakges
- rubygem-jekyll seems to be affected by keywords / positional
argument treatment change??
By the way, is it better to create "central" bugzilla ticket to keep track of ruby32 related issues for each package?
There should be created the tracker as part of Ruby 3.2 change proposal process. So maybe I should prepare the change proposal early and we would get the tracker "for free".
I have put together the change proposal:
https://fedoraproject.org/wiki/Changes/Ruby_3.2
Please review, although with exception of "Detailed Description" chapter, where the changes are described, it is basically just copy/paste of the Ruby 3.1 change proposal.
I have marked the change as "ChangeReadyForWrangler" already. BTW everybody feel free to add yourselves as a change (co-)owner.
Vít
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, report it: https://pagure.io/fedora-infrastructure/new_issue
I have put together the change proposal:
https://fedoraproject.org/wiki/Changes/Ruby_3.2
Please review, although with exception of "Detailed Description" chapter, where the changes are described, it is basically just copy/paste of the Ruby 3.1 change proposal.
I have marked the change as "ChangeReadyForWrangler" already. BTW everybody feel free to add yourselves as a change (co-)owner.
For the "WASI based WebAssembly support" feature, there is no way to use this feature from Ruby RPM. Users need to build Ruby from the source with a specific build target configure option. Does it make sense to show the feature on the proposal page?
Dne 04. 11. 22 v 19:13 Jun Aruga (he / him) napsal(a):
I have put together the change proposal:
https://fedoraproject.org/wiki/Changes/Ruby_3.2
Please review, although with exception of "Detailed Description" chapter, where the changes are described, it is basically just copy/paste of the Ruby 3.1 change proposal.
I have marked the change as "ChangeReadyForWrangler" already. BTW everybody feel free to add yourselves as a change (co-)owner.
For the "WASI based WebAssembly support" feature, there is no way to use this feature from Ruby RPM. Users need to build Ruby from the source with a specific build target configure option. Does it make sense to show the feature on the proposal page?
Could you please elaborate? Do you suggest we should describe how to prepare that build or that we should rather not mention WASI, because the RPM does not actually support it?
I don't think that the former would be really valuable. Unless the RPM package Ruby would make it easier in some way.
Vít
On Mon, Nov 7, 2022 at 10:44 AM Vít Ondruch vondruch@redhat.com wrote:
Dne 04. 11. 22 v 19:13 Jun Aruga (he / him) napsal(a):
I have put together the change proposal:
https://fedoraproject.org/wiki/Changes/Ruby_3.2
Please review, although with exception of "Detailed Description" chapter, where the changes are described, it is basically just copy/paste of the Ruby 3.1 change proposal.
I have marked the change as "ChangeReadyForWrangler" already. BTW everybody feel free to add yourselves as a change (co-)owner.
For the "WASI based WebAssembly support" feature, there is no way to use this feature from Ruby RPM. Users need to build Ruby from the source with a specific build target configure option. Does it make sense to show the feature on the proposal page?
Could you please elaborate? Do you suggest we should describe how to prepare that build or that we should rather not mention WASI, because the RPM does not actually support it?
Sure. First, are you ok for the part 'For the "WASI based WebAssembly support" feature, there is no way to use this feature from Ruby RPM.'?
That means https://bugs.ruby-lang.org/issues/19053#note-3
When building ruby to run on the WebAssembly runtime with `configure --host wasm32-unknown-wasi`, it works on the WebAssembly runtime (wasmtime).
``` $ pwd /home/jaruga/src/ruby-3.2.0-preview2_wasi_fedora
$ ./autogen.sh
$ ./configure LDFLAGS="-Xlinker -zstack-size=16777216" \ -prefix=/usr/local/ruby-3.2.0-preview2-wasm32-wasi \ --host wasm32-unknown-wasi \ --with-destdir=./ruby-wasm32-wasi \ --with-static-linked-ext \ --with-ext=ripper,monitor
$ make $ make install
$ wasmtime ruby-wasm32-wasi/usr/local/ruby-3.2.0-preview2-wasm32-wasi/bin/ruby --mapdir /::./ruby-wasm32-wasi/ -- -e 'puts RUBY_PLATFORM' wasm32-wasi ```
But the binary doesn't work on normal use.
``` $ ruby-wasm32-wasi/usr/local/ruby-3.2.0-preview2-wasm32-wasi/bin/ruby -v bash: ruby-wasm32-wasi/usr/local/ruby-3.2.0-preview2-wasm32-wasi/bin/ruby: cannot execute binary file: Exec format error
$ ruby-wasm32-wasi/usr/local/ruby-3.2.0-preview2-wasm32-wasi/bin/ruby -e 'puts "a"' bash: ruby-wasm32-wasi/usr/local/ruby-3.2.0-preview2-wasm32-wasi/bin/ruby: cannot execute binary file: Exec format error ```
Because the binary format is different.
``` $ file /usr/bin/ruby-mri /usr/bin/ruby-mri: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=37b172d9897934e511f5e8496b7409471488a99e, for GNU/Linux 3.2.0, stripped
$ file ruby-wasm32-wasi/usr/local/ruby-3.2.0-preview2-wasm32-wasi/bin/ruby ruby-wasm32-wasi/usr/local/ruby-3.2.0-preview2-wasm32-wasi/bin/ruby: WebAssembly (wasm) binary module version 0x1 (MVP) ```
I don't think that the former would be really valuable. Unless the RPM package Ruby would make it easier in some way.
I am suggesting that "we should rather not mention WASI, because the RPM does not actually support it". That is what we did for our document about the MJIT in the past in the RHEL side, as the MJIT didn't work due to RHEL's hardening setting. Or just add note that "the Ruby RPM doesn't support the WebAssemly. If you want to use the feature, compile from the source."
Dne 09. 11. 22 v 12:34 Jun Aruga (he / him) napsal(a):
On Mon, Nov 7, 2022 at 10:44 AM Vít Ondruch vondruch@redhat.com wrote:
Dne 04. 11. 22 v 19:13 Jun Aruga (he / him) napsal(a):
I have put together the change proposal:
https://fedoraproject.org/wiki/Changes/Ruby_3.2
Please review, although with exception of "Detailed Description" chapter, where the changes are described, it is basically just copy/paste of the Ruby 3.1 change proposal.
I have marked the change as "ChangeReadyForWrangler" already. BTW everybody feel free to add yourselves as a change (co-)owner.
For the "WASI based WebAssembly support" feature, there is no way to use this feature from Ruby RPM. Users need to build Ruby from the source with a specific build target configure option. Does it make sense to show the feature on the proposal page?
Could you please elaborate? Do you suggest we should describe how to prepare that build or that we should rather not mention WASI, because the RPM does not actually support it?
Sure. First, are you ok for the part 'For the "WASI based WebAssembly support" feature, there is no way to use this feature from Ruby RPM.'?
That means https://bugs.ruby-lang.org/issues/19053#note-3
When building ruby to run on the WebAssembly runtime with `configure --host wasm32-unknown-wasi`, it works on the WebAssembly runtime (wasmtime).
$ pwd /home/jaruga/src/ruby-3.2.0-preview2_wasi_fedora $ ./autogen.sh $ ./configure LDFLAGS="-Xlinker -zstack-size=16777216" \ -prefix=/usr/local/ruby-3.2.0-preview2-wasm32-wasi \ --host wasm32-unknown-wasi \ --with-destdir=./ruby-wasm32-wasi \ --with-static-linked-ext \ --with-ext=ripper,monitor $ make $ make install $ wasmtime ruby-wasm32-wasi/usr/local/ruby-3.2.0-preview2-wasm32-wasi/bin/ruby --mapdir /::./ruby-wasm32-wasi/ -- -e 'puts RUBY_PLATFORM' wasm32-wasi
But the binary doesn't work on normal use.
$ ruby-wasm32-wasi/usr/local/ruby-3.2.0-preview2-wasm32-wasi/bin/ruby -v bash: ruby-wasm32-wasi/usr/local/ruby-3.2.0-preview2-wasm32-wasi/bin/ruby: cannot execute binary file: Exec format error $ ruby-wasm32-wasi/usr/local/ruby-3.2.0-preview2-wasm32-wasi/bin/ruby -e 'puts "a"' bash: ruby-wasm32-wasi/usr/local/ruby-3.2.0-preview2-wasm32-wasi/bin/ruby: cannot execute binary file: Exec format error
Because the binary format is different.
$ file /usr/bin/ruby-mri /usr/bin/ruby-mri: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=37b172d9897934e511f5e8496b7409471488a99e, for GNU/Linux 3.2.0, stripped $ file ruby-wasm32-wasi/usr/local/ruby-3.2.0-preview2-wasm32-wasi/bin/ruby ruby-wasm32-wasi/usr/local/ruby-3.2.0-preview2-wasm32-wasi/bin/ruby: WebAssembly (wasm) binary module version 0x1 (MVP)
Thx for explanation and useful examples.
> I don't think that the former would be really valuable. Unless the RPM > package Ruby would make it easier in some way. I am suggesting that "we should rather not mention WASI, because the RPM does not actually support it". That is what we did for our document about the MJIT in the past in the RHEL side, as the MJIT didn't work due to RHEL's hardening setting. Or just add note that "the Ruby RPM doesn't support the WebAssemly. If you want to use the feature, compile from the source."
I have dropped the section entirely. Because based on your explanation, I'd say that WebAssembly is currently out of scope, as long as we are not able to provide the WebAssembly Ruby blob.
Thx a lot. Appreciate your help.
Vít
I don't think that the former would be really valuable. Unless the RPM package Ruby would make it easier in some way.
I am suggesting that "we should rather not mention WASI, because the RPM does not actually support it". That is what we did for our document about the MJIT in the past in the RHEL side, as the MJIT didn't work due to RHEL's hardening setting. Or just add note that "the Ruby RPM doesn't support the WebAssemly. If you want to use the feature, compile from the source."
I have dropped the section entirely. Because based on your explanation, I'd say that WebAssembly is currently out of scope, as long as we are not able to provide the WebAssembly Ruby blob.
Thx a lot. Appreciate your help.
OK. That makes sense. Thanks.
I think the Ruby wasm's document could be improved. I just sent a PR to improve that.
wasm/README.md: Add a note about the Ruby built for wasm. https://github.com/ruby/ruby/pull/6707
Dne 01. 11. 22 v 14:09 Vít Ondruch napsal(a):
Dne 14. 10. 22 v 19:56 Vít Ondruch napsal(a):
Dne 13. 10. 22 v 13:49 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/10/13 0:26:
Hi again,
I have prepared update again. You can see the changes in the PR [1] I have opened (not intended to be merged, just to show the diff) and the scratch build is here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=92950720
I have not spot anything which would caught my attention. Please give it a try and let me know in case of issues.
Thx
Vít
[1] https://src.fedoraproject.org/rpms/ruby/pull-request/134
Thank you for your work.
While Pavel is trying rebuilding rubygem- packages continuously, now I tried myself rebuilding.
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/ https://copr.fedorainfracloud.org/coprs/mtasaka/heavypkg-newruby-test/
So far
- Out of 495 rubygem- packages:
- ~447 packages built successfully - ~48 failed to build
- And out of other 58 packages which has "BR: ruby-devel" or "BR:
pkgconfig(ruby)" - ~53 packages built successfully - ~5 failed to build
Just a quick glance at these (I have not checked all of these, just selected some of them)
- Removal of File.exists? / Object#=~ / "tainted"ness affects
several pacakges
- rubygem-jekyll seems to be affected by keywords / positional
argument treatment change??
By the way, is it better to create "central" bugzilla ticket to keep track of ruby32 related issues for each package?
There should be created the tracker as part of Ruby 3.2 change proposal process. So maybe I should prepare the change proposal early and we would get the tracker "for free".
I have put together the change proposal:
And the change was approved:
https://pagure.io/fesco/issue/2893
Vít
Hi again,
Here is yet another version from Friday:
https://koji.fedoraproject.org/koji/taskinfo?taskID=92978738
Nothing really special from Ruby POV, but I have enabled out-of-source build, as was previously discussed here:
https://src.fedoraproject.org/rpms/ruby/pull-request/120
https://src.fedoraproject.org/rpms/ruby/pull-request/122
So while this should not have any influence on resulting package, it might come handy when somebody wants to clean the source tree and play with e.g. different configuration options or what not.
Vít
Vít Ondruch wrote on 2022/10/17 23:24:
Hi again,
Here is yet another version from Friday:
https://koji.fedoraproject.org/koji/taskinfo?taskID=92978738
Nothing really special from Ruby POV, but I have enabled out-of-source build, as was previously discussed here:
https://src.fedoraproject.org/rpms/ruby/pull-request/120
https://src.fedoraproject.org/rpms/ruby/pull-request/122
So while this should not have any influence on resulting package, it might come handy when somebody wants to clean the source tree and play with e.g. different configuration options or what not.
Vít
Thank you.
By the way, do you have some plan to bring ruby 3.2 development rpm to f38 buildroot earlier than 2022 Christmas (say, around 2022/11/E)?
The reason I am asking here is that: * As I wrote above, ruby3.2 is to be released on 2022/12/25 (perhaps), usually we wait for this, and actually ruby mass rebuild usually begins around 2nd week of January? Then mass rebuild for whole Fedora packages (for F38) begins at 2023-01-18, so (as usual) the timing is very tight.
* Now rpm supports tilde, tilde is regarded as older than non-tilde version. So we can use, say, ruby-3.2.0~preview2-170.20221021gitabcdefg.fc38, for example, without "resetting" release number to 0.1.XXXX. Then we can set the release number of subpackages (such as rubygem-io-console) to (0.5.12-)170.gitabcdefg.fc38, so now we don't have to fight with release number, just we have to keep increasing this.
* And perhaps on 2022/11/E, I guess ruby3.2 would almost stable.
Regards, Mamoru
Dne 21. 10. 22 v 13:56 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/10/17 23:24:
Hi again,
Here is yet another version from Friday:
https://koji.fedoraproject.org/koji/taskinfo?taskID=92978738
Nothing really special from Ruby POV, but I have enabled out-of-source build, as was previously discussed here:
https://src.fedoraproject.org/rpms/ruby/pull-request/120
https://src.fedoraproject.org/rpms/ruby/pull-request/122
So while this should not have any influence on resulting package, it might come handy when somebody wants to clean the source tree and play with e.g. different configuration options or what not.
Vít
Thank you.
By the way, do you have some plan to bring ruby 3.2 development rpm to f38 buildroot earlier than 2022 Christmas (say, around 2022/11/E)?
Short answer is no.
Honestly, I don't trust Ruby upstream they will keep their ABI stable enough and I have never tried to ask what is their stance here. From my POV, with exception of the final release date, the development always appeared quite random. I remember several years the huge changes in their configuration scripts done just during the December, few days/week prior the release (which of course says nothing about ABI stability ...)
The reason I am asking here is that:
- As I wrote above, ruby3.2 is to be released on 2022/12/25 (perhaps),
usually we wait for this, and actually ruby mass rebuild usually begins around 2nd week of January? Then mass rebuild for whole Fedora packages (for F38) begins at 2023-01-18, so (as usual) the timing is very tight.
Oh, I have not checked the dates. This comes earlier and earlier :/ If it was even earlier, we could do our rebuild afterwards ;) I could ask Ben, what are his thoughts and why there are 3 weeks for mass rebuild followed with branching right away.
- Now rpm supports tilde, tilde is regarded as older than non-tilde
version. So we can use, say, ruby-3.2.0~preview2-170.20221021gitabcdefg.fc38, for example, without "resetting" release number to 0.1.XXXX. Then we can set the release number of subpackages (such as rubygem-io-console) to (0.5.12-)170.gitabcdefg.fc38, so now we don't have to fight with release number, just we have to keep increasing this.
The release number was never priority for my local experiments. But the tilde is probably something to consider. Not sure what impact it will have on the work with the archive name etc. But it could help with the Copr rebuilds and what not. Thx for pointing this out. I'll try to take 2nd look.
Vít
- And perhaps on 2022/11/E, I guess ruby3.2 would almost stable.
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, report it: https://pagure.io/fedora-infrastructure/new_issue
On Fri, Oct 21, 2022 at 3:39 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 21. 10. 22 v 13:56 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/10/17 23:24:
Hi again,
Here is yet another version from Friday:
https://koji.fedoraproject.org/koji/taskinfo?taskID=92978738
Nothing really special from Ruby POV, but I have enabled out-of-source build, as was previously discussed here:
https://src.fedoraproject.org/rpms/ruby/pull-request/120
https://src.fedoraproject.org/rpms/ruby/pull-request/122
So while this should not have any influence on resulting package, it might come handy when somebody wants to clean the source tree and play with e.g. different configuration options or what not.
Vít
Thank you.
By the way, do you have some plan to bring ruby 3.2 development rpm to f38 buildroot earlier than 2022 Christmas (say, around 2022/11/E)?
Thanks for the work. I am trying to build on the private-ruby-3.2 branch. Where is the SRPM file including the ruby-3.2.0-70bc8cc6c2.tar.xz ? Could you share?
I have been testing Ruby 3.2.0 preview2. The outcome is below. https://www.ruby-lang.org/en/news/2022/09/09/ruby-3-2-0-preview2-released/
## WebAssembly support
This is one of the new features in Ruby 3.2.0, and that is to build a Ruby source for the WebAssembly target, and then run a Ruby code on the Ruby on the Web Assembly runtime. But this feature is exclusive from the current Ruby in the Ruby RPM. When building Ruby for that, we can not run the Ruby without the WebAssembly runtime. So, I think it's not realistic to include the feature in the Ruby RPM.
See devel@ mailing list - Subject: "Packaging a cross-compilation environment (wasi-libc)" for details.
## Regexp timeout
I found a small issue on a new feature. Then it was fixed. https://bugs.ruby-lang.org/issues/19055
## YJIT support
YJIT is to improve the performance of Ruby code by using Rust. It's like MJIT (previously called JIT) by using gcc or clang.
I think adding this feature in the Ruby RPM is realistic. So, I tested this feature with the upstream Ruby source code in some cases.
Because in my understanding the YJIT is only available with the `ruby --yijt` option. It seems that it doesn't affect the current Ruby features. Possibly we need to add "BuildRequires rust cargo", and also needs a dependency rust (and cargo?) to run the `ruby --yjit`.
``` $ ./configure --enable-yjit ... $ make $ make install
$ ruby --help ... Features: gems rubygems (only for debugging, default: enabled) ... mjit C compiler-based JIT compiler (default: disabled) yjit in-process JIT compiler (default: disabled) # <= This line appears. And this feature is only enabled with the `ruby --yjit`. ...
$ ruby --yjit my_script.rb ```
See the following links for details. https://bugs.ruby-lang.org/issues/18481 https://github.com/ruby/ruby/blob/master/doc/yjit/yjit.md#installation https://github.com/Shopify/yjit-bench
Jun
-- Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic See https://www.worldtimebuddy.com/czech-republic-prague-to-utc for the timezone.
Thanks for the work. I am trying to build on the private-ruby-3.2 branch. Where is the SRPM file including the ruby-3.2.0-70bc8cc6c2.tar.xz ? Could you share?
I found the ruby-3.2.0-70bc8cc6c2.tar.xz at https://koji.fedoraproject.org/koji/taskinfo?taskID=92950720 . You already shared it.
Hi,
On 10/27/22 15:14, Jun Aruga (he / him) wrote:
On Fri, Oct 21, 2022 at 3:39 PM Vít Ondruchvondruch@redhat.com wrote:
Dne 21. 10. 22 v 13:56 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/10/17 23:24:
Hi again,
Here is yet another version from Friday:
https://koji.fedoraproject.org/koji/taskinfo?taskID=92978738
Nothing really special from Ruby POV, but I have enabled out-of-source build, as was previously discussed here:
https://src.fedoraproject.org/rpms/ruby/pull-request/120
https://src.fedoraproject.org/rpms/ruby/pull-request/122
So while this should not have any influence on resulting package, it might come handy when somebody wants to clean the source tree and play with e.g. different configuration options or what not.
Vít
Thank you.
By the way, do you have some plan to bring ruby 3.2 development rpm to f38 buildroot earlier than 2022 Christmas (say, around 2022/11/E)?
Thanks for the work. I am trying to build on the private-ruby-3.2 branch. Where is the SRPM file including the ruby-3.2.0-70bc8cc6c2.tar.xz ? Could you share?
I have been testing Ruby 3.2.0 preview2. The outcome is below. https://www.ruby-lang.org/en/news/2022/09/09/ruby-3-2-0-preview2-released/
## WebAssembly support
This is one of the new features in Ruby 3.2.0, and that is to build a Ruby source for the WebAssembly target, and then run a Ruby code on the Ruby on the Web Assembly runtime. But this feature is exclusive from the current Ruby in the Ruby RPM. When building Ruby for that, we can not run the Ruby without the WebAssembly runtime. So, I think it's not realistic to include the feature in the Ruby RPM.
I do not think any distribution will be able to reasonably support this.
From my understanding of WASM, it is required to crosscompile everything needed to run the application, so that it is usable in browser or other WASM runtimes.
It is a feature that upstream supports, which is nice from language usability perspective, but not something we are able to or want to reasonably support. Those who want to use it, need to crosscompile whole Ruby from source, as is the case with any other C application.
Or, such people can download the .src.rpm unpack it and adjust the specfile to match their needs.
I think it is comparable to mruby (the lightweight embeddable ruby): https://github.com/mruby/mruby These kinds of applications are better fine tuned by app developers themselves than the Linux distribution packagers.
See devel@ mailing list - Subject: "Packaging a cross-compilation environment (wasi-libc)" for details.
## Regexp timeout
I found a small issue on a new feature. Then it was fixed. https://bugs.ruby-lang.org/issues/19055
## YJIT support
YJIT is to improve the performance of Ruby code by using Rust. It's like MJIT (previously called JIT) by using gcc or clang.
I think adding this feature in the Ruby RPM is realistic. So, I tested this feature with the upstream Ruby source code in some cases.
Because in my understanding the YJIT is only available with the `ruby --yijt` option. It seems that it doesn't affect the current Ruby features. Possibly we need to add "BuildRequires rust cargo", and also needs a dependency rust (and cargo?) to run the `ruby --yjit`.
$ ./configure --enable-yjit ... $ make $ make install $ ruby --help ... Features: gems rubygems (only for debugging, default: enabled) ... mjit C compiler-based JIT compiler (default: disabled) yjit in-process JIT compiler (default: disabled) # <= This line appears. And this feature is only enabled with the `ruby --yjit`. ... $ ruby --yjit my_script.rb
See the following links for details. https://bugs.ruby-lang.org/issues/18481 https://github.com/ruby/ruby/blob/master/doc/yjit/yjit.md#installation
I read that document, we should only need the `%{_bindir}/rustc`. Ruby upstream was successful in keeping the production version without any external dependencies apart from base Rust libraries AFAICT.
At least that's what I understood from requirement: `... and Cargo (if you want to build in dev/debug mode)` This to me implies that cargo is only needed for dev/debug mode, which is not needed for Ruby distributed in Fedora IMO.
Another downside of yjit is that it is currently only x86_64 and aarch64 AFAICT. https://github.com/ruby/ruby/blob/master/doc/yjit/yjit.md#current-limitation...
Thanks for working on this, Jun.
Regards, Jarek
https://github.com/Shopify/yjit-bench
Jun
-- Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic Seehttps://www.worldtimebuddy.com/czech-republic-prague-to-utc for the timezone. _______________________________________________ ruby-sig mailing list --ruby-sig@lists.fedoraproject.org To unsubscribe send an email toruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o... Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue
On Thu, Oct 27, 2022 at 4:14 PM Jarek Prokop jprokop@redhat.com wrote:
Hi, On 10/27/22 15:14, Jun Aruga (he / him) wrote:
On Fri, Oct 21, 2022 at 3:39 PM Vít Ondruch vondruch@redhat.com vondruch@redhat.com wrote:
Dne 21. 10. 22 v 13:56 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/10/17 23:24:
Hi again,
Here is yet another version from Friday: https://koji.fedoraproject.org/koji/taskinfo?taskID=92978738
Nothing really special from Ruby POV, but I have enabled out-of-source build, as was previously discussed here: https://src.fedoraproject.org/rpms/ruby/pull-request/120 https://src.fedoraproject.org/rpms/ruby/pull-request/122
So while this should not have any influence on resulting package, it might come handy when somebody wants to clean the source tree and play with e.g. different configuration options or what not.
Vít
Thank you.
By the way, do you have some plan to bring ruby 3.2 development rpm to f38 buildroot earlier than 2022 Christmas (say, around 2022/11/E)?
Thanks for the work. I am trying to build on the private-ruby-3.2 branch. Where is the SRPM file including the ruby-3.2.0-70bc8cc6c2.tar.xz ? Could you share?
I have been testing Ruby 3.2.0 preview2. The outcome is below.https://www.ruby-lang.org/en/news/2022/09/09/ruby-3-2-0-preview2-released/
## WebAssembly support
This is one of the new features in Ruby 3.2.0, and that is to build a Ruby source for the WebAssembly target, and then run a Ruby code on the Ruby on the Web Assembly runtime. But this feature is exclusive from the current Ruby in the Ruby RPM. When building Ruby for that, we can not run the Ruby without the WebAssembly runtime. So, I think it's not realistic to include the feature in the Ruby RPM.
I do not think any distribution will be able to reasonably support this.
From my understanding of WASM, it is required to crosscompile everything needed to run the application, so that it is usable in browser or other WASM runtimes.
It is a feature that upstream supports, which is nice from language usability perspective, but not something we are able to or want to reasonably support. Those who want to use it, need to crosscompile whole Ruby from source, as is the case with any other C application.
Or, such people can download the .src.rpm unpack it and adjust the specfile to match their needs.
I think it is comparable to mruby (the lightweight embeddable ruby): https://github.com/mruby/mruby These kinds of applications are better fine tuned by app developers themselves than the Linux distribution packagers.
Hi Jarek, Thanks for sharing the info. For the mruby, in the past I developed an iOS application on iPad and iPhone. In the application build process, I built an Objective-C app with C or C++ library sources. The libraries are managed as static libraries. So, I guess the mruby's case is something like this. For the WASM, the application developers can build the Ruby with the WASM target when building their applications.
See devel@ mailing list - Subject: "Packaging a cross-compilation environment (wasi-libc)" for details.
## Regexp timeout
I found a small issue on a new feature. Then it was fixed.https://bugs.ruby-lang.org/issues/19055
## YJIT support
YJIT is to improve the performance of Ruby code by using Rust. It's like MJIT (previously called JIT) by using gcc or clang.
I think adding this feature in the Ruby RPM is realistic. So, I tested this feature with the upstream Ruby source code in some cases.
Because in my understanding the YJIT is only available with the `ruby --yijt` option. It seems that it doesn't affect the current Ruby features. Possibly we need to add "BuildRequires rust cargo", and also needs a dependency rust (and cargo?) to run the `ruby --yjit`.
$ ./configure --enable-yjit ... $ make $ make install $ ruby --help ... Features: gems rubygems (only for debugging, default: enabled) ... mjit C compiler-based JIT compiler (default: disabled) yjit in-process JIT compiler (default: disabled) # <= This line appears. And this feature is only enabled with the `ruby --yjit`. ... $ ruby --yjit my_script.rb
See the following links for details.https://bugs.ruby-lang.org/issues/18481https://github.com/ruby/ruby/blob/mas...
I read that document, we should only need the `%{_bindir}/rustc`. Ruby upstream was successful in keeping the production version without any external dependencies apart from base Rust libraries AFAICT.
At least that's what I understood from requirement: `... and Cargo (if you want to build in dev/debug mode)` This to me implies that cargo is only needed for dev/debug mode, which is not needed for Ruby distributed in Fedora IMO.
Another downside of yjit is that it is currently only x86_64 and aarch64 AFAICT. https://github.com/ruby/ruby/blob/master/doc/yjit/yjit.md#current-limitation...
Thanks for working on this, Jun.
Thanks for your input. I will create a pull-request to the private-ruby-3.2 branch to add the YJIT feature.
Jun
Thanks for your input. I will create a pull-request to the private-ruby-3.2 branch to add the YJIT feature.
Here is the PR.
WIP: Enable YJIT feature. https://src.fedoraproject.org/rpms/ruby/pull-request/139
I plan to test the YJIT and check the performance on the mock environment. https://github.com/Shopify/yjit-bench
Dne 21. 10. 22 v 15:33 Vít Ondruch napsal(a):
Dne 21. 10. 22 v 13:56 Mamoru TASAKA napsal(a):
- Now rpm supports tilde, tilde is regarded as older than non-tilde
version. So we can use, say, ruby-3.2.0~preview2-170.20221021gitabcdefg.fc38, for example, without "resetting" release number to 0.1.XXXX.
Looking into this, I don't think we can use the tilde easily. Yes, it would work for the `previewN` releases, but how would you envision this for regular snapshots?
So should we keep using the `preview2` suffix after the preview2 is released and up until e.g. the preview3 is out? Possibly in combination with caret?
For example given these releases:
3.2.0~20220916git6ad6994457
3.2.0~20221012git70bc8cc6c
3.2.0~preview1
the scheme would not work:
~~~
$ rpmdev-vercmp 3.2.0~20220916git6ad6994457 3.2.0~20221012git70bc8cc6c 3.2.0~20220916git6ad6994457 < 3.2.0~20221012git70bc8cc6c
$ rpmdev-vercmp 3.2.0~20221012git70bc8cc6c 3.2.0~preview1 3.2.0~20221012git70bc8cc6c > 3.2.0~preview1 ~~~
But it could be better, if the date is always first:
3.2.0~20220916git6ad6994457
3.2.0~20221012git70bc8cc6c
3.2.0~20221015preview1
3.2.0~20221101preview1^git4b1504ae0a
But I am not sure this is not overcomplicated.
So any other scheme which would work? 😇
BTW it is interesting, that it seems the guidelines suggest against using release for snapshot information [1] and actually encourages usage of the caret. This is new to me. I wish they have announced the changes.
Vít
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_tradi...
Then we can set the release number of subpackages (such as rubygem-io-console) to (0.5.12-)170.gitabcdefg.fc38, so now we don't have to fight with release number, just we have to keep increasing this.
The release number was never priority for my local experiments. But the tilde is probably something to consider. Not sure what impact it will have on the work with the archive name etc. But it could help with the Copr rebuilds and what not. Thx for pointing this out. I'll try to take 2nd look.
Vít
- And perhaps on 2022/11/E, I guess ruby3.2 would almost stable.
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, report it: https://pagure.io/fedora-infrastructure/new_issue
Vít Ondruch wrote on 2022/12/02 21:02:
Dne 21. 10. 22 v 15:33 Vít Ondruch napsal(a):
Dne 21. 10. 22 v 13:56 Mamoru TASAKA napsal(a):
- Now rpm supports tilde, tilde is regarded as older than non-tilde version.
So we can use, say, ruby-3.2.0~preview2-170.20221021gitabcdefg.fc38, for example, without "resetting" release number to 0.1.XXXX.
But it could be better, if the date is always first:
3.2.0~20220916git6ad6994457
3.2.0~20221012git70bc8cc6c
3.2.0~20221015preview1
3.2.0~20221101preview1^git4b1504ae0a
But I am not sure this is not overcomplicated.
So any other scheme which would work? 😇
Just use tilde + date + some other git / preview / or random string, I think this is easy usage.
Mamoru
Dne 02. 12. 22 v 13:11 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/12/02 21:02:
Dne 21. 10. 22 v 15:33 Vít Ondruch napsal(a):
Dne 21. 10. 22 v 13:56 Mamoru TASAKA napsal(a):
- Now rpm supports tilde, tilde is regarded as older than non-tilde
version. So we can use, say, ruby-3.2.0~preview2-170.20221021gitabcdefg.fc38, for example, without "resetting" release number to 0.1.XXXX.
But it could be better, if the date is always first:
3.2.0~20220916git6ad6994457
3.2.0~20221012git70bc8cc6c
3.2.0~20221015preview1
3.2.0~20221101preview1^git4b1504ae0a
But I am not sure this is not overcomplicated.
So any other scheme which would work? 😇
Just use tilde + date + some other git / preview / or random string, I think this is easy usage.
Ah, right. I was overthinking this. If the date is there, change from `preview` back to `git` doesn't really matter. Will look at it.
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, report it: https://pagure.io/fedora-infrastructure/new_issue
Dne 02. 12. 22 v 14:00 Vít Ondruch napsal(a):
Dne 02. 12. 22 v 13:11 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/12/02 21:02:
Dne 21. 10. 22 v 15:33 Vít Ondruch napsal(a):
Dne 21. 10. 22 v 13:56 Mamoru TASAKA napsal(a):
- Now rpm supports tilde, tilde is regarded as older than
non-tilde version. So we can use, say, ruby-3.2.0~preview2-170.20221021gitabcdefg.fc38, for example, without "resetting" release number to 0.1.XXXX.
But it could be better, if the date is always first:
3.2.0~20220916git6ad6994457
3.2.0~20221012git70bc8cc6c
3.2.0~20221015preview1
3.2.0~20221101preview1^git4b1504ae0a
But I am not sure this is not overcomplicated.
So any other scheme which would work? 😇
Just use tilde + date + some other git / preview / or random string, I think this is easy usage.
Ah, right. I was overthinking this. If the date is there, change from `preview` back to `git` doesn't really matter. Will look at it.
So this is result of my tinkering:
https://src.fedoraproject.org/rpms/ruby/c/fa665a95d97dc6da8175c682681e66a2e1...
https://koji.fedoraproject.org/koji/taskinfo?taskID=94834602
The release still must be higher then last Ruby release. It should actually be higher then the release of overlapping gems such as rubygem-{rdoc,json}. Maybe I should bump it to -300?
Vít
Hi again,
Here is yet another test build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=93660576
and the associated changes can be seen in the PR [1]. There is nothing of interested apart from enabling one test case resolved upstream (that was the trigger to prepare the update).
As always, any feedback is welcome (and don't worry, I keep your previous feedback on my mind, but also as always PRs are welcome 😉)
Vít
[1] https://src.fedoraproject.org/rpms/ruby/pull-request/134
Hi all,
Here is yet another update. This time 0436f1e15a. The changes are in private-ruby-3.2 branch in dist-git and here is the scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=94825188
The most interesting change is the PubGrub resolver [1], which is now used in Bundler instead of Molinillo.
As always, please give it a try and let me know should there be any concerns.
Vít
Hi again,
Ruby 3.2 RC 1 was released today and therefore here is yet another update:
https://koji.fedoraproject.org/koji/taskinfo?taskID=95021656
This is like 5th scratch build attempt, where all the previous failed on i686. So not sure if it succeeds. Other then that, except bundled gem updates, I have not noticed anything particularly interesting. PTAL and let me know should you face any issues.
Best,
Vít
Dne 06. 12. 22 v 19:12 Vít Ondruch napsal(a):
Hi again,
Ruby 3.2 RC 1 was released today and therefore here is yet another update:
https://koji.fedoraproject.org/koji/taskinfo?taskID=95021656
This was not really good attempt. Here is better one, while the i686 is failed again :/
https://koji.fedoraproject.org/koji/taskinfo?taskID=95043381
I might disable the MJIT test cases ....
Vít
This is like 5th scratch build attempt, where all the previous failed on i686. So not sure if it succeeds. Other then that, except bundled gem updates, I have not noticed anything particularly interesting. PTAL and let me know should you face any issues.
Best,
Vít
Hi everyone,
I am back with yet another update:
https://koji.fedoraproject.org/koji/taskinfo?taskID=95134506
There is nothing what would catch my eye. Nevertheless, there are disabled the MJIT tests on i686, because they are failing and failing. I turns out that Jarek already reported ticket against GCC, which did not get too much attention:
https://bugzilla.redhat.com/show_bug.cgi?id=2125026
And BTW, doing updates of all stable versions yesterday / today, I had to apple the same medicine to the official Rawhide build. The older releases were OKish. I won't mind if anybody tried to crack the nut and find the culprit.
Thx
Vít
Dne 07. 12. 22 v 10:42 Vít Ondruch napsal(a):
Dne 06. 12. 22 v 19:12 Vít Ondruch napsal(a):
Hi again,
Ruby 3.2 RC 1 was released today and therefore here is yet another update:
https://koji.fedoraproject.org/koji/taskinfo?taskID=95021656
This was not really good attempt. Here is better one, while the i686 is failed again :/
https://koji.fedoraproject.org/koji/taskinfo?taskID=95043381
I might disable the MJIT test cases ....
Vít
This is like 5th scratch build attempt, where all the previous failed on i686. So not sure if it succeeds. Other then that, except bundled gem updates, I have not noticed anything particularly interesting. PTAL and let me know should you face any issues.
Best,
Vít
Hi everyone,
I have noticed, that my version/release changes were not correct. IRB could not require ruby-default-gems:
https://copr.fedorainfracloud.org/coprs/vondruch/ruby-3.2/build/5126185/
Therefore I have prepared yet another update. You can grab the scratch build here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=95271437
Nothing really interesting there. Although, Bundler have dropped bundled tpmdir gem. Less bundling is always good news.
As always, let me know any feedback.
Thx
Vít
Few months ago, I have noticed some rumors about mass-prebuild tool [1]. Since Ruby 3.2 rebuild seems to be nice opportunity to test this out, I gave it a try. This is my config (there is really not much to configure ;)) :
~~~
$ cat mpb.config archs: x86_64 chroot: fedora-rawhide name: ruby-3.2 packages: ruby: src_type: file src: /home/vondruch/fedora-scm/own/ruby/ruby-3.2.0~20221212gitece6246057-174.fc38.src.rpm data: /home/vondruch/fedora-scm/own/ruby/mpb/ verbose: 1 retry: 5
~~~
And here is the resulting repository:
https://copr.fedorainfracloud.org/coprs/vondruch/ruby-3.2
And intermediate results:
~~~
Build status of reverse dependencies: — 570 out of 571 builds are done. Pending: 0 Running: 0 Success: 527 Under check: 1 Manual confirmation needed: 11 Failed: 32
~~~
I have briefly checked two failures:
1) rubygem-activesupport - https://copr.fedorainfracloud.org/coprs/vondruch/ruby-3.2/build/5131908/
Where this might be upstream cure:
https://github.com/rails/rails/commit/e4140140af5832e045bf8196d1bcbe9e5276a8...
2) webkitgtk - https://copr.fedorainfracloud.org/coprs/vondruch/ruby-3.2/build/5132009/
Obviously, the issue is with independent rubygem-json, which was not build by mass-prebuild. This is probably tricky due to rubygem-json being subpackage of ruby while there is also independent RPM.
I'll try to fix these and run another round of builds.
All in all, I am very excited about the mass-prebuild. While there are certainly areas for improvement, the tool is quite easy to setup and execute. I'll encourage everybody to give it a try. I'd say that this can be valuable for testing frameworks updates, which tends to influence huge dependency chains. Also, I have reported around ~6 tickets and the author is very responsive, so I am quite that next version will be much better (e.g. the dependency chain will be properly resolved [2]).
Vít
[1] https://gitlab.com/fedora/packager-tools/mass-prebuild
[2] https://gitlab.com/fedora/packager-tools/mass-prebuild/-/issues/56
Dne 12. 12. 22 v 22:27 Vít Ondruch napsal(a):
Hi everyone,
I have noticed, that my version/release changes were not correct. IRB could not require ruby-default-gems:
https://copr.fedorainfracloud.org/coprs/vondruch/ruby-3.2/build/5126185/
Therefore I have prepared yet another update. You can grab the scratch build here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=95271437
Nothing really interesting there. Although, Bundler have dropped bundled tpmdir gem. Less bundling is always good news.
As always, let me know any feedback.
Thx
Vít
Vít Ondruch wrote on 2022/12/13 17:29:
Obviously, the issue is with independent rubygem-json, which was not build by mass-prebuild. This is probably tricky due to rubygem-json being subpackage of ruby while there is also independent RPM.
I've recently updated rubygem-json to 2.6.3: https://koji.fedoraproject.org/koji/buildinfo?buildID=2096881
Just note that webkitgtk-2.39.2-6.fc38 is known to FTBFS with ruby3.2, -7.fc38 is needed (currently still building), see:
https://src.fedoraproject.org/rpms/webkitgtk/c/9d80218444055c571711b4d86fb5b... https://bugs.webkit.org/show_bug.cgi?id=246743 https://github.com/WebKit/WebKit/pull/7531
Regards, Mamoru
Dne 13. 12. 22 v 10:12 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/12/13 17:29:
- webkitgtk -
https://copr.fedorainfracloud.org/coprs/vondruch/ruby-3.2/build/5132009/
Obviously, the issue is with independent rubygem-json, which was not build by mass-prebuild. This is probably tricky due to rubygem-json being subpackage of ruby while there is also independent RPM.
I've recently updated rubygem-json to 2.6.3: https://koji.fedoraproject.org/koji/buildinfo?buildID=2096881
Yes, therefore it has higher NVR then the one coming from Ruby, but the mass-prebuild has not attempted the build at all. I have reported the issue here:
https://gitlab.com/fedora/packager-tools/mass-prebuild/-/issues/57
Just note that webkitgtk-2.39.2-6.fc38 is known to FTBFS with ruby3.2, -7.fc38 is needed (currently still building), see:
https://src.fedoraproject.org/rpms/webkitgtk/c/9d80218444055c571711b4d86fb5b...
https://bugs.webkit.org/show_bug.cgi?id=246743 https://github.com/WebKit/WebKit/pull/7531
Nice work, thx a lot! Apart of obviously fixing the compatibility with Ruby 3.2, this should also make the mass-prebuild run faster, because it will save the retries and check builds, which are sloooooow.
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, report it: https://pagure.io/fedora-infrastructure/new_issue
Dne 13. 12. 22 v 9:29 Vít Ondruch napsal(a):
Few months ago, I have noticed some rumors about mass-prebuild tool [1]. Since Ruby 3.2 rebuild seems to be nice opportunity to test this out, I gave it a try. This is my config (there is really not much to configure ;)) :
$ cat mpb.config archs: x86_64 chroot: fedora-rawhide name: ruby-3.2 packages: ruby: src_type: file src: /home/vondruch/fedora-scm/own/ruby/ruby-3.2.0~20221212gitece6246057-174.fc38.src.rpm data: /home/vondruch/fedora-scm/own/ruby/mpb/ verbose: 1 retry: 5
And here is the resulting repository:
https://copr.fedorainfracloud.org/coprs/vondruch/ruby-3.2
And intermediate results:
BTW the interpretation of the results is as follows:
Build status of reverse dependencies: — 570 out of 571 builds are done.
1 build is still under check, that is to figure out, if the build failure is caused by the updated Ruby or if it was already failed previously:
Pending: 0 Running: 0
Nothing is left to build in the official repo
Success: 527
Number of successful builds.
Under check: 1
One build is still running in the check repo as explained above.
Manual confirmation needed: 11
These are the packages which should deserve out attention. They used to build but does not build with Ruby 3.2
Failed: 32
These packages were already FTBFS
Vít
I have briefly checked two failures: 1) rubygem-activesupport - https://copr.fedorainfracloud.org/coprs/vondruch/ruby-3.2/build/5131908/ Where this might be upstream cure: https://github.com/rails/rails/commit/e4140140af5832e045bf8196d1bcbe9e5276a8fb 2) webkitgtk - https://copr.fedorainfracloud.org/coprs/vondruch/ruby-3.2/build/5132009/ Obviously, the issue is with independent rubygem-json, which was not build by mass-prebuild. This is probably tricky due to rubygem-json being subpackage of ruby while there is also independent RPM. I'll try to fix these and run another round of builds. All in all, I am very excited about the mass-prebuild. While there are certainly areas for improvement, the tool is quite easy to setup and execute. I'll encourage everybody to give it a try. I'd say that this can be valuable for testing frameworks updates, which tends to influence huge dependency chains. Also, I have reported around ~6 tickets and the author is very responsive, so I am quite that next version will be much better (e.g. the dependency chain will be properly resolved [2]). Vít [1] https://gitlab.com/fedora/packager-tools/mass-prebuild [2] https://gitlab.com/fedora/packager-tools/mass-prebuild/-/issues/56 Dne 12. 12. 22 v 22:27 Vít Ondruch napsal(a): > Hi everyone, > > I have noticed, that my version/release changes were not correct. IRB > could not require ruby-default-gems: > > https://copr.fedorainfracloud.org/coprs/vondruch/ruby-3.2/build/5126185/ > > Therefore I have prepared yet another update. You can grab the > scratch build here: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=95271437 > > Nothing really interesting there. Although, Bundler have dropped > bundled tpmdir gem. Less bundling is always good news. > > As always, let me know any feedback. > > Thx > > > Vít > > > >
Dne 13. 12. 22 v 9:29 Vít Ondruch napsal(a):
- rubygem-activesupport -
https://copr.fedorainfracloud.org/coprs/vondruch/ruby-3.2/build/5131908/
Where this might be upstream cure:
https://github.com/rails/rails/commit/e4140140af5832e045bf8196d1bcbe9e5276a8...
This does not help :/
https://copr.fedorainfracloud.org/coprs/vondruch/ruby-3.2/build/5132765/
I have reported this issue upstream:
https://github.com/rails/rails/issues/46712
Surprisingly, I can't see Ruby 3.2 in their CI.
Vít
Hi,
I am back again with yet another update, this time to 6af6857ecf. The changes are in dist-git and the build is here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=95591030
I am still surprised that this cycle, there are not big breakages. So there is nothing to report from my side, except that I am not convinced that the change to the tilde versions works as it is supposed to. I think that the `%{?development_release}` would need to be added not just to the Ruby version, but also to the subpackages and therefore to the Provides, etc. So if anybody tries update from the previous snapshot, please let me know your practical experience.
Vít
Vít Ondruch wrote on 2022/12/22 17:48:
Hi,
I am back again with yet another update, this time to 6af6857ecf. The changes are in dist-git and the build is here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=95591030
I am still surprised that this cycle, there are not big breakages. So there is nothing to report from my side, except that I am not convinced that the change to the tilde versions works as it is supposed to. I think that the `%{?development_release}` would need to be added not just to the Ruby version, but also to the subpackages and therefore to the Provides, etc. So if anybody tries update from the previous snapshot, please let me know your practical experience.
Vít
Well, looks like "my" copr build says that (some of) rubygem-foo pkgs building C extensions began to FTBFS with 20221223git7d700a9f5d, while 20221220git8f081d4d0 they were okay.
For examples:
rubygem-glib2 https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/package... rubygem-nokogiri https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/package... rubygem-rdiscount https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/package...
Looking at the build logs, I strongly believe this is because of this change:
https://github.com/ruby/ruby/commit/0a9544ce4ab86963dde0f3ad0b489b6a354cc8b3 Subject: [PATCH] [rubygems/rubygems] Cleanup intermediate artifacts after installing built extensions
https://github.com/rubygems/rubygems/commit/98b6a959bd
So building C extensions, .so is removed from ext/ directory, so at %check, for example doing $ ruby -Ilib:ext:. -e 'Dir.glob........' cannot find required .so file and %check fails.
So what should Fedora side srpm do? - Revert the above change on ruby (and also rubygems) - Or make every rubygem-foo pkgs building C extension to use -I%{buildroot}%{gem_extdir_mri} instead of -Iext
Regards, Mamoru
Mamoru TASAKA wrote on 2022/12/23 16:46:
Vít Ondruch wrote on 2022/12/22 17:48:
Hi,
I am back again with yet another update, this time to 6af6857ecf. The changes are in dist-git and the build is here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=95591030
I am still surprised that this cycle, there are not big breakages. So there is nothing to report from my side, except that I am not convinced that the change to the tilde versions works as it is supposed to. I think that the `%{?development_release}` would need to be added not just to the Ruby version, but also to the subpackages and therefore to the Provides, etc. So if anybody tries update from the previous snapshot, please let me know your practical experience.
Vít
Well, looks like "my" copr build says that (some of) rubygem-foo pkgs building C extensions began to FTBFS with 20221223git7d700a9f5d, while 20221220git8f081d4d0 they were okay.
For examples:
rubygem-glib2 https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/package... rubygem-nokogiri https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/package... rubygem-rdiscount https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/package...
Looking at the build logs, I strongly believe this is because of this change:
https://github.com/ruby/ruby/commit/0a9544ce4ab86963dde0f3ad0b489b6a354cc8b3 Subject: [PATCH] [rubygems/rubygems] Cleanup intermediate artifacts after installing built extensions
https://github.com/rubygems/rubygems/commit/98b6a959bd
So building C extensions, .so is removed from ext/ directory, so at %check, for example doing $ ruby -Ilib:ext:. -e 'Dir.glob........' cannot find required .so file and %check fails.
So what should Fedora side srpm do?
- Revert the above change on ruby (and also rubygems)
- Or make every rubygem-foo pkgs building C extension to use -I%{buildroot}%{gem_extdir_mri} instead of -Iext
Also, (as Vít enabled yjit the above 20221223git7d700a9f5d also enabled yjit), then rubygem-rspec-core got FTBFS with 20221223git7d700a9f5d, while with 20221223git7d700a9f5d *without* yjit, rubygem-rspec-core builds successfully.
With yjit, rubygem-rspec-core shows:
=============================================================== Failures:
1) RSpec::Core::Example#run memory leaks, see GH-321, GH-1921 releases references to the examples / their ivars Failure/Error: expect(get_all.call).to eq opts.fetch(:post_gc)
expected: [] got: ["after_all", "before_all"]
(compared using ==) # ./spec/rspec/core/example_spec.rb:469:in `expect_gc' # ./spec/rspec/core/example_spec.rb:492:in `block (4 levels) in <top (required)>' # ./spec/support/sandboxing.rb:16:in `block (3 levels) in <top (required)>' # ./spec/support/sandboxing.rb:7:in `block (2 levels) in <top (required)>'
Finished in 12.79 seconds (files took 0.47826 seconds to load) 2209 examples, 1 failure, 4 pending
Failed examples:
rspec ./spec/rspec/core/example_spec.rb:472 # RSpec::Core::Example#run memory leaks, see GH-321, GH-1921 releases references to the examples / their ivars ===============================================================
So this may mean that yjit interacts badly with GC. Would someone investigate this?
Regards, Mamoru
Dne 23. 12. 22 v 11:30 Mamoru TASAKA napsal(a):
Mamoru TASAKA wrote on 2022/12/23 16:46:
Vít Ondruch wrote on 2022/12/22 17:48:
Hi,
I am back again with yet another update, this time to 6af6857ecf. The changes are in dist-git and the build is here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=95591030
I am still surprised that this cycle, there are not big breakages. So there is nothing to report from my side, except that I am not convinced that the change to the tilde versions works as it is supposed to. I think that the `%{?development_release}` would need to be added not just to the Ruby version, but also to the subpackages and therefore to the Provides, etc. So if anybody tries update from the previous snapshot, please let me know your practical experience.
Vít
Well, looks like "my" copr build says that (some of) rubygem-foo pkgs building C extensions began to FTBFS with 20221223git7d700a9f5d, while 20221220git8f081d4d0 they were okay.
For examples:
rubygem-glib2 https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/package... rubygem-nokogiri https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/package... rubygem-rdiscount https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/package...
Looking at the build logs, I strongly believe this is because of this change:
https://github.com/ruby/ruby/commit/0a9544ce4ab86963dde0f3ad0b489b6a354cc8b3
Subject: [PATCH] [rubygems/rubygems] Cleanup intermediate artifacts after installing built extensions
https://github.com/rubygems/rubygems/commit/98b6a959bd
So building C extensions, .so is removed from ext/ directory, so at %check, for example doing $ ruby -Ilib:ext:. -e 'Dir.glob........' cannot find required .so file and %check fails.
So what should Fedora side srpm do?
- Revert the above change on ruby (and also rubygems)
- Or make every rubygem-foo pkgs building C extension to use
-I%{buildroot}%{gem_extdir_mri} instead of -Iext
Also, (as Vít enabled yjit the above 20221223git7d700a9f5d also enabled yjit), then rubygem-rspec-core got FTBFS with 20221223git7d700a9f5d, while with 20221223git7d700a9f5d *without* yjit, rubygem-rspec-core builds successfully.
With yjit, rubygem-rspec-core shows:
=============================================================== Failures:
1) RSpec::Core::Example#run memory leaks, see GH-321, GH-1921 releases references to the examples / their ivars Failure/Error: expect(get_all.call).to eq opts.fetch(:post_gc) expected: [] got: ["after_all", "before_all"] (compared using ==) # ./spec/rspec/core/example_spec.rb:469:in `expect_gc' # ./spec/rspec/core/example_spec.rb:492:in `block (4 levels) in <top (required)>' # ./spec/support/sandboxing.rb:16:in `block (3 levels) in <top (required)>' # ./spec/support/sandboxing.rb:7:in `block (2 levels) in <top (required)>'
Finished in 12.79 seconds (files took 0.47826 seconds to load) 2209 examples, 1 failure, 4 pending
Failed examples:
rspec ./spec/rspec/core/example_spec.rb:472 # RSpec::Core::Example#run memory leaks, see GH-321, GH-1921 releases references to the examples / their ivars ===============================================================
So this may mean that yjit interacts badly with GC. Would someone investigate this?
I would not blame YJIT at first. There is something fishy with GC:
https://bugs.ruby-lang.org/issues/19248
Not sure if it might be related or not. Will need to take closer look.
Vít
Dne 23. 12. 22 v 13:59 Vít Ondruch napsal(a):
Dne 23. 12. 22 v 11:30 Mamoru TASAKA napsal(a):
Mamoru TASAKA wrote on 2022/12/23 16:46:
Vít Ondruch wrote on 2022/12/22 17:48:
Hi,
I am back again with yet another update, this time to 6af6857ecf. The changes are in dist-git and the build is here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=95591030
I am still surprised that this cycle, there are not big breakages. So there is nothing to report from my side, except that I am not convinced that the change to the tilde versions works as it is supposed to. I think that the `%{?development_release}` would need to be added not just to the Ruby version, but also to the subpackages and therefore to the Provides, etc. So if anybody tries update from the previous snapshot, please let me know your practical experience.
Vít
Well, looks like "my" copr build says that (some of) rubygem-foo pkgs building C extensions began to FTBFS with 20221223git7d700a9f5d, while 20221220git8f081d4d0 they were okay.
For examples:
rubygem-glib2 https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/package... rubygem-nokogiri https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/package... rubygem-rdiscount https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/package...
Looking at the build logs, I strongly believe this is because of this change:
https://github.com/ruby/ruby/commit/0a9544ce4ab86963dde0f3ad0b489b6a354cc8b3
Subject: [PATCH] [rubygems/rubygems] Cleanup intermediate artifacts after installing built extensions
https://github.com/rubygems/rubygems/commit/98b6a959bd
So building C extensions, .so is removed from ext/ directory, so at %check, for example doing $ ruby -Ilib:ext:. -e 'Dir.glob........' cannot find required .so file and %check fails.
So what should Fedora side srpm do?
- Revert the above change on ruby (and also rubygems)
- Or make every rubygem-foo pkgs building C extension to use
-I%{buildroot}%{gem_extdir_mri} instead of -Iext
Also, (as Vít enabled yjit the above 20221223git7d700a9f5d also enabled yjit), then rubygem-rspec-core got FTBFS with 20221223git7d700a9f5d, while with 20221223git7d700a9f5d *without* yjit, rubygem-rspec-core builds successfully.
With yjit, rubygem-rspec-core shows:
=============================================================== Failures:
1) RSpec::Core::Example#run memory leaks, see GH-321, GH-1921 releases references to the examples / their ivars Failure/Error: expect(get_all.call).to eq opts.fetch(:post_gc) expected: [] got: ["after_all", "before_all"] (compared using ==) # ./spec/rspec/core/example_spec.rb:469:in `expect_gc' # ./spec/rspec/core/example_spec.rb:492:in `block (4 levels) in <top (required)>' # ./spec/support/sandboxing.rb:16:in `block (3 levels) in <top (required)>' # ./spec/support/sandboxing.rb:7:in `block (2 levels) in <top (required)>'
Finished in 12.79 seconds (files took 0.47826 seconds to load) 2209 examples, 1 failure, 4 pending
Failed examples:
rspec ./spec/rspec/core/example_spec.rb:472 # RSpec::Core::Example#run memory leaks, see GH-321, GH-1921 releases references to the examples / their ivars ===============================================================
So this may mean that yjit interacts badly with GC. Would someone investigate this?
I would not blame YJIT at first.
Trying myself, I can confirm that disabling YJIT makes the test succeed. I still find hard to believe it. Reported here:
https://bugs.ruby-lang.org/issues/19254
Thx for spotting this.
Vít
There is something fishy with GC:
https://bugs.ruby-lang.org/issues/19248
Not sure if it might be related or not. Will need to take closer look.
Vít
Dne 23. 12. 22 v 8:46 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/12/22 17:48:
Hi,
I am back again with yet another update, this time to 6af6857ecf. The changes are in dist-git and the build is here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=95591030
I am still surprised that this cycle, there are not big breakages. So there is nothing to report from my side, except that I am not convinced that the change to the tilde versions works as it is supposed to. I think that the `%{?development_release}` would need to be added not just to the Ruby version, but also to the subpackages and therefore to the Provides, etc. So if anybody tries update from the previous snapshot, please let me know your practical experience.
Vít
Well, looks like "my" copr build says that (some of) rubygem-foo pkgs building C extensions began to FTBFS with 20221223git7d700a9f5d, while 20221220git8f081d4d0 they were okay.
For examples:
rubygem-glib2 https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/package... rubygem-nokogiri https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/package... rubygem-rdiscount https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/package...
Looking at the build logs, I strongly believe this is because of this change:
https://github.com/ruby/ruby/commit/0a9544ce4ab86963dde0f3ad0b489b6a354cc8b3
Subject: [PATCH] [rubygems/rubygems] Cleanup intermediate artifacts after installing built extensions
https://github.com/rubygems/rubygems/commit/98b6a959bd
So building C extensions, .so is removed from ext/ directory, so at %check, for example doing $ ruby -Ilib:ext:. -e 'Dir.glob........' cannot find required .so file and %check fails.
So what should Fedora side srpm do?
- Revert the above change on ruby (and also rubygems)
- Or make every rubygem-foo pkgs building C extension to use
-I%{buildroot}%{gem_extdir_mri} instead of -Iext
The latter is the approach we use on various places (just random references):
https://src.fedoraproject.org/rpms/rubygem-bcrypt/blob/rawhide/f/rubygem-bcr...
https://src.fedoraproject.org/rpms/rubygem-bindex/blob/rawhide/f/rubygem-bin...
https://src.fedoraproject.org/rpms/rubygem-json/blob/rawhide/f/rubygem-json....
I don't think that `-Iext` was ever optimal, because that is never the place from where the extension is used. It would be even much better, if RubyGems used out of source build, somewhere in `/tmp` or so (there is still room for improvement :)).
Vít
P.S. it is getting closer to the release, time for subtle breaking changes :D
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, report it: https://pagure.io/fedora-infrastructure/new_issue
Vít Ondruch wrote on 2022/12/23 22:30:
Dne 23. 12. 22 v 8:46 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/12/22 17:48:
Hi,
I am back again with yet another update, this time to 6af6857ecf. The changes are in dist-git and the build is here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=95591030
I am still surprised that this cycle, there are not big breakages. So there is nothing to report from my side, except that I am not convinced that the change to the tilde versions works as it is supposed to. I think that the `%{?development_release}` would need to be added not just to the Ruby version, but also to the subpackages and therefore to the Provides, etc. So if anybody tries update from the previous snapshot, please let me know your practical experience.
Vít
Well, looks like "my" copr build says that (some of) rubygem-foo pkgs building C extensions began to FTBFS with 20221223git7d700a9f5d, while 20221220git8f081d4d0 they were okay.
For examples:
rubygem-glib2 https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/package... rubygem-nokogiri https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/package... rubygem-rdiscount https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/package...
Looking at the build logs, I strongly believe this is because of this change:
https://github.com/ruby/ruby/commit/0a9544ce4ab86963dde0f3ad0b489b6a354cc8b3 Subject: [PATCH] [rubygems/rubygems] Cleanup intermediate artifacts after installing built extensions
https://github.com/rubygems/rubygems/commit/98b6a959bd
So building C extensions, .so is removed from ext/ directory, so at %check, for example doing $ ruby -Ilib:ext:. -e 'Dir.glob........' cannot find required .so file and %check fails.
So what should Fedora side srpm do?
- Revert the above change on ruby (and also rubygems)
- Or make every rubygem-foo pkgs building C extension to use -I%{buildroot}%{gem_extdir_mri} instead of -Iext
The latter is the approach we use on various places (just random references):
https://src.fedoraproject.org/rpms/rubygem-bcrypt/blob/rawhide/f/rubygem-bcr...
https://src.fedoraproject.org/rpms/rubygem-bindex/blob/rawhide/f/rubygem-bin...
https://src.fedoraproject.org/rpms/rubygem-json/blob/rawhide/f/rubygem-json....
I don't think that `-Iext` was ever optimal, because that is never the place from where the extension is used. It would be even much better, if RubyGems used out of source build, somewhere in `/tmp` or so (there is still room for improvement :)).
Okay, I've fixed this side issue (i.e. use %{buildroot}%{gem_extdir_mri} instead of ext).
Regards, Mamoru
Vít
P.S. it is getting closer to the release, time for subtle breaking changes :D
Regards, Mamoru
Dne 26. 12. 22 v 9:13 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/12/23 22:30:
Dne 23. 12. 22 v 8:46 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/12/22 17:48:
Hi,
I am back again with yet another update, this time to 6af6857ecf. The changes are in dist-git and the build is here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=95591030
I am still surprised that this cycle, there are not big breakages. So there is nothing to report from my side, except that I am not convinced that the change to the tilde versions works as it is supposed to. I think that the `%{?development_release}` would need to be added not just to the Ruby version, but also to the subpackages and therefore to the Provides, etc. So if anybody tries update from the previous snapshot, please let me know your practical experience.
Vít
Well, looks like "my" copr build says that (some of) rubygem-foo pkgs building C extensions began to FTBFS with 20221223git7d700a9f5d, while 20221220git8f081d4d0 they were okay.
For examples:
rubygem-glib2 https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/package... rubygem-nokogiri https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/package... rubygem-rdiscount https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/package...
Looking at the build logs, I strongly believe this is because of this change:
https://github.com/ruby/ruby/commit/0a9544ce4ab86963dde0f3ad0b489b6a354cc8b3
Subject: [PATCH] [rubygems/rubygems] Cleanup intermediate artifacts after installing built extensions
https://github.com/rubygems/rubygems/commit/98b6a959bd
So building C extensions, .so is removed from ext/ directory, so at %check, for example doing $ ruby -Ilib:ext:. -e 'Dir.glob........' cannot find required .so file and %check fails.
So what should Fedora side srpm do?
- Revert the above change on ruby (and also rubygems)
- Or make every rubygem-foo pkgs building C extension to use
-I%{buildroot}%{gem_extdir_mri} instead of -Iext
The latter is the approach we use on various places (just random references):
https://src.fedoraproject.org/rpms/rubygem-bcrypt/blob/rawhide/f/rubygem-bcr...
https://src.fedoraproject.org/rpms/rubygem-bindex/blob/rawhide/f/rubygem-bin...
https://src.fedoraproject.org/rpms/rubygem-json/blob/rawhide/f/rubygem-json....
I don't think that `-Iext` was ever optimal, because that is never the place from where the extension is used. It would be even much better, if RubyGems used out of source build, somewhere in `/tmp` or so (there is still room for improvement :)).
Okay, I've fixed this side issue (i.e. use %{buildroot}%{gem_extdir_mri} instead of ext).
Just looking at the change [1] a few ideas come to my mind:
* Using `%{buildroot}` is inconsistent, because the rest of the code is in `%{_builddir}`. That is the reason I am using `$(dirs +1)%{gem_extdir_mri}` which admittedly is not readable neither universal. Maybe we could use `%{_builddir}/%{buildsubdir}` instead, but I am not sure under what circumstances is the `%{buildsubdir}` defined (it is not always defined AFAIK).
* Maybe we are doing it wrong and we could use help of RubyGems + `GEM_PATH` and let them figure out the path 🤔
Vít
[1] https://src.fedoraproject.org/rpms/rubygem-gtk3/c/a57c4e7add2e5bcd753e2f12d9...
Regards, Mamoru
Vít
P.S. it is getting closer to the release, time for subtle breaking changes :D
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, report it: https://pagure.io/fedora-infrastructure/new_issue
Hi,
Yet another update. This time to c5eefb7f37. The changes are in dist-git and here is the scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=95623134
Nothing particularly interesting on the Ruby side. Nevertheless, I have tried to convert the licenses into SPDX, creating "Public Domain" license review ticket along the way:
https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/145
I have started fresh rebuild of dependencies here:
https://copr.fedorainfracloud.org/coprs/vondruch/ruby-3.2/builds/
@Mamoru, going to look at your last comments now :)
Vít
Hi again,
So here is the official Ruby 3.2 build (randomly failed on aarch64 it seems):
https://koji.fedoraproject.org/koji/taskinfo?taskID=95722738
The changes are in dist-git as always.
Of course there needed to be some last second changes which break stuff:
https://bugs.ruby-lang.org/issues/19297
https://bugs.ruby-lang.org/issues/19298
But otherwise nothing really striking.
Now I'll probably do a few more tests and prepare official PR against Rawhide, so we can start with the rebuild soon.
Vít
ruby-sig@lists.fedoraproject.org