Dne 26. 12. 22 v 9:13 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/12/23 22:30:
>
> Dne 23. 12. 22 v 8:46 Mamoru TASAKA napsal(a):
>> 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
>
>
> The latter is the approach we use on various places (just random
> references):
>
>
https://src.fedoraproject.org/rpms/rubygem-bcrypt/blob/rawhide/f/rubygem-...
>
>
>
https://src.fedoraproject.org/rpms/rubygem-bindex/blob/rawhide/f/rubygem-...
>
>
>
https://src.fedoraproject.org/rpms/rubygem-json/blob/rawhide/f/rubygem-js...
>
>
> I don't think that `-Iext` was ever optimal, because that is never
> the place from where the extension is used. It would be even much
> better, if RubyGems used out of source build, somewhere in `/tmp` or
> so (there is still room for improvement :)).
>
Okay, I've fixed this side issue (i.e. use
%{buildroot}%{gem_extdir_mri} instead of ext).
Just looking at the change [1] a few ideas come to my mind:
* Using `%{buildroot}` is inconsistent, because the rest of the code is
in `%{_builddir}`. That is the reason I am using `$(dirs
+1)%{gem_extdir_mri}` which admittedly is not readable neither
universal. Maybe we could use `%{_builddir}/%{buildsubdir}` instead, but
I am not sure under what circumstances is the `%{buildsubdir}` defined
(it is not always defined AFAIK).
* Maybe we are doing it wrong and we could use help of RubyGems +
`GEM_PATH` and let them figure out the path 🤔
Vít
[1]
Regards,
Mamoru
>
> Vít
>
> P.S. it is getting closer to the release, time for subtle breaking
> changes :D
>
>>
>> Regards,
>> Mamoru
_______________________________________________
ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-leave(a)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.fedoraprojec...
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue