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=95591030I 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ítWell, 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-glib2/ rubygem-nokogiri https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/package/rubygem-nokogiri/ rubygem-rdiscount https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test/package/rubygem-rdiscount/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 afterinstalling built extensions https://github.com/rubygems/rubygems/commit/98b6a959bdSo 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 -IextAlso, (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 ivarsFailure/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
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ 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
