On Fri, Sep 23, 2022 at 1:02 PM Vít Ondruch <vondr...@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 <pval...@redhat.com> wrote: > >> >> >> On Mon, Sep 19, 2022 at 6:42 PM Vít Ondruch <vondr...@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 <vondr...@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). Pavel > > Vít > > > > > _______________________________________________ > ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org > To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue >
_______________________________________________ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
