Hi,
It is again the time to look at where Ruby 3.3 development stands. So here is PR with the changes:
https://src.fedoraproject.org/rpms/ruby/pull-request/159
and scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=106071236
You probably remember, that I used to create the PR from private branch. However this time I have decided to create the PR from my fork. This should allow me to force pushes, which should help me in doing rebases and possibly extracting some changes into stable branches.
Now let me list some modifications in random order.
* `%gem_spec` macro with options:
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/blob/77c580dfa85f921d9...
This is my initial version, just to enable to use this macro in ruby.spec. I think I'll similarly modify all the related macros. While they'll be more complex, their use in ruby.spec will outweigh that. And I should add some documentation ...
BTW there are several possibilities in choosing how complex/flexible this macro will be and I think this is one of the changes which could be backported to Ruby 3.2. So feedback is appreciated. Looking at the macro, this bit `%{?1:%{expand:%{%{1}_version}}}%{!?1:%{version}}` is probably not very good idea for possible use in rubygem-*.gemspec.
* There is still problem with syntax-suggest test suite, which tries to download some pieces from interned :/ However, I have replaced the "revert" patches with custom patch disabling the syntax-suggest test case in a hope that this will be easier to maintain. Those previous patches weren't. Trying to modify them for Ruby 3.3 proved to be problematic.
* I have reordered build dependencies a bit, trying to group them
* readline-devel was dropped, since upstream replaced readline-ext by reline
* Dependency on Rust is still optional and does not influence too much. I don't think it even impacts `%files` section. That is still good.
* MJIT was replaced by RJIT. I have not tested functionality, but at least it resolves some issues with misplaced files.
* For a while, since upstream migrated from minitest back to test-unit, the skipped test were not easily identifiable. Luckily, I have discovered `--show-skip` option, which lists the skipped tests. And there are some issues to resolve, upstream as well as downstream. I have yet to investigate them.
* Racc is now bundled gem instead of default gem. That means it will live in ruby-bundled-gems. I don't think this should have impact on anything. However, it made me realize, that we don't have `bundled` provides for the bundled/default gems. This is a bit annoying, because maintaining this list is PITA. I have to explore what improvements were done in the generators area in RPM.
And this is mostly it. Please note that I did very little (or possibly even less than that ;) ) testing. So be careful. And as always, looking for your feedback here, in BZ, or PR.
Best,
Vít
Dne 12. 09. 23 v 10:08 Vít Ondruch napsal(a):
- Racc is now bundled gem instead of default gem. That means it will
live in ruby-bundled-gems. I don't think this should have impact on anything.
Actually, this might be problem:
https://github.com/ruby/rdoc/pull/1019
I have not verified the changes, but it seems that has the capability in embedding itself into code generated by it. There are several issues I can see:
1) The RDoc will essentially bundle Racc, therefore it should have bundled provide.
2) The generated code will be bigger.
3) If there is some problem with Racc, we will need to regenerate the libraries (OTOH, not sure what was backward compatibility of Racc with the generated code ...)
Vít
Hello,
I've checked the PR as well - all checks out :)
I'll build it in my COPR ruby-testing repo... will keep you posted.
On Tue, Sep 12, 2023 at 10:17 AM Vít Ondruch vondruch@redhat.com wrote:
Dne 12. 09. 23 v 10:08 Vít Ondruch napsal(a):
- Racc is now bundled gem instead of default gem. That means it will
live in ruby-bundled-gems. I don't think this should have impact on anything.
Actually, this might be problem:
https://github.com/ruby/rdoc/pull/1019
I have not verified the changes, but it seems that has the capability in embedding itself into code generated by it. There are several issues I can see:
- The RDoc will essentially bundle Racc, therefore it should have
bundled provide.
I see.
The generated code will be bigger.
If there is some problem with Racc, we will need to regenerate the
libraries (OTOH, not sure what was backward compatibility of Racc with the generated code ...)
Oh no...
Vít
Otherwise it sounds great! Thanks for the work!
Pavel
Testing upgrade, I get:
``` # dnf update ruby Last metadata expiration check: 3:45:31 ago on Wed 13 Sep 2023 12:42:06 PM UTC. Dependencies resolved.
Problem: problem with installed package rubygem-json-2.6.3-204.fc39.x86_64 - package rubygem-json-2.6.3-204.fc39.x86_64 from @System requires libruby.so.3.2()(64bit), but none of the providers can be installed - package rubygem-json-2.6.3-204.fc39.x86_64 from rawhide requires libruby.so.3.2()(64bit), but none of the providers can be installed - cannot install both ruby-libs-3.3.0~20230905git7c8932365f-182.fc40.x86_64 from copr:copr.fedorainfracloud.org:pvalena:ruby-testing and ruby-libs-3.2.2-181.fc39.x86_64 from @System - cannot install both ruby-libs-3.2.2-181.fc39.x86_64 from rawhide and ruby-libs-3.3.0~20230905git7c8932365f-182.fc40.x86_64 from copr:copr.fedorainfracloud.org:pvalena:ruby-testing - package ruby-3.3.0~20230905git7c8932365f-182.fc40.x86_64 from copr:copr.fedorainfracloud.org:pvalena:ruby-testing requires libruby.so.3.3()(64bit), but none of the providers can be installed - package ruby-3.3.0~20230905git7c8932365f-182.fc40.x86_64 from copr:copr.fedorainfracloud.org:pvalena:ruby-testing requires ruby-libs(x86-64) = 3.3.0~20230905git7c8932365f-182.fc40, but none of the providers can be installed - cannot install the best update candidate for package ruby-3.2.2-181.fc39.x86_64 ===================================================================================================== Package Arch Version Repository Size ===================================================================================================== Skipping packages with conflicts: (add '--best --allowerasing' to command line to force their upgrade): ruby-libs x86_64 3.3.0~20230905git7c8932365f-182.fc40
copr:copr.fedorainfracloud.org:pvalena:ruby-testing 3.8 M Skipping packages with broken dependencies: ruby x86_64 3.3.0~20230905git7c8932365f-182.fc40
copr:copr.fedorainfracloud.org:pvalena:ruby-testing 42 k
Transaction Summary ===================================================================================================== Skip 2 Packages
Nothing to do. Complete! ```
While using suggested options ('--allowerasing --best') installs ruby 3.3, json gem is downgraded and then next update says:
``` # dnf update 'ruby*' Last metadata expiration check: 3:49:05 ago on Wed 13 Sep 2023 12:42:06 PM UTC. Dependencies resolved.
Problem: package rubygem-json-2.6.3-204.fc39.x86_64 from rawhide requires libruby.so.3.2()(64bit), but none of the providers can be installed - cannot install both ruby-libs-3.2.2-181.fc39.x86_64 from rawhide and ruby-libs-3.3.0~20230905git7c8932365f-182.fc40.x86_64 from @System - cannot install the best update candidate for package rubygem-json-2.6.3-182.fc40.x86_64 - cannot install the best update candidate for package ruby-libs-3.3.0~20230905git7c8932365f-182.fc40.x86_64 ===================================================================================================== Package Arch Version Repository Size ===================================================================================================== Upgrading: rubygem-bundler noarch 2.5.0.dev-182.fc40 copr:copr.fedorainfracloud.org:pvalena:ruby-testing 382 k rubygem-rdoc noarch 6.5.0-182.fc40 copr:copr.fedorainfracloud.org:pvalena:ruby-testing 464 k Skipping packages with conflicts: (add '--best --allowerasing' to command line to force their upgrade): ruby-libs x86_64 3.2.2-181.fc39 rawhide 4.0 M Skipping packages with broken dependencies: rubygem-json x86_64 2.6.3-204.fc39 rawhide 69 k
Transaction Summary ===================================================================================================== Upgrade 2 Packages Skip 2 Packages
``` Note the bundler and rdoc gems were not updated with the ruby update (I hope they would still work ok).
Standalone install works fine & the test suite even passes (or fails or errors the same as with Ruby 3.2).
Regards, Pavel
On Tue, Sep 12, 2023 at 5:53 PM Pavel Valena pvalena@redhat.com wrote:
Hello,
I've checked the PR as well - all checks out :)
I'll build it in my COPR ruby-testing repo... will keep you posted.
On Tue, Sep 12, 2023 at 10:17 AM Vít Ondruch vondruch@redhat.com wrote:
Dne 12. 09. 23 v 10:08 Vít Ondruch napsal(a):
- Racc is now bundled gem instead of default gem. That means it will
live in ruby-bundled-gems. I don't think this should have impact on anything.
Actually, this might be problem:
https://github.com/ruby/rdoc/pull/1019
I have not verified the changes, but it seems that has the capability in embedding itself into code generated by it. There are several issues I can see:
- The RDoc will essentially bundle Racc, therefore it should have
bundled provide.
I see.
The generated code will be bigger.
If there is some problem with Racc, we will need to regenerate the
libraries (OTOH, not sure what was backward compatibility of Racc with the generated code ...)
Oh no...
Vít
Otherwise it sounds great! Thanks for the work!
Pavel
Well, this is kind of expected and the `--best --allowerasing` (actually the `--best` could be enough) is probably the right solution in this situation. Let me explain.
If we build Ruby 3.3 as an official build for Fedora, the first step after building Ruby would be to take the independent rubygem-json, bump it and build against Ruby 3.3. That would resolve the issue. However, this is just test build, so I don't do that. But it would be probably the right thing to do for your Copr repo. That would be helpful for two reasons:
1) Given the above, it is important to ensure that the rubygem-json rebuild is possible and that there is e.g. no circular dependency which would prohibit this.
2) It would allow to test the upgrade scenario as you did.
Vít
Dne 13. 09. 23 v 18:38 Pavel Valena napsal(a):
Testing upgrade, I get:
# dnf update ruby Last metadata expiration check: 3:45:31 ago on Wed 13 Sep 2023 12:42:06 PM UTC. Dependencies resolved. Problem: problem with installed package rubygem-json-2.6.3-204.fc39.x86_64 - package rubygem-json-2.6.3-204.fc39.x86_64 from @System requires libruby.so.3.2()(64bit), but none of the providers can be installed - package rubygem-json-2.6.3-204.fc39.x86_64 from rawhide requires libruby.so.3.2()(64bit), but none of the providers can be installed - cannot install both ruby-libs-3.3.0~20230905git7c8932365f-182.fc40.x86_64 from copr:copr.fedorainfracloud.org:pvalena:ruby-testing and ruby-libs-3.2.2-181.fc39.x86_64 from @System - cannot install both ruby-libs-3.2.2-181.fc39.x86_64 from rawhide and ruby-libs-3.3.0~20230905git7c8932365f-182.fc40.x86_64 from copr:copr.fedorainfracloud.org:pvalena:ruby-testing - package ruby-3.3.0~20230905git7c8932365f-182.fc40.x86_64 from copr:copr.fedorainfracloud.org:pvalena:ruby-testing requires libruby.so.3.3()(64bit), but none of the providers can be installed - package ruby-3.3.0~20230905git7c8932365f-182.fc40.x86_64 from copr:copr.fedorainfracloud.org:pvalena:ruby-testing requires ruby-libs(x86-64) = 3.3.0~20230905git7c8932365f-182.fc40, but none of the providers can be installed - cannot install the best update candidate for package ruby-3.2.2-181.fc39.x86_64 ===================================================================================================== Package Arch Version Repository Size ===================================================================================================== Skipping packages with conflicts: (add '--best --allowerasing' to command line to force their upgrade): ruby-libs x86_64 3.3.0~20230905git7c8932365f-182.fc40 copr:copr.fedorainfracloud.org:pvalena:ruby-testing 3.8 M Skipping packages with broken dependencies: ruby x86_64 3.3.0~20230905git7c8932365f-182.fc40 copr:copr.fedorainfracloud.org:pvalena:ruby-testing 42 k Transaction Summary ===================================================================================================== Skip 2 Packages Nothing to do. Complete!While using suggested options ('--allowerasing --best') installs ruby 3.3, json gem is downgraded and then next update says:
# dnf update 'ruby*' Last metadata expiration check: 3:49:05 ago on Wed 13 Sep 2023 12:42:06 PM UTC. Dependencies resolved. Problem: package rubygem-json-2.6.3-204.fc39.x86_64 from rawhide requires libruby.so.3.2()(64bit), but none of the providers can be installed - cannot install both ruby-libs-3.2.2-181.fc39.x86_64 from rawhide and ruby-libs-3.3.0~20230905git7c8932365f-182.fc40.x86_64 from @System - cannot install the best update candidate for package rubygem-json-2.6.3-182.fc40.x86_64 - cannot install the best update candidate for package ruby-libs-3.3.0~20230905git7c8932365f-182.fc40.x86_64 ===================================================================================================== Package Arch Version Repository Size ===================================================================================================== Upgrading: rubygem-bundler noarch 2.5.0.dev-182.fc40 copr:copr.fedorainfracloud.org:pvalena:ruby-testing 382 k rubygem-rdoc noarch 6.5.0-182.fc40 copr:copr.fedorainfracloud.org:pvalena:ruby-testing 464 k Skipping packages with conflicts: (add '--best --allowerasing' to command line to force their upgrade): ruby-libs x86_64 3.2.2-181.fc39 rawhide 4.0 M Skipping packages with broken dependencies: rubygem-json x86_64 2.6.3-204.fc39 rawhide 69 k Transaction Summary ===================================================================================================== Upgrade 2 Packages Skip 2 PackagesNote the bundler and rdoc gems were not updated with the ruby update (I hope they would still work ok).
Standalone install works fine & the test suite even passes (or fails or errors the same as with Ruby 3.2).
Regards, Pavel
On Tue, Sep 12, 2023 at 5:53 PM Pavel Valena pvalena@redhat.com wrote:
Hello, I've checked the PR as well - all checks out :) I'll build it in my COPR ruby-testing repo... will keep you posted. On Tue, Sep 12, 2023 at 10:17 AM Vít Ondruch <vondruch@redhat.com> wrote: Dne 12. 09. 23 v 10:08 Vít Ondruch napsal(a): > > * Racc is now bundled gem instead of default gem. That means it will > live in ruby-bundled-gems. I don't think this should have impact on > anything. Actually, this might be problem: https://github.com/ruby/rdoc/pull/1019 I have not verified the changes, but it seems that has the capability in embedding itself into code generated by it. There are several issues I can see: 1) The RDoc will essentially bundle Racc, therefore it should have bundled provide. I see. 2) The generated code will be bigger. 3) If there is some problem with Racc, we will need to regenerate the libraries (OTOH, not sure what was backward compatibility of Racc with the generated code ...) Oh no... Vít Otherwise it sounds great! Thanks for the work! Pavel
ruby-sig mailing list --ruby-sig@lists.fedoraproject.org To unsubscribe send an email toruby-sig-leave@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.o... Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue
Hello, Vít:
Thank you for initial work for ruby 3.3 .
Vít Ondruch wrote on 2023/09/12 17:08:
- `%gem_spec` macro with options:
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/blob/77c580dfa85f921d9...
This is my initial version, just to enable to use this macro in ruby.spec. I think I'll similarly modify all the related macros. While they'll be more complex, their use in ruby.spec will outweigh that. And I should add some documentation ...
BTW there are several possibilities in choosing how complex/flexible this macro will be and I think this is one of the changes which could be backported to Ruby 3.2. So feedback is appreciated. Looking at the macro, this bit `%{?1:%{expand:%{%{1}_version}}}%{!?1:%{version}}` is probably not very good idea for possible use in rubygem-*.gemspec.
I think this should be :
%gem_spec(d) %{gem_dir}/specifications%{?-d:/default}/%{?1}%{!?1:%{gem_name}}-%{?1:%{expand:%{%{1}_version}}}%{!?1:%{version}}%{?prerelease}.gemspec
(instead of %gem_spec(d) %{gem_dir}/specifications%{?-d:/default}/%{1}..... )
Otherwise, for example trying to build rubygem-json fails like: ------------------------------------------- Processing files: rubygem-json-2.6.3-204.fc40.x86_64 error: File not found: /builddir/build/BUILDROOT/rubygem-json-2.6.3-204.fc40.101.x86_64/usr/share/gems/specifications/%{1}json-2.6.3.gemspec File not found: /builddir/build/BUILDROOT/rubygem-json-2.6.3-204.fc40.101.x86_64/usr/share/gems/specifications/%{1}json-2.6.3.gemspec -------------------------------------------
Now I am trying to rebuild gem related pkgs depending on libruby.3.2 (with using %{?1} for %gem_spec macro)
Regards, Mamoru
Dne 14. 09. 23 v 14:13 Mamoru TASAKA napsal(a):
Hello, Vít:
Thank you for initial work for ruby 3.3 .
Vít Ondruch wrote on 2023/09/12 17:08:
- `%gem_spec` macro with options:
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/blob/77c580dfa85f921d9...
This is my initial version, just to enable to use this macro in ruby.spec. I think I'll similarly modify all the related macros. While they'll be more complex, their use in ruby.spec will outweigh that. And I should add some documentation ...
BTW there are several possibilities in choosing how complex/flexible this macro will be and I think this is one of the changes which could be backported to Ruby 3.2. So feedback is appreciated. Looking at the macro, this bit `%{?1:%{expand:%{%{1}_version}}}%{!?1:%{version}}` is probably not very good idea for possible use in rubygem-*.gemspec.
I think this should be :
%gem_spec(d) %{gem_dir}/specifications%{?-d:/default}/%{?1}%{!?1:%{gem_name}}-%{?1:%{expand:%{%{1}_version}}}%{!?1:%{version}}%{?prerelease}.gemspec
(instead of %gem_spec(d) %{gem_dir}/specifications%{?-d:/default}/%{1}..... )
Otherwise, for example trying to build rubygem-json fails like:
Processing files: rubygem-json-2.6.3-204.fc40.x86_64 error: File not found: /builddir/build/BUILDROOT/rubygem-json-2.6.3-204.fc40.101.x86_64/usr/share/gems/specifications/%{1}json-2.6.3.gemspec File not found: /builddir/build/BUILDROOT/rubygem-json-2.6.3-204.fc40.101.x86_64/usr/share/gems/specifications/%{1}json-2.6.3.gemspec
Oh, right, sorry. I knew it is incomplete, but I have not realized this is immediately going to break other packages 🙈
My initial change included two options. There was also option to specify the version. I have later thought it is overcomplicated to have two options, if I could defer the macro name, but I have missed the original use case. And we were fine without this possibilities up to now.
Still, would there be some value in the option enabling to specify version? Should it be named or positional? The `%{prerelease}` does not make this question any easier.
Vít
Now I am trying to rebuild gem related pkgs depending on libruby.3.2 (with using %{?1} for %gem_spec macro)
Regards, Mamoru
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@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.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Mamoru TASAKA wrote on 2023/09/14 21:13:
Hello, Vít:
Thank you for initial work for ruby 3.3 .
Vít Ondruch wrote on 2023/09/12 17:08:
- `%gem_spec` macro with options:
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/blob/77c580dfa85f921d9...
This is my initial version, just to enable to use this macro in ruby.spec. I think I'll similarly modify all the related macros. While they'll be more complex, their use in ruby.spec will outweigh that. And I should add some documentation ...
BTW there are several possibilities in choosing how complex/flexible this macro will be and I think this is one of the changes which could be backported to Ruby 3.2. So feedback is appreciated. Looking at the macro, this bit `%{?1:%{expand:%{%{1}_version}}}%{!?1:%{version}}` is probably not very good idea for possible use in rubygem-*.gemspec.
I think this should be :
%gem_spec(d) %{gem_dir}/specifications%{?-d:/default}/%{?1}%{!?1:%{gem_name}}-%{?1:%{expand:%{%{1}_version}}}%{!?1:%{version}}%{?prerelease}.gemspec
(instead of %gem_spec(d) %{gem_dir}/specifications%{?-d:/default}/%{1}..... )
Otherwise, for example trying to build rubygem-json fails like:
Processing files: rubygem-json-2.6.3-204.fc40.x86_64 error: File not found: /builddir/build/BUILDROOT/rubygem-json-2.6.3-204.fc40.101.x86_64/usr/share/gems/specifications/%{1}json-2.6.3.gemspec File not found: /builddir/build/BUILDROOT/rubygem-json-2.6.3-204.fc40.101.x86_64/usr/share/gems/specifications/%{1}json-2.6.3.gemspec
Now I am trying to rebuild gem related pkgs depending on libruby.3.2 (with using %{?1} for %gem_spec macro)
Okay, so with my initial builds for rubygem-XXXX packages, among 456 packages, 50 packages failed to build (1 just fixed one of them, so currently 49).
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/pac...
Some types of errors (I noticed) which is affecting several packages are:
* minitest 5.19 side change: MiniTest class support deprecated: example: test/test_async.rb:28:in `<main>': uninitialized constant MiniTest (NameError) https://github.com/minitest/minitest/commit/a2c6c18570f6f0a1bf6af70fe3b6d959...
* ruby logger change. example: NoMethodError: undefined method `[]' for nil https://github.com/ruby/logger/pull/85 -> affects like https://github.com/resque/resque/issues/1856
* Regexp.new now rejects 3rd argument: example: wrong number of arguments (given 3, expected 1..2) https://github.com/ruby/ruby/pull/7039
* mocha being updated from 1.15.0 to 2.1 - perhaps some adjustment is needed example: `require': cannot load such file -- mocha/setup (LoadError)
* Some packages expect that there are no warnings, but now with ruby3.3 when trying to load default gems which are going to be gemified, warnings are generated like:
$ ruby -e "require 'csv'" -e:1: warning: csv which will be not part of the default gems since Ruby 3.4.0
https://github.com/ruby/ruby/pull/8126 , and the above warnings cause some tests fail. So this may mean that we have to package those default gems into separated rubygem-XXX srpm , at least before ruby 3.4 lands.
* And, currently some tests segfault.
* (Just note that there are some other reasons which cause test failure: I have not investigated them yet.)
Some topics: * rubygem-nifti sees test failure on s390x, this is perhaps big endian issue. * rubygem-byebug fails to build (on test suite), however it seems this needs the undestanding of ruby internal change, and seems very difficult for me....
I may post some detailed results (if I have time), however as I wrote above the results can be shown on: https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/pac...
Regards, Mamoru
Dne 17. 09. 23 v 15:42 Mamoru TASAKA napsal(a):
Mamoru TASAKA wrote on 2023/09/14 21:13:
Hello, Vít:
Thank you for initial work for ruby 3.3 .
Vít Ondruch wrote on 2023/09/12 17:08:
- `%gem_spec` macro with options:
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/blob/77c580dfa85f921d9...
This is my initial version, just to enable to use this macro in ruby.spec. I think I'll similarly modify all the related macros. While they'll be more complex, their use in ruby.spec will outweigh that. And I should add some documentation ...
BTW there are several possibilities in choosing how complex/flexible this macro will be and I think this is one of the changes which could be backported to Ruby 3.2. So feedback is appreciated. Looking at the macro, this bit `%{?1:%{expand:%{%{1}_version}}}%{!?1:%{version}}` is probably not very good idea for possible use in rubygem-*.gemspec.
I think this should be :
%gem_spec(d) %{gem_dir}/specifications%{?-d:/default}/%{?1}%{!?1:%{gem_name}}-%{?1:%{expand:%{%{1}_version}}}%{!?1:%{version}}%{?prerelease}.gemspec
(instead of %gem_spec(d) %{gem_dir}/specifications%{?-d:/default}/%{1}..... )
Otherwise, for example trying to build rubygem-json fails like:
Processing files: rubygem-json-2.6.3-204.fc40.x86_64 error: File not found: /builddir/build/BUILDROOT/rubygem-json-2.6.3-204.fc40.101.x86_64/usr/share/gems/specifications/%{1}json-2.6.3.gemspec File not found: /builddir/build/BUILDROOT/rubygem-json-2.6.3-204.fc40.101.x86_64/usr/share/gems/specifications/%{1}json-2.6.3.gemspec
Now I am trying to rebuild gem related pkgs depending on libruby.3.2 (with using %{?1} for %gem_spec macro)
Okay, so with my initial builds for rubygem-XXXX packages, among 456 packages, 50 packages failed to build (1 just fixed one of them, so currently 49).
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/pac...
Some types of errors (I noticed) which is affecting several packages are:
- minitest 5.19 side change: MiniTest class support deprecated:
example: test/test_async.rb:28:in `<main>': uninitialized constant MiniTest (NameError) https://github.com/minitest/minitest/commit/a2c6c18570f6f0a1bf6af70fe3b6d959...
While I am aware of this issue in rubygem-async_sinatra, I have let this package deliberately unfixed, because I don't think it is maintained. So either their maintainer will fix it or it will be later automatically removed from Fedora. I don't really intend to prolong life of such packages.
- ruby logger change.
example: NoMethodError: undefined method `[]' for nil https://github.com/ruby/logger/pull/85 -> affects like https://github.com/resque/resque/issues/1856
- Regexp.new now rejects 3rd argument:
example: wrong number of arguments (given 3, expected 1..2) https://github.com/ruby/ruby/pull/7039
- mocha being updated from 1.15.0 to 2.1 - perhaps some adjustment is
needed example: `require': cannot load such file -- mocha/setup (LoadError)
Assuming this is about rubygem-rack-cors, this is similar case to the rubygem-async_sinatra. I have submitted fix upstream:
https://github.com/cyu/rack-cors/pull/266
and put @valtri on CC. So he should be aware.
- Some packages expect that there are no warnings, but now with ruby3.3
when trying to load default gems which are going to be gemified, warnings are generated like:
$ ruby -e "require 'csv'" -e:1: warning: csv which will be not part of the default gems since Ruby 3.4.0
I think that this was reported here:
https://bugs.ruby-lang.org/issues/19885
https://github.com/ruby/ruby/pull/8126 , and the above warnings cause some tests fail. So this may mean that we have to package those default gems into separated rubygem-XXX srpm , at least before ruby 3.4 lands.
And, currently some tests segfault.
(Just note that there are some other reasons which cause test failure:
I have not investigated them yet.)
Some topics:
- rubygem-nifti sees test failure on s390x, this is perhaps big endian
issue.
Interesting. nifti failed during mass rebuild, but later it was update by its maintainer. So it would probably deserve bug report and maybe some `ExcludeArch`?
- rubygem-byebug fails to build (on test suite), however it seems this
needs the undestanding of ruby internal change, and seems very difficult for me....
Is there any future in byebug? Wasn't it obsoleted/replaced by the `debug` gem which is shipped with Ruby?
I may post some detailed results (if I have time), however as I wrote above the results can be shown on: https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/pac...
Thank you for the initial tests. I'll look into your findings later in more detail. These were just quick notes mostly just from my memory :)
Vít
Hello, again:
Vít Ondruch wrote on 2023/09/18 17:24:
Dne 17. 09. 23 v 15:42 Mamoru TASAKA napsal(a):
Okay, so with my initial builds for rubygem-XXXX packages, among 456 packages, 50 packages failed to build (1 just fixed one of them, so currently 49).
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/pac...
Some types of errors (I noticed) which is affecting several packages are:
- minitest 5.19 side change: MiniTest class support deprecated:
example: test/test_async.rb:28:in `<main>': uninitialized constant MiniTest (NameError) https://github.com/minitest/minitest/commit/a2c6c18570f6f0a1bf6af70fe3b6d959...
While I am aware of this issue in rubygem-async_sinatra, I have let this package deliberately unfixed, because I don't think it is maintained. So either their maintainer will fix it or it will be later automatically removed from Fedora. I don't really intend to prolong life of such packages.
- ruby logger change.
example: NoMethodError: undefined method `[]' for nil https://github.com/ruby/logger/pull/85 -> affects like https://github.com/resque/resque/issues/1856
- Regexp.new now rejects 3rd argument:
example: wrong number of arguments (given 3, expected 1..2) https://github.com/ruby/ruby/pull/7039
- mocha being updated from 1.15.0 to 2.1 - perhaps some adjustment is needed
example: `require': cannot load such file -- mocha/setup (LoadError)
Assuming this is about rubygem-rack-cors, this is similar case to the rubygem-async_sinatra. I have submitted fix upstream:
https://github.com/cyu/rack-cors/pull/266
and put @valtri on CC. So he should be aware.
- Some packages expect that there are no warnings, but now with ruby3.3
when trying to load default gems which are going to be gemified, warnings are generated like:
$ ruby -e "require 'csv'" -e:1: warning: csv which will be not part of the default gems since Ruby 3.4.0
I think that this was reported here:
Thank you for info. This is actually what I want to track.
https://github.com/ruby/ruby/pull/8126 , and the above warnings cause some tests fail. So this may mean that we have to package those default gems into separated rubygem-XXX srpm , at least before ruby 3.4 lands.
And, currently some tests segfault.
(Just note that there are some other reasons which cause test failure:
I have not investigated them yet.)
Some topics:
- rubygem-nifti sees test failure on s390x, this is perhaps big endian issue.
Interesting. nifti failed during mass rebuild, but later it was update by its maintainer. So it would probably deserve bug report and maybe some `ExcludeArch`?
Okay, I will check rubygem-nifti commit on Fedora dist-git (and perhaps I will probably file bugzilla ticket for rubygem-nifti).
(Well, rubygem-nifti is actually noarch, but I often wonder if we should always try to build packages for all arches even if the srpm itself is noarch: sometimes I see endian issue like this, for example.)
- rubygem-byebug fails to build (on test suite), however it seems this needs
the undestanding of ruby internal change, and seems very difficult for me....
Is there any future in byebug? Wasn't it obsoleted/replaced by the `debug` gem which is shipped with Ruby?
Thank you for info. Well, it seems that actually my usage of byebug gem can be enough satisfied with debug gem. So now I incline to orphan byebug rather than spending time to fix byebug test failure...
but what I've found is that power_assert testsuite depends on byebug: https://github.com/ruby/power_assert/blob/297fa68908c45c4ca6c41e0940ebcc0697...
Before I orphan byebug, first I will try to contact with power_assert upstream.
I may post some detailed results (if I have time), however as I wrote above the results can be shown on: https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/pac...
Thank you for the initial tests. I'll look into your findings later in more detail. These were just quick notes mostly just from my memory :)
Vít
Mamoru
Follow up:
Mamoru TASAKA wrote on 2023/09/18 20:16:
Hello, again:
Vít Ondruch wrote on 2023/09/18 17:24:
Dne 17. 09. 23 v 15:42 Mamoru TASAKA napsal(a):
Some topics:
- rubygem-nifti sees test failure on s390x, this is perhaps big endian issue.
Interesting. nifti failed during mass rebuild, but later it was update by its maintainer. So it would probably deserve bug report and maybe some `ExcludeArch`?
Okay, I will check rubygem-nifti commit on Fedora dist-git (and perhaps I will probably file bugzilla ticket for rubygem-nifti).
Reported: https://bugzilla.redhat.com/show_bug.cgi?id=2239481
(Well, rubygem-nifti is actually noarch, but I often wonder if we should always try to build packages for all arches even if the srpm itself is noarch: sometimes I see endian issue like this, for example.)
- rubygem-byebug fails to build (on test suite), however it seems this needs
the undestanding of ruby internal change, and seems very difficult for me....
Is there any future in byebug? Wasn't it obsoleted/replaced by the `debug` gem which is shipped with Ruby?
Thank you for info. Well, it seems that actually my usage of byebug gem can be enough satisfied with debug gem. So now I incline to orphan byebug rather than spending time to fix byebug test failure...
but what I've found is that power_assert testsuite depends on byebug: https://github.com/ruby/power_assert/blob/297fa68908c45c4ca6c41e0940ebcc0697...
Before I orphan byebug, first I will try to contact with power_assert upstream.
(As Vít already noticed) reported: https://github.com/ruby/power_assert/issues/47
Mamoru
Hello all, again:
Mamoru TASAKA wrote on 2023/09/17 22:42:
Okay, so with my initial builds for rubygem-XXXX packages, among 456 packages, 50 packages failed to build (1 just fixed one of them, so currently 49).
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/pac...
Some types of errors (I noticed) which is affecting several packages are:
- Regexp.new now rejects 3rd argument:
example: wrong number of arguments (given 3, expected 1..2) https://github.com/ruby/ruby/pull/7039
rubygem-cookiejar hits this issue:
------------------------------------------------ Failure/Error: PARAM2 = Regexp.new "(#{PATTERN::TOKEN})(?:=(#{PATTERN::VALUE2}))?(?:\Z|;)", '', 'n'
ArgumentError: wrong number of arguments (given 3, expected 1..2) ------------------------------------------------
It looks like the following packages need rubygem-cookiejar when rebuilding, and when rebuilding the same error when (in cookiejar internal):
* rubygem-em-http-request * rubygem-em-websocket * rubygem-faraday * rubygem-webmock
Now rubygem-cookiejar upstream got archived: https://github.com/dwaite/cookiejar
while there is the fork named "cookiejar2": https://github.com/dorianmariefr/cookiejar2
It seems cookiejar upstream is very responsive, actually the PR I've submitted about the above Regexp issue was merged very quickly: https://github.com/dorianmariefr/cookiejar2/pull/2
Now I've applied the above PR to Fedora rubygem-cookiejar, but in the future perhaps we should switch to use cookiejar2 instead of cookiejar.
( CCing pvalena )
Regards, Mamoru
Dne 19. 09. 23 v 13:22 Mamoru TASAKA napsal(a):
Hello all, again:
Mamoru TASAKA wrote on 2023/09/17 22:42:
Okay, so with my initial builds for rubygem-XXXX packages, among 456 packages, 50 packages failed to build (1 just fixed one of them, so currently 49).
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/pac...
Some types of errors (I noticed) which is affecting several packages are:
- Regexp.new now rejects 3rd argument:
example: wrong number of arguments (given 3, expected 1..2) https://github.com/ruby/ruby/pull/7039
rubygem-cookiejar hits this issue:
Failure/Error: PARAM2 = Regexp.new "(#{PATTERN::TOKEN})(?:=(#{PATTERN::VALUE2}))?(?:\Z|;)", '', 'n'
ArgumentError: wrong number of arguments (given 3, expected 1..2)
It looks like the following packages need rubygem-cookiejar when rebuilding, and when rebuilding the same error when (in cookiejar internal):
- rubygem-em-http-request
IOW all this comes to em-http-request and there is upstream request to replace the cookiejar dependency:
https://github.com/igrigorik/em-http-request/issues/354
But I'll take closer look later.
Vít
- rubygem-em-websocket
- rubygem-faraday
- rubygem-webmock
Now rubygem-cookiejar upstream got archived: https://github.com/dwaite/cookiejar
while there is the fork named "cookiejar2": https://github.com/dorianmariefr/cookiejar2
It seems cookiejar upstream is very responsive, actually the PR I've submitted about the above Regexp issue was merged very quickly: https://github.com/dorianmariefr/cookiejar2/pull/2
Now I've applied the above PR to Fedora rubygem-cookiejar, but in the future perhaps we should switch to use cookiejar2 instead of cookiejar.
( CCing pvalena )
Regards, Mamoru _______________________________________________ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@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.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Looks great, thanks!
I think the switch should rather occur on rubygems.org ... https://rubygems.org/gems/cookiejar2 - the naming difference might create some issues.
Alternatively, we could package it as rubygem-cookiejar2, and let it provide Cookiejar.
Pavel
On Tue, Sep 19, 2023 at 1:22 PM Mamoru TASAKA mtasaka@fedoraproject.org wrote:
Hello all, again:
Mamoru TASAKA wrote on 2023/09/17 22:42:
Okay, so with my initial builds for rubygem-XXXX packages, among 456
packages,
50 packages failed to build (1 just fixed one of them, so currently 49).
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/pac...
Some types of errors (I noticed) which is affecting several packages are:
- Regexp.new now rejects 3rd argument: example: wrong number of arguments (given 3, expected 1..2) https://github.com/ruby/ruby/pull/7039
rubygem-cookiejar hits this issue:
Failure/Error: PARAM2 = Regexp.new "(#{PATTERN::TOKEN})(?:=(#{PATTERN::VALUE2}))?(?:\Z|;)", '', 'n'
ArgumentError: wrong number of arguments (given 3, expected 1..2)
It looks like the following packages need rubygem-cookiejar when rebuilding, and when rebuilding the same error when (in cookiejar internal):
- rubygem-em-http-request
- rubygem-em-websocket
- rubygem-faraday
- rubygem-webmock
Now rubygem-cookiejar upstream got archived: https://github.com/dwaite/cookiejar
while there is the fork named "cookiejar2": https://github.com/dorianmariefr/cookiejar2
It seems cookiejar upstream is very responsive, actually the PR I've submitted about the above Regexp issue was merged very quickly: https://github.com/dorianmariefr/cookiejar2/pull/2
Now I've applied the above PR to Fedora rubygem-cookiejar, but in the future perhaps we should switch to use cookiejar2 instead of cookiejar.
( CCing pvalena )
Regards, Mamoru
Hi,
Ruby 3.3 Preview 2 was released last week and here I am with the updated version. You can find the changes in my PR:
https://src.fedoraproject.org/rpms/ruby/pull-request/159
and here is the associated scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=106353657
I have not noticed anything particularly interesting in that release. However, I have fixed and improved the macros I was talking about. For clarity (and probably backport), I have extracted them into separate commit:
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/d500de24cdcb4d848ab3...
This commit introduces `%{gem_name_version}` macro, which by default does `%{gem_name}-%{version}%{?prerelease}`. Or if called with custom gem name, such as `%gem_name_version foo`, the action is `%{1}-%{expand:%{%{1}_version}}%{?prerelease}`. This assumes that there is `%{foo_version}` defined for correct output.
This macro is later reused in all `%gem_` macros, which now also accept custom gem name.
There is also additional `-d` option for `%gem_spec` macro, which refers to the .gemspec of default gems.
As always, feedback is appreciated via all common channels.
Vít
Hello,
I decided to do some more testing, and found out that gem install doesn't work:
``` # Rawhide, all updated
$ sudo dnf install ruby Last metadata expiration check: 0:06:58 ago on Wed 20 Sep 2023 05:31:53 PM UTC. Dependencies resolved. ============================================================================================ Package Arch Version Repository Size ============================================================================================ Installing: ruby x86_64 3.3.0~20230905git7c8932365f-182.fc40
copr:copr.fedorainfracloud.org:pvalena:ruby-testing 42 k Installing dependencies: ruby-default-gems noarch 3.3.0~20230905git7c8932365f-182.fc40
copr:copr.fedorainfracloud.org:pvalena:ruby-testing 32 k ruby-libs x86_64 3.3.0~20230905git7c8932365f-182.fc40
copr:copr.fedorainfracloud.org:pvalena:ruby-testing 3.8 M rubygem-io-console x86_64 0.6.0-182.fc40 copr:copr.fedorainfracloud.org:pvalena:ruby-testing 25 k rubygem-json x86_64 2.6.3-182.fc40 copr:copr.fedorainfracloud.org:pvalena:ruby-testing 53 k rubygem-psych x86_64 5.1.0-182.fc40 copr:copr.fedorainfracloud.org:pvalena:ruby-testing 51 k rubypick noarch 1.1.1-19.fc39 rawhide 9.9 k Installing weak dependencies: rubygem-bigdecimal x86_64 3.1.4-182.fc40 copr:copr.fedorainfracloud.org:pvalena:ruby-testing 69 k rubygem-bundler noarch 2.5.0.dev-182.fc40
copr:copr.fedorainfracloud.org:pvalena:ruby-testing 382 k rubygem-rdoc noarch 6.5.0-182.fc40 copr:copr.fedorainfracloud.org:pvalena:ruby-testing 464 k rubygems noarch 3.5.0.dev-182.fc40
copr:copr.fedorainfracloud.org:pvalena:ruby-testing 260 k
Transaction Summary ============================================================================================ Install 11 Packages
Total download size: 5.2 M Installed size: 18 M Is this ok [y/N]: y Downloading Packages: (1/11): ruby-3.3.0~20230905git7c8932365f-182.fc40.x86_64.rp 269 kB/s | 42 kB 00:00 (2/11): ruby-default-gems-3.3.0~20230905git7c8932365f-182.f 195 kB/s | 32 kB 00:00 (3/11): rubygem-bigdecimal-3.1.4-182.fc40.x86_64.rpm 1.2 MB/s | 69 kB 00:00 (4/11): rubygem-bundler-2.5.0.dev-182.fc40.noarch.rpm 2.9 MB/s | 382 kB 00:00 (5/11): rubygem-io-console-0.6.0-182.fc40.x86_64.rpm 296 kB/s | 25 kB 00:00 (6/11): ruby-libs-3.3.0~20230905git7c8932365f-182.fc40.x86_ 12 MB/s | 3.8 MB 00:00 (7/11): rubygem-json-2.6.3-182.fc40.x86_64.rpm 1.3 MB/s | 53 kB 00:00 (8/11): rubygem-psych-5.1.0-182.fc40.x86_64.rpm 1.2 MB/s | 51 kB 00:00 (9/11): rubygem-rdoc-6.5.0-182.fc40.noarch.rpm 6.6 MB/s | 464 kB 00:00 (10/11): rubygems-3.5.0.dev-182.fc40.noarch.rpm 3.3 MB/s | 260 kB 00:00 (11/11): rubypick-1.1.1-19.fc39.noarch.rpm 85 kB/s | 9.9 kB 00:00 -------------------------------------------------------------------------------------------- Total 8.9 MB/s | 5.2 MB 00:00 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing : 1/1 Installing : ruby-libs-3.3.0~20230905git7c8932365f-182.fc40.x86_64 1/11 Installing : rubygem-bigdecimal-3.1.4-182.fc40.x86_64 2/11 Installing : ruby-default-gems-3.3.0~20230905git7c8932365f-182.fc40.noarch 3/11 Installing : rubygem-bundler-2.5.0.dev-182.fc40.noarch 4/11 Installing : rubygem-io-console-0.6.0-182.fc40.x86_64 5/11 Installing : rubygem-json-2.6.3-182.fc40.x86_64 6/11 Installing : rubygem-psych-5.1.0-182.fc40.x86_64 7/11 Installing : rubygem-rdoc-6.5.0-182.fc40.noarch 8/11 Installing : rubygems-3.5.0.dev-182.fc40.noarch 9/11 Installing : rubypick-1.1.1-19.fc39.noarch 10/11 Installing : ruby-3.3.0~20230905git7c8932365f-182.fc40.x86_64 11/11 Running scriptlet: ruby-3.3.0~20230905git7c8932365f-182.fc40.x86_64 11/11 Verifying : ruby-3.3.0~20230905git7c8932365f-182.fc40.x86_64 1/11 Verifying : ruby-default-gems-3.3.0~20230905git7c8932365f-182.fc40.noarch 2/11 Verifying : ruby-libs-3.3.0~20230905git7c8932365f-182.fc40.x86_64 3/11 Verifying : rubygem-bigdecimal-3.1.4-182.fc40.x86_64 4/11 Verifying : rubygem-bundler-2.5.0.dev-182.fc40.noarch 5/11 Verifying : rubygem-io-console-0.6.0-182.fc40.x86_64 6/11 Verifying : rubygem-json-2.6.3-182.fc40.x86_64 7/11 Verifying : rubygem-psych-5.1.0-182.fc40.x86_64 8/11 Verifying : rubygem-rdoc-6.5.0-182.fc40.noarch 9/11 Verifying : rubygems-3.5.0.dev-182.fc40.noarch 10/11 Verifying : rubypick-1.1.1-19.fc39.noarch 11/11
Installed: ruby-3.3.0~20230905git7c8932365f-182.fc40.x86_64 ruby-default-gems-3.3.0~20230905git7c8932365f-182.fc40.noarch ruby-libs-3.3.0~20230905git7c8932365f-182.fc40.x86_64 rubygem-bigdecimal-3.1.4-182.fc40.x86_64 rubygem-bundler-2.5.0.dev-182.fc40.noarch rubygem-io-console-0.6.0-182.fc40.x86_64 rubygem-json-2.6.3-182.fc40.x86_64 rubygem-psych-5.1.0-182.fc40.x86_64 rubygem-rdoc-6.5.0-182.fc40.noarch rubygems-3.5.0.dev-182.fc40.noarch rubypick-1.1.1-19.fc39.noarch
Complete!
$ gem install rails internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:128:in `require': libruby.so.3.2: cannot open shared object file: No such file or directory - /usr/lib64/gems/ruby/stringio-3.0.8/stringio.so (LoadError) from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:128:in `require' from /usr/share/rubygems/rubygems/remote_fetcher.rb:78:in `initialize' from /usr/share/rubygems/rubygems/remote_fetcher.rb:56:in `new' from /usr/share/rubygems/rubygems/remote_fetcher.rb:56:in `fetcher' from /usr/share/rubygems/rubygems/spec_fetcher.rb:77:in `initialize' from /usr/share/rubygems/rubygems/spec_fetcher.rb:43:in `new' from /usr/share/rubygems/rubygems/spec_fetcher.rb:43:in `fetcher' from /usr/share/rubygems/rubygems/resolver/installer_set.rb:43:in `initialize' from /usr/share/rubygems/rubygems/dependency_installer.rb:285:in `new' from /usr/share/rubygems/rubygems/dependency_installer.rb:285:in `resolve_dependencies' from /usr/share/rubygems/rubygems/commands/install_command.rb:206:in `install_gem' from /usr/share/rubygems/rubygems/commands/install_command.rb:231:in `block in install_gems' from /usr/share/rubygems/rubygems/commands/install_command.rb:224:in `each' from /usr/share/rubygems/rubygems/commands/install_command.rb:224:in `install_gems' from /usr/share/rubygems/rubygems/commands/install_command.rb:170:in `execute' from /usr/share/rubygems/rubygems/command.rb:326:in `invoke_with_build_args' from /usr/share/rubygems/rubygems/command_manager.rb:253:in `invoke_command' from /usr/share/rubygems/rubygems/command_manager.rb:193:in `process_args' from /usr/share/rubygems/rubygems/command_manager.rb:151:in `run' from /usr/share/rubygems/rubygems/gem_runner.rb:56:in `run' from /usr/bin/gem:12:in `<main>' ``` I didn't try with your latest version.
Regards, Pavel
On Mon, Sep 18, 2023 at 6:24 PM Vít Ondruch vondruch@redhat.com wrote:
Hi,
Ruby 3.3 Preview 2 was released last week and here I am with the updated version. You can find the changes in my PR:
https://src.fedoraproject.org/rpms/ruby/pull-request/159
and here is the associated scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=106353657
I have not noticed anything particularly interesting in that release. However, I have fixed and improved the macros I was talking about. For clarity (and probably backport), I have extracted them into separate commit:
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/d500de24cdcb4d848ab3...
This commit introduces `%{gem_name_version}` macro, which by default does `%{gem_name}-%{version}%{?prerelease}`. Or if called with custom gem name, such as `%gem_name_version foo`, the action is `%{1}-%{expand:%{%{1}_version}}%{?prerelease}`. This assumes that there is `%{foo_version}` defined for correct output.
This macro is later reused in all `%gem_` macros, which now also accept custom gem name.
There is also additional `-d` option for `%gem_spec` macro, which refers to the .gemspec of default gems.
As always, feedback is appreciated via all common channels.
Vít
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@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.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 9/20/23 19:41, Pavel Valena wrote:
Hello,
I decided to do some more testing, and found out that gem install doesn't work:
<...snip...> $ gem install rails <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:128:in `require': libruby.so.3.2: cannot open shared object file: No such file or directory - /usr/lib64/gems/ruby/stringio-3.0.8/stringio.so (LoadError)
^ Not sure how, but stringio is probably the wrong binary version? Some env pollution? Trying locally in a rawhide Fedora container with your copr (skipping setting up the copr...):
``` $ podman run --rm -it registry.fedoraproject.org/fedora:rawhide # dnf install -y ruby.3.3.0~20230905git7c8932365f-182.fc40 # gem install rails Fetching zeitwerk-2.6.11.gem Successfully installed zeitwerk-2.6.11 Fetching thor-1.2.2.gem Successfully installed thor-1.2.2 <...snip... It fails later due to missing build deps> ```
Regards, Jarek
from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:128:in `require' <...snip...> I didn't try with your latest version.
Regards, Pavel
On Mon, Sep 18, 2023 at 6:24 PM Vít Ondruch vondruch@redhat.com wrote:
Hi, Ruby 3.3 Preview 2 was released last week and here I am with the updated version. You can find the changes in my PR: https://src.fedoraproject.org/rpms/ruby/pull-request/159 and here is the associated scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=106353657 I have not noticed anything particularly interesting in that release. However, I have fixed and improved the macros I was talking about. For clarity (and probably backport), I have extracted them into separate commit: https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/d500de24cdcb4d848ab3df29d76f711104b3683e This commit introduces `%{gem_name_version}` macro, which by default does `%{gem_name}-%{version}%{?prerelease}`. Or if called with custom gem name, such as `%gem_name_version foo`, the action is `%{1}-%{expand:%{%{1}_version}}%{?prerelease}`. This assumes that there is `%{foo_version}` defined for correct output. This macro is later reused in all `%gem_` macros, which now also accept custom gem name. There is also additional `-d` option for `%gem_spec` macro, which refers to the .gemspec of default gems. As always, feedback is appreciated via all common channels. Vít _______________________________________________ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@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 toruby-sig-leave@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.o... Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue
Hi,
I am back with new update, this time it is rev 3c11cdbcfe. The changes are in the PR:
https://src.fedoraproject.org/rpms/ruby/pull-request/159
and build (in progress ATM) is here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=106474426
The main reason I have prepared this update is this change:
https://github.com/ruby/ruby/commit/647390308239fbf82d159ecd83ed8df090af518d
Which hopefully resolves the issue we were seeing with SystemTap and enables removal of the workaround patch. If somebody has some cycles to experiment with the SystemTap test case, that would be super cool (adding Lukáš from QE on CC, if he gets interested by a chance ;) ).
Vít
Hi,
I am back again with yet another update, this time to e029375a7d. The changes are in the PR:
https://src.fedoraproject.org/rpms/ruby/pull-request/159
And the scratch build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=107409961
From upstream POV, there is nothing particularly interesting, except of the rename of the new Ruby source code parser from YART to prism and on strange JIT test failure.
From changes in the .spec file, I have migrated every custom reference of gem path to the %gem_ macros. This was enabled by this commit:
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/c514f5f13c709dc28975...
Please note that this commit also introduces `%gem_name_version` macro, which we could use in place of `%{gem_name}-%{version}`.
Next on my table is allow usage of generators on default/bundled gems. More details on this approach is here:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
and in practice, this will look like:
~~~
$ git diff diff --git a/ruby.spec b/ruby.spec index 1aea20b..51f3065 100644 --- a/ruby.spec +++ b/ruby.spec @@ -196,6 +196,11 @@ Source15: test_openssl_fips.rb %{load:%{SOURCE4}} %{load:%{SOURCE5}}
+%global __local_generator_requires make -C %{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby TESTRUN_SCRIPT="--enable-gems %{SOURCE9}" +%global __local_generator_provides make -C %{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby TESTRUN_SCRIPT="--enable-gems %{SOURCE10}" +%global __local_generator_conflicts make -C %{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby TESTRUN_SCRIPT="--enable-gems %{SOURCE11}" +%global __local_generator_path ^%{gem_dir}/specifications/.*.gemspec$ + # Fix ruby_version abuse. # https://bugs.ruby-lang.org/issues/11002 Patch0: ruby-2.3.0-ruby_version.patch @@ -229,6 +234,7 @@ Requires: %{name}-libs%{?_isa} = %{version}-%{release} Recommends: ruby(rubygems) >= %{rubygems_version} Recommends: rubygem(bigdecimal) >= %{bigdecimal_version}
+BuildRequires: rpm-local-generator-support # Build dependencies BuildRequires: autoconf BuildRequires: gcc
~~~
But to enable this, I'll soon need help with a review of:
https://copr.fedorainfracloud.org/coprs/vondruch/rpm-local-generator/package...
Please take a look and as always, any feedback is welcome. And also, thx a lot who already did some test builds and compatibility fixes. That is really great!
Vít
Vít Ondruch wrote on 2023/10/13 0:20:
Hi,
I am back again with yet another update, this time to e029375a7d. The changes are in the PR:
Vít, would you take a look at this change?
https://github.com/rubygems/rubygems/pull/5327
In ruby.git , these are imported from 7aebe2a52bac2a925c475c511640ad13a7d20490 to 9dcaa832592af0125ba6407a506b2b3953b2f81c , I guess.
Perhaps due to the above changes:
[A] now "gem build ../foo-version.spec" as we usually do in rubygem-foo.spec fails like:
--------------------------------------------------------- + gem build ../Ascii85-1.1.0.gemspec Defaulting to user installation because default GEM_HOME (/usr/share/gems) is not writable. Invalid gemspec in [../Ascii85-1.1.0.gemspec]: ../Ascii85-1.1.0.gemspec:1: unknown regexp options - har ...se default GEM_HOME (/usr/share/gems) is not writable. ... ^~~~~~ ../Ascii85-1.1.0.gemspec:1: syntax error, unexpected local variable or method, expecting end-of-input ...t GEM_HOME (/usr/share/gems) is not writable. ... ^~ ERROR: Error loading gemspec. Aborting. error: Bad exit status from /var/tmp/rpm-tmp.Cvl7rH (%build) ---------------------------------------------------------
So this affects (breaks) almost all of Fedora rubygem- packages.
[B] Also, even if I workaround this, %gem_install , i.e. $ gem install -V --local --build-root . --force --document=ri,rdoc %{gem_name}-%{version}.gem now installs files under $HOME/.local:
--------------------------------------------------------- + gem install -V --local --build-root . --force --document=ri,rdoc Ascii85-1.1.0.gem Defaulting to user installation because default GEM_HOME (/usr/share/gems) is not writable. WARNING: You build with buildroot. Build root: /builddir/build/BUILD/Ascii85-1.1.0 Bin dir: /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/bin Gem home: /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby Plugins dir: /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/plugins /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/.travis.yml /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Ascii85.gemspec /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Gemfile /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/History.txt /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/LICENSE /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/README.md /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Rakefile /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/bin/ascii85 /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/lib/Ascii85/version.rb /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/lib/ascii85.rb /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/spec/lib/ascii85_spec.rb /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/bin/ascii85 ---------------------------------------------------------
So for now, I essentially reverted the above PR5327 changes on my local ruby.src (based on your ruby.src) and it looks working as before, so again I am going to do trial rebuild for all rubygem- packages.
(Well, when I saw these lots of git changelog related to rubygems part on ruby.git, I had a bad feeling about this.....)
Regards, Mamoru
https://src.fedoraproject.org/rpms/ruby/pull-request/159
And the scratch build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=107409961
From upstream POV, there is nothing particularly interesting, except of the rename of the new Ruby source code parser from YART to prism and on strange JIT test failure.
From changes in the .spec file, I have migrated every custom reference of gem path to the %gem_ macros. This was enabled by this commit:
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/c514f5f13c709dc28975...
Please note that this commit also introduces `%gem_name_version` macro, which we could use in place of `%{gem_name}-%{version}`.
Next on my table is allow usage of generators on default/bundled gems. More details on this approach is here:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
and in practice, this will look like:
$ git diff diff --git a/ruby.spec b/ruby.spec index 1aea20b..51f3065 100644 --- a/ruby.spec +++ b/ruby.spec @@ -196,6 +196,11 @@ Source15: test_openssl_fips.rb %{load:%{SOURCE4}} %{load:%{SOURCE5}} +%global __local_generator_requires make -C %{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby TESTRUN_SCRIPT="--enable-gems %{SOURCE9}" +%global __local_generator_provides make -C %{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby TESTRUN_SCRIPT="--enable-gems %{SOURCE10}" +%global __local_generator_conflicts make -C %{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby TESTRUN_SCRIPT="--enable-gems %{SOURCE11}" +%global __local_generator_path ^%{gem_dir}/specifications/.*\.gemspec$ + # Fix ruby_version abuse. # https://bugs.ruby-lang.org/issues/11002 Patch0: ruby-2.3.0-ruby_version.patch @@ -229,6 +234,7 @@ Requires: %{name}-libs%{?_isa} = %{version}-%{release} Recommends: ruby(rubygems) >= %{rubygems_version} Recommends: rubygem(bigdecimal) >= %{bigdecimal_version} +BuildRequires: rpm-local-generator-support # Build dependencies BuildRequires: autoconf BuildRequires: gccBut to enable this, I'll soon need help with a review of:
https://copr.fedorainfracloud.org/coprs/vondruch/rpm-local-generator/package...
Please take a look and as always, any feedback is welcome. And also, thx a lot who already did some test builds and compatibility fixes. That is really great!
Vít
Dne 15. 10. 23 v 1:48 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2023/10/13 0:20:
Hi,
I am back again with yet another update, this time to e029375a7d. The changes are in the PR:
Vít, would you take a look at this change?
It is on my TODO list, but I am still postponing feedback, because I did not have high hopes this will go right. Oh well.
Thx for spotting this.
Vít
In ruby.git , these are imported from 7aebe2a52bac2a925c475c511640ad13a7d20490 to 9dcaa832592af0125ba6407a506b2b3953b2f81c , I guess.
Perhaps due to the above changes:
[A] now "gem build ../foo-version.spec" as we usually do in rubygem-foo.spec fails like:
- gem build ../Ascii85-1.1.0.gemspec
Defaulting to user installation because default GEM_HOME (/usr/share/gems) is not writable. Invalid gemspec in [../Ascii85-1.1.0.gemspec]: ../Ascii85-1.1.0.gemspec:1: unknown regexp options - har ...se default GEM_HOME (/usr/share/gems) is not writable. ... ^~~~~~ ../Ascii85-1.1.0.gemspec:1: syntax error, unexpected local variable or method, expecting end-of-input ...t GEM_HOME (/usr/share/gems) is not writable. ... ^~ ERROR: Error loading gemspec. Aborting. error: Bad exit status from /var/tmp/rpm-tmp.Cvl7rH (%build)
So this affects (breaks) almost all of Fedora rubygem- packages.
[B] Also, even if I workaround this, %gem_install , i.e. $ gem install -V --local --build-root . --force --document=ri,rdoc %{gem_name}-%{version}.gem now installs files under $HOME/.local:
- gem install -V --local --build-root . --force --document=ri,rdoc
Ascii85-1.1.0.gem Defaulting to user installation because default GEM_HOME (/usr/share/gems) is not writable. WARNING: You build with buildroot. Build root: /builddir/build/BUILD/Ascii85-1.1.0 Bin dir: /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/bin Gem home: /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby Plugins dir: /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/plugins /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/.travis.yml
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Ascii85.gemspec
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Gemfile
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/History.txt
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/LICENSE
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/README.md
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Rakefile
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/bin/ascii85
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/lib/Ascii85/version.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/lib/ascii85.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/spec/lib/ascii85_spec.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/bin/ascii85
So for now, I essentially reverted the above PR5327 changes on my local ruby.src (based on your ruby.src) and it looks working as before, so again I am going to do trial rebuild for all rubygem- packages.
(Well, when I saw these lots of git changelog related to rubygems part on ruby.git, I had a bad feeling about this.....)
Regards, Mamoru
https://src.fedoraproject.org/rpms/ruby/pull-request/159
And the scratch build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=107409961
From upstream POV, there is nothing particularly interesting, except of the rename of the new Ruby source code parser from YART to prism and on strange JIT test failure.
From changes in the .spec file, I have migrated every custom reference of gem path to the %gem_ macros. This was enabled by this commit:
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/c514f5f13c709dc28975...
Please note that this commit also introduces `%gem_name_version` macro, which we could use in place of `%{gem_name}-%{version}`.
Next on my table is allow usage of generators on default/bundled gems. More details on this approach is here:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
and in practice, this will look like:
$ git diff diff --git a/ruby.spec b/ruby.spec index 1aea20b..51f3065 100644 --- a/ruby.spec +++ b/ruby.spec @@ -196,6 +196,11 @@ Source15: test_openssl_fips.rb %{load:%{SOURCE4}} %{load:%{SOURCE5}} +%global __local_generator_requires make -C %{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby TESTRUN_SCRIPT="--enable-gems %{SOURCE9}" +%global __local_generator_provides make -C %{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby TESTRUN_SCRIPT="--enable-gems %{SOURCE10}" +%global __local_generator_conflicts make -C %{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby TESTRUN_SCRIPT="--enable-gems %{SOURCE11}" +%global __local_generator_path ^%{gem_dir}/specifications/.*\.gemspec$ + # Fix ruby_version abuse. # https://bugs.ruby-lang.org/issues/11002 Patch0: ruby-2.3.0-ruby_version.patch @@ -229,6 +234,7 @@ Requires: %{name}-libs%{?_isa} = %{version}-%{release} Recommends: ruby(rubygems) >= %{rubygems_version} Recommends: rubygem(bigdecimal) >= %{bigdecimal_version} +BuildRequires: rpm-local-generator-support # Build dependencies BuildRequires: autoconf BuildRequires: gccBut to enable this, I'll soon need help with a review of:
https://copr.fedorainfracloud.org/coprs/vondruch/rpm-local-generator/package...
Please take a look and as always, any feedback is welcome. And also, thx a lot who already did some test builds and compatibility fixes. That is really great!
Vít
Dne 15. 10. 23 v 1:48 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2023/10/13 0:20:
Hi,
I am back again with yet another update, this time to e029375a7d. The changes are in the PR:
Vít, would you take a look at this change?
https://github.com/rubygems/rubygems/pull/5327
In ruby.git , these are imported from 7aebe2a52bac2a925c475c511640ad13a7d20490 to 9dcaa832592af0125ba6407a506b2b3953b2f81c , I guess.
Perhaps due to the above changes:
[A] now "gem build ../foo-version.spec" as we usually do in rubygem-foo.spec fails like:
- gem build ../Ascii85-1.1.0.gemspec
Defaulting to user installation because default GEM_HOME (/usr/share/gems) is not writable. Invalid gemspec in [../Ascii85-1.1.0.gemspec]: ../Ascii85-1.1.0.gemspec:1: unknown regexp options - har ...se default GEM_HOME (/usr/share/gems) is not writable. ... ^~~~~~ ../Ascii85-1.1.0.gemspec:1: syntax error, unexpected local variable or method, expecting end-of-input ...t GEM_HOME (/usr/share/gems) is not writable. ... ^~ ERROR: Error loading gemspec. Aborting. error: Bad exit status from /var/tmp/rpm-tmp.Cvl7rH (%build)
So this affects (breaks) almost all of Fedora rubygem- packages.
https://github.com/rubygems/rubygems/issues/7082
Testing with e.g. rubygem-json, this would be the workaround I guess:
~~~
$ sed -i '/^Defaulting to user installation/d' json-2.6.3.gemspec
~~~
Vít
[B] Also, even if I workaround this, %gem_install , i.e. $ gem install -V --local --build-root . --force --document=ri,rdoc %{gem_name}-%{version}.gem now installs files under $HOME/.local:
- gem install -V --local --build-root . --force --document=ri,rdoc
Ascii85-1.1.0.gem Defaulting to user installation because default GEM_HOME (/usr/share/gems) is not writable. WARNING: You build with buildroot. Build root: /builddir/build/BUILD/Ascii85-1.1.0 Bin dir: /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/bin Gem home: /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby Plugins dir: /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/plugins /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/.travis.yml
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Ascii85.gemspec
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Gemfile
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/History.txt
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/LICENSE
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/README.md
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Rakefile
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/bin/ascii85
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/lib/Ascii85/version.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/lib/ascii85.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/spec/lib/ascii85_spec.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/bin/ascii85
So for now, I essentially reverted the above PR5327 changes on my local ruby.src (based on your ruby.src) and it looks working as before, so again I am going to do trial rebuild for all rubygem- packages.
(Well, when I saw these lots of git changelog related to rubygems part on ruby.git, I had a bad feeling about this.....)
Regards, Mamoru
https://src.fedoraproject.org/rpms/ruby/pull-request/159
And the scratch build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=107409961
From upstream POV, there is nothing particularly interesting, except of the rename of the new Ruby source code parser from YART to prism and on strange JIT test failure.
From changes in the .spec file, I have migrated every custom reference of gem path to the %gem_ macros. This was enabled by this commit:
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/c514f5f13c709dc28975...
Please note that this commit also introduces `%gem_name_version` macro, which we could use in place of `%{gem_name}-%{version}`.
Next on my table is allow usage of generators on default/bundled gems. More details on this approach is here:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
and in practice, this will look like:
$ git diff diff --git a/ruby.spec b/ruby.spec index 1aea20b..51f3065 100644 --- a/ruby.spec +++ b/ruby.spec @@ -196,6 +196,11 @@ Source15: test_openssl_fips.rb %{load:%{SOURCE4}} %{load:%{SOURCE5}} +%global __local_generator_requires make -C %{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby TESTRUN_SCRIPT="--enable-gems %{SOURCE9}" +%global __local_generator_provides make -C %{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby TESTRUN_SCRIPT="--enable-gems %{SOURCE10}" +%global __local_generator_conflicts make -C %{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby TESTRUN_SCRIPT="--enable-gems %{SOURCE11}" +%global __local_generator_path ^%{gem_dir}/specifications/.*\.gemspec$ + # Fix ruby_version abuse. # https://bugs.ruby-lang.org/issues/11002 Patch0: ruby-2.3.0-ruby_version.patch @@ -229,6 +234,7 @@ Requires: %{name}-libs%{?_isa} = %{version}-%{release} Recommends: ruby(rubygems) >= %{rubygems_version} Recommends: rubygem(bigdecimal) >= %{bigdecimal_version} +BuildRequires: rpm-local-generator-support # Build dependencies BuildRequires: autoconf BuildRequires: gccBut to enable this, I'll soon need help with a review of:
https://copr.fedorainfracloud.org/coprs/vondruch/rpm-local-generator/package...
Please take a look and as always, any feedback is welcome. And also, thx a lot who already did some test builds and compatibility fixes. That is really great!
Vít
Dne 20. 10. 23 v 14:13 Vít Ondruch napsal(a):
Dne 15. 10. 23 v 1:48 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2023/10/13 0:20:
Hi,
I am back again with yet another update, this time to e029375a7d. The changes are in the PR:
Vít, would you take a look at this change?
https://github.com/rubygems/rubygems/pull/5327
In ruby.git , these are imported from 7aebe2a52bac2a925c475c511640ad13a7d20490 to 9dcaa832592af0125ba6407a506b2b3953b2f81c , I guess.
Perhaps due to the above changes:
[A] now "gem build ../foo-version.spec" as we usually do in rubygem-foo.spec fails like:
- gem build ../Ascii85-1.1.0.gemspec
Defaulting to user installation because default GEM_HOME (/usr/share/gems) is not writable. Invalid gemspec in [../Ascii85-1.1.0.gemspec]: ../Ascii85-1.1.0.gemspec:1: unknown regexp options - har ...se default GEM_HOME (/usr/share/gems) is not writable. ... ^~~~~~ ../Ascii85-1.1.0.gemspec:1: syntax error, unexpected local variable or method, expecting end-of-input ...t GEM_HOME (/usr/share/gems) is not writable. ... ^~ ERROR: Error loading gemspec. Aborting. error: Bad exit status from /var/tmp/rpm-tmp.Cvl7rH (%build)
So this affects (breaks) almost all of Fedora rubygem- packages.
https://github.com/rubygems/rubygems/issues/7082
Testing with e.g. rubygem-json, this would be the workaround I guess:
$ sed -i '/^Defaulting to user installation/d' json-2.6.3.gemspecVít
[B] Also, even if I workaround this, %gem_install , i.e. $ gem install -V --local --build-root . --force --document=ri,rdoc %{gem_name}-%{version}.gem now installs files under $HOME/.local:
- gem install -V --local --build-root . --force --document=ri,rdoc
Ascii85-1.1.0.gem Defaulting to user installation because default GEM_HOME (/usr/share/gems) is not writable. WARNING: You build with buildroot. Build root: /builddir/build/BUILD/Ascii85-1.1.0 Bin dir: /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/bin Gem home: /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby Plugins dir: /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/plugins /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/.travis.yml
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Ascii85.gemspec
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Gemfile
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/History.txt
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/LICENSE
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/README.md
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Rakefile
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/bin/ascii85
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/lib/Ascii85/version.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/lib/ascii85.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/spec/lib/ascii85_spec.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/bin/ascii85
For the beginning, I have reported this here:
https://github.com/rubygems/rubygems/issues/7083
Vít
So for now, I essentially reverted the above PR5327 changes on my local ruby.src (based on your ruby.src) and it looks working as before, so again I am going to do trial rebuild for all rubygem- packages.
(Well, when I saw these lots of git changelog related to rubygems part on ruby.git, I had a bad feeling about this.....)
Regards, Mamoru
https://src.fedoraproject.org/rpms/ruby/pull-request/159
And the scratch build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=107409961
From upstream POV, there is nothing particularly interesting, except of the rename of the new Ruby source code parser from YART to prism and on strange JIT test failure.
From changes in the .spec file, I have migrated every custom reference of gem path to the %gem_ macros. This was enabled by this commit:
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/c514f5f13c709dc28975...
Please note that this commit also introduces `%gem_name_version` macro, which we could use in place of `%{gem_name}-%{version}`.
Next on my table is allow usage of generators on default/bundled gems. More details on this approach is here:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
and in practice, this will look like:
$ git diff diff --git a/ruby.spec b/ruby.spec index 1aea20b..51f3065 100644 --- a/ruby.spec +++ b/ruby.spec @@ -196,6 +196,11 @@ Source15: test_openssl_fips.rb %{load:%{SOURCE4}} %{load:%{SOURCE5}} +%global __local_generator_requires make -C %{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby TESTRUN_SCRIPT="--enable-gems %{SOURCE9}" +%global __local_generator_provides make -C %{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby TESTRUN_SCRIPT="--enable-gems %{SOURCE10}" +%global __local_generator_conflicts make -C %{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby TESTRUN_SCRIPT="--enable-gems %{SOURCE11}" +%global __local_generator_path ^%{gem_dir}/specifications/.*\.gemspec$ + # Fix ruby_version abuse. # https://bugs.ruby-lang.org/issues/11002 Patch0: ruby-2.3.0-ruby_version.patch @@ -229,6 +234,7 @@ Requires: %{name}-libs%{?_isa} = %{version}-%{release} Recommends: ruby(rubygems) >= %{rubygems_version} Recommends: rubygem(bigdecimal) >= %{bigdecimal_version} +BuildRequires: rpm-local-generator-support # Build dependencies BuildRequires: autoconf BuildRequires: gccBut to enable this, I'll soon need help with a review of:
https://copr.fedorainfracloud.org/coprs/vondruch/rpm-local-generator/package...
Please take a look and as always, any feedback is welcome. And also, thx a lot who already did some test builds and compatibility fixes. That is really great!
Vít
BTW, the question also is, what is the influence of PR5327 on our settings:
https://src.fedoraproject.org/rpms/ruby/blob/5bf57b1504871230600103083d77ff3...
In theory, we should be able to drop this.
Vít
Dne 20. 10. 23 v 14:21 Vít Ondruch napsal(a):
Dne 20. 10. 23 v 14:13 Vít Ondruch napsal(a):
Dne 15. 10. 23 v 1:48 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2023/10/13 0:20:
Hi,
I am back again with yet another update, this time to e029375a7d. The changes are in the PR:
Vít, would you take a look at this change?
https://github.com/rubygems/rubygems/pull/5327
In ruby.git , these are imported from 7aebe2a52bac2a925c475c511640ad13a7d20490 to 9dcaa832592af0125ba6407a506b2b3953b2f81c , I guess.
Perhaps due to the above changes:
[A] now "gem build ../foo-version.spec" as we usually do in rubygem-foo.spec fails like:
- gem build ../Ascii85-1.1.0.gemspec
Defaulting to user installation because default GEM_HOME (/usr/share/gems) is not writable. Invalid gemspec in [../Ascii85-1.1.0.gemspec]: ../Ascii85-1.1.0.gemspec:1: unknown regexp options - har ...se default GEM_HOME (/usr/share/gems) is not writable. ... ^~~~~~ ../Ascii85-1.1.0.gemspec:1: syntax error, unexpected local variable or method, expecting end-of-input ...t GEM_HOME (/usr/share/gems) is not writable. ... ^~ ERROR: Error loading gemspec. Aborting. error: Bad exit status from /var/tmp/rpm-tmp.Cvl7rH (%build)
So this affects (breaks) almost all of Fedora rubygem- packages.
https://github.com/rubygems/rubygems/issues/7082
Testing with e.g. rubygem-json, this would be the workaround I guess:
$ sed -i '/^Defaulting to user installation/d' json-2.6.3.gemspecVít
[B] Also, even if I workaround this, %gem_install , i.e. $ gem install -V --local --build-root . --force --document=ri,rdoc %{gem_name}-%{version}.gem now installs files under $HOME/.local:
- gem install -V --local --build-root . --force --document=ri,rdoc
Ascii85-1.1.0.gem Defaulting to user installation because default GEM_HOME (/usr/share/gems) is not writable. WARNING: You build with buildroot. Build root: /builddir/build/BUILD/Ascii85-1.1.0 Bin dir: /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/bin Gem home: /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby Plugins dir: /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/plugins /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/.travis.yml
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Ascii85.gemspec
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Gemfile
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/History.txt
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/LICENSE
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/README.md
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Rakefile
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/bin/ascii85
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/lib/Ascii85/version.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/lib/ascii85.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/spec/lib/ascii85_spec.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/bin/ascii85
For the beginning, I have reported this here:
https://github.com/rubygems/rubygems/issues/7083
Vít
So for now, I essentially reverted the above PR5327 changes on my local ruby.src (based on your ruby.src) and it looks working as before, so again I am going to do trial rebuild for all rubygem- packages.
(Well, when I saw these lots of git changelog related to rubygems part on ruby.git, I had a bad feeling about this.....)
Regards, Mamoru
https://src.fedoraproject.org/rpms/ruby/pull-request/159
And the scratch build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=107409961
From upstream POV, there is nothing particularly interesting, except of the rename of the new Ruby source code parser from YART to prism and on strange JIT test failure.
From changes in the .spec file, I have migrated every custom reference of gem path to the %gem_ macros. This was enabled by this commit:
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/c514f5f13c709dc28975...
Please note that this commit also introduces `%gem_name_version` macro, which we could use in place of `%{gem_name}-%{version}`.
Next on my table is allow usage of generators on default/bundled gems. More details on this approach is here:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
and in practice, this will look like:
$ git diff diff --git a/ruby.spec b/ruby.spec index 1aea20b..51f3065 100644 --- a/ruby.spec +++ b/ruby.spec @@ -196,6 +196,11 @@ Source15: test_openssl_fips.rb %{load:%{SOURCE4}} %{load:%{SOURCE5}} +%global __local_generator_requires make -C %{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby TESTRUN_SCRIPT="--enable-gems %{SOURCE9}" +%global __local_generator_provides make -C %{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby TESTRUN_SCRIPT="--enable-gems %{SOURCE10}" +%global __local_generator_conflicts make -C %{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby TESTRUN_SCRIPT="--enable-gems %{SOURCE11}" +%global __local_generator_path ^%{gem_dir}/specifications/.*\.gemspec$ + # Fix ruby_version abuse. # https://bugs.ruby-lang.org/issues/11002 Patch0: ruby-2.3.0-ruby_version.patch @@ -229,6 +234,7 @@ Requires: %{name}-libs%{?_isa} = %{version}-%{release} Recommends: ruby(rubygems) >= %{rubygems_version} Recommends: rubygem(bigdecimal) >= %{bigdecimal_version} +BuildRequires: rpm-local-generator-support # Build dependencies BuildRequires: autoconf BuildRequires: gccBut to enable this, I'll soon need help with a review of:
https://copr.fedorainfracloud.org/coprs/vondruch/rpm-local-generator/package...
Please take a look and as always, any feedback is welcome. And also, thx a lot who already did some test builds and compatibility fixes. That is really great!
Vít
Vít Ondruch wrote on 2023/10/20 21:21:
Dne 20. 10. 23 v 14:13 Vít Ondruch napsal(a):
Dne 15. 10. 23 v 1:48 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2023/10/13 0:20:
Hi,
I am back again with yet another update, this time to e029375a7d. The changes are in the PR:
Vít, would you take a look at this change?
https://github.com/rubygems/rubygems/pull/5327
In ruby.git , these are imported from 7aebe2a52bac2a925c475c511640ad13a7d20490 to 9dcaa832592af0125ba6407a506b2b3953b2f81c , I guess.
Perhaps due to the above changes:
[A] now "gem build ../foo-version.spec" as we usually do in rubygem-foo.spec fails like:
- gem build ../Ascii85-1.1.0.gemspec
Defaulting to user installation because default GEM_HOME (/usr/share/gems) is not writable. Invalid gemspec in [../Ascii85-1.1.0.gemspec]: ../Ascii85-1.1.0.gemspec:1: unknown regexp options - har ...se default GEM_HOME (/usr/share/gems) is not writable. ... ^~~~~~ ../Ascii85-1.1.0.gemspec:1: syntax error, unexpected local variable or method, expecting end-of-input ...t GEM_HOME (/usr/share/gems) is not writable. ... ^~ ERROR: Error loading gemspec. Aborting. error: Bad exit status from /var/tmp/rpm-tmp.Cvl7rH (%build)
So this affects (breaks) almost all of Fedora rubygem- packages.
https://github.com/rubygems/rubygems/issues/7082
Testing with e.g. rubygem-json, this would be the workaround I guess:
$ sed -i '/^Defaulting to user installation/d' json-2.6.3.gemspecVít
[B] Also, even if I workaround this, %gem_install , i.e. $ gem install -V --local --build-root . --force --document=ri,rdoc %{gem_name}-%{version}.gem now installs files under $HOME/.local:
- gem install -V --local --build-root . --force --document=ri,rdoc Ascii85-1.1.0.gem
Defaulting to user installation because default GEM_HOME (/usr/share/gems) is not writable. WARNING: You build with buildroot. Build root: /builddir/build/BUILD/Ascii85-1.1.0 Bin dir: /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/bin Gem home: /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby Plugins dir: /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/plugins /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/.travis.yml /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Ascii85.gemspec /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Gemfile /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/History.txt /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/LICENSE /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/README.md /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Rakefile /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/bin/ascii85 /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/lib/Ascii85/version.rb /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/lib/ascii85.rb /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/spec/lib/ascii85_spec.rb /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/bin/ascii85
For the beginning, I have reported this here:
https://github.com/rubygems/rubygems/issues/7083
Vít
Thank you for reporting these to the upstream. I will keep track of these bugs.
Mamoru
Dne 20. 10. 23 v 14:58 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2023/10/20 21:21:
Dne 20. 10. 23 v 14:13 Vít Ondruch napsal(a):
Dne 15. 10. 23 v 1:48 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2023/10/13 0:20:
Hi,
I am back again with yet another update, this time to e029375a7d. The changes are in the PR:
Vít, would you take a look at this change?
https://github.com/rubygems/rubygems/pull/5327
In ruby.git , these are imported from 7aebe2a52bac2a925c475c511640ad13a7d20490 to 9dcaa832592af0125ba6407a506b2b3953b2f81c , I guess.
Perhaps due to the above changes:
[A] now "gem build ../foo-version.spec" as we usually do in rubygem-foo.spec fails like:
- gem build ../Ascii85-1.1.0.gemspec
Defaulting to user installation because default GEM_HOME (/usr/share/gems) is not writable. Invalid gemspec in [../Ascii85-1.1.0.gemspec]: ../Ascii85-1.1.0.gemspec:1: unknown regexp options - har ...se default GEM_HOME (/usr/share/gems) is not writable. ... ^~~~~~ ../Ascii85-1.1.0.gemspec:1: syntax error, unexpected local variable or method, expecting end-of-input ...t GEM_HOME (/usr/share/gems) is not writable. ... ^~ ERROR: Error loading gemspec. Aborting. error: Bad exit status from /var/tmp/rpm-tmp.Cvl7rH (%build)
So this affects (breaks) almost all of Fedora rubygem- packages.
https://github.com/rubygems/rubygems/issues/7082
Testing with e.g. rubygem-json, this would be the workaround I guess:
$ sed -i '/^Defaulting to user installation/d' json-2.6.3.gemspecVít
[B] Also, even if I workaround this, %gem_install , i.e. $ gem install -V --local --build-root . --force --document=ri,rdoc %{gem_name}-%{version}.gem now installs files under $HOME/.local:
- gem install -V --local --build-root . --force --document=ri,rdoc
Ascii85-1.1.0.gem Defaulting to user installation because default GEM_HOME (/usr/share/gems) is not writable. WARNING: You build with buildroot. Build root: /builddir/build/BUILD/Ascii85-1.1.0 Bin dir: /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/bin Gem home: /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby Plugins dir: /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/plugins /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/.travis.yml
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Ascii85.gemspec
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Gemfile
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/History.txt
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/LICENSE
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/README.md
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Rakefile
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/bin/ascii85
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/lib/Ascii85/version.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/lib/ascii85.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/spec/lib/ascii85_spec.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/bin/ascii85
For the beginning, I have reported this here:
BTW this should be workaround:
~~~
diff --git a/macros.rubygems b/macros.rubygems index f6e830f..9a0add2 100644 --- a/macros.rubygems +++ b/macros.rubygems @@ -43,7 +43,9 @@ CONFIGURE_ARGS="--with-cflags='%{optflags}' --with-cxxflags='%{optflags}' --with gem install \\ -V \\ --local \\ - --build-root %{-d*}%{!?-d:.} \\ + --install-dir %{-d*}%{!?-d:.%{gem_dir}} \\ + --bindir .%{_bindir} \\ + --no-user-install \\ --force \\ --document=ri,rdoc \\ %{-n*}%{!?-n:%{gem_name}-%{version}%{?prerelease}.gem} \
~~~
Which is essentially revert of this commit:
https://src.fedoraproject.org/rpms/ruby/c/68e54df6f95dfca1c634dc383e32a311c3...
Vít
Vít
Thank you for reporting these to the upstream. I will keep track of these bugs.
Mamoru _______________________________________________ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@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.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Dne 15. 10. 23 v 1:48 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2023/10/13 0:20:
Hi,
I am back again with yet another update, this time to e029375a7d. The changes are in the PR:
Vít, would you take a look at this change?
https://github.com/rubygems/rubygems/pull/5327
In ruby.git , these are imported from 7aebe2a52bac2a925c475c511640ad13a7d20490 to 9dcaa832592af0125ba6407a506b2b3953b2f81c , I guess.
Perhaps due to the above changes:
[A] now "gem build ../foo-version.spec" as we usually do in rubygem-foo.spec fails like:
- gem build ../Ascii85-1.1.0.gemspec
Defaulting to user installation because default GEM_HOME (/usr/share/gems) is not writable. Invalid gemspec in [../Ascii85-1.1.0.gemspec]: ../Ascii85-1.1.0.gemspec:1: unknown regexp options - har ...se default GEM_HOME (/usr/share/gems) is not writable. ... ^~~~~~ ../Ascii85-1.1.0.gemspec:1: syntax error, unexpected local variable or method, expecting end-of-input ...t GEM_HOME (/usr/share/gems) is not writable. ... ^~ ERROR: Error loading gemspec. Aborting. error: Bad exit status from /var/tmp/rpm-tmp.Cvl7rH (%build)
So this affects (breaks) almost all of Fedora rubygem- packages.
I have decided to workaround this by simple patch which just disables printing this message:
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/555691277a4134a97790...
This keeps the things most in line with upstream.
The question still is if we should remove the operating_system.rb override for user install. Probably not at this time, because we do more then just simply enabling user installation. And the current implementation is doing too much heuristics :/
[B] Also, even if I workaround this, %gem_install , i.e. $ gem install -V --local --build-root . --force --document=ri,rdoc %{gem_name}-%{version}.gem now installs files under $HOME/.local:
- gem install -V --local --build-root . --force --document=ri,rdoc
Ascii85-1.1.0.gem Defaulting to user installation because default GEM_HOME (/usr/share/gems) is not writable. WARNING: You build with buildroot. Build root: /builddir/build/BUILD/Ascii85-1.1.0 Bin dir: /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/bin Gem home: /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby Plugins dir: /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/plugins /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/.travis.yml
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Ascii85.gemspec
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Gemfile
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/History.txt
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/LICENSE
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/README.md
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Rakefile
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/bin/ascii85
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/lib/Ascii85/version.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/lib/ascii85.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/spec/lib/ascii85_spec.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/bin/ascii85
I have decided to revert to use `--install-dir` again:
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/682a0ee3599884734f7a...
In addition, I have submitted this PR to improve the logic a bit:
https://github.com/rubygems/rubygems/pull/7100
(this might also help to our case, where we need to specify `--no-user-install` when somebody wish to use `--install-dir`).
And also this ticket in a hope to improve the situation more broadly, but I am not very hopeful it will change much:
https://github.com/rubygems/rubygems/issues/7089
But I wish the StdLib gems were installed into different directory then the rest of `gem install`ed gems. I think that would help us tremendously.
Vít
Dne 12. 10. 23 v 17:20 Vít Ondruch napsal(a):
Next on my table is allow usage of generators on default/bundled gems. More details on this approach is here:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
and in practice, this will look like:
$ git diff diff --git a/ruby.spec b/ruby.spec index 1aea20b..51f3065 100644 --- a/ruby.spec +++ b/ruby.spec @@ -196,6 +196,11 @@ Source15: test_openssl_fips.rb %{load:%{SOURCE4}} %{load:%{SOURCE5}} +%global __local_generator_requires make -C %{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby TESTRUN_SCRIPT="--enable-gems %{SOURCE9}" +%global __local_generator_provides make -C %{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby TESTRUN_SCRIPT="--enable-gems %{SOURCE10}" +%global __local_generator_conflicts make -C %{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby TESTRUN_SCRIPT="--enable-gems %{SOURCE11}" +%global __local_generator_path ^%{gem_dir}/specifications/.*\.gemspec$ + # Fix ruby_version abuse. # https://bugs.ruby-lang.org/issues/11002 Patch0: ruby-2.3.0-ruby_version.patch @@ -229,6 +234,7 @@ Requires: %{name}-libs%{?_isa} = %{version}-%{release} Recommends: ruby(rubygems) >= %{rubygems_version} Recommends: rubygem(bigdecimal) >= %{bigdecimal_version} +BuildRequires: rpm-local-generator-support # Build dependencies BuildRequires: autoconf BuildRequires: gccBut to enable this, I'll soon need help with a review of:
https://copr.fedorainfracloud.org/coprs/vondruch/rpm-local-generator/package...
I have submitted this package for a review. Can somebody help me please? The package can't be simpler.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2244428
Thx in advance
BTW it shaves off ~60 lines of the ruby.spec
Vít
And this is now used in Ruby. Please see the changes in the PR:
https://src.fedoraproject.org/rpms/ruby/pull-request/159
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/6d8ecfca02947b5f1ce4... https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/865f5b3a896ed1b423ad...
And the associated build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=107710823
Yes, this is the latest snapshot. So please give it a proper test. And thx for all the feedback (yes, I remember I have to check the RubyGems, but I wanted to finish the generators first).
Vít
Dne 16. 10. 23 v 16:19 Vít Ondruch napsal(a):
Dne 12. 10. 23 v 17:20 Vít Ondruch napsal(a):
Next on my table is allow usage of generators on default/bundled gems. More details on this approach is here:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
and in practice, this will look like:
$ git diff diff --git a/ruby.spec b/ruby.spec index 1aea20b..51f3065 100644 --- a/ruby.spec +++ b/ruby.spec @@ -196,6 +196,11 @@ Source15: test_openssl_fips.rb %{load:%{SOURCE4}} %{load:%{SOURCE5}} +%global __local_generator_requires make -C %{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby TESTRUN_SCRIPT="--enable-gems %{SOURCE9}" +%global __local_generator_provides make -C %{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby TESTRUN_SCRIPT="--enable-gems %{SOURCE10}" +%global __local_generator_conflicts make -C %{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby TESTRUN_SCRIPT="--enable-gems %{SOURCE11}" +%global __local_generator_path ^%{gem_dir}/specifications/.*\.gemspec$ + # Fix ruby_version abuse. # https://bugs.ruby-lang.org/issues/11002 Patch0: ruby-2.3.0-ruby_version.patch @@ -229,6 +234,7 @@ Requires: %{name}-libs%{?_isa} = %{version}-%{release} Recommends: ruby(rubygems) >= %{rubygems_version} Recommends: rubygem(bigdecimal) >= %{bigdecimal_version} +BuildRequires: rpm-local-generator-support # Build dependencies BuildRequires: autoconf BuildRequires: gccBut to enable this, I'll soon need help with a review of:
https://copr.fedorainfracloud.org/coprs/vondruch/rpm-local-generator/package...
I have submitted this package for a review. Can somebody help me please? The package can't be simpler.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2244428
Thx in advance
BTW it shaves off ~60 lines of the ruby.spec
Vít
Hi
On 10/12/23 17:20, Vít Ondruch wrote:
Hi,
I am back again with yet another update, this time to e029375a7d. The changes are in the PR:
https://src.fedoraproject.org/rpms/ruby/pull-request/159
And the scratch build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=107409961
From upstream POV, there is nothing particularly interesting, except of the rename of the new Ruby source code parser from YART to prism and on strange JIT test failure.
From changes in the .spec file, I have migrated every custom reference of gem path to the %gem_ macros. This was enabled by this commit:
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/c514f5f13c709dc28975...
Please note that this commit also introduces `%gem_name_version` macro, which we could use in place of `%{gem_name}-%{version}`.
Would you consider making the macro partially Lua instead, or do you want to enjoy the new features of RPM? :)
For C9S and C8S the gsub RPM macro is problematic since it was introduced in RPM version 4.19 as a "lua-less" gsub macro option: https://github.com/rpm-software-management/rpm/blob/05c3b37d1f8f91c3face5eea...
Trying to build it on those distros, I am currently experimenting with just using Lua for string manipulation and the later expansion, I can provide the Lua based macro once I finish rewriting it. I plan to rewrite only the portion where it expands the %{foo_version} for "%gem_name_version foo".
Next on my table is allow usage of generators on default/bundled gems. More details on this approach is here:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
and in practice, this will look like:
<...snip>
Regards, Jarek
Please take a look and as always, any feedback is welcome. And also, thx a lot who already did some test builds and compatibility fixes. That is really great!
Vít
Dne 01. 11. 23 v 11:27 jprokop@redhat.com napsal(a):
Hi
On 10/12/23 17:20, Vít Ondruch wrote:
Hi,
I am back again with yet another update, this time to e029375a7d. The changes are in the PR:
https://src.fedoraproject.org/rpms/ruby/pull-request/159
And the scratch build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=107409961
From upstream POV, there is nothing particularly interesting, except of the rename of the new Ruby source code parser from YART to prism and on strange JIT test failure.
From changes in the .spec file, I have migrated every custom reference of gem path to the %gem_ macros. This was enabled by this commit:
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/c514f5f13c709dc28975...
Please note that this commit also introduces `%gem_name_version` macro, which we could use in place of `%{gem_name}-%{version}`.
Would you consider making the macro partially Lua instead,
I thought this will come, therefore I still have this laying around:
~~~
$ git stash show -p diff --git a/macros.rubygems b/macros.rubygems index f6e830f..f27ba48 100644 --- a/macros.rubygems +++ b/macros.rubygems @@ -12,7 +12,7 @@ # to be predefined. Please note that for the version macros are the dashes # replaced by underscores. # -%gem_name_version() %{?1}%{!?1:%{gem_name}}-%{?1:%{expand:%{%{gsub %{1} - _}_version}}}%{!?1:%{version}}%{?prerelease} +%gem_name_version() %{?1}%{!?1:%{gem_name}}-%{?1:%{expand:%{lua:local str = rpm.expand("%1"); str = str:gsub("-", "_"); print("%" .. str .. "_version");}}}%{!?1:%{version}}%{?prerelease}
# Common gem locations and files. # ~~~
or do you want to enjoy the new features of RPM? :)
Actually I'd like it to keep as modern as possible. I know it is burden for RHEL, but I don't want RHEL to be obstacle for innovation.
For C9S and C8S the gsub RPM macro is problematic since it was introduced in RPM version 4.19 as a "lua-less" gsub macro option: https://github.com/rpm-software-management/rpm/blob/05c3b37d1f8f91c3face5eea...
Trying to build it on those distros, I am currently experimenting with just using Lua for string manipulation and the later expansion, I can provide the Lua based macro once I finish rewriting it. I plan to rewrite only the portion where it expands the %{foo_version} for "%gem_name_version foo".
Actually, maybe it would be worth of asking RPM team if they would be willing to backport e.g. the `gsub` into RHEL.
Vít
Next on my table is allow usage of generators on default/bundled gems. More details on this approach is here:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
and in practice, this will look like:
<...snip>
Regards, Jarek
Please take a look and as always, any feedback is welcome. And also, thx a lot who already did some test builds and compatibility fixes. That is really great!
Vít
ruby-sig mailing list --ruby-sig@lists.fedoraproject.org To unsubscribe send an email toruby-sig-leave@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.o... Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue
On 11/1/23 15:01, Vít Ondruch wrote:
Dne 01. 11. 23 v 11:27 jprokop@redhat.com napsal(a):
Hi
On 10/12/23 17:20, Vít Ondruch wrote:
Hi,
I am back again with yet another update, this time to e029375a7d. The changes are in the PR:
https://src.fedoraproject.org/rpms/ruby/pull-request/159
And the scratch build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=107409961
From upstream POV, there is nothing particularly interesting, except of the rename of the new Ruby source code parser from YART to prism and on strange JIT test failure.
From changes in the .spec file, I have migrated every custom reference of gem path to the %gem_ macros. This was enabled by this commit:
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/c514f5f13c709dc28975...
Please note that this commit also introduces `%gem_name_version` macro, which we could use in place of `%{gem_name}-%{version}`.
Would you consider making the macro partially Lua instead,
I thought this will come, therefore I still have this laying around:
$ git stash show -p diff --git a/macros.rubygems b/macros.rubygems index f6e830f..f27ba48 100644 --- a/macros.rubygems +++ b/macros.rubygems @@ -12,7 +12,7 @@ # to be predefined. Please note that for the version macros are the dashes # replaced by underscores. # -%gem_name_version() %{?1}%{!?1:%{gem_name}}-%{?1:%{expand:%{%{gsub %{1} - _}_version}}}%{!?1:%{version}}%{?prerelease} +%gem_name_version() %{?1}%{!?1:%{gem_name}}-%{?1:%{expand:%{lua:local str = rpm.expand("%1"); str = str:gsub("-", "_"); print("%" .. str .. "_version");}}}%{!?1:%{version}}%{?prerelease} # Common gem locations and files. #
Yeah we ended up +- on the same note: ~~~ %gem_name_version() %{?1}%{!?1:%{gem_name}}-%{?1:%{lua: st = string.gsub(rpm.expand("%{1}"), "-", "_"); print(rpm.expand('%{'..st..'_version}'))}}%{!?1:%{version}}%{?prerelease} ~~~
or do you want to enjoy the new features of RPM? :)
Actually I'd like it to keep as modern as possible. I know it is burden for RHEL, but I don't want RHEL to be obstacle for innovation.
Fair.
For C9S and C8S the gsub RPM macro is problematic since it was introduced in RPM version 4.19 as a "lua-less" gsub macro option: https://github.com/rpm-software-management/rpm/blob/05c3b37d1f8f91c3face5eea...
Trying to build it on those distros, I am currently experimenting with just using Lua for string manipulation and the later expansion, I can provide the Lua based macro once I finish rewriting it. I plan to rewrite only the portion where it expands the %{foo_version} for "%gem_name_version foo".
Actually, maybe it would be worth of asking RPM team if they would be willing to backport e.g. the `gsub` into RHEL.
Vít
Next on my table is allow usage of generators on default/bundled gems. More details on this approach is here:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
and in practice, this will look like:
<...snip>
Regards, Jarek
Hi,
I am back again with updated version of Ruby, this time c44d65427e. Please see the changes in the upstream PR and test the build (currently in progress) here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=108034430
Apart of fixes for the "user install gems" discussed in other parts of this thread, there is fix for the "TestYJIT#test_bug_19316" test failure (which is not important on itself, just a few of you were involved, thx!). I have not noticed anything else outstanding.
As always, please give it a try and I am looking forward to your feedback.
Vít
Hi, Vít:
Vít Ondruch wrote on 2023/10/24 23:07:
Hi,
I am back again with updated version of Ruby, this time c44d65427e. Please see the changes in the upstream PR and test the build (currently in progress) here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=108034430
Apart of fixes for the "user install gems" discussed in other parts of this thread, there is fix for the "TestYJIT#test_bug_19316" test failure (which is not important on itself, just a few of you were involved, thx!). I have not noticed anything else outstanding.
As always, please give it a try and I am looking forward to your feedback.
Vít
This seems to be working, thank you.
BTW (although I am sure I saw ppc64le test failure in some previous commit) at least as of a2badf3066 I no longer see ppc64le/TestCoverage#test_coverage_suspendable test failure, not sure what commit cured this test.
Regards, Mamoru
Dne 25. 10. 23 v 16:11 Mamoru TASAKA napsal(a):
Hi, Vít:
Vít Ondruch wrote on 2023/10/24 23:07:
Hi,
I am back again with updated version of Ruby, this time c44d65427e. Please see the changes in the upstream PR and test the build (currently in progress) here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=108034430
Apart of fixes for the "user install gems" discussed in other parts of this thread, there is fix for the "TestYJIT#test_bug_19316" test failure (which is not important on itself, just a few of you were involved, thx!). I have not noticed anything else outstanding.
As always, please give it a try and I am looking forward to your feedback.
Vít
This seems to be working, thank you.
BTW (although I am sure I saw ppc64le test failure in some previous commit) at least as of a2badf3066 I no longer see ppc64le/TestCoverage#test_coverage_suspendable test failure, not sure what commit cured this test.
Probably this?
https://github.com/ruby/ruby/pull/8670
I'll re-enable this test. Thx for spotting this.
Vít
On Wed, Oct 25, 2023 at 4:31 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 25. 10. 23 v 16:11 Mamoru TASAKA napsal(a):
Hi, Vít:
Vít Ondruch wrote on 2023/10/24 23:07:
Hi,
I am back again with updated version of Ruby, this time c44d65427e. Please see the changes in the upstream PR and test the build (currently in progress) here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=108034430
Apart of fixes for the "user install gems" discussed in other parts of this thread, there is fix for the "TestYJIT#test_bug_19316" test failure (which is not important on itself, just a few of you were involved, thx!). I have not noticed anything else outstanding.
As always, please give it a try and I am looking forward to your feedback.
Hello,
this time I'm getting strange build errors in my COPR like:
``` /builddir/build/BUILD/ruby-3.3.0-c44d65427e/redhat-linux-build/ruby: error while loading shared libraries: libruby.so.3.3: cannot open shared object file: No such file or directory ``` https://gist.github.com/pvalena/63a91bca8ddf40c275f1f218b9a265a9 https://copr.fedorainfracloud.org/coprs/build/6565734
Not sure if that's something on my side... It's not a random error though. Strangely enough, I can't reproduce it locally (local build is fine), even in the same buildroot.
Btw. `rust` it's pulled in for the build :) ...I hope that's intended.
Pavel
Vít
This seems to be working, thank you.
BTW (although I am sure I saw ppc64le test failure in some previous commit) at least as of a2badf3066 I no longer see ppc64le/TestCoverage#test_coverage_suspendable test failure, not sure what commit cured this test.
Probably this?
https://github.com/ruby/ruby/pull/8670
I'll re-enable this test. Thx for spotting this.
Vít
Dne 26. 10. 23 v 18:26 Pavel Valena napsal(a):
On Wed, Oct 25, 2023 at 4:31 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 25. 10. 23 v 16:11 Mamoru TASAKA napsal(a): > Hi, Vít: > > Vít Ondruch wrote on 2023/10/24 23:07: >> Hi, >> >> I am back again with updated version of Ruby, this time c44d65427e. >> Please see the changes in the upstream PR and test the build >> (currently in progress) here: >> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=108034430 >> >> Apart of fixes for the "user install gems" discussed in other parts >> of this thread, there is fix for the "TestYJIT#test_bug_19316" test >> failure (which is not important on itself, just a few of you were >> involved, thx!). I have not noticed anything else outstanding. >> >> As always, please give it a try and I am looking forward to your >> feedback.Hello,
this time I'm getting strange build errors in my COPR like:
/builddir/build/BUILD/ruby-3.3.0-c44d65427e/redhat-linux-build/ruby: error while loading shared libraries: libruby.so.3.3: cannot open shared object file: No such file or directoryhttps://gist.github.com/pvalena/63a91bca8ddf40c275f1f218b9a265a9 https://copr.fedorainfracloud.org/coprs/build/6565734
Not sure if that's something on my side... It's not a random error though. Strangely enough, I can't reproduce it locally (local build is fine), even in the same buildroot.
Sorry, not sure what is going on and the links you have shared don't provide enough context. The rawhide builds are either complete or they failed with different issue then the Gist.
Btw. `rust` it's pulled in for the build :) ...I hope that's intended.
Yes, RJIT.
Vít
Pavel
>> >> >> Vít > > > This seems to be working, thank you. > > BTW (although I am sure I saw ppc64le test failure in some previous > commit) > at least as of a2badf3066 I no longer see > ppc64le/TestCoverage#test_coverage_suspendable > test failure, not sure what commit cured this test. Probably this? https://github.com/ruby/ruby/pull/8670 I'll re-enable this test. Thx for spotting this. Vít
ruby-sig mailing list --ruby-sig@lists.fedoraproject.org To unsubscribe send an email toruby-sig-leave@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.o... Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue
On Fri, Oct 27, 2023 at 12:36 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 26. 10. 23 v 18:26 Pavel Valena napsal(a):
On Wed, Oct 25, 2023 at 4:31 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 25. 10. 23 v 16:11 Mamoru TASAKA napsal(a):
Hi, Vít:
Vít Ondruch wrote on 2023/10/24 23:07:
Hi,
I am back again with updated version of Ruby, this time c44d65427e. Please see the changes in the upstream PR and test the build (currently in progress) here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=108034430
Apart of fixes for the "user install gems" discussed in other parts of this thread, there is fix for the "TestYJIT#test_bug_19316" test failure (which is not important on itself, just a few of you were involved, thx!). I have not noticed anything else outstanding.
As always, please give it a try and I am looking forward to your feedback.
Hello,
this time I'm getting strange build errors in my COPR like:
/builddir/build/BUILD/ruby-3.3.0-c44d65427e/redhat-linux-build/ruby: error while loading shared libraries: libruby.so.3.3: cannot open shared object file: No such file or directoryhttps://gist.github.com/pvalena/63a91bca8ddf40c275f1f218b9a265a9 https://copr.fedorainfracloud.org/coprs/build/6565734
Not sure if that's something on my side... It's not a random error though. Strangely enough, I can't reproduce it locally (local build is fine), even in the same buildroot.
Sorry, not sure what is going on and the links you have shared don't provide enough context. The rawhide builds are either complete or they failed with different issue then the Gist.
I believe the error is really there, but I might be mistaken to consider it most important part of the log. It's in between the ----------------------------------------------------------------------; here f.e. in fedora-rawhide-x86_64:
~~~ Invoking `/builddir/build/BUILD/ruby-3.3.0-c44d65427e/redhat-linux-build/ruby -rrubygems /builddir/build/BUILD/ruby-3.3.0-c44d65427e/bin/gem --backtrace build lib/bundler/bundler.gemspec` failed with output: ---------------------------------------------------------------------- /builddir/build/BUILD/ruby-3.3.0-c44d65427e/redhat-linux-build/ruby: error while loading shared libraries: libruby.so.3.3: cannot open shared object file: No such file or directory ---------------------------------------------------------------------- # ./spec/bundler/support/helpers.rb:202:in `sys_exec' # ./spec/bundler/support/helpers.rb:165:in `gem_command' # ./spec/bundler/support/helpers.rb:343:in `with_built_bundler' # ./spec/bundler/support/helpers.rb:304:in `block (2 levels) in system_gems' # ./spec/bundler/support/helpers.rb:300:in `each' # ./spec/bundler/support/helpers.rb:300:in `block in system_gems' # ./spec/bundler/support/helpers.rb:357:in `block in with_gem_path_as' # ./spec/bundler/support/helpers.rb:371:in `without_env_side_effects' # ./spec/bundler/support/helpers.rb:352:in `with_gem_path_as' # ./spec/bundler/support/helpers.rb:298:in `system_gems' # ./spec/bundler/spec_helper.rb:92:in `block (2 levels) in <top (required)>' ~~~
Yes, it's very strange - and it happens every time I try. But I'm fine with it as long as no one else experiences the issue :).
Builds so far: https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6565230/ https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6567675/ https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6565734/ https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6565235/ https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6582818/
It didn't happen with previous builds though....
Btw. `rust` it's pulled in for the build :) ...I hope that's intended.
Yes, RJIT.
Looking forward to it.
Thanks! Pavel
Vít
Pavel
Vít
This seems to be working, thank you.
BTW (although I am sure I saw ppc64le test failure in some previous commit) at least as of a2badf3066 I no longer see ppc64le/TestCoverage#test_coverage_suspendable test failure, not sure what commit cured this test.
Probably this?
https://github.com/ruby/ruby/pull/8670
I'll re-enable this test. Thx for spotting this.
Vít
Pavel Valena wrote on 2023/11/01 3:42:
On Fri, Oct 27, 2023 at 12:36 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 26. 10. 23 v 18:26 Pavel Valena napsal(a):
On Wed, Oct 25, 2023 at 4:31 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 25. 10. 23 v 16:11 Mamoru TASAKA napsal(a):
Hi, Vít:
Vít Ondruch wrote on 2023/10/24 23:07:
Hi,
I am back again with updated version of Ruby, this time c44d65427e. Please see the changes in the upstream PR and test the build (currently in progress) here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=108034430
Apart of fixes for the "user install gems" discussed in other parts of this thread, there is fix for the "TestYJIT#test_bug_19316" test failure (which is not important on itself, just a few of you were involved, thx!). I have not noticed anything else outstanding.
As always, please give it a try and I am looking forward to your feedback.
Hello,
this time I'm getting strange build errors in my COPR like:
/builddir/build/BUILD/ruby-3.3.0-c44d65427e/redhat-linux-build/ruby: error while loading shared libraries: libruby.so.3.3: cannot open shared object file: No such file or directoryhttps://gist.github.com/pvalena/63a91bca8ddf40c275f1f218b9a265a9 https://copr.fedorainfracloud.org/coprs/build/6565734
Not sure if that's something on my side... It's not a random error though. Strangely enough, I can't reproduce it locally (local build is fine), even in the same buildroot.
Sorry, not sure what is going on and the links you have shared don't provide enough context. The rawhide builds are either complete or they failed with different issue then the Gist.
I believe the error is really there, but I might be mistaken to consider it most important part of the log. It's in between the ----------------------------------------------------------------------; here f.e. in fedora-rawhide-x86_64:
Invoking `/builddir/build/BUILD/ruby-3.3.0-c44d65427e/redhat-linux-build/ruby -rrubygems /builddir/build/BUILD/ruby-3.3.0-c44d65427e/bin/gem --backtrace build lib/bundler/bundler.gemspec` failed with output: ---------------------------------------------------------------------- /builddir/build/BUILD/ruby-3.3.0-c44d65427e/redhat-linux-build/ruby: error while loading shared libraries: libruby.so.3.3: cannot open shared object file: No such file or directory ---------------------------------------------------------------------- # ./spec/bundler/support/helpers.rb:202:in `sys_exec' # ./spec/bundler/support/helpers.rb:165:in `gem_command' # ./spec/bundler/support/helpers.rb:343:in `with_built_bundler' # ./spec/bundler/support/helpers.rb:304:in `block (2 levels) in system_gems' # ./spec/bundler/support/helpers.rb:300:in `each' # ./spec/bundler/support/helpers.rb:300:in `block in system_gems' # ./spec/bundler/support/helpers.rb:357:in `block in with_gem_path_as' # ./spec/bundler/support/helpers.rb:371:in `without_env_side_effects' # ./spec/bundler/support/helpers.rb:352:in `with_gem_path_as' # ./spec/bundler/support/helpers.rb:298:in `system_gems' # ./spec/bundler/spec_helper.rb:92:in `block (2 levels) in <top (required)>'Yes, it's very strange - and it happens every time I try. But I'm fine with it as long as no one else experiences the issue :).
Builds so far: https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6565230/ https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6567675/ https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6565734/ https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6565235/ https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6582818/
It didn't happen with previous builds though....
Looking at your copr setting, you have enabled "--with bundler_tests" on x86_64 arch only:
``` Modified fedora-rawhide-x86_64: Mock options: --with bundler_tests ``` and correspondingly build is failing on
+ make -C redhat-linux-build test-bundler-parallel
Mamoru
Dne 31. 10. 23 v 23:45 Mamoru TASAKA napsal(a):
Pavel Valena wrote on 2023/11/01 3:42:
On Fri, Oct 27, 2023 at 12:36 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 26. 10. 23 v 18:26 Pavel Valena napsal(a):
On Wed, Oct 25, 2023 at 4:31 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 25. 10. 23 v 16:11 Mamoru TASAKA napsal(a):
Hi, Vít:
Vít Ondruch wrote on 2023/10/24 23:07:
Hi,
I am back again with updated version of Ruby, this time c44d65427e. Please see the changes in the upstream PR and test the build (currently in progress) here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=108034430
Apart of fixes for the "user install gems" discussed in other parts of this thread, there is fix for the "TestYJIT#test_bug_19316" test failure (which is not important on itself, just a few of you were involved, thx!). I have not noticed anything else outstanding.
As always, please give it a try and I am looking forward to your feedback.
Hello,
this time I'm getting strange build errors in my COPR like:
/builddir/build/BUILD/ruby-3.3.0-c44d65427e/redhat-linux-build/ruby: error while loading shared libraries: libruby.so.3.3: cannot open shared object file: No such file or directoryhttps://gist.github.com/pvalena/63a91bca8ddf40c275f1f218b9a265a9 https://copr.fedorainfracloud.org/coprs/build/6565734
Oh, I can finally see the error. So this would be the right place to take a look at to get a whole picture:
https://download.copr.fedorainfracloud.org/results/pvalena/ruby-testing/fedo...
Not sure if that's something on my side... It's not a random error though. Strangely enough, I can't reproduce it locally (local build is fine), even in the same buildroot.
Sorry, not sure what is going on and the links you have shared don't provide enough context. The rawhide builds are either complete or they failed with different issue then the Gist.
I believe the error is really there, but I might be mistaken to consider it most important part of the log. It's in between the ----------------------------------------------------------------------; here f.e. in fedora-rawhide-x86_64:
Invoking `/builddir/build/BUILD/ruby-3.3.0-c44d65427e/redhat-linux-build/ruby -rrubygems /builddir/build/BUILD/ruby-3.3.0-c44d65427e/bin/gem --backtrace build lib/bundler/bundler.gemspec` failed with output: ---------------------------------------------------------------------- /builddir/build/BUILD/ruby-3.3.0-c44d65427e/redhat-linux-build/ruby: error while loading shared libraries: libruby.so.3.3: cannot open shared object file: No such file or directory ---------------------------------------------------------------------- # ./spec/bundler/support/helpers.rb:202:in `sys_exec' # ./spec/bundler/support/helpers.rb:165:in `gem_command' # ./spec/bundler/support/helpers.rb:343:in `with_built_bundler' # ./spec/bundler/support/helpers.rb:304:in `block (2 levels) in system_gems' # ./spec/bundler/support/helpers.rb:300:in `each' # ./spec/bundler/support/helpers.rb:300:in `block in system_gems' # ./spec/bundler/support/helpers.rb:357:in `block in with_gem_path_as' # ./spec/bundler/support/helpers.rb:371:in `without_env_side_effects' # ./spec/bundler/support/helpers.rb:352:in `with_gem_path_as' # ./spec/bundler/support/helpers.rb:298:in `system_gems' # ./spec/bundler/spec_helper.rb:92:in `block (2 levels) in <top (required)>'Yes, it's very strange - and it happens every time I try. But I'm fine with it as long as no one else experiences the issue :).
Builds so far: https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6565230/
https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6567675/
https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6565734/
https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6565235/
https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6582818/
It didn't happen with previous builds though....
Looking at your copr setting, you have enabled "--with bundler_tests" on x86_64 arch only:
Modified fedora-rawhide-x86_64: Mock options: --with bundler_testsand correspondingly build is failing on
- make -C redhat-linux-build test-bundler-parallel
Good catch! Thank you for providing second (third?) pair of eyes. It is indeed good idea to test Bundler. Now who will only fix this? :D
Vít
Mamoru _______________________________________________ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@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.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Wed, Nov 1, 2023 at 10:07 AM Vít Ondruch vondruch@redhat.com wrote:
Dne 31. 10. 23 v 23:45 Mamoru TASAKA napsal(a):
Pavel Valena wrote on 2023/11/01 3:42:
On Fri, Oct 27, 2023 at 12:36 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 26. 10. 23 v 18:26 Pavel Valena napsal(a):
On Wed, Oct 25, 2023 at 4:31 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 25. 10. 23 v 16:11 Mamoru TASAKA napsal(a):
Hi, Vít:
Vít Ondruch wrote on 2023/10/24 23:07: > Hi, > > I am back again with updated version of Ruby, this time c44d65427e. > Please see the changes in the upstream PR and test the build > (currently in progress) here: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=108034430 > > Apart of fixes for the "user install gems" discussed in other parts > of this thread, there is fix for the "TestYJIT#test_bug_19316" test > failure (which is not important on itself, just a few of you were > involved, thx!). I have not noticed anything else outstanding. > > As always, please give it a try and I am looking forward to your > feedback.
Hello,
this time I'm getting strange build errors in my COPR like:
/builddir/build/BUILD/ruby-3.3.0-c44d65427e/redhat-linux-build/ruby: error while loading shared libraries: libruby.so.3.3: cannot open shared object file: No such file or directoryhttps://gist.github.com/pvalena/63a91bca8ddf40c275f1f218b9a265a9 https://copr.fedorainfracloud.org/coprs/build/6565734
Oh, I can finally see the error. So this would be the right place to take a look at to get a whole picture:
https://download.copr.fedorainfracloud.org/results/pvalena/ruby-testing/fedo...
Not sure if that's something on my side... It's not a random error though. Strangely enough, I can't reproduce it locally (local build is fine), even in the same buildroot.
Sorry, not sure what is going on and the links you have shared don't provide enough context. The rawhide builds are either complete or they failed with different issue then the Gist.
I believe the error is really there, but I might be mistaken to consider it most important part of the log. It's in between the ----------------------------------------------------------------------; here f.e. in fedora-rawhide-x86_64:
Invoking `/builddir/build/BUILD/ruby-3.3.0-c44d65427e/redhat-linux-build/ruby -rrubygems /builddir/build/BUILD/ruby-3.3.0-c44d65427e/bin/gem --backtrace build lib/bundler/bundler.gemspec` failed with output: ---------------------------------------------------------------------- /builddir/build/BUILD/ruby-3.3.0-c44d65427e/redhat-linux-build/ruby: error while loading shared libraries: libruby.so.3.3: cannot open shared object file: No such file or directory ---------------------------------------------------------------------- # ./spec/bundler/support/helpers.rb:202:in `sys_exec' # ./spec/bundler/support/helpers.rb:165:in `gem_command' # ./spec/bundler/support/helpers.rb:343:in `with_built_bundler' # ./spec/bundler/support/helpers.rb:304:in `block (2 levels) in system_gems' # ./spec/bundler/support/helpers.rb:300:in `each' # ./spec/bundler/support/helpers.rb:300:in `block in system_gems' # ./spec/bundler/support/helpers.rb:357:in `block in with_gem_path_as' # ./spec/bundler/support/helpers.rb:371:in `without_env_side_effects' # ./spec/bundler/support/helpers.rb:352:in `with_gem_path_as' # ./spec/bundler/support/helpers.rb:298:in `system_gems' # ./spec/bundler/spec_helper.rb:92:in `block (2 levels) in <top (required)>'Yes, it's very strange - and it happens every time I try. But I'm fine with it as long as no one else experiences the issue :).
Builds so far:
https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6565230/
https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6567675/
https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6565734/
https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6565235/
https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6582818/
It didn't happen with previous builds though....
Looking at your copr setting, you have enabled "--with bundler_tests" on x86_64 arch only:
Modified fedora-rawhide-x86_64: Mock options: --with bundler_testsand correspondingly build is failing on
- make -C redhat-linux-build test-bundler-parallel
Good catch! Thank you for providing second (third?) pair of eyes. It is indeed good idea to test Bundler. Now who will only fix this? :D
Good catch indeed. Thanks for looking into this, I totally forgot I have enabled it, as the tests did just work :]. I'm afraid I don't have any spare cycles to look into this though.
Pavel
Vít
Mamoru _______________________________________________ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@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.o...
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Dne 01. 11. 23 v 14:31 Pavel Valena napsal(a):
On Wed, Nov 1, 2023 at 10:07 AM Vít Ondruch vondruch@redhat.com wrote:
Dne 31. 10. 23 v 23:45 Mamoru TASAKA napsal(a): > Pavel Valena wrote on 2023/11/01 3:42: >> On Fri, Oct 27, 2023 at 12:36 PM Vít Ondruch <vondruch@redhat.com> >> wrote: >> >>> >>> Dne 26. 10. 23 v 18:26 Pavel Valena napsal(a): >>> >>> >>> >>> On Wed, Oct 25, 2023 at 4:31 PM Vít Ondruch <vondruch@redhat.com> >>> wrote: >>> >>>> >>>> Dne 25. 10. 23 v 16:11 Mamoru TASAKA napsal(a): >>>>> Hi, Vít: >>>>> >>>>> Vít Ondruch wrote on 2023/10/24 23:07: >>>>>> Hi, >>>>>> >>>>>> I am back again with updated version of Ruby, this time c44d65427e. >>>>>> Please see the changes in the upstream PR and test the build >>>>>> (currently in progress) here: >>>>>> >>>>>> https://koji.fedoraproject.org/koji/taskinfo?taskID=108034430 >>>>>> >>>>>> Apart of fixes for the "user install gems" discussed in other parts >>>>>> of this thread, there is fix for the "TestYJIT#test_bug_19316" test >>>>>> failure (which is not important on itself, just a few of you were >>>>>> involved, thx!). I have not noticed anything else outstanding. >>>>>> >>>>>> As always, please give it a try and I am looking forward to your >>>>>> feedback. >>>> >>> >>> Hello, >>> >>> this time I'm getting strange build errors in my COPR like: >>> >>> ``` >>> /builddir/build/BUILD/ruby-3.3.0-c44d65427e/redhat-linux-build/ruby: >>> error while loading shared libraries: libruby.so.3.3: cannot open >>> shared >>> object file: No such file or directory >>> ``` >>> https://gist.github.com/pvalena/63a91bca8ddf40c275f1f218b9a265a9 >>> https://copr.fedorainfracloud.org/coprs/build/6565734 Oh, I can finally see the error. So this would be the right place to take a look at to get a whole picture: https://download.copr.fedorainfracloud.org/results/pvalena/ruby-testing/fedora-rawhide-x86_64/06565734-ruby/builder-live.log.gz >>> >>> Not sure if that's something on my side... It's not a random error >>> though. >>> Strangely enough, I can't reproduce it locally (local build is >>> fine), even >>> in the same buildroot. >>> >>> >>> Sorry, not sure what is going on and the links you have shared don't >>> provide enough context. The rawhide builds are either complete or they >>> failed with different issue then the Gist. >>> >> >> I believe the error is really there, but I might be mistaken to >> consider it >> most important part of the log. >> It's in between the >> ----------------------------------------------------------------------; >> here f.e. in fedora-rawhide-x86_64: >> >> ~~~ >> Invoking >> `/builddir/build/BUILD/ruby-3.3.0-c44d65427e/redhat-linux-build/ruby >> -rrubygems /builddir/build/BUILD/ruby-3.3.0-c44d65427e/bin/gem >> --backtrace >> build lib/bundler/bundler.gemspec` failed with output: >> ---------------------------------------------------------------------- >> /builddir/build/BUILD/ruby-3.3.0-c44d65427e/redhat-linux-build/ruby: >> error while loading shared libraries: libruby.so.3.3: cannot open shared >> object file: No such file or directory >> ---------------------------------------------------------------------- >> # ./spec/bundler/support/helpers.rb:202:in `sys_exec' >> # ./spec/bundler/support/helpers.rb:165:in `gem_command' >> # ./spec/bundler/support/helpers.rb:343:in `with_built_bundler' >> # ./spec/bundler/support/helpers.rb:304:in `block (2 levels) in >> system_gems' >> # ./spec/bundler/support/helpers.rb:300:in `each' >> # ./spec/bundler/support/helpers.rb:300:in `block in system_gems' >> # ./spec/bundler/support/helpers.rb:357:in `block in with_gem_path_as' >> # ./spec/bundler/support/helpers.rb:371:in `without_env_side_effects' >> # ./spec/bundler/support/helpers.rb:352:in `with_gem_path_as' >> # ./spec/bundler/support/helpers.rb:298:in `system_gems' >> # ./spec/bundler/spec_helper.rb:92:in `block (2 levels) in <top >> (required)>' >> ~~~ >> >> Yes, it's very strange - and it happens every time I try. But I'm >> fine with >> it as long as no one else experiences the issue :). >> >> Builds so far: >> https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6565230/ >> >> https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6567675/ >> >> https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6565734/ >> >> https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6565235/ >> >> https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6582818/ >> >> >> It didn't happen with previous builds though.... > > > Looking at your copr setting, you have enabled "--with bundler_tests" on > x86_64 arch only: > > ``` > Modified fedora-rawhide-x86_64: > Mock options: --with bundler_tests > ``` > and correspondingly build is failing on > > + make -C redhat-linux-build test-bundler-parallel Good catch! Thank you for providing second (third?) pair of eyes. It is indeed good idea to test Bundler. Now who will only fix this? :DGood catch indeed. Thanks for looking into this, I totally forgot I have enabled it, as the tests did just work :]. I'm afraid I don't have any spare cycles to look into this though.
https://bugs.ruby-lang.org/issues/19984
Vít
Hi,
Here is yet another Ruby 3.3 snapshot, this time a1e24ab484:
https://koji.fedoraproject.org/koji/taskinfo?taskID=108418495
The respective changes are available in my PR. There is nothing particular what would catch my attention. Happy testing and thx for all the feedback and support.
Vít
Hi,
On 11/1/23 17:13, Vít Ondruch wrote:
Hi,
Here is yet another Ruby 3.3 snapshot, this time a1e24ab484:
https://koji.fedoraproject.org/koji/taskinfo?taskID=108418495
The respective changes are available in my PR. There is nothing particular what would catch my attention. Happy testing and thx for all the feedback and support.
JFTR, rubygem-rdoc has broken deps, resulting in not being able to install rubygem-rdoc and on EL* systems also the rubygems-devel by extension, this has to do with the `.dev` suffix that gets transformed in rubygem-io-console version.
For fedora, I am doing the repoqueries and installs agains my new reverse dep rebuild Copr, with the SRPM from the koji build mentioned above (no content edits or adjustments): https://copr.fedorainfracloud.org/coprs/jackorp/ruby-3.3-fedora-november/
The correct rdoc refuses to install: ~~~ $ dnf install rubygem-rdoc-6.5.0-183.fc40.noarch Last metadata expiration check: 0:09:16 ago on Tue Nov 7 11:44:02 2023. Error: Problem: conflicting requests - nothing provides rubygem(io-console) >= 0.6.1.dev needed by rubygem-rdoc-6.5.0-183.fc40.noarch from copr:copr.fedorainfracloud.org:jackorp:ruby-3.3-fedora-november (try to add '--skip-broken' to skip uninstallable packages) ~~~
I'll paste just relevant parts of rpm queries, to minimize noise: Fedora Rawhide: ~~~ $ dnf install rubygems-devel $ rpm -q --requires rubygems-devel rubygem(rdoc) >= 6.5.0
$ rpm -q rubygems-devel rubygems-devel-3.5.0.dev-183.fc40.noarch
# rubygem-rdoc of this exact version is uninstallable $ dnf repoquery --requires "rubygem-rdoc-6.5.0-183.fc40.noarch" rubygem(io-console) >= 0.6.1.dev
$ rpm -q --provides rubygem-io-console rubygem(io-console) = 0.6.1~dev rubygem-io-console = 0.6.1.dev-183.fc40 rubygem-io-console(x86-64) = 0.6.1.dev-183.fc40
~~~
Output for EL9 is more or less the same, just s/fc40/el9/, but it's more problematic there, as there isn't new enough version of rdoc, unlike in Fedora.
Jarek
Vít
Dne 07. 11. 23 v 12:56 jprokop@redhat.com napsal(a):
Hi,
On 11/1/23 17:13, Vít Ondruch wrote:
Hi,
Here is yet another Ruby 3.3 snapshot, this time a1e24ab484:
https://koji.fedoraproject.org/koji/taskinfo?taskID=108418495
The respective changes are available in my PR. There is nothing particular what would catch my attention. Happy testing and thx for all the feedback and support.
JFTR, rubygem-rdoc has broken deps, resulting in not being able to install rubygem-rdoc and on EL* systems also the rubygems-devel by extension, this has to do with the `.dev` suffix that gets transformed in rubygem-io-console version.
For fedora, I am doing the repoqueries and installs agains my new reverse dep rebuild Copr, with the SRPM from the koji build mentioned above (no content edits or adjustments): https://copr.fedorainfracloud.org/coprs/jackorp/ruby-3.3-fedora-november/
The correct rdoc refuses to install:
$ dnf install rubygem-rdoc-6.5.0-183.fc40.noarch Last metadata expiration check: 0:09:16 ago on Tue Nov 7 11:44:02 2023. Error: Problem: conflicting requests - nothing provides rubygem(io-console) >= 0.6.1.dev needed by rubygem-rdoc-6.5.0-183.fc40.noarch from copr:copr.fedorainfracloud.org:jackorp:ruby-3.3-fedora-november (try to add '--skip-broken' to skip uninstallable packages)I'll paste just relevant parts of rpm queries, to minimize noise: Fedora Rawhide:
$ dnf install rubygems-devel $ rpm -q --requires rubygems-devel rubygem(rdoc) >= 6.5.0 $ rpm -q rubygems-devel rubygems-devel-3.5.0.dev-183.fc40.noarch # rubygem-rdoc of this exact version is uninstallable $ dnf repoquery --requires "rubygem-rdoc-6.5.0-183.fc40.noarch" rubygem(io-console) >= 0.6.1.dev $ rpm -q --provides rubygem-io-console rubygem(io-console) = 0.6.1~dev rubygem-io-console = 0.6.1.dev-183.fc40 rubygem-io-console(x86-64) = 0.6.1.dev-183.fc40Output for EL9 is more or less the same, just s/fc40/el9/, but it's more problematic there, as there isn't new enough version of rdoc, unlike in Fedora.
Good spot. Yes, this is quite unfortunate. We have already faced similar issues, but that were typically just issues with upgrades, which were easy to neglect. But this would probably deserve some improvement.
The issue is that wile it is easy to generate provides such as `rubygem(io-console) = 0.6.1~dev`, where the `~` replaces the period, because there is information about "pre-release", it is not that easy to generate the requires, because there is no such information that the dependency is pre-release. So I can see several options:
1) Close our eyes and ignore the issue in a hope that stable release will not suffer the same
2) Improve the requires generator. But there will be needed some heuristics, which might be error prone.
3) Temporarily patch the tarball and drop the `.dev` suffix(es).
Not sure if (3) is feasible, but at the first look, this looks to be like the least effort.
Vít
On 11/9/23 18:27, Vít Ondruch wrote:
Dne 07. 11. 23 v 12:56 jprokop@redhat.com napsal(a):
Hi,
On 11/1/23 17:13, Vít Ondruch wrote:
Hi,
Here is yet another Ruby 3.3 snapshot, this time a1e24ab484:
https://koji.fedoraproject.org/koji/taskinfo?taskID=108418495
The respective changes are available in my PR. There is nothing particular what would catch my attention. Happy testing and thx for all the feedback and support.
JFTR, rubygem-rdoc has broken deps, resulting in not being able to install rubygem-rdoc and on EL* systems also the rubygems-devel by extension, this has to do with the `.dev` suffix that gets transformed in rubygem-io-console version.
For fedora, I am doing the repoqueries and installs agains my new reverse dep rebuild Copr, with the SRPM from the koji build mentioned above (no content edits or adjustments): https://copr.fedorainfracloud.org/coprs/jackorp/ruby-3.3-fedora-november/
The correct rdoc refuses to install:
$ dnf install rubygem-rdoc-6.5.0-183.fc40.noarch Last metadata expiration check: 0:09:16 ago on Tue Nov 7 11:44:02 2023. Error: Problem: conflicting requests - nothing provides rubygem(io-console) >= 0.6.1.dev needed by rubygem-rdoc-6.5.0-183.fc40.noarch from copr:copr.fedorainfracloud.org:jackorp:ruby-3.3-fedora-november (try to add '--skip-broken' to skip uninstallable packages)I'll paste just relevant parts of rpm queries, to minimize noise: Fedora Rawhide:
$ dnf install rubygems-devel $ rpm -q --requires rubygems-devel rubygem(rdoc) >= 6.5.0 $ rpm -q rubygems-devel rubygems-devel-3.5.0.dev-183.fc40.noarch # rubygem-rdoc of this exact version is uninstallable $ dnf repoquery --requires "rubygem-rdoc-6.5.0-183.fc40.noarch" rubygem(io-console) >= 0.6.1.dev $ rpm -q --provides rubygem-io-console rubygem(io-console) = 0.6.1~dev rubygem-io-console = 0.6.1.dev-183.fc40 rubygem-io-console(x86-64) = 0.6.1.dev-183.fc40Output for EL9 is more or less the same, just s/fc40/el9/, but it's more problematic there, as there isn't new enough version of rdoc, unlike in Fedora.
Good spot. Yes, this is quite unfortunate. We have already faced similar issues, but that were typically just issues with upgrades, which were easy to neglect. But this would probably deserve some improvement.
The issue is that wile it is easy to generate provides such as `rubygem(io-console) = 0.6.1~dev`, where the `~` replaces the period, because there is information about "pre-release", it is not that easy to generate the requires, because there is no such information that the dependency is pre-release. So I can see several options:
- Close our eyes and ignore the issue in a hope that stable release
will not suffer the same
Generally up for this option for this situation. So far I have just adjusted the spec: ~~~ %package -n rubygem-io-console # ... Other definitions for the package ... Provides: rubygem(io-console) = 0.6.1.dev ~~~
- Improve the requires generator. But there will be needed some
heuristics, which might be error prone.
This'd be preferred, or adjust the provides generator.
I'd like to point out that I noticed there is already some smartistic on the Provider generator side: https://src.fedoraproject.org/rpms/ruby/blob/5fd12c42e7911fe5a07db3f92167983... Could we just provide %{version}.dev AND %{version}~dev for such packages? We'd dodge doing error prone heuristics on Requirement generator and be IMO more correct in listing provides for pre-release gem versions.
- Temporarily patch the tarball and drop the `.dev` suffix(es).
3) a) If any such situation arises for actual release, adjust the requirement via already existing macros, to workaround this situation.
But I find point 3 overall to not be that great (I prefer option 1 for WIP pre-release PRs, least amount of work IMO).
Jarek
Not sure if (3) is feasible, but at the first look, this looks to be like the least effort.
Vít
Dne 09. 11. 23 v 19:09 jprokop@redhat.com napsal(a):
On 11/9/23 18:27, Vít Ondruch wrote:
Dne 07. 11. 23 v 12:56 jprokop@redhat.com napsal(a):
Hi,
On 11/1/23 17:13, Vít Ondruch wrote:
Hi,
Here is yet another Ruby 3.3 snapshot, this time a1e24ab484:
https://koji.fedoraproject.org/koji/taskinfo?taskID=108418495
The respective changes are available in my PR. There is nothing particular what would catch my attention. Happy testing and thx for all the feedback and support.
JFTR, rubygem-rdoc has broken deps, resulting in not being able to install rubygem-rdoc and on EL* systems also the rubygems-devel by extension, this has to do with the `.dev` suffix that gets transformed in rubygem-io-console version.
For fedora, I am doing the repoqueries and installs agains my new reverse dep rebuild Copr, with the SRPM from the koji build mentioned above (no content edits or adjustments): https://copr.fedorainfracloud.org/coprs/jackorp/ruby-3.3-fedora-november/
The correct rdoc refuses to install:
$ dnf install rubygem-rdoc-6.5.0-183.fc40.noarch Last metadata expiration check: 0:09:16 ago on Tue Nov 7 11:44:02 2023. Error: Problem: conflicting requests - nothing provides rubygem(io-console) >= 0.6.1.dev needed by rubygem-rdoc-6.5.0-183.fc40.noarch from copr:copr.fedorainfracloud.org:jackorp:ruby-3.3-fedora-november (try to add '--skip-broken' to skip uninstallable packages)I'll paste just relevant parts of rpm queries, to minimize noise: Fedora Rawhide:
$ dnf install rubygems-devel $ rpm -q --requires rubygems-devel rubygem(rdoc) >= 6.5.0 $ rpm -q rubygems-devel rubygems-devel-3.5.0.dev-183.fc40.noarch # rubygem-rdoc of this exact version is uninstallable $ dnf repoquery --requires "rubygem-rdoc-6.5.0-183.fc40.noarch" rubygem(io-console) >= 0.6.1.dev $ rpm -q --provides rubygem-io-console rubygem(io-console) = 0.6.1~dev rubygem-io-console = 0.6.1.dev-183.fc40 rubygem-io-console(x86-64) = 0.6.1.dev-183.fc40Output for EL9 is more or less the same, just s/fc40/el9/, but it's more problematic there, as there isn't new enough version of rdoc, unlike in Fedora.
Good spot. Yes, this is quite unfortunate. We have already faced similar issues, but that were typically just issues with upgrades, which were easy to neglect. But this would probably deserve some improvement.
The issue is that wile it is easy to generate provides such as `rubygem(io-console) = 0.6.1~dev`, where the `~` replaces the period, because there is information about "pre-release", it is not that easy to generate the requires, because there is no such information that the dependency is pre-release. So I can see several options:
- Close our eyes and ignore the issue in a hope that stable release
will not suffer the same
Generally up for this option for this situation. So far I have just adjusted the spec:
%package -n rubygem-io-console # ... Other definitions for the package ... Provides: rubygem(io-console) = 0.6.1.dev
Yes, this will probably work, as long as Ruby is always installed on clean system. However, should there come io-console 0.6.1, the 0.6.1.dev might be kept installed I am afraid.
~~~
$ rpmdev-vercmp 0.6.1.dev 0.6.1 0.6.1.dev > 0.6.1
~~~
But not sure. You can check and let me know ;)
- Improve the requires generator. But there will be needed some
heuristics, which might be error prone.
This'd be preferred, or adjust the provides generator.
I'd like to point out that I noticed there is already some smartistic on the Provider generator side: https://src.fedoraproject.org/rpms/ruby/blob/5fd12c42e7911fe5a07db3f92167983... Could we just provide %{version}.dev AND %{version}~dev for such packages? We'd dodge doing error prone heuristics on Requirement generator and be IMO more correct in listing provides for pre-release gem versions.
It would be easy to generate the additional provide, but I am afraid it would be problematic as I have explained above.
- Temporarily patch the tarball and drop the `.dev` suffix(es).
a) If any such situation arises for actual release, adjust the requirement via already existing macros, to workaround this situation.
After all, I went for much simpler solution ;)
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/bb3a95723018cc892089...
The only remaining question is if the remaining `Recommends: rubygem(io-console)` should be treated the same way. Being soft dependencies, I believe that the `Requires` wins and the `Recommends` becomes no op. Not really sure if the version might help updating io-console at some point or it might actually hinder the installation, because e.g. there actually might have been io-console 0.6.1.dev installed already.
The more I think about it, the more I am in favor of removing the versions from io-console dependencies altogether.
Vít
But I find point 3 overall to not be that great (I prefer option 1 for WIP pre-release PRs, least amount of work IMO).
Jarek
Not sure if (3) is feasible, but at the first look, this looks to be like the least effort.
Vít
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@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.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Hi,
I am back again with yet another update, this time commit ad3db6711c. The changes are in my PR and the build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=108809158
I have not noticed anything really interesting. The most interesting thing is actually inclusion of the changes from the "Cache `Gem.default_dir`" PR [1]. That helps with RubyGems test suite. I currently observe just 7 test failures, which is nice improvement.
As always, than you for all the feedback and help with fixing all the dependencies. Good job everybody!
Vít
[1] https://src.fedoraproject.org/rpms/ruby/pull-request/162
Hi,
I am back with yet another update of Ruby 3.3, this time rev 24e0b185ab. The changes are in my PR and the scratch build is available here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=109487230
This starting to be boring, because there is nothing what would caught my attention. So the only thing worth of mentioning is that there are included several RubyGems, which fixes multiple test failures of RubyGems test suite running on Fedora Ruby. And this also my give some change to my proposal:
https://bugs.ruby-lang.org/issues/19972
As always. Any feedback is welcome.
Vít
Vít Ondruch wrote on 2023/11/24 22:17:
Hi,
I am back with yet another update of Ruby 3.3, this time rev 24e0b185ab. The changes are in my PR and the scratch build is available here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=109487230
This starting to be boring, because there is nothing what would caught my attention. So the only thing worth of mentioning is that there are included several RubyGems, which fixes multiple test failures of RubyGems test suite running on Fedora Ruby. And this also my give some change to my proposal:
https://bugs.ruby-lang.org/issues/19972
As always. Any feedback is welcome.
Vít
Ummmm....
Looks like * Test passing: https://github.com/ruby/ruby/commit/c8b60c8ac2c8bbd077150792b5b207e983ab3634 * Test failing: https://github.com/ruby/ruby/commit/071df40495e31f6d3fd14ae8686b01edf9a689e3
``` 1) An exception occurred during: before :each UDPSocket#local_address using IPv4 using an implicit hostname the returned Addrinfo uses the correct IP address ERROR Socket::ResolutionError: getaddrinfo: Name or service not known /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/local_address_spec.rb:66:in `connect' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/local_address_spec.rb:66:in `block (4 levels) in <top (required)>' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/local_address_spec.rb:4:in `<top (required)>'
2) An exception occurred during: before :each UDPSocket#local_address using IPv6 using an implicit hostname the returned Addrinfo uses the correct IP address ERROR Socket::ResolutionError: getaddrinfo: Name or service not known /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/local_address_spec.rb:66:in `connect' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/local_address_spec.rb:66:in `block (4 levels) in <top (required)>' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/local_address_spec.rb:4:in `<top (required)>'
3) An exception occurred during: before :each UDPSocket#remote_address using IPv4 using an implicit hostname the returned Addrinfo uses the correct IP address ERROR Socket::ResolutionError: getaddrinfo: Name or service not known /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/remote_address_spec.rb:65:in `connect' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/remote_address_spec.rb:65:in `block (4 levels) in <top (required)>' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/remote_address_spec.rb:4:in `<top (required)>'
4) An exception occurred during: before :each UDPSocket#remote_address using IPv6 using an implicit hostname the returned Addrinfo uses the correct IP address ERROR Socket::ResolutionError: getaddrinfo: Name or service not known /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/remote_address_spec.rb:65:in `connect' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/remote_address_spec.rb:65:in `block (4 levels) in <top (required)>' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/remote_address_spec.rb:4:in `<top (required)>'
Finished in 65.764894 seconds
3728 files, 32871 examples, 191872 expectations, 0 failures, 4 errors, 0 tagged ```
I may try to bisect (I am going to bed for now), but maybe due to this commit?
Mamoru https://github.com/ruby/ruby/commit/d2ba8ea54a4089959afdeecdd963e3c4ff391748
Dne 07. 12. 23 v 15:27 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2023/11/24 22:17:
Hi,
I am back with yet another update of Ruby 3.3, this time rev 24e0b185ab. The changes are in my PR and the scratch build is available here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=109487230
This starting to be boring, because there is nothing what would caught my attention. So the only thing worth of mentioning is that there are included several RubyGems, which fixes multiple test failures of RubyGems test suite running on Fedora Ruby. And this also my give some change to my proposal:
https://bugs.ruby-lang.org/issues/19972
As always. Any feedback is welcome.
Vít
Ummmm....
Looks like
- Test passing:
https://github.com/ruby/ruby/commit/c8b60c8ac2c8bbd077150792b5b207e983ab3634
- Test failing:
https://github.com/ruby/ruby/commit/071df40495e31f6d3fd14ae8686b01edf9a689e3
1) An exception occurred during: before :each UDPSocket#local_address using IPv4 using an implicit hostname the returned Addrinfo uses the correct IP address ERROR Socket::ResolutionError: getaddrinfo: Name or service not known /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/local_address_spec.rb:66:in `connect' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/local_address_spec.rb:66:in `block (4 levels) in <top (required)>' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/local_address_spec.rb:4:in `<top (required)>' 2) An exception occurred during: before :each UDPSocket#local_address using IPv6 using an implicit hostname the returned Addrinfo uses the correct IP address ERROR Socket::ResolutionError: getaddrinfo: Name or service not known /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/local_address_spec.rb:66:in `connect' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/local_address_spec.rb:66:in `block (4 levels) in <top (required)>' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/local_address_spec.rb:4:in `<top (required)>' 3) An exception occurred during: before :each UDPSocket#remote_address using IPv4 using an implicit hostname the returned Addrinfo uses the correct IP address ERROR Socket::ResolutionError: getaddrinfo: Name or service not known /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/remote_address_spec.rb:65:in `connect' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/remote_address_spec.rb:65:in `block (4 levels) in <top (required)>' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/remote_address_spec.rb:4:in `<top (required)>' 4) An exception occurred during: before :each UDPSocket#remote_address using IPv6 using an implicit hostname the returned Addrinfo uses the correct IP address ERROR Socket::ResolutionError: getaddrinfo: Name or service not known /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/remote_address_spec.rb:65:in `connect' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/remote_address_spec.rb:65:in `block (4 levels) in <top (required)>' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/remote_address_spec.rb:4:in `<top (required)>' Finished in 65.764894 seconds 3728 files, 32871 examples, 191872 expectations, 0 failures, 4 errors, 0 taggedI may try to bisect (I am going to bed for now), but maybe due to this commit?
Mamoru https://github.com/ruby/ruby/commit/d2ba8ea54a4089959afdeecdd963e3c4ff391748
By coincidence, I started to experiment with the same commit and I can confirm the issue. This is due to our builder being offline. When enabling the network access, the test cases pass just fine. I have reported this upstream:
https://bugs.ruby-lang.org/issues/20048
Thank you for heads up.
Vít
Hi everybody,
Here is yet another snapshot of Ruby 3.3, this time rev 071df40495:
https://koji.fedoraproject.org/koji/taskinfo?taskID=110009405
From upstream POV, I have not noticed nothing particularly interesting.
But I have reverted back the `%gem_install` macro to use again the `--build-root` option. However:
1) I have not tested the changes
2) and I am not 100% sure for how long, because I'd like to experiment with reverting operating_system.rb back away from using `--user-install` [1]. Previously, there were issues with default gems, but the default gems location is configurable these days [2]. But this might unfortunately need more work or some patches, because the recent changes [3] with possible default use of `--user-install` might have still some rough edges.
As always, thank you for your testing and thanks for all your feedback.
Vít
[1] https://src.fedoraproject.org/rpms/ruby/c/5bd6a6753bdf406a2ce63cb6012a979ab4...
Hi everybody,
Ruby 3.3 RC1 is here:
https://www.ruby-lang.org/en/news/2023/12/11/ruby-3-3-0-rc1-released/
And therefore I have updated the PR with recent changes and the build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=110183096
I have not seen anything what would caught my attention. And I hope that there won't be any big changes since now, because upstream promises stable ABI with RC1:
https://bugs.ruby-lang.org/issues/19980#note-3
We will see. As always, any feedback is welcome.
Vít
Vít Ondruch wrote on 2023/12/11 21:26:
Hi everybody,
Ruby 3.3 RC1 is here:
https://www.ruby-lang.org/en/news/2023/12/11/ruby-3-3-0-rc1-released/
And therefore I have updated the PR with recent changes and the build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=110183096
I have not seen anything what would caught my attention. And I hope that there won't be any big changes since now, because upstream promises stable ABI with RC1:
https://bugs.ruby-lang.org/issues/19980#note-3
We will see. As always, any feedback is welcome.
Vít
Okay, thank you.
Now I've again tried rebuilding all rubygem-XXX packages with https://github.com/ruby/ruby/commit/505715ddf17e004d184c0b71afb40a31e2e8c98e (later than ruby-3.3RC1 commit) (with additional notes). The results are again shown as below.
Now 10 packages are failing to build:
A. The following 6 packages are failing due to the same reasons as before:
1. rubygem-actionview https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/bui... 2. rubygem-aruba https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/bui... 3. rubygem-async_sinatra https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/bui... 4. rubygem-byebug https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/bui... 5. rubygem-childprocess https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/bui... 6. rubygem-ronn-ng https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/bui...
B. The following packages failed to build, build failure was occuring from before, but this time failed with the different reasons than before
7. rubygem-railties https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/bui... Test suite expects some output, but actual output shows some diffs than expected like: ``` F
Failure: ApplicationTests::BinSetupTest#test_bin_setup_output [test/application/bin_setup_test.rb:51]: --- expected +++ actual @@ -2,10 +2,22 @@ The Gemfile's dependencies are satisfied
== Preparing database == +/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/message_verifier.rb:4: warning: base64 was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add base64 to your Gemfile or gemspec. Also contact author of activesupport-7.0.8 to add base64 into its gemspec. +/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/core_ext/object/json.rb:5: warning: bigdecimal was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add bigdecimal to your Gemfile or gemspec. Also contact author of activesupport-7.0.8 to add bigdecimal into its gemspec. +/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/notifications/fanout.rb:3: warning: mutex_m was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add mutex_m to your Gemfile or gemspec. Also contact author of activesupport-7.0.8 to add mutex_m into its gemspec. +/usr/share/gems/gems/mail-2.7.1/lib/mail.rb:9: warning: net/smtp was loaded from the standard library, but is not part of the default gems since Ruby 3.1.0. Add net-smtp to your Gemfile or gemspec. Also contact author of mail-2.7.1 to add net-smtp into its gemspec. Created database 'app_development' Created database 'app_test' ```
C. New failures 8. rubygem-rails-deprecated_sanitizer https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/bui... ``` 1) Failure: DeprecatedSanitizerTest#test_Action_View_sanitizer_vendor_returns_constant_from_HTML_module [/builddir/build/BUILD/rails-deprecated_sanitizer-1.0.4/usr/share/gems/gems/rails-deprecated_sanitizer-1.0.4/test/deprecated_sanitizer_test.rb:15]: Expected: HTML::LinkSanitizer Actual: Rails::HTML4::LinkSanitizer ``` Most likely due to rubygem-rails-html-sanitizer update from 1.4.3 to 1.6.0, especially perhaps due to this commit: https://github.com/rails/rails-html-sanitizer/commit/206942674e5fb16e90d777d... Maybe just fixing rails-deprecated_sanitizer testsuite is fine, but I am not sure.
Note that rawhide koschei build is also failing: https://koschei.fedoraproject.org/package/rubygem-rails-deprecated_sanitizer...
9. rubygem-rubygems-mirror https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/bui... ``` + ruby -Ilib -e 'Dir.glob "./test/test_*.rb", &method(:require)' internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:127:in `require': cannot load such file -- rubygems/indexer (LoadError) from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:127:in `require' from /builddir/build/BUILD/rubygems-mirror-1.3.0/usr/share/gems/gems/rubygems-mirror-1.3.0/lib/rubygems/mirror/test_setup.rb:7:in `<top (required)>' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:127:in `require' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:127:in `require' from /builddir/build/BUILD/rubygems-mirror-1.3.0/usr/share/gems/gems/rubygems-mirror-1.3.0/test/test_gem_mirror.rb:3:in `<top (required)>' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:127:in `require' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:127:in `require' from internal:dir:411:in `glob' from -e:1:in `<main>' ``` This is due to: https://github.com/ruby/ruby/commit/4817166e54ad98f9b3e9d06e9e8c7ccff992a957 Maybe packaging rubygem-rubygems-generate_index rpm is needed.
10. rubygem-puma Well, actually the testsuite of this package seems very flaky... https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/pac...
Maybe testsuite again gets successful when I resubmit build when the overload on copr build server is low, I am not sure.
Notes: D. rubygem-liquid (which was previously failing to build) now fixed with applying upstream PR.
E. Actually the following packages fail to build with ruby commit:505715ddf17e004d184c0b71afb40a31e2e8c98e as well as with ruby 3.3RC1: * rubygem-eventmachine * rubygem-log4r It turned out to be exactly due to: https://bugs.ruby-lang.org/issues/20048 (UDPSocket getaddrinfo issue). I've verified that now the above 2 packages successfully build after: https://github.com/ruby/ruby/commit/25711e7063060920d14e42a530da6f7198926629
Anyway I think now ruby 3.3 state is almost good.
Regards, Mamoru
Dne 12. 12. 23 v 15:11 Mamoru TASAKA napsal(a):
C. New failures 8. rubygem-rails-deprecated_sanitizer https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/bui...
1) Failure: DeprecatedSanitizerTest#test_Action_View_sanitizer_vendor_returns_constant_from_HTML_module [/builddir/build/BUILD/rails-deprecated_sanitizer-1.0.4/usr/share/gems/gems/rails-deprecated_sanitizer-1.0.4/test/deprecated_sanitizer_test.rb:15]: Expected: HTML::LinkSanitizer Actual: Rails::HTML4::LinkSanitizerMost likely due to rubygem-rails-html-sanitizer update from 1.4.3 to 1.6.0,
Did I break it by update? I hope it fixed something else at least :) Anyway, do we still need it? Will need to take a look.
especially perhaps due to this commit: https://github.com/rails/rails-html-sanitizer/commit/206942674e5fb16e90d777d... Maybe just fixing rails-deprecated_sanitizer testsuite is fine, but I am not sure.
Note that rawhide koschei build is also failing: https://koschei.fedoraproject.org/package/rubygem-rails-deprecated_sanitizer...
I wish Koschei notifications were back ...
- rubygem-rubygems-mirror
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/bui...
+ ruby -Ilib -e 'Dir.glob "./test/test_*.rb", &method(:require)' <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:127:in `require': cannot load such file -- rubygems/indexer (LoadError) from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:127:in `require' from /builddir/build/BUILD/rubygems-mirror-1.3.0/usr/share/gems/gems/rubygems-mirror-1.3.0/lib/rubygems/mirror/test_setup.rb:7:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:127:in `require' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:127:in `require' from /builddir/build/BUILD/rubygems-mirror-1.3.0/usr/share/gems/gems/rubygems-mirror-1.3.0/test/test_gem_mirror.rb:3:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:127:in `require' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:127:in `require' from <internal:dir>:411:in `glob' from -e:1:in `<main>'This is due to: https://github.com/ruby/ruby/commit/4817166e54ad98f9b3e9d06e9e8c7ccff992a957 Maybe packaging rubygem-rubygems-generate_index rpm is needed.
This is unfortunate :/ I have made a comment here:
https://github.com/rubygems/rubygems/pull/7085#issuecomment-1852192107
Vít
Dne 12. 12. 23 v 15:59 Vít Ondruch napsal(a):
Dne 12. 12. 23 v 15:11 Mamoru TASAKA napsal(a):
C. New failures 8. rubygem-rails-deprecated_sanitizer https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/bui...
1) Failure: DeprecatedSanitizerTest#test_Action_View_sanitizer_vendor_returns_constant_from_HTML_module [/builddir/build/BUILD/rails-deprecated_sanitizer-1.0.4/usr/share/gems/gems/rails-deprecated_sanitizer-1.0.4/test/deprecated_sanitizer_test.rb:15]: Expected: HTML::LinkSanitizer Actual: Rails::HTML4::LinkSanitizerMost likely due to rubygem-rails-html-sanitizer update from 1.4.3 to 1.6.0,
Did I break it by update? I hope it fixed something else at least :) Anyway, do we still need it? Will need to take a look.
This used to be needed by rubygem-rails-dom-testing, but the dependency was dropped with version 2+ [1]. I have orphaned the rubygem-rails-deprecated_sanitizer.
Vít
[1] https://github.com/rails/rails-dom-testing/commit/06adecc349381e906c481c3296...
Dne 12. 12. 23 v 15:11 Mamoru TASAKA napsal(a):
- rubygem-rubygems-mirror
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/bui...
+ ruby -Ilib -e 'Dir.glob "./test/test_*.rb", &method(:require)' <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:127:in `require': cannot load such file -- rubygems/indexer (LoadError) from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:127:in `require' from /builddir/build/BUILD/rubygems-mirror-1.3.0/usr/share/gems/gems/rubygems-mirror-1.3.0/lib/rubygems/mirror/test_setup.rb:7:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:127:in `require' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:127:in `require' from /builddir/build/BUILD/rubygems-mirror-1.3.0/usr/share/gems/gems/rubygems-mirror-1.3.0/test/test_gem_mirror.rb:3:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:127:in `require' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:127:in `require' from <internal:dir>:411:in `glob' from -e:1:in `<main>'This is due to: https://github.com/ruby/ruby/commit/4817166e54ad98f9b3e9d06e9e8c7ccff992a957 Maybe packaging rubygem-rubygems-generate_index rpm is needed.
I have reported this here:
https://github.com/rubygems/rubygems-mirror/issues/76
But I don't think this is super important package.
Vít
Vít Ondruch wrote on 2023/12/11 21:26:
Hi everybody,
Ruby 3.3 RC1 is here:
https://www.ruby-lang.org/en/news/2023/12/11/ruby-3-3-0-rc1-released/
And therefore I have updated the PR with recent changes and the build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=110183096
I have not seen anything what would caught my attention. And I hope that there won't be any big changes since now, because upstream promises stable ABI with RC1:
https://bugs.ruby-lang.org/issues/19980#note-3
We will see. As always, any feedback is welcome.
Vít
Another Umm....
Now * Build OK https://github.com/ruby/ruby/commit/2350c7946275cd570cc1d7cd892abc16ac68a92c * Build FAIL https://github.com/ruby/ruby/commit/75f4a687ed54e3b1863ba1767c666a0bea809c8a
Failing like:
``` + make -C redhat-linux-build -s runruby 'TESTRUN_SCRIPT=-e " module Bundler; module Persistent; module Net; module HTTP; end; end; end; end; require '''bundler/vendor/net-http-persistent/lib/net/http/persistent'''; puts '''%{bundler_net_http_persistent_version}: 4.0.2'''; puts %Q[Bundler::Persistent::Net::HTTP::Persistent::VERSION: #{Bundler::Persistent::Net::HTTP::Persistent::VERSION}]; exit 1 if Bundler::Persistent::Net::HTTP::Persistent::VERSION != '''4.0.2'''; "' /builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/rubygems/timeout/lib/timeout.rb:25:in `<top (required)>': uninitialized constant Gem (NameError) from /builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/rubygems/net-protocol/lib/net/protocol.rb:23:in `require_relative' from /builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/rubygems/net-protocol/lib/net/protocol.rb:23:in `<top (required)>' from /builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/rubygems/net-http/lib/net/http.rb:23:in `require_relative' from /builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/rubygems/net-http/lib/net/http.rb:23:in `<top (required)>' from /builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/rubygems/net/http.rb:3:in `require_relative' from /builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/rubygems/net/http.rb:3:in `<top (required)>' from /builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/bundler/vendored_net_http.rb:4:in `require' from /builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/bundler/vendored_net_http.rb:4:in `<top (required)>' from /builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/bundler/vendor/net-http-persistent/lib/net/http/persistent.rb:1:in `require_relative' from /builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/bundler/vendor/net-http-persistent/lib/net/http/persistent.rb:1:in `<top (required)>' from -e:1:in `require' from -e:1:in `<main>' make: *** [uncommon.mk:1375: runruby] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.Dh4Yrz (%check) Bad exit status from /var/tmp/rpm-tmp.Dh4Yrz (%check) ```
Looking at: https://github.com/ruby/ruby/compare/2350c79462...75f4a687ed54e3b1863ba1767c... I suspect the above failure is related to: https://github.com/ruby/ruby/commit/ce924ce1fb029f19fd34a43f2012a485f4f62b53
Vít, would you have a look at this? Thank you.
Regards, Mamoru
Dne 13. 12. 23 v 13:44 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2023/12/11 21:26:
Hi everybody,
Ruby 3.3 RC1 is here:
https://www.ruby-lang.org/en/news/2023/12/11/ruby-3-3-0-rc1-released/
And therefore I have updated the PR with recent changes and the build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=110183096
I have not seen anything what would caught my attention. And I hope that there won't be any big changes since now, because upstream promises stable ABI with RC1:
https://bugs.ruby-lang.org/issues/19980#note-3
We will see. As always, any feedback is welcome.
Vít
Another Umm....
Now
- Build OK
https://github.com/ruby/ruby/commit/2350c7946275cd570cc1d7cd892abc16ac68a92c
- Build FAIL
https://github.com/ruby/ruby/commit/75f4a687ed54e3b1863ba1767c666a0bea809c8a
Failing like:
+ make -C redhat-linux-build -s runruby 'TESTRUN_SCRIPT=-e " module Bundler; module Persistent; module Net; module HTTP; end; end; end; end; require '\''bundler/vendor/net-http-persistent/lib/net/http/persistent'\''; puts '\''%{bundler_net_http_persistent_version}: 4.0.2'\''; puts %Q[Bundler::Persistent::Net::HTTP::Persistent::VERSION: #{Bundler::Persistent::Net::HTTP::Persistent::VERSION}]; exit 1 if Bundler::Persistent::Net::HTTP::Persistent::VERSION != '\''4.0.2'\''; "' /builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/rubygems/timeout/lib/timeout.rb:25:in `<top (required)>': uninitialized constant Gem (NameError) from /builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/rubygems/net-protocol/lib/net/protocol.rb:23:in `require_relative' from /builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/rubygems/net-protocol/lib/net/protocol.rb:23:in `<top (required)>' from /builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/rubygems/net-http/lib/net/http.rb:23:in `require_relative' from /builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/rubygems/net-http/lib/net/http.rb:23:in `<top (required)>' from /builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/rubygems/net/http.rb:3:in `require_relative' from /builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/rubygems/net/http.rb:3:in `<top (required)>' from /builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/bundler/vendored_net_http.rb:4:in `require' from /builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/bundler/vendored_net_http.rb:4:in `<top (required)>' from /builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/bundler/vendor/net-http-persistent/lib/net/http/persistent.rb:1:in `require_relative' from /builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/bundler/vendor/net-http-persistent/lib/net/http/persistent.rb:1:in `<top (required)>' from -e:1:in `require' from -e:1:in `<main>' make: *** [uncommon.mk:1375: runruby] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.Dh4Yrz (%check) Bad exit status from /var/tmp/rpm-tmp.Dh4Yrz (%check)Looking at: https://github.com/ruby/ruby/compare/2350c79462...75f4a687ed54e3b1863ba1767c...
I suspect the above failure is related to: https://github.com/ruby/ruby/commit/ce924ce1fb029f19fd34a43f2012a485f4f62b53
Vít, would you have a look at this? Thank you.
I am probably right about hitting this issue, because there are 4 newly bundled gems and I am adding the version check and other stuff. So yes, stay tuned.
Vít
Regards, Mamoru
-- _______________________________________________ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@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.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Dne 13. 12. 23 v 13:44 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2023/12/11 21:26:
Hi everybody,
Ruby 3.3 RC1 is here:
https://www.ruby-lang.org/en/news/2023/12/11/ruby-3-3-0-rc1-released/
And therefore I have updated the PR with recent changes and the build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=110183096
I have not seen anything what would caught my attention. And I hope that there won't be any big changes since now, because upstream promises stable ABI with RC1:
https://bugs.ruby-lang.org/issues/19980#note-3
We will see. As always, any feedback is welcome.
Vít
Another Umm....
Now
- Build OK
https://github.com/ruby/ruby/commit/2350c7946275cd570cc1d7cd892abc16ac68a92c
- Build FAIL
https://github.com/ruby/ruby/commit/75f4a687ed54e3b1863ba1767c666a0bea809c8a
Failing like:
+ make -C redhat-linux-build -s runruby 'TESTRUN_SCRIPT=-e " module Bundler; module Persistent; module Net; module HTTP; end; end; end; end; require '\''bundler/vendor/net-http-persistent/lib/net/http/persistent'\''; puts '\''%{bundler_net_http_persistent_version}: 4.0.2'\''; puts %Q[Bundler::Persistent::Net::HTTP::Persistent::VERSION: #{Bundler::Persistent::Net::HTTP::Persistent::VERSION}]; exit 1 if Bundler::Persistent::Net::HTTP::Persistent::VERSION != '\''4.0.2'\''; "' /builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/rubygems/timeout/lib/timeout.rb:25:in `<top (required)>': uninitialized constant Gem (NameError) from /builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/rubygems/net-protocol/lib/net/protocol.rb:23:in `require_relative' from /builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/rubygems/net-protocol/lib/net/protocol.rb:23:in `<top (required)>' from /builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/rubygems/net-http/lib/net/http.rb:23:in `require_relative' from /builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/rubygems/net-http/lib/net/http.rb:23:in `<top (required)>' from /builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/rubygems/net/http.rb:3:in `require_relative' from /builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/rubygems/net/http.rb:3:in `<top (required)>' from /builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/bundler/vendored_net_http.rb:4:in `require' from /builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/bundler/vendored_net_http.rb:4:in `<top (required)>' from /builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/bundler/vendor/net-http-persistent/lib/net/http/persistent.rb:1:in `require_relative' from /builddir/build/BUILD/ruby-3.3.0-745ab3e4c7/lib/bundler/vendor/net-http-persistent/lib/net/http/persistent.rb:1:in `<top (required)>' from -e:1:in `require' from -e:1:in `<main>' make: *** [uncommon.mk:1375: runruby] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.Dh4Yrz (%check) Bad exit status from /var/tmp/rpm-tmp.Dh4Yrz (%check)
This should be the medicine:
~~~
@@ -924,12 +983,12 @@ make -C %{_vpath_builddir} -s runruby TESTRUN_SCRIPT="-e " \ # constant Gem (NameError) issue. # https://github.com/rubygems/rubygems/issues/5119 make -C %{_vpath_builddir} -s runruby TESTRUN_SCRIPT="-e " \ - module Bundler; module Persistent; module Net; module HTTP; \ - end; end; end; end; \ + module Gem; end; \ + module Bundler; end; \ require 'bundler/vendor/net-http-persistent/lib/net/http/persistent'; \ puts '%%{bundler_net_http_persistent_version}: %{bundler_net_http_persistent_version}'; \ - puts %Q[Bundler::Persistent::Net::HTTP::Persistent::VERSION: #{Bundler::Persistent::Net::HTTP::Persistent::VERSION}]; \ - exit 1 if Bundler::Persistent::Net::HTTP::Persistent::VERSION != '%{bundler_net_http_persistent_version}'; \ + puts %Q[Gem::Net::HTTP::Persistent::VERSION: #{Gem::Net::HTTP::Persistent::VERSION}]; \ + exit 1 if Gem::Net::HTTP::Persistent::VERSION != '%{bundler_net_http_persistent_version}'; \ ""
# Thor.
~~~
Looking at: https://github.com/ruby/ruby/compare/2350c79462...75f4a687ed54e3b1863ba1767c...
I suspect the above failure is related to: https://github.com/ruby/ruby/commit/ce924ce1fb029f19fd34a43f2012a485f4f62b53
This is the upstream PR for more details:
https://github.com/rubygems/rubygems/pull/6793
Vít
Vít, would you have a look at this? Thank you.
Regards, Mamoru
-- _______________________________________________ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@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.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Hi again,
I'm back with yet another update, this time rev a7ad9f3836. The build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=110284699
This time, there are several changes I'd like to mention.
* There is included patch fixing several of the network related spec failures, therefore we don't need to workaround them anymore.
* There are now several more gems bundled in RubyGems. Mamoru already knows. Apart of the issues he hit, this means the licensing information of RubyGems is not up2date anymore. I have opened several tickets around various default gems and RubyGems requesting license clarification. I have also update the license information in ruby.spec a bit.
* Some of you probably noticed the "auto user install" feature of RubyGems [1]. There were several issues, which should have been fixed now. I thought that it could help us a bit, but I am not sure anymore. In theory, we could remove this branch [2] in our operating_system.rb. But we would constantly need to look at "Defaulting to user installation because default installation directory (#{Gem.dir}) is not writable." message, which does not make any sense to me. I have proposed this PR [3] to make it configurable (and then probably got completely confused 🤯) ...
Nevertheless, I still believe that configuring the directories without these flags (which we used up until Ruby 2.5) is better over all and therefore I have changed the operating_system.rb to the original way [4]. This is possible now, because the location for default gems can be configured, which was not possible before.
This is also my biggest concern. If you can test this, I'd really appreciate. After all, both methods should be good enough.
And that should be it. Any feedback is appreciated.
Thx a lot
Vít
[1] https://github.com/rubygems/rubygems/pull/5327
[2] https://src.fedoraproject.org/rpms/ruby/blob/5fd12c42e7911fe5a07db3f92167983...
[3] https://github.com/rubygems/rubygems/pull/7243
[4] https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/d3eaae9cc22d725b74df...
Hello, again:
Vít Ondruch wrote on 2023/12/14 0:30:
Hi again,
I'm back with yet another update, this time rev a7ad9f3836. The build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=110284699
This time, there are several changes I'd like to mention.
There is included patch fixing several of the network related spec failures, therefore we don't need to workaround them anymore.
There are now several more gems bundled in RubyGems. Mamoru already knows. Apart of the issues he hit, this means the licensing information of RubyGems is not up2date anymore. I have opened several tickets around various default gems and RubyGems requesting license clarification. I have also update the license information in ruby.spec a bit.
Looks like this is now causing issue on several packages. Now I am trying to rebuild again, but some packages now newly began to fail.
For example, rubygem-actionmailbox now began to fail (previously build was successful), like:
``` + ruby -rbundler -Ilib:test -e 'Dir.glob "./test/**/*_test.rb", &method(:require)' /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/resolver.rb:116:in `rescue in solve_versions': Could not find compatible versions (Bundler::SolveFailure)
Because every version of actionmailer depends on net-imap >= 0 and every version of net-imap depends on net-protocol >= 0, every version of actionmailer requires net-protocol >= 0. So, because net-protocol >= 0 could not be found in locally installed gems and Gemfile depends on actionmailer >= 0, version solving has failed. from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/resolver.rb:79:in `solve_versions' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/resolver.rb:32:in `start' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:595:in `start_resolution' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:311:in `resolve' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:548:in `materialize' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:203:in `specs' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:270:in `specs_for' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/runtime.rb:18:in `setup' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler.rb:164:in `setup' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/setup.rb:23:in `block in <top (required)>' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/ui/shell.rb:159:in `with_level' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/ui/shell.rb:111:in `silence' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/setup.rb:23:in `<top (required)>' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:127:in `require' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:127:in `require' from /builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/dummy/config/boot.rb:4:in `<top (required)>' from /builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/dummy/config/application.rb:1:in `require_relative' from /builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/dummy/config/application.rb:1:in `<top (required)>' from /builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/dummy/config/environment.rb:2:in `require_relative' from /builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/dummy/config/environment.rb:2:in `<top (required)>' from /builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/test_helper.rb:6:in `require_relative' from /builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/test_helper.rb:6:in `<top (required)>' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:127:in `require' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:127:in `require' from /builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/controllers/ingresses/mailgun/inbound_emails_controller_test.rb:3:in `<top (required)>' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:127:in `require' from internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:127:in `require' from internal:dir:411:in `glob' from -e:1:in `<main>' /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/vendor/pub_grub/lib/pub_grub/version_solver.rb:237:in `resolve_conflict': Could not find compatible versions (Bundler::PubGrub::SolveFailure) ``` Link: https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/bui...
Most likely this is due to recent net-http and net-protocol vendorization. Looks like rails related rubygem- packages, and "vagrant-libvirt" package fail to build due to this issue. (vagrant-libvirt: https://copr.fedorainfracloud.org/coprs/mtasaka/rubydep-heavypkg-test-3-2/bu... )
- Some of you probably noticed the "auto user install" feature of RubyGems [1]. There were several issues, which should have been fixed now. I thought that it could help us a bit, but I am not sure anymore. In theory, we could remove this branch [2] in our operating_system.rb. But we would constantly need to look at "Defaulting to user installation because default installation directory (#{Gem.dir}) is not writable." message, which does not make any sense to me. I have proposed this PR [3] to make it configurable (and then probably got completely confused 🤯) ...
Nevertheless, I still believe that configuring the directories without these flags (which we used up until Ruby 2.5) is better over all and therefore I have changed the operating_system.rb to the original way [4]. This is possible now, because the location for default gems can be configured, which was not possible before.
This is also my biggest concern. If you can test this, I'd really appreciate. After all, both methods should be good enough.
And that should be it. Any feedback is appreciated.
Thx a lot
Vít
[1] https://github.com/rubygems/rubygems/pull/5327 [2] https://src.fedoraproject.org/rpms/ruby/blob/5fd12c42e7911fe5a07db3f92167983... [3] https://github.com/rubygems/rubygems/pull/7243 [4] https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/d3eaae9cc22d725b74df...
Mamoru
Dne 14. 12. 23 v 9:21 Mamoru TASAKA napsal(a):
Hello, again:
Vít Ondruch wrote on 2023/12/14 0:30:
Hi again,
I'm back with yet another update, this time rev a7ad9f3836. The build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=110284699
This time, there are several changes I'd like to mention.
- There is included patch fixing several of the network related spec
failures, therefore we don't need to workaround them anymore.
- There are now several more gems bundled in RubyGems. Mamoru already
knows. Apart of the issues he hit, this means the licensing information of RubyGems is not up2date anymore. I have opened several tickets around various default gems and RubyGems requesting license clarification. I have also update the license information in ruby.spec a bit.
Looks like this is now causing issue on several packages. Now I am trying to rebuild again, but some packages now newly began to fail.
For example, rubygem-actionmailbox now began to fail (previously build was successful), like:
+ ruby -rbundler -Ilib:test -e 'Dir.glob "./test/**/*_test.rb", &method(:require)' /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/resolver.rb:116:in `rescue in solve_versions': Could not find compatible versions (Bundler::SolveFailure) Because every version of actionmailer depends on net-imap >= 0 and every version of net-imap depends on net-protocol >= 0, every version of actionmailer requires net-protocol >= 0. So, because net-protocol >= 0 could not be found in locally installed gems and Gemfile depends on actionmailer >= 0, version solving has failed. from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/resolver.rb:79:in `solve_versions' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/resolver.rb:32:in `start' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:595:in `start_resolution' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:311:in `resolve' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:548:in `materialize' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:203:in `specs' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:270:in `specs_for' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/runtime.rb:18:in `setup' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler.rb:164:in `setup' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/setup.rb:23:in `block in <top (required)>' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/ui/shell.rb:159:in `with_level' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/ui/shell.rb:111:in `silence' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/setup.rb:23:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:127:in `require' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:127:in `require' from /builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/dummy/config/boot.rb:4:in `<top (required)>' from /builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/dummy/config/application.rb:1:in `require_relative' from /builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/dummy/config/application.rb:1:in `<top (required)>' from /builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/dummy/config/environment.rb:2:in `require_relative' from /builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/dummy/config/environment.rb:2:in `<top (required)>' from /builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/test_helper.rb:6:in `require_relative' from /builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/test_helper.rb:6:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:127:in `require' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:127:in `require' from /builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/controllers/ingresses/mailgun/inbound_emails_controller_test.rb:3:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:127:in `require' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:127:in `require' from <internal:dir>:411:in `glob' from -e:1:in `<main>' /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/vendor/pub_grub/lib/pub_grub/version_solver.rb:237:in `resolve_conflict': Could not find compatible versions (Bundler::PubGrub::SolveFailure)Link: https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/bui...
Most likely this is due to recent net-http and net-protocol vendorization. Looks like rails related rubygem- packages, and "vagrant-libvirt" package fail to build due to this issue. (vagrant-libvirt: https://copr.fedorainfracloud.org/coprs/mtasaka/rubydep-heavypkg-test-3-2/bu... )
I'll take a close look a bit later.
However, from top of my head, there were also other changes, such as this:
https://github.com/rubygems/rubygems/pull/7242
where the description says "once a default gem is specified directly in the Gemfile, or resolved as a transitive dependency, it becomes part of the bundle and gets treated as a "regular gem", so it's cached, explicitly installed in the configured location, etc."
But this is just wild guess.
(BTW this was reverted a few hours ago by https://github.com/rubygems/rubygems/pull/7266).
Vít
- Some of you probably noticed the "auto user install" feature of
RubyGems [1]. There were several issues, which should have been fixed now. I thought that it could help us a bit, but I am not sure anymore. In theory, we could remove this branch [2] in our operating_system.rb. But we would constantly need to look at "Defaulting to user installation because default installation directory (#{Gem.dir}) is not writable." message, which does not make any sense to me. I have proposed this PR [3] to make it configurable (and then probably got completely confused 🤯) ...
Nevertheless, I still believe that configuring the directories without these flags (which we used up until Ruby 2.5) is better over all and therefore I have changed the operating_system.rb to the original way [4]. This is possible now, because the location for default gems can be configured, which was not possible before.
This is also my biggest concern. If you can test this, I'd really appreciate. After all, both methods should be good enough.
And that should be it. Any feedback is appreciated.
Thx a lot
Vít
[1] https://github.com/rubygems/rubygems/pull/5327 [2] https://src.fedoraproject.org/rpms/ruby/blob/5fd12c42e7911fe5a07db3f92167983... [3] https://github.com/rubygems/rubygems/pull/7243 [4] https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/d3eaae9cc22d725b74df...
Mamoru
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@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.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Dne 14. 12. 23 v 9:51 Vít Ondruch napsal(a):
Dne 14. 12. 23 v 9:21 Mamoru TASAKA napsal(a):
Hello, again:
Vít Ondruch wrote on 2023/12/14 0:30:
Hi again,
I'm back with yet another update, this time rev a7ad9f3836. The build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=110284699
This time, there are several changes I'd like to mention.
- There is included patch fixing several of the network related spec
failures, therefore we don't need to workaround them anymore.
- There are now several more gems bundled in RubyGems. Mamoru
already knows. Apart of the issues he hit, this means the licensing information of RubyGems is not up2date anymore. I have opened several tickets around various default gems and RubyGems requesting license clarification. I have also update the license information in ruby.spec a bit.
Looks like this is now causing issue on several packages. Now I am trying to rebuild again, but some packages now newly began to fail.
For example, rubygem-actionmailbox now began to fail (previously build was successful), like:
+ ruby -rbundler -Ilib:test -e 'Dir.glob "./test/**/*_test.rb", &method(:require)' /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/resolver.rb:116:in `rescue in solve_versions': Could not find compatible versions (Bundler::SolveFailure) Because every version of actionmailer depends on net-imap >= 0 and every version of net-imap depends on net-protocol >= 0, every version of actionmailer requires net-protocol >= 0. So, because net-protocol >= 0 could not be found in locally installed gems and Gemfile depends on actionmailer >= 0, version solving has failed. from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/resolver.rb:79:in `solve_versions' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/resolver.rb:32:in `start' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:595:in `start_resolution' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:311:in `resolve' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:548:in `materialize' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:203:in `specs' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:270:in `specs_for' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/runtime.rb:18:in `setup' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler.rb:164:in `setup' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/setup.rb:23:in `block in <top (required)>' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/ui/shell.rb:159:in `with_level' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/ui/shell.rb:111:in `silence' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/setup.rb:23:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:127:in `require' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:127:in `require' from /builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/dummy/config/boot.rb:4:in `<top (required)>' from /builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/dummy/config/application.rb:1:in `require_relative' from /builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/dummy/config/application.rb:1:in `<top (required)>' from /builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/dummy/config/environment.rb:2:in `require_relative' from /builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/dummy/config/environment.rb:2:in `<top (required)>' from /builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/test_helper.rb:6:in `require_relative' from /builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/test_helper.rb:6:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:127:in `require' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:127:in `require' from /builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/controllers/ingresses/mailgun/inbound_emails_controller_test.rb:3:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:127:in `require' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:127:in `require' from <internal:dir>:411:in `glob' from -e:1:in `<main>' /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/vendor/pub_grub/lib/pub_grub/version_solver.rb:237:in `resolve_conflict': Could not find compatible versions (Bundler::PubGrub::SolveFailure)Link: https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/bui...
Most likely this is due to recent net-http and net-protocol vendorization. Looks like rails related rubygem- packages, and "vagrant-libvirt" package fail to build due to this issue. (vagrant-libvirt: https://copr.fedorainfracloud.org/coprs/mtasaka/rubydep-heavypkg-test-3-2/bu... )
I'll take a close look a bit later.
However, from top of my head, there were also other changes, such as this:
https://github.com/rubygems/rubygems/pull/7242
where the description says "once a default gem is specified directly in the Gemfile, or resolved as a transitive dependency, it becomes part of the bundle and gets treated as a "regular gem", so it's cached, explicitly installed in the configured location, etc."
But this is just wild guess.
(BTW this was reverted a few hours ago by https://github.com/rubygems/rubygems/pull/7266).
Hm, I've got the latest and it did not helped. Well, going to dig deeper ...
Vít
Vít
- Some of you probably noticed the "auto user install" feature of
RubyGems [1]. There were several issues, which should have been fixed now. I thought that it could help us a bit, but I am not sure anymore. In theory, we could remove this branch [2] in our operating_system.rb. But we would constantly need to look at "Defaulting to user installation because default installation directory (#{Gem.dir}) is not writable." message, which does not make any sense to me. I have proposed this PR [3] to make it configurable (and then probably got completely confused 🤯) ...
Nevertheless, I still believe that configuring the directories without these flags (which we used up until Ruby 2.5) is better over all and therefore I have changed the operating_system.rb to the original way [4]. This is possible now, because the location for default gems can be configured, which was not possible before.
This is also my biggest concern. If you can test this, I'd really appreciate. After all, both methods should be good enough.
And that should be it. Any feedback is appreciated.
Thx a lot
Vít
[1] https://github.com/rubygems/rubygems/pull/5327 [2] https://src.fedoraproject.org/rpms/ruby/blob/5fd12c42e7911fe5a07db3f92167983... [3] https://github.com/rubygems/rubygems/pull/7243 [4] https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/d3eaae9cc22d725b74df...
Mamoru
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@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.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Dne 14. 12. 23 v 11:24 Vít Ondruch napsal(a):
Dne 14. 12. 23 v 9:51 Vít Ondruch napsal(a):
Dne 14. 12. 23 v 9:21 Mamoru TASAKA napsal(a):
Hello, again:
Vít Ondruch wrote on 2023/12/14 0:30:
Hi again,
I'm back with yet another update, this time rev a7ad9f3836. The build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=110284699
This time, there are several changes I'd like to mention.
- There is included patch fixing several of the network related
spec failures, therefore we don't need to workaround them anymore.
- There are now several more gems bundled in RubyGems. Mamoru
already knows. Apart of the issues he hit, this means the licensing information of RubyGems is not up2date anymore. I have opened several tickets around various default gems and RubyGems requesting license clarification. I have also update the license information in ruby.spec a bit.
Looks like this is now causing issue on several packages. Now I am trying to rebuild again, but some packages now newly began to fail.
For example, rubygem-actionmailbox now began to fail (previously build was successful), like:
+ ruby -rbundler -Ilib:test -e 'Dir.glob "./test/**/*_test.rb", &method(:require)' /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/resolver.rb:116:in `rescue in solve_versions': Could not find compatible versions (Bundler::SolveFailure) Because every version of actionmailer depends on net-imap >= 0 and every version of net-imap depends on net-protocol >= 0, every version of actionmailer requires net-protocol >= 0. So, because net-protocol >= 0 could not be found in locally installed gems and Gemfile depends on actionmailer >= 0, version solving has failed. from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/resolver.rb:79:in `solve_versions' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/resolver.rb:32:in `start' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:595:in `start_resolution' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:311:in `resolve' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:548:in `materialize' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:203:in `specs' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:270:in `specs_for' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/runtime.rb:18:in `setup' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler.rb:164:in `setup' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/setup.rb:23:in `block in <top (required)>' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/ui/shell.rb:159:in `with_level' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/ui/shell.rb:111:in `silence' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/setup.rb:23:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:127:in `require' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:127:in `require' from /builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/dummy/config/boot.rb:4:in `<top (required)>' from /builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/dummy/config/application.rb:1:in `require_relative' from /builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/dummy/config/application.rb:1:in `<top (required)>' from /builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/dummy/config/environment.rb:2:in `require_relative' from /builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/dummy/config/environment.rb:2:in `<top (required)>' from /builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/test_helper.rb:6:in `require_relative' from /builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/test_helper.rb:6:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:127:in `require' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:127:in `require' from /builddir/build/BUILD/actionmailbox-7.0.8/usr/share/gems/gems/actionmailbox-7.0.8/test/controllers/ingresses/mailgun/inbound_emails_controller_test.rb:3:in `<top (required)>' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:127:in `require' from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:127:in `require' from <internal:dir>:411:in `glob' from -e:1:in `<main>' /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/vendor/pub_grub/lib/pub_grub/version_solver.rb:237:in `resolve_conflict': Could not find compatible versions (Bundler::PubGrub::SolveFailure)Link: https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/bui...
Most likely this is due to recent net-http and net-protocol vendorization. Looks like rails related rubygem- packages, and "vagrant-libvirt" package fail to build due to this issue. (vagrant-libvirt: https://copr.fedorainfracloud.org/coprs/mtasaka/rubydep-heavypkg-test-3-2/bu... )
I'll take a close look a bit later.
However, from top of my head, there were also other changes, such as this:
https://github.com/rubygems/rubygems/pull/7242
where the description says "once a default gem is specified directly in the Gemfile, or resolved as a transitive dependency, it becomes part of the bundle and gets treated as a "regular gem", so it's cached, explicitly installed in the configured location, etc."
But this is just wild guess.
(BTW this was reverted a few hours ago by https://github.com/rubygems/rubygems/pull/7266).
Hm, I've got the latest and it did not helped. Well, going to dig deeper ...
Upstream ticket:
https://github.com/rubygems/rubygems/issues/7273
Vít
Dear Rubyists,
As it turns out, yesterday version was not a big success, as we learned the hard way (thx Mamoru). So here I am back with updated version, this time rev e3631277c3. The changes are in my PR and the build is here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=110328934
As always, please give it a try and let me know.
Cheers,
Vít
Vít Ondruch wrote on 2023/12/14 23:10:
Dear Rubyists,
As it turns out, yesterday version was not a big success, as we learned the hard way (thx Mamoru). So here I am back with updated version, this time rev e3631277c3. The changes are in my PR and the build is here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=110328934
As always, please give it a try and let me know.
Cheers,
Vít
Looks like this is again in good shape, thank you.
Regards, Mamoru
Dne 15. 12. 23 v 13:56 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2023/12/14 23:10:
Dear Rubyists,
As it turns out, yesterday version was not a big success, as we learned the hard way (thx Mamoru). So here I am back with updated version, this time rev e3631277c3. The changes are in my PR and the build is here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=110328934
As always, please give it a try and let me know.
Cheers,
Vít
Looks like this is again in good shape, thank you.
Thx.
Although, playing around with rubygem-railties, I am now facing these warnings:
~~~
* Test file: test/application/bin_setup_test.rb /usr/share/gems/gems/mail-2.8.1/lib/mail.rb:9: warning: net/smtp was loaded from the standard library, but is not part of the default gems since Ruby 3.1.0. Add net-smtp to your Gemfile or gemspec. Also contact author of mail-2.8.1 to add net-smtp into its gemspec. Run options: --seed 43340
# Running:
.F
Failure: ApplicationTests::BinSetupTest#test_bin_setup_output [test/application/bin_setup_test.rb:51]: --- expected +++ actual @@ -2,10 +2,13 @@ The Gemfile's dependencies are satisfied
== Preparing database == +/usr/share/gems/gems/mail-2.8.1/lib/mail.rb:9: warning: net/smtp was loaded from the standard library, but is not part of the default gems since Ruby 3.1.0. Add net-smtp to your Gemfile or gemspec. Also contact author of mail-2.8.1 to add net-smtp into its gemspec. Created database 'app_development' Created database 'app_test'
== Removing old logs and tempfiles == +/usr/share/gems/gems/mail-2.8.1/lib/mail.rb:9: warning: net/smtp was loaded from the standard library, but is not part of the default gems since Ruby 3.1.0. Add net-smtp to your Gemfile or gemspec. Also contact author of mail-2.8.1 to add net-smtp into its gemspec.
== Restarting application server == +/usr/share/gems/gems/mail-2.8.1/lib/mail.rb:9: warning: net/smtp was loaded from the standard library, but is not part of the default gems since Ruby 3.1.0. Add net-smtp to your Gemfile or gemspec. Also contact author of mail-2.8.1 to add net-smtp into its gemspec. "
rails test test/application/bin_setup_test.rb:30
Finished in 6.203737s, 0.3224 runs/s, 1.1284 assertions/s. 2 runs, 7 assertions, 1 failures, 0 errors, 0 skips ~~~
Specifically due to this, I have build the rubygem-mail-2.8.1 but the warnings are still fired. Trying to get more recent Ruby 🤷♂️
Vít
Regards, Mamoru -- _______________________________________________ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@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.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Dne 15. 12. 23 v 14:13 Vít Ondruch napsal(a):
Dne 15. 12. 23 v 13:56 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2023/12/14 23:10:
Dear Rubyists,
As it turns out, yesterday version was not a big success, as we learned the hard way (thx Mamoru). So here I am back with updated version, this time rev e3631277c3. The changes are in my PR and the build is here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=110328934
As always, please give it a try and let me know.
Cheers,
Vít
Looks like this is again in good shape, thank you.
Thx.
Although, playing around with rubygem-railties, I am now facing these warnings:
* Test file: test/application/bin_setup_test.rb /usr/share/gems/gems/mail-2.8.1/lib/mail.rb:9: warning: net/smtp was loaded from the standard library, but is not part of the default gems since Ruby 3.1.0. Add net-smtp to your Gemfile or gemspec. Also contact author of mail-2.8.1 to add net-smtp into its gemspec. Run options: --seed 43340 # Running: .F Failure: ApplicationTests::BinSetupTest#test_bin_setup_output [test/application/bin_setup_test.rb:51]: --- expected +++ actual @@ -2,10 +2,13 @@ The Gemfile's dependencies are satisfied == Preparing database == +/usr/share/gems/gems/mail-2.8.1/lib/mail.rb:9: warning: net/smtp was loaded from the standard library, but is not part of the default gems since Ruby 3.1.0. Add net-smtp to your Gemfile or gemspec. Also contact author of mail-2.8.1 to add net-smtp into its gemspec. Created database 'app_development' Created database 'app_test' == Removing old logs and tempfiles == +/usr/share/gems/gems/mail-2.8.1/lib/mail.rb:9: warning: net/smtp was loaded from the standard library, but is not part of the default gems since Ruby 3.1.0. Add net-smtp to your Gemfile or gemspec. Also contact author of mail-2.8.1 to add net-smtp into its gemspec. == Restarting application server == +/usr/share/gems/gems/mail-2.8.1/lib/mail.rb:9: warning: net/smtp was loaded from the standard library, but is not part of the default gems since Ruby 3.1.0. Add net-smtp to your Gemfile or gemspec. Also contact author of mail-2.8.1 to add net-smtp into its gemspec. " rails test test/application/bin_setup_test.rb:30 Finished in 6.203737s, 0.3224 runs/s, 1.1284 assertions/s. 2 runs, 7 assertions, 1 failures, 0 errors, 0 skipsSpecifically due to this, I have build the rubygem-mail-2.8.1 but the warnings are still fired. Trying to get more recent Ruby 🤷♂️
Ok, so the "mail" warning is resolved. But there are others now:
~~~
* Test file: test/application/bin_setup_test.rb /usr/share/gems/gems/minitest-5.20.0/lib/minitest.rb:3: warning: mutex_m was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add mutex_m to your Gemfile or gemspec. Also contact author of minitest-5.20.0 to add mutex_m into its gemspec. /usr/share/gems/gems/activesupport-7.0.8/lib/active_support/testing/parallelization.rb:3: warning: drb was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add drb to your Gemfile or gemspec. Also contact author of activesupport-7.0.8 to add drb into its gemspec. /usr/share/gems/gems/activesupport-7.0.8/lib/active_support/message_encryptor.rb:4: warning: base64 was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add base64 to your Gemfile or gemspec. Also contact author of activesupport-7.0.8 to add base64 into its gemspec. /usr/share/gems/gems/activesupport-7.0.8/lib/active_support/message_encryptor.rb:4: warning: base64 was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add base64 to your Gemfile or gemspec. Also contact author of activesupport-7.0.8 to add base64 into its gemspec. /usr/share/gems/gems/activesupport-7.0.8/lib/active_support/core_ext/object/json.rb:5: warning: bigdecimal was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add bigdecimal to your Gemfile or gemspec. Also contact author of activesupport-7.0.8 to add bigdecimal into its gemspec. Run options: --seed 17375
# Running:
F
Failure: ApplicationTests::BinSetupTest#test_bin_setup_output [test/application/bin_setup_test.rb:51]: --- expected +++ actual @@ -2,10 +2,19 @@ The Gemfile's dependencies are satisfied
== Preparing database == +/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/message_verifier.rb:4: warning: base64 was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add base64 to your Gemfile or gemspec. Also contact author of activesupport-7.0.8 to add base64 into its gemspec. +/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/core_ext/object/json.rb:5: warning: bigdecimal was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add bigdecimal to your Gemfile or gemspec. Also contact author of activesupport-7.0.8 to add bigdecimal into its gemspec. +/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/notifications/fanout.rb:3: warning: mutex_m was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add mutex_m to your Gemfile or gemspec. Also contact author of activesupport-7.0.8 to add mutex_m into its gemspec. Created database 'app_development' Created database 'app_test'
== Removing old logs and tempfiles == +/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/message_verifier.rb:4: warning: base64 was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add base64 to your Gemfile or gemspec. Also contact author of activesupport-7.0.8 to add base64 into its gemspec. +/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/core_ext/object/json.rb:5: warning: bigdecimal was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add bigdecimal to your Gemfile or gemspec. Also contact author of activesupport-7.0.8 to add bigdecimal into its gemspec. +/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/notifications/fanout.rb:3: warning: mutex_m was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add mutex_m to your Gemfile or gemspec. Also contact author of activesupport-7.0.8 to add mutex_m into its gemspec.
== Restarting application server == +/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/message_verifier.rb:4: warning: base64 was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add base64 to your Gemfile or gemspec. Also contact author of activesupport-7.0.8 to add base64 into its gemspec. +/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/core_ext/object/json.rb:5: warning: bigdecimal was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add bigdecimal to your Gemfile or gemspec. Also contact author of activesupport-7.0.8 to add bigdecimal into its gemspec. +/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/notifications/fanout.rb:3: warning: mutex_m was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add mutex_m to your Gemfile or gemspec. Also contact author of activesupport-7.0.8 to add mutex_m into its gemspec. "
rails test test/application/bin_setup_test.rb:30
.
Finished in 8.081659s, 0.2475 runs/s, 0.8662 assertions/s. 2 runs, 7 assertions, 1 failures, 0 errors, 0 skips
~~~
It seems that Rails 7.1 already fixes these issues. There is also 7.0 patch committed, but unreleased:
https://github.com/rails/rails/commit/81699b52d2acff1840e3ace5e59412f4fa3934...
I think I'm rather going to apply the patch, because:
1) We don't know when Rails 7.0 update is going to be released
2) Even if the release is done in time, we would need to do the update.
And specifically the AS is widely used, so who knows what else it might break.
Vít
Dne 15. 12. 23 v 16:34 Vít Ondruch napsal(a):
Dne 15. 12. 23 v 14:13 Vít Ondruch napsal(a):
Dne 15. 12. 23 v 13:56 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2023/12/14 23:10:
Dear Rubyists,
As it turns out, yesterday version was not a big success, as we learned the hard way (thx Mamoru). So here I am back with updated version, this time rev e3631277c3. The changes are in my PR and the build is here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=110328934
As always, please give it a try and let me know.
Cheers,
Vít
Looks like this is again in good shape, thank you.
Thx.
Although, playing around with rubygem-railties, I am now facing these warnings:
* Test file: test/application/bin_setup_test.rb /usr/share/gems/gems/mail-2.8.1/lib/mail.rb:9: warning: net/smtp was loaded from the standard library, but is not part of the default gems since Ruby 3.1.0. Add net-smtp to your Gemfile or gemspec. Also contact author of mail-2.8.1 to add net-smtp into its gemspec. Run options: --seed 43340 # Running: .F Failure: ApplicationTests::BinSetupTest#test_bin_setup_output [test/application/bin_setup_test.rb:51]: --- expected +++ actual @@ -2,10 +2,13 @@ The Gemfile's dependencies are satisfied == Preparing database == +/usr/share/gems/gems/mail-2.8.1/lib/mail.rb:9: warning: net/smtp was loaded from the standard library, but is not part of the default gems since Ruby 3.1.0. Add net-smtp to your Gemfile or gemspec. Also contact author of mail-2.8.1 to add net-smtp into its gemspec. Created database 'app_development' Created database 'app_test' == Removing old logs and tempfiles == +/usr/share/gems/gems/mail-2.8.1/lib/mail.rb:9: warning: net/smtp was loaded from the standard library, but is not part of the default gems since Ruby 3.1.0. Add net-smtp to your Gemfile or gemspec. Also contact author of mail-2.8.1 to add net-smtp into its gemspec. == Restarting application server == +/usr/share/gems/gems/mail-2.8.1/lib/mail.rb:9: warning: net/smtp was loaded from the standard library, but is not part of the default gems since Ruby 3.1.0. Add net-smtp to your Gemfile or gemspec. Also contact author of mail-2.8.1 to add net-smtp into its gemspec. " rails test test/application/bin_setup_test.rb:30 Finished in 6.203737s, 0.3224 runs/s, 1.1284 assertions/s. 2 runs, 7 assertions, 1 failures, 0 errors, 0 skipsSpecifically due to this, I have build the rubygem-mail-2.8.1 but the warnings are still fired. Trying to get more recent Ruby 🤷♂️
Ok, so the "mail" warning is resolved. But there are others now:
* Test file: test/application/bin_setup_test.rb /usr/share/gems/gems/minitest-5.20.0/lib/minitest.rb:3: warning: mutex_m was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add mutex_m to your Gemfile or gemspec. Also contact author of minitest-5.20.0 to add mutex_m into its gemspec. /usr/share/gems/gems/activesupport-7.0.8/lib/active_support/testing/parallelization.rb:3: warning: drb was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add drb to your Gemfile or gemspec. Also contact author of activesupport-7.0.8 to add drb into its gemspec. /usr/share/gems/gems/activesupport-7.0.8/lib/active_support/message_encryptor.rb:4: warning: base64 was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add base64 to your Gemfile or gemspec. Also contact author of activesupport-7.0.8 to add base64 into its gemspec. /usr/share/gems/gems/activesupport-7.0.8/lib/active_support/message_encryptor.rb:4: warning: base64 was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add base64 to your Gemfile or gemspec. Also contact author of activesupport-7.0.8 to add base64 into its gemspec. /usr/share/gems/gems/activesupport-7.0.8/lib/active_support/core_ext/object/json.rb:5: warning: bigdecimal was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add bigdecimal to your Gemfile or gemspec. Also contact author of activesupport-7.0.8 to add bigdecimal into its gemspec. Run options: --seed 17375 # Running: F Failure: ApplicationTests::BinSetupTest#test_bin_setup_output [test/application/bin_setup_test.rb:51]: --- expected +++ actual @@ -2,10 +2,19 @@ The Gemfile's dependencies are satisfied == Preparing database == +/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/message_verifier.rb:4: warning: base64 was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add base64 to your Gemfile or gemspec. Also contact author of activesupport-7.0.8 to add base64 into its gemspec. +/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/core_ext/object/json.rb:5: warning: bigdecimal was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add bigdecimal to your Gemfile or gemspec. Also contact author of activesupport-7.0.8 to add bigdecimal into its gemspec. +/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/notifications/fanout.rb:3: warning: mutex_m was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add mutex_m to your Gemfile or gemspec. Also contact author of activesupport-7.0.8 to add mutex_m into its gemspec. Created database 'app_development' Created database 'app_test' == Removing old logs and tempfiles == +/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/message_verifier.rb:4: warning: base64 was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add base64 to your Gemfile or gemspec. Also contact author of activesupport-7.0.8 to add base64 into its gemspec. +/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/core_ext/object/json.rb:5: warning: bigdecimal was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add bigdecimal to your Gemfile or gemspec. Also contact author of activesupport-7.0.8 to add bigdecimal into its gemspec. +/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/notifications/fanout.rb:3: warning: mutex_m was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add mutex_m to your Gemfile or gemspec. Also contact author of activesupport-7.0.8 to add mutex_m into its gemspec. == Restarting application server == +/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/message_verifier.rb:4: warning: base64 was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add base64 to your Gemfile or gemspec. Also contact author of activesupport-7.0.8 to add base64 into its gemspec. +/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/core_ext/object/json.rb:5: warning: bigdecimal was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add bigdecimal to your Gemfile or gemspec. Also contact author of activesupport-7.0.8 to add bigdecimal into its gemspec. +/usr/share/gems/gems/activesupport-7.0.8/lib/active_support/notifications/fanout.rb:3: warning: mutex_m was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add mutex_m to your Gemfile or gemspec. Also contact author of activesupport-7.0.8 to add mutex_m into its gemspec. " rails test test/application/bin_setup_test.rb:30 . Finished in 8.081659s, 0.2475 runs/s, 0.8662 assertions/s. 2 runs, 7 assertions, 1 failures, 0 errors, 0 skipsIt seems that Rails 7.1 already fixes these issues. There is also 7.0 patch committed, but unreleased:
https://github.com/rails/rails/commit/81699b52d2acff1840e3ace5e59412f4fa3934...
I think I'm rather going to apply the patch, because:
Cannot apply the patch ATM, because Ruby 3.2 does not have the corresponding provides (but could have). The PR is waiting here:
https://src.fedoraproject.org/rpms/rubygem-activesupport/pull-request/4
Vít
We don't know when Rails 7.0 update is going to be released
Even if the release is done in time, we would need to do the update.
And specifically the AS is widely used, so who knows what else it might break.
Vít
Hi everybody,
As you might have figured from my other email, I have yet another Ruby update. This time rev 04f7be6126 and the scratch build is available here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=110382113
There were some RubyGems/Bundler vendored gems updates and as can be seen from the other threads, there is still some activity with regards to reporting bundled/default gems. I have not noticed anything else.
As always, please give it a try and any feedback is welcome.
Thx
Vít
Hi again,
I'm back with yet another update, this time rev 8e6f63df47. The build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=110562000
From what I have noticed, there is included RubyGems 3.5.1 instead of 3.5.0.dev. And there seems to be fixed some issues with reporting bundled gems, I have mentioned in different thread.
Please give it a try and as always, any feedback is appreciated.
Vít
P.S. The official release date is in less then one week!
Hi everybody,
I am back with yet another update, this time rev 8e6f63df47. The changes are in my PR, while the build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=110562000
I have not noticed any noteworthy from upstream POV, but downstream, I have extracted the bundled Racc into separate sub package, to prevent possible collisions with standalone rubygem-racc (as discussed elsewhere). I have also provided multiple `bundled` provides. I know the line between what is part of Ruby and what is independent project is blurry and even blurrier then it used to be. However, it is probably better to have more `bundled` provides than less.
As always, please give it a try and any feedback is welcome.
Thx
Vít
Vít Ondruch wrote on 2023/12/21 21:08:
Hi everybody,
I am back with yet another update, this time rev 8e6f63df47. The changes are in my PR, while the build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=110562000
I have not noticed any noteworthy from upstream POV, but downstream, I have extracted the bundled Racc into separate sub package, to prevent possible collisions with standalone rubygem-racc (as discussed elsewhere). I have also provided multiple `bundled` provides. I know the line between what is part of Ruby and what is independent project is blurry and even blurrier then it used to be. However, it is probably better to have more `bundled` provides than less.
As always, please give it a try and any feedback is welcome.
Thx
Unfortunately, alexandria testsuite began to segfault (sometimes, not always)...
Once I've reported: https://bugs.ruby-lang.org/issues/20079 Looks like https://github.com/ruby/ruby/commit/11fa76b1b521072c200c78ea023960221ff426d6 is the culprit. Letting the upstream reproduce the issue may be difficult...
Regards, Mamoru
Hi again,
I am back, this time with rev e8639098ed. The build is available here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=110695618
From upstream POV, there is not much interesting to mention. Downstream, I have applied patches to revert this PR:
https://github.com/ruby/ruby/pull/9274
To workaround the Alexandria segfaults. I'll observe the upstream ticket and hopefully there will be some proper solution soon. This is likely the very last test release prior the official Ruby 3.3 release, because I'll be off my work computer for the end of year holidays. So as always, thank you for all the feedback and see you next year with the stable Ruby 3.3.
Vít
On 9/12/23 10:08, Vít Ondruch wrote:
Hi,
It is again the time to look at where Ruby 3.3 development stands. So here is PR with the changes:
Trying out Ruby 3.3.0 official release in local mock, I hit SSL issues with tests in net-http library, due to expired certificates.
This upstream PR that fixes it bu updating it: https://github.com/ruby/net-http/pull/169
And this is a PR in upstream Ruby git that checks out individual commits for the affected library (libraries to be exact) for CI to pass: https://github.com/ruby/ruby/pull/9403 This is unfortunate.
Other than that, it builds on x86_64, which does make me optimistic, great work on the pre-releases for Fedora.
Regards, Jarek
Hi everybody and happy new year,
Being back from holidays, here is Ruby 3.3.0.
https://koji.fedoraproject.org/koji/taskinfo?taskID=111186668
As some of you have noticed, there are issues with expired certificates. I have asked backport here:
https://bugs.ruby-lang.org/issues/20106
Other than that, there does not seem to be anything surprising.
As I have already mentioned elsewhere, I have reset the release back to 1. I have not tested the updates yet, so I'm going to give it a try. If that looks OK, I'll ask the side tag and we can move forward with the mass rebuild. I'll keep you informed.
And as always, any feedback is appreciated.
Vít
On Tue, Jan 2, 2024 at 3:38 PM Vít Ondruch vondruch@redhat.com wrote:
Hi everybody and happy new year,
Being back from holidays, here is Ruby 3.3.0.
https://koji.fedoraproject.org/koji/taskinfo?taskID=111186668
As some of you have noticed, there are issues with expired certificates. I have asked backport here:
https://bugs.ruby-lang.org/issues/20106
Other than that, there does not seem to be anything surprising.
As I have already mentioned elsewhere, I have reset the release back to
- I have not tested the updates yet, so I'm going to give it a try. If
that looks OK, I'll ask the side tag and we can move forward with the mass rebuild. I'll keep you informed.
And as always, any feedback is appreciated.
Hello, thanks!
Already building it; for testing with `-1`. But so far I have failure on aarch; FAIL 103/1871 tests failed
FAIL 103/1871 tests failed: https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6848059/
Seems like fibers and Ractors... will retry. Others have succeeded!
I'm rebuilding the few remaining deps in my COPR repo. Hopefully, I'll be able to test with Rails (dnf install ruby-on-rails....) soon.
Regards, Pavel
Vít
Dne 02. 01. 24 v 16:15 Pavel Valena napsal(a):
On Tue, Jan 2, 2024 at 3:38 PM Vít Ondruch vondruch@redhat.com wrote:
Hi everybody and happy new year, Being back from holidays, here is Ruby 3.3.0. https://koji.fedoraproject.org/koji/taskinfo?taskID=111186668 As some of you have noticed, there are issues with expired certificates. I have asked backport here: https://bugs.ruby-lang.org/issues/20106 Other than that, there does not seem to be anything surprising. As I have already mentioned elsewhere, I have reset the release back to 1. I have not tested the updates yet, so I'm going to give it a try. If that looks OK, I'll ask the side tag and we can move forward with the mass rebuild. I'll keep you informed. And as always, any feedback is appreciated.Hello, thanks!
Already building it; for testing with `-1`. But so far I have failure on aarch; FAIL 103/1871 tests failed
FAIL 103/1871 tests failed: https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6848059/
Seems like fibers and Ractors... will retry. Others have succeeded!
My build succeeded everywhere. Nevertheless, there were some reports about issues with fibers (e.g. https://bugs.ruby-lang.org/issues/20085). So we should probably observe and if needed, apply some patch.
Vít
I'm rebuilding the few remaining deps in my COPR repo. Hopefully, I'll be able to test with Rails (dnf install ruby-on-rails....) soon.
Regards, Pavel
Vít-- _______________________________________________ ruby-sig mailing list --ruby-sig@lists.fedoraproject.org To unsubscribe send an email toruby-sig-leave@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.o... Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue
On 1/2/24 16:41, Vít Ondruch wrote:
Dne 02. 01. 24 v 16:15 Pavel Valena napsal(a):
On Tue, Jan 2, 2024 at 3:38 PM Vít Ondruch vondruch@redhat.com wrote:
Hi everybody and happy new year, Being back from holidays, here is Ruby 3.3.0. https://koji.fedoraproject.org/koji/taskinfo?taskID=111186668 As some of you have noticed, there are issues with expired certificates. I have asked backport here: https://bugs.ruby-lang.org/issues/20106 Other than that, there does not seem to be anything surprising. As I have already mentioned elsewhere, I have reset the release back to 1. I have not tested the updates yet, so I'm going to give it a try. If that looks OK, I'll ask the side tag and we can move forward with the mass rebuild. I'll keep you informed. And as always, any feedback is appreciated.Hello, thanks!
Already building it; for testing with `-1`. But so far I have failure on aarch; FAIL 103/1871 tests failed
FAIL 103/1871 tests failed: https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6848059/
Seems like fibers and Ractors... will retry. Others have succeeded!
My build succeeded everywhere. Nevertheless, there were some reports about issues with fibers (e.g. https://bugs.ruby-lang.org/issues/20085). So we should probably observe and if needed, apply some patch.
I did a build from my EL9 specific specfile here: https://copr.fedorainfracloud.org/coprs/jackorp/ruby-builds/build/6848355/
It failed with a bunch of segfaults as well, it seems the issue is reproducible on copr infra. The number of failed tests is the same as with Pavel's build (103/1871)
Actually, the hw_info differs for copr and koji. Koji is missing `paca pacg` (I guess those are related to the mentioned `ASFLAGS=-mbranch-protection=pac-ret`), though ssbs is present on both.
My copr build hw_info.log.gz: https://download.copr.fedorainfracloud.org/results/jackorp/ruby-builds/fedor... Passed koji build hw_info.log.gz: https://kojipkgs.fedoraproject.org//work/tasks/6817/111186817/hw_info.log
Also despite both of the infra are reporting the same Vendor ID and Model Name, there are visually half the CPU flags missing on Koji compared to copr.
Jarek
Vít
I'm rebuilding the few remaining deps in my COPR repo. Hopefully, I'll be able to test with Rails (dnf install ruby-on-rails....) soon.
Regards, Pavel
Vít-- _______________________________________________ ruby-sig mailing list --ruby-sig@lists.fedoraproject.org To unsubscribe send an email toruby-sig-leave@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.o... 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 toruby-sig-leave@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.o... Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue
Dne 02. 01. 24 v 17:16 jprokop@redhat.com napsal(a):
On 1/2/24 16:41, Vít Ondruch wrote:
Dne 02. 01. 24 v 16:15 Pavel Valena napsal(a):
On Tue, Jan 2, 2024 at 3:38 PM Vít Ondruch vondruch@redhat.com wrote:
Hi everybody and happy new year, Being back from holidays, here is Ruby 3.3.0. https://koji.fedoraproject.org/koji/taskinfo?taskID=111186668 As some of you have noticed, there are issues with expired certificates. I have asked backport here: https://bugs.ruby-lang.org/issues/20106 Other than that, there does not seem to be anything surprising. As I have already mentioned elsewhere, I have reset the release back to 1. I have not tested the updates yet, so I'm going to give it a try. If that looks OK, I'll ask the side tag and we can move forward with the mass rebuild. I'll keep you informed. And as always, any feedback is appreciated.Hello, thanks!
Already building it; for testing with `-1`. But so far I have failure on aarch; FAIL 103/1871 tests failed
FAIL 103/1871 tests failed: https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6848059/
Seems like fibers and Ractors... will retry. Others have succeeded!
My build succeeded everywhere. Nevertheless, there were some reports about issues with fibers (e.g. https://bugs.ruby-lang.org/issues/20085). So we should probably observe and if needed, apply some patch.
I did a build from my EL9 specific specfile here: https://copr.fedorainfracloud.org/coprs/jackorp/ruby-builds/build/6848355/
It failed with a bunch of segfaults as well, it seems the issue is reproducible on copr infra. The number of failed tests is the same as with Pavel's build (103/1871)
Actually, the hw_info differs for copr and koji. Koji is missing `paca pacg` (I guess those are related to the mentioned `ASFLAGS=-mbranch-protection=pac-ret`), though ssbs is present on both.
My copr build hw_info.log.gz: https://download.copr.fedorainfracloud.org/results/jackorp/ruby-builds/fedor... Passed koji build hw_info.log.gz: https://kojipkgs.fedoraproject.org//work/tasks/6817/111186817/hw_info.log
Also despite both of the infra are reporting the same Vendor ID and Model Name, there are visually half the CPU flags missing on Koji compared to copr.
Hoping that somebody is going to try the patch on my behalf (unless I hit the issue myself ;) )
Vít
Jarek
Vít
I'm rebuilding the few remaining deps in my COPR repo. Hopefully, I'll be able to test with Rails (dnf install ruby-on-rails....) soon.
Regards, Pavel
Vít-- _______________________________________________ ruby-sig mailing list --ruby-sig@lists.fedoraproject.org To unsubscribe send an email toruby-sig-leave@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.o... 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 toruby-sig-leave@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.o... 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 toruby-sig-leave@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.o... Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue
On Tue, Jan 2, 2024 at 5:31 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 02. 01. 24 v 17:16 jprokop@redhat.com napsal(a):
On 1/2/24 16:41, Vít Ondruch wrote:
Dne 02. 01. 24 v 16:15 Pavel Valena napsal(a):
On Tue, Jan 2, 2024 at 3:38 PM Vít Ondruch vondruch@redhat.com wrote:
Hi everybody and happy new year,
Being back from holidays, here is Ruby 3.3.0.
https://koji.fedoraproject.org/koji/taskinfo?taskID=111186668
As some of you have noticed, there are issues with expired certificates. I have asked backport here:
https://bugs.ruby-lang.org/issues/20106
Other than that, there does not seem to be anything surprising.
As I have already mentioned elsewhere, I have reset the release back to
- I have not tested the updates yet, so I'm going to give it a try. If
that looks OK, I'll ask the side tag and we can move forward with the mass rebuild. I'll keep you informed.
And as always, any feedback is appreciated.
Hello, thanks!
Already building it; for testing with `-1`. But so far I have failure on aarch; FAIL 103/1871 tests failed
FAIL 103/1871 tests failed: https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6848059/
Seems like fibers and Ractors... will retry. Others have succeeded!
My build succeeded everywhere. Nevertheless, there were some reports about issues with fibers (e.g. https://bugs.ruby-lang.org/issues/20085). So we should probably observe and if needed, apply some patch.
I did a build from my EL9 specific specfile here: https://copr.fedorainfracloud.org/coprs/jackorp/ruby-builds/build/6848355/
It failed with a bunch of segfaults as well, it seems the issue is reproducible on copr infra. The number of failed tests is the same as with Pavel's build (103/1871)
Actually, the hw_info differs for copr and koji. Koji is missing `paca pacg` (I guess those are related to the mentioned `ASFLAGS=-mbranch-protection=pac-ret`), though ssbs is present on both.
My copr build hw_info.log.gz: https://download.copr.fedorainfracloud.org/results/jackorp/ruby-builds/fedor... Passed koji build hw_info.log.gz: https://kojipkgs.fedoraproject.org//work/tasks/6817/111186817/hw_info.log
Also despite both of the infra are reporting the same Vendor ID and Model Name, there are visually half the CPU flags missing on Koji compared to copr.
Hoping that somebody is going to try the patch on my behalf (unless I hit the issue myself ;) )
My second build hit 101 issues, similarly to the previous one.
Running with the patch from issue 20085: https://copr.fedorainfracloud.org/coprs/build/6850032
So far so good. Commit: https://src.fedoraproject.org/fork/pvalena/rpms/ruby/c/7f32705242dd2b55e72d3...
Btw. WRT rails, I'm removing byebug from `rubyonrails` comps: https://pagure.io/fedora-comps/pull-request/925 (orphaned 6+ weeks)
Pavel
Vít
Jarek
Vít
I'm rebuilding the few remaining deps in my COPR repo. Hopefully, I'll be able to test with Rails (dnf install ruby-on-rails....) soon.
Regards, Pavel
Vít
On Tue, Jan 2, 2024 at 9:07 PM Pavel Valena pvalena@redhat.com wrote:
On Tue, Jan 2, 2024 at 5:31 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 02. 01. 24 v 17:16 jprokop@redhat.com napsal(a):
On 1/2/24 16:41, Vít Ondruch wrote:
Dne 02. 01. 24 v 16:15 Pavel Valena napsal(a):
On Tue, Jan 2, 2024 at 3:38 PM Vít Ondruch vondruch@redhat.com wrote:
Hi everybody and happy new year,
Being back from holidays, here is Ruby 3.3.0.
https://koji.fedoraproject.org/koji/taskinfo?taskID=111186668
As some of you have noticed, there are issues with expired certificates. I have asked backport here:
https://bugs.ruby-lang.org/issues/20106
Other than that, there does not seem to be anything surprising.
As I have already mentioned elsewhere, I have reset the release back to
- I have not tested the updates yet, so I'm going to give it a try. If
that looks OK, I'll ask the side tag and we can move forward with the mass rebuild. I'll keep you informed.
And as always, any feedback is appreciated.
Hello, thanks!
Already building it; for testing with `-1`. But so far I have failure on aarch; FAIL 103/1871 tests failed
FAIL 103/1871 tests failed:
https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6848059/
Seems like fibers and Ractors... will retry. Others have succeeded!
My build succeeded everywhere. Nevertheless, there were some reports about issues with fibers (e.g. https://bugs.ruby-lang.org/issues/20085). So we should probably observe and if needed, apply some patch.
I did a build from my EL9 specific specfile here: https://copr.fedorainfracloud.org/coprs/jackorp/ruby-builds/build/6848355/
It failed with a bunch of segfaults as well, it seems the issue is reproducible on copr infra. The number of failed tests is the same as with Pavel's build (103/1871)
Actually, the hw_info differs for copr and koji. Koji is missing `paca pacg` (I guess those are related to the mentioned `ASFLAGS=-mbranch-protection=pac-ret`), though ssbs is present on both.
My copr build hw_info.log.gz: https://download.copr.fedorainfracloud.org/results/jackorp/ruby-builds/fedor... Passed koji build hw_info.log.gz: https://kojipkgs.fedoraproject.org//work/tasks/6817/111186817/hw_info.log
Also despite both of the infra are reporting the same Vendor ID and Model Name, there are visually half the CPU flags missing on Koji compared to copr.
Hoping that somebody is going to try the patch on my behalf (unless I hit the issue myself ;) )
My second build hit 101 issues, similarly to the previous one.
Running with the patch from issue 20085: https://copr.fedorainfracloud.org/coprs/build/6850032
So far so good. Commit: https://src.fedoraproject.org/fork/pvalena/rpms/ruby/c/7f32705242dd2b55e72d3...
Btw. WRT rails, I'm removing byebug from `rubyonrails` comps: https://pagure.io/fedora-comps/pull-request/925 (orphaned 6+ weeks)
With byebug resurrected in my COPR; my rails test works fine with Ruby 3.3:
Log: https://gist.github.com/pvalena/47299184b16a3f81b6c954dca65dcc9f
Pavel
Pavel
Vít
Jarek
Vít
I'm rebuilding the few remaining deps in my COPR repo. Hopefully, I'll be able to test with Rails (dnf install ruby-on-rails....) soon.
Regards, Pavel
Vít
Dne 02. 01. 24 v 21:50 Pavel Valena napsal(a):
On Tue, Jan 2, 2024 at 9:07 PM Pavel Valena pvalena@redhat.com wrote:
On Tue, Jan 2, 2024 at 5:31 PM Vít Ondruch <vondruch@redhat.com> wrote: Dne 02. 01. 24 v 17:16 jprokop@redhat.com napsal(a):On 1/2/24 16:41, Vít Ondruch wrote:Dne 02. 01. 24 v 16:15 Pavel Valena napsal(a):On Tue, Jan 2, 2024 at 3:38 PM Vít Ondruch <vondruch@redhat.com> wrote: Hi everybody and happy new year, Being back from holidays, here is Ruby 3.3.0. https://koji.fedoraproject.org/koji/taskinfo?taskID=111186668 As some of you have noticed, there are issues with expired certificates. I have asked backport here: https://bugs.ruby-lang.org/issues/20106 Other than that, there does not seem to be anything surprising. As I have already mentioned elsewhere, I have reset the release back to 1. I have not tested the updates yet, so I'm going to give it a try. If that looks OK, I'll ask the side tag and we can move forward with the mass rebuild. I'll keep you informed. And as always, any feedback is appreciated. Hello, thanks! Already building it; for testing with `-1`. But so far I have failure on aarch; FAIL 103/1871 tests failed FAIL 103/1871 tests failed: https://copr.fedorainfracloud.org/coprs/pvalena/ruby-testing/build/6848059/ Seems like fibers and Ractors... will retry. Others have succeeded!My build succeeded everywhere. Nevertheless, there were some reports about issues with fibers (e.g. https://bugs.ruby-lang.org/issues/20085). So we should probably observe and if needed, apply some patch.I did a build from my EL9 specific specfile here: https://copr.fedorainfracloud.org/coprs/jackorp/ruby-builds/build/6848355/ It failed with a bunch of segfaults as well, it seems the issue is reproducible on copr infra. The number of failed tests is the same as with Pavel's build (103/1871) Actually, the hw_info differs for copr and koji. Koji is missing `paca pacg` (I guess those are related to the mentioned `ASFLAGS=-mbranch-protection=pac-ret`), though ssbs is present on both. My copr build hw_info.log.gz: https://download.copr.fedorainfracloud.org/results/jackorp/ruby-builds/fedora-rawhide-aarch64/06848355-ruby/hw_info.log.gz Passed koji build hw_info.log.gz: https://kojipkgs.fedoraproject.org//work/tasks/6817/111186817/hw_info.log Also despite both of the infra are reporting the same Vendor ID and Model Name, there are visually half the CPU flags missing on Koji compared to copr.Hoping that somebody is going to try the patch on my behalf (unless I hit the issue myself ;) ) My second build hit 101 issues, similarly to the previous one.
Hm, I have just done the official build in Koji and again without issues and I have never hit this even doing test in Copr, strange. I am still on hold with the patch.
Running with the patch from issue 20085: https://copr.fedorainfracloud.org/coprs/build/6850032 So far so good. Commit: https://src.fedoraproject.org/fork/pvalena/rpms/ruby/c/7f32705242dd2b55e72d3e9e5eed0934e38ad043?branch=stream-3.3 Btw. WRT rails, I'm removing byebug from `rubyonrails` comps: https://pagure.io/fedora-comps/pull-request/925 (orphaned 6+ weeks)
Good idea!
With byebug resurrected in my COPR; my rails test works fine with Ruby 3.3:
Not sure I understand the "resurrected". Do we need byebug or not?
Vít
Log: https://gist.github.com/pvalena/47299184b16a3f81b6c954dca65dcc9f
Pavel
On 1/3/24 11:23, Vít Ondruch wrote:
Dne 02. 01. 24 v 21:50 Pavel Valena napsal(a):
My build succeeded everywhere. Nevertheless, there were some reports about issues with fibers (e.g. https://bugs.ruby-lang.org/issues/20085). So we should probably observe and if needed, apply some patch.I did a build from my EL9 specific specfile here: https://copr.fedorainfracloud.org/coprs/jackorp/ruby-builds/build/6848355/ It failed with a bunch of segfaults as well, it seems the issue is reproducible on copr infra. The number of failed tests is the same as with Pavel's build (103/1871) Actually, the hw_info differs for copr and koji. Koji is missing `paca pacg` (I guess those are related to the mentioned `ASFLAGS=-mbranch-protection=pac-ret`), though ssbs is present on both. My copr build hw_info.log.gz: https://download.copr.fedorainfracloud.org/results/jackorp/ruby-builds/fedora-rawhide-aarch64/06848355-ruby/hw_info.log.gz Passed koji build hw_info.log.gz: https://kojipkgs.fedoraproject.org//work/tasks/6817/111186817/hw_info.log Also despite both of the infra are reporting the same Vendor ID and Model Name, there are visually half the CPU flags missing on Koji compared to copr.Hoping that somebody is going to try the patch on my behalf (unless I hit the issue myself ;) ) My second build hit 101 issues, similarly to the previous one.Hm, I have just done the official build in Koji and again without issues and I have never hit this even doing test in Copr, strange. I am still on hold with the patch.
I am worried that Koji is doing something weird or has some weird setup causing us not to trigger the bug.
I have an RPi 4 lying around, I'll try the build there, see if this issue is affecting that platform, as Fedora supports those arm CPUs.
(I'd not like upgrading it to Fedora 40 in the future and finding out Ruby programs are segfaulting around Fibers and whatnot.)
Alternatively, this might be worth bringing to fedora-devel, see if someome there is wiser about that patch for ARM platforms.
Jarek
On 1/3/24 11:48, jprokop@redhat.com wrote:
On 1/3/24 11:23, Vít Ondruch wrote:
Dne 02. 01. 24 v 21:50 Pavel Valena napsal(a):
My build succeeded everywhere. Nevertheless, there were some reports about issues with fibers (e.g. https://bugs.ruby-lang.org/issues/20085). So we should probably observe and if needed, apply some patch.I did a build from my EL9 specific specfile here: https://copr.fedorainfracloud.org/coprs/jackorp/ruby-builds/build/6848355/ It failed with a bunch of segfaults as well, it seems the issue is reproducible on copr infra. The number of failed tests is the same as with Pavel's build (103/1871) Actually, the hw_info differs for copr and koji. Koji is missing `paca pacg` (I guess those are related to the mentioned `ASFLAGS=-mbranch-protection=pac-ret`), though ssbs is present on both. My copr build hw_info.log.gz: https://download.copr.fedorainfracloud.org/results/jackorp/ruby-builds/fedora-rawhide-aarch64/06848355-ruby/hw_info.log.gz Passed koji build hw_info.log.gz: https://kojipkgs.fedoraproject.org//work/tasks/6817/111186817/hw_info.log Also despite both of the infra are reporting the same Vendor ID and Model Name, there are visually half the CPU flags missing on Koji compared to copr.Hoping that somebody is going to try the patch on my behalf (unless I hit the issue myself ;) ) My second build hit 101 issues, similarly to the previous one.Hm, I have just done the official build in Koji and again without issues and I have never hit this even doing test in Copr, strange. I am still on hold with the patch.
I am worried that Koji is doing something weird or has some weird setup causing us not to trigger the bug.
I have an RPi 4 lying around, I'll try the build there, see if this issue is affecting that platform, as Fedora supports those arm CPUs.
That was a fun excersize, but (un)fortunately RPi 4 arm CPU does not seem to have PAC support, therefore I cannot reproduce the bug there.
I'd personally include the patch.
(I'd not like upgrading it to Fedora 40 in the future and finding out Ruby programs are segfaulting around Fibers and whatnot.)
Alternatively, this might be worth bringing to fedora-devel, see if someome there is wiser about that patch for ARM platforms.
Jarek
Dne 03. 01. 24 v 13:50 Jarek Prokop napsal(a):
On 1/3/24 11:48, jprokop@redhat.com wrote:
On 1/3/24 11:23, Vít Ondruch wrote:
Dne 02. 01. 24 v 21:50 Pavel Valena napsal(a):
My build succeeded everywhere. Nevertheless, there were some reports about issues with fibers (e.g. https://bugs.ruby-lang.org/issues/20085). So we should probably observe and if needed, apply some patch.I did a build from my EL9 specific specfile here: https://copr.fedorainfracloud.org/coprs/jackorp/ruby-builds/build/6848355/ It failed with a bunch of segfaults as well, it seems the issue is reproducible on copr infra. The number of failed tests is the same as with Pavel's build (103/1871) Actually, the hw_info differs for copr and koji. Koji is missing `paca pacg` (I guess those are related to the mentioned `ASFLAGS=-mbranch-protection=pac-ret`), though ssbs is present on both. My copr build hw_info.log.gz: https://download.copr.fedorainfracloud.org/results/jackorp/ruby-builds/fedora-rawhide-aarch64/06848355-ruby/hw_info.log.gz Passed koji build hw_info.log.gz: https://kojipkgs.fedoraproject.org//work/tasks/6817/111186817/hw_info.log Also despite both of the infra are reporting the same Vendor ID and Model Name, there are visually half the CPU flags missing on Koji compared to copr.Hoping that somebody is going to try the patch on my behalf (unless I hit the issue myself ;) ) My second build hit 101 issues, similarly to the previous one.Hm, I have just done the official build in Koji and again without issues and I have never hit this even doing test in Copr, strange. I am still on hold with the patch.
I am worried that Koji is doing something weird or has some weird setup causing us not to trigger the bug.
I have an RPi 4 lying around, I'll try the build there, see if this issue is affecting that platform, as Fedora supports those arm CPUs.
That was a fun excersize, but (un)fortunately RPi 4 arm CPU does not seem to have PAC support, therefore I cannot reproduce the bug there.
I'd personally include the patch.
(I'd not like upgrading it to Fedora 40 in the future and finding out Ruby programs are segfaulting around Fibers and whatnot.)
Alternatively, this might be worth bringing to fedora-devel, see if someome there is wiser about that patch for ARM platforms.
Thx for the fedora-devel email explaining the details and also your worries. Now it makes a bit more sense why you insist. In any case, I think we are good for the moment. We still can wait for:
1) Upstream backport and Ruby 3.3.1 (because some people looked quite worried).
2) We can backport ourselves prior mass rebuild starts.
So we'll see as the story unfolds. Please give me a nudge prior 2024-01-17 when the mass rebuild is scheduled.
Vít
ruby-sig@lists.fedoraproject.org
-
Jarek Prokop -
jprokop＠redhat.com
-
Mamoru TASAKA -
Pavel Valena -
Ruby SIG mailing list
-
Vít Ondruch