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/pack...
>> rubygem-nokogiri
>>
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/pack...
>> rubygem-rdiscount
>>
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/pack...
>>
>> 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:
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