On Fri, Sep 23, 2022 at 1:02 PM Vít Ondruch <vondruch(a)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(a)redhat.com> wrote:
>
>>
>>
>> On Mon, Sep 19, 2022 at 6:42 PM Vít Ondruch <vondruch(a)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(a)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/8d26c0c202d3c098478fe17067a12b803504187...
>
>
>
https://github.com/ruby/ruby/blob/a78c733cc32cc3da3796cbf65da21cdd40c6323...
>
> 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: