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
Regards,
Mamoru