Re: Ruby 3.3 - Mass rebuild
Vít Ondruch wrote on 2024/01/04 22:51: Dne 04. 01. 24 v 9:39 Vít Ondruch napsal(a): Dne 03. 01. 24 v 19:43 Vít Ondruch napsal(a): Dne 03. 01. 24 v 18:59 Vít Ondruch napsal(a): Dne 03. 01. 24 v 18:55 Vít Ondruch napsal(a): Dne 03. 01. 24 v 18:00 Vít Ondruch napsal(a): Dne 03. 01. 24 v 17:18 Mamoru TASAKA napsal(a): Mamoru TASAKA wrote on 2024/01/04 1:06: Vít Ondruch wrote on 2024/01/03 19:20: Hi everybody, Ruby 3.3 is out and it is time for Ruby mass rebuild. First of all, I'd like to thank to Mamoru for the preparation and lot of fixes all around. I really appreciate that. I think we are well prepared for the rebuild, therefore I have requested side-tag: ~~~ $ fedpkg request-side-tag Side tag 'f40-build-side-80411' (id 80411) created. Use 'fedpkg build --target=f40-build-side-80411' to use it. Use 'koji wait-repo f40-build-side-80411' to wait for the build repo to be generated. ~~~ Ruby 3.3 is already merged [1] and build there: https://koji.fedoraproject.org/koji/builds?inherited=0=80411=-build_id=1 or using: ~~~ $ koji list-tagged f40-build-side-80411 ~~~ Now this is a list of packages, which very likely needs rebuild: ~~~ $ dnf repoquery --disablerepo=* --enablerepo=rawhide --enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' | sort | uniq ~~~ You can take the package and just fire rebuild, but please ensure that you are using f40-build-side-80411 build target, i.e. the build command should look like: ~~~ $ fedpkg build --target f40-build-side-80411 ~~~ Please be careful, because if you, by a chance, omit the f40-build-side-80411 target, you'll be building against Ruby 3.2 which is not what you want. If you won't do it by yourself, I'll be rebuilding all packages after I am finished with my packages. I'll be using fermig [2] to help me with that. If you don't want me to touch your packages for whatever reason, please let me know. As always, any help/testing/feedback is welcome. Vít [1] https://github.com/fedora-ruby/fermig [2] https://src.fedoraproject.org/rpms/ruby/pull-request/159 Thank you for preparing ruby3.3 for F-40. Now I think the leftover (not rebuilt against ruby3.3) are the following: 1 kf5-kross-interpreters-22.04.3-5.fc39.src.rpm 3 openbabel-3.1.1-21.fc39.src.rpm Umm... looks like redhat-rpm-config-273-1.fc40 change (-Wl,-z,pack-relative-relocs) is causing this: for now reported against redhat-rpm-config: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2256645 2 libsbml-5.20.2-4.fc40.src.rpm Now building (perhaps will succeed): https://koji.fedoraproject.org/koji/taskinfo?taskID=111244836 libsbml build successfully finished. 4 subversion-1.14.2-22.fc40.src.rpm Build failing, perhaps due to zlib-ng-compat switch, already reported: https://bugzilla.redhat.com/show_bug.cgi?id=2255746 After libsbml build finishes, I think we can merge ruby33 side tag into F40 build tree. Thx for the help with rebuilds. I am pondering about a few packages, e.g.: libsolv needs rebuild it seems: https://github.com/openSUSE/libsolv/issues/548 https://koji.fedoraproject.org/koji/taskinfo?taskID=111249415 And I think that VIM might fall into the same bucket. Yep, VIM cannot load vim-command-t and if somebody using the Ruby bindings. But I don't think this is major issue and VIM is updated quite often. So not a show stopper. Despite there has been some activity related to the kf5-kross-interpreters / openbabel, I'll rather wont wait and merge it now. Anybody can rebuild those later. Vít Done: https://bodhi.fedoraproject.org/updates/FEDORA-2024-d093bd520d Vít CRITPATH update, probably due to DNF. Will look at that tomorrow. So there actually were some gating failures. I have waved them and the update has finally landed. Should there be needed any further fixes, please apply them directly in Rawhide, as usually. Mamoru than you for adding the kf5-kross-interpreters / openbabel in the mean time. Just casually checking Koschei for "ruby" packages, it seems that all of them were already rebuilt and I am flattered I can't see any new issue. Very nice. Thx all for your great work and your support. Vít Good to hear. Thanks to Vít and all the folks for the nice work for landing new ruby into Fedora 40. Mamoru -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3 - Mass rebuild
Dne 04. 01. 24 v 9:39 Vít Ondruch napsal(a): Dne 03. 01. 24 v 19:43 Vít Ondruch napsal(a): Dne 03. 01. 24 v 18:59 Vít Ondruch napsal(a): Dne 03. 01. 24 v 18:55 Vít Ondruch napsal(a): Dne 03. 01. 24 v 18:00 Vít Ondruch napsal(a): Dne 03. 01. 24 v 17:18 Mamoru TASAKA napsal(a): Mamoru TASAKA wrote on 2024/01/04 1:06: Vít Ondruch wrote on 2024/01/03 19:20: Hi everybody, Ruby 3.3 is out and it is time for Ruby mass rebuild. First of all, I'd like to thank to Mamoru for the preparation and lot of fixes all around. I really appreciate that. I think we are well prepared for the rebuild, therefore I have requested side-tag: ~~~ $ fedpkg request-side-tag Side tag 'f40-build-side-80411' (id 80411) created. Use 'fedpkg build --target=f40-build-side-80411' to use it. Use 'koji wait-repo f40-build-side-80411' to wait for the build repo to be generated. ~~~ Ruby 3.3 is already merged [1] and build there: https://koji.fedoraproject.org/koji/builds?inherited=0=80411=-build_id=1 or using: ~~~ $ koji list-tagged f40-build-side-80411 ~~~ Now this is a list of packages, which very likely needs rebuild: ~~~ $ dnf repoquery --disablerepo=* --enablerepo=rawhide --enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' | sort | uniq ~~~ You can take the package and just fire rebuild, but please ensure that you are using f40-build-side-80411 build target, i.e. the build command should look like: ~~~ $ fedpkg build --target f40-build-side-80411 ~~~ Please be careful, because if you, by a chance, omit the f40-build-side-80411 target, you'll be building against Ruby 3.2 which is not what you want. If you won't do it by yourself, I'll be rebuilding all packages after I am finished with my packages. I'll be using fermig [2] to help me with that. If you don't want me to touch your packages for whatever reason, please let me know. As always, any help/testing/feedback is welcome. Vít [1] https://github.com/fedora-ruby/fermig [2] https://src.fedoraproject.org/rpms/ruby/pull-request/159 Thank you for preparing ruby3.3 for F-40. Now I think the leftover (not rebuilt against ruby3.3) are the following: 1 kf5-kross-interpreters-22.04.3-5.fc39.src.rpm 3 openbabel-3.1.1-21.fc39.src.rpm Umm... looks like redhat-rpm-config-273-1.fc40 change (-Wl,-z,pack-relative-relocs) is causing this: for now reported against redhat-rpm-config: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2256645 2 libsbml-5.20.2-4.fc40.src.rpm Now building (perhaps will succeed): https://koji.fedoraproject.org/koji/taskinfo?taskID=111244836 libsbml build successfully finished. 4 subversion-1.14.2-22.fc40.src.rpm Build failing, perhaps due to zlib-ng-compat switch, already reported: https://bugzilla.redhat.com/show_bug.cgi?id=2255746 After libsbml build finishes, I think we can merge ruby33 side tag into F40 build tree. Thx for the help with rebuilds. I am pondering about a few packages, e.g.: libsolv needs rebuild it seems: https://github.com/openSUSE/libsolv/issues/548 https://koji.fedoraproject.org/koji/taskinfo?taskID=111249415 And I think that VIM might fall into the same bucket. Yep, VIM cannot load vim-command-t and if somebody using the Ruby bindings. But I don't think this is major issue and VIM is updated quite often. So not a show stopper. Despite there has been some activity related to the kf5-kross-interpreters / openbabel, I'll rather wont wait and merge it now. Anybody can rebuild those later. Vít Done: https://bodhi.fedoraproject.org/updates/FEDORA-2024-d093bd520d Vít CRITPATH update, probably due to DNF. Will look at that tomorrow. So there actually were some gating failures. I have waved them and the update has finally landed. Should there be needed any further fixes, please apply them directly in Rawhide, as usually. Mamoru than you for adding the kf5-kross-interpreters / openbabel in the mean time. Just casually checking Koschei for "ruby" packages, it seems that all of them were already rebuilt and I am flattered I can't see any new issue. Very nice. Thx all for your great work and your support. Vít OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3 - Mass rebuild
Dne 03. 01. 24 v 19:43 Vít Ondruch napsal(a): Dne 03. 01. 24 v 18:59 Vít Ondruch napsal(a): Dne 03. 01. 24 v 18:55 Vít Ondruch napsal(a): Dne 03. 01. 24 v 18:00 Vít Ondruch napsal(a): Dne 03. 01. 24 v 17:18 Mamoru TASAKA napsal(a): Mamoru TASAKA wrote on 2024/01/04 1:06: Vít Ondruch wrote on 2024/01/03 19:20: Hi everybody, Ruby 3.3 is out and it is time for Ruby mass rebuild. First of all, I'd like to thank to Mamoru for the preparation and lot of fixes all around. I really appreciate that. I think we are well prepared for the rebuild, therefore I have requested side-tag: ~~~ $ fedpkg request-side-tag Side tag 'f40-build-side-80411' (id 80411) created. Use 'fedpkg build --target=f40-build-side-80411' to use it. Use 'koji wait-repo f40-build-side-80411' to wait for the build repo to be generated. ~~~ Ruby 3.3 is already merged [1] and build there: https://koji.fedoraproject.org/koji/builds?inherited=0=80411=-build_id=1 or using: ~~~ $ koji list-tagged f40-build-side-80411 ~~~ Now this is a list of packages, which very likely needs rebuild: ~~~ $ dnf repoquery --disablerepo=* --enablerepo=rawhide --enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' | sort | uniq ~~~ You can take the package and just fire rebuild, but please ensure that you are using f40-build-side-80411 build target, i.e. the build command should look like: ~~~ $ fedpkg build --target f40-build-side-80411 ~~~ Please be careful, because if you, by a chance, omit the f40-build-side-80411 target, you'll be building against Ruby 3.2 which is not what you want. If you won't do it by yourself, I'll be rebuilding all packages after I am finished with my packages. I'll be using fermig [2] to help me with that. If you don't want me to touch your packages for whatever reason, please let me know. As always, any help/testing/feedback is welcome. Vít [1] https://github.com/fedora-ruby/fermig [2] https://src.fedoraproject.org/rpms/ruby/pull-request/159 Thank you for preparing ruby3.3 for F-40. Now I think the leftover (not rebuilt against ruby3.3) are the following: 1 kf5-kross-interpreters-22.04.3-5.fc39.src.rpm 3 openbabel-3.1.1-21.fc39.src.rpm Umm... looks like redhat-rpm-config-273-1.fc40 change (-Wl,-z,pack-relative-relocs) is causing this: for now reported against redhat-rpm-config: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2256645 2 libsbml-5.20.2-4.fc40.src.rpm Now building (perhaps will succeed): https://koji.fedoraproject.org/koji/taskinfo?taskID=111244836 libsbml build successfully finished. 4 subversion-1.14.2-22.fc40.src.rpm Build failing, perhaps due to zlib-ng-compat switch, already reported: https://bugzilla.redhat.com/show_bug.cgi?id=2255746 After libsbml build finishes, I think we can merge ruby33 side tag into F40 build tree. Thx for the help with rebuilds. I am pondering about a few packages, e.g.: libsolv needs rebuild it seems: https://github.com/openSUSE/libsolv/issues/548 https://koji.fedoraproject.org/koji/taskinfo?taskID=111249415 And I think that VIM might fall into the same bucket. Yep, VIM cannot load vim-command-t and if somebody using the Ruby bindings. But I don't think this is major issue and VIM is updated quite often. So not a show stopper. Despite there has been some activity related to the kf5-kross-interpreters / openbabel, I'll rather wont wait and merge it now. Anybody can rebuild those later. Vít Done: https://bodhi.fedoraproject.org/updates/FEDORA-2024-d093bd520d Vít CRITPATH update, probably due to DNF. Will look at that tomorrow. So there actually were some gating failures. I have waved them and the update has finally landed. Should there be needed any further fixes, please apply them directly in Rawhide, as usually. Mamoru than you for adding the kf5-kross-interpreters / openbabel in the mean time. Vít OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3 - Mass rebuild
Dne 03. 01. 24 v 18:59 Vít Ondruch napsal(a): Dne 03. 01. 24 v 18:55 Vít Ondruch napsal(a): Dne 03. 01. 24 v 18:00 Vít Ondruch napsal(a): Dne 03. 01. 24 v 17:18 Mamoru TASAKA napsal(a): Mamoru TASAKA wrote on 2024/01/04 1:06: Vít Ondruch wrote on 2024/01/03 19:20: Hi everybody, Ruby 3.3 is out and it is time for Ruby mass rebuild. First of all, I'd like to thank to Mamoru for the preparation and lot of fixes all around. I really appreciate that. I think we are well prepared for the rebuild, therefore I have requested side-tag: ~~~ $ fedpkg request-side-tag Side tag 'f40-build-side-80411' (id 80411) created. Use 'fedpkg build --target=f40-build-side-80411' to use it. Use 'koji wait-repo f40-build-side-80411' to wait for the build repo to be generated. ~~~ Ruby 3.3 is already merged [1] and build there: https://koji.fedoraproject.org/koji/builds?inherited=0=80411=-build_id=1 or using: ~~~ $ koji list-tagged f40-build-side-80411 ~~~ Now this is a list of packages, which very likely needs rebuild: ~~~ $ dnf repoquery --disablerepo=* --enablerepo=rawhide --enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' | sort | uniq ~~~ You can take the package and just fire rebuild, but please ensure that you are using f40-build-side-80411 build target, i.e. the build command should look like: ~~~ $ fedpkg build --target f40-build-side-80411 ~~~ Please be careful, because if you, by a chance, omit the f40-build-side-80411 target, you'll be building against Ruby 3.2 which is not what you want. If you won't do it by yourself, I'll be rebuilding all packages after I am finished with my packages. I'll be using fermig [2] to help me with that. If you don't want me to touch your packages for whatever reason, please let me know. As always, any help/testing/feedback is welcome. Vít [1] https://github.com/fedora-ruby/fermig [2] https://src.fedoraproject.org/rpms/ruby/pull-request/159 Thank you for preparing ruby3.3 for F-40. Now I think the leftover (not rebuilt against ruby3.3) are the following: 1 kf5-kross-interpreters-22.04.3-5.fc39.src.rpm 3 openbabel-3.1.1-21.fc39.src.rpm Umm... looks like redhat-rpm-config-273-1.fc40 change (-Wl,-z,pack-relative-relocs) is causing this: for now reported against redhat-rpm-config: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2256645 2 libsbml-5.20.2-4.fc40.src.rpm Now building (perhaps will succeed): https://koji.fedoraproject.org/koji/taskinfo?taskID=111244836 libsbml build successfully finished. 4 subversion-1.14.2-22.fc40.src.rpm Build failing, perhaps due to zlib-ng-compat switch, already reported: https://bugzilla.redhat.com/show_bug.cgi?id=2255746 After libsbml build finishes, I think we can merge ruby33 side tag into F40 build tree. Thx for the help with rebuilds. I am pondering about a few packages, e.g.: libsolv needs rebuild it seems: https://github.com/openSUSE/libsolv/issues/548 https://koji.fedoraproject.org/koji/taskinfo?taskID=111249415 And I think that VIM might fall into the same bucket. Yep, VIM cannot load vim-command-t and if somebody using the Ruby bindings. But I don't think this is major issue and VIM is updated quite often. So not a show stopper. Despite there has been some activity related to the kf5-kross-interpreters / openbabel, I'll rather wont wait and merge it now. Anybody can rebuild those later. Vít Done: https://bodhi.fedoraproject.org/updates/FEDORA-2024-d093bd520d Vít CRITPATH update, probably due to DNF. Will look at that tomorrow. Vít OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3 - Mass rebuild
Dne 03. 01. 24 v 18:55 Vít Ondruch napsal(a): Dne 03. 01. 24 v 18:00 Vít Ondruch napsal(a): Dne 03. 01. 24 v 17:18 Mamoru TASAKA napsal(a): Mamoru TASAKA wrote on 2024/01/04 1:06: Vít Ondruch wrote on 2024/01/03 19:20: Hi everybody, Ruby 3.3 is out and it is time for Ruby mass rebuild. First of all, I'd like to thank to Mamoru for the preparation and lot of fixes all around. I really appreciate that. I think we are well prepared for the rebuild, therefore I have requested side-tag: ~~~ $ fedpkg request-side-tag Side tag 'f40-build-side-80411' (id 80411) created. Use 'fedpkg build --target=f40-build-side-80411' to use it. Use 'koji wait-repo f40-build-side-80411' to wait for the build repo to be generated. ~~~ Ruby 3.3 is already merged [1] and build there: https://koji.fedoraproject.org/koji/builds?inherited=0=80411=-build_id=1 or using: ~~~ $ koji list-tagged f40-build-side-80411 ~~~ Now this is a list of packages, which very likely needs rebuild: ~~~ $ dnf repoquery --disablerepo=* --enablerepo=rawhide --enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' | sort | uniq ~~~ You can take the package and just fire rebuild, but please ensure that you are using f40-build-side-80411 build target, i.e. the build command should look like: ~~~ $ fedpkg build --target f40-build-side-80411 ~~~ Please be careful, because if you, by a chance, omit the f40-build-side-80411 target, you'll be building against Ruby 3.2 which is not what you want. If you won't do it by yourself, I'll be rebuilding all packages after I am finished with my packages. I'll be using fermig [2] to help me with that. If you don't want me to touch your packages for whatever reason, please let me know. As always, any help/testing/feedback is welcome. Vít [1] https://github.com/fedora-ruby/fermig [2] https://src.fedoraproject.org/rpms/ruby/pull-request/159 Thank you for preparing ruby3.3 for F-40. Now I think the leftover (not rebuilt against ruby3.3) are the following: 1 kf5-kross-interpreters-22.04.3-5.fc39.src.rpm 3 openbabel-3.1.1-21.fc39.src.rpm Umm... looks like redhat-rpm-config-273-1.fc40 change (-Wl,-z,pack-relative-relocs) is causing this: for now reported against redhat-rpm-config: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2256645 2 libsbml-5.20.2-4.fc40.src.rpm Now building (perhaps will succeed): https://koji.fedoraproject.org/koji/taskinfo?taskID=111244836 libsbml build successfully finished. 4 subversion-1.14.2-22.fc40.src.rpm Build failing, perhaps due to zlib-ng-compat switch, already reported: https://bugzilla.redhat.com/show_bug.cgi?id=2255746 After libsbml build finishes, I think we can merge ruby33 side tag into F40 build tree. Thx for the help with rebuilds. I am pondering about a few packages, e.g.: libsolv needs rebuild it seems: https://github.com/openSUSE/libsolv/issues/548 https://koji.fedoraproject.org/koji/taskinfo?taskID=111249415 And I think that VIM might fall into the same bucket. Yep, VIM cannot load vim-command-t and if somebody using the Ruby bindings. But I don't think this is major issue and VIM is updated quite often. So not a show stopper. Despite there has been some activity related to the kf5-kross-interpreters / openbabel, I'll rather wont wait and merge it now. Anybody can rebuild those later. Vít Done: https://bodhi.fedoraproject.org/updates/FEDORA-2024-d093bd520d Vít OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3 - Mass rebuild
Dne 03. 01. 24 v 18:00 Vít Ondruch napsal(a): Dne 03. 01. 24 v 17:18 Mamoru TASAKA napsal(a): Mamoru TASAKA wrote on 2024/01/04 1:06: Vít Ondruch wrote on 2024/01/03 19:20: Hi everybody, Ruby 3.3 is out and it is time for Ruby mass rebuild. First of all, I'd like to thank to Mamoru for the preparation and lot of fixes all around. I really appreciate that. I think we are well prepared for the rebuild, therefore I have requested side-tag: ~~~ $ fedpkg request-side-tag Side tag 'f40-build-side-80411' (id 80411) created. Use 'fedpkg build --target=f40-build-side-80411' to use it. Use 'koji wait-repo f40-build-side-80411' to wait for the build repo to be generated. ~~~ Ruby 3.3 is already merged [1] and build there: https://koji.fedoraproject.org/koji/builds?inherited=0=80411=-build_id=1 or using: ~~~ $ koji list-tagged f40-build-side-80411 ~~~ Now this is a list of packages, which very likely needs rebuild: ~~~ $ dnf repoquery --disablerepo=* --enablerepo=rawhide --enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' | sort | uniq ~~~ You can take the package and just fire rebuild, but please ensure that you are using f40-build-side-80411 build target, i.e. the build command should look like: ~~~ $ fedpkg build --target f40-build-side-80411 ~~~ Please be careful, because if you, by a chance, omit the f40-build-side-80411 target, you'll be building against Ruby 3.2 which is not what you want. If you won't do it by yourself, I'll be rebuilding all packages after I am finished with my packages. I'll be using fermig [2] to help me with that. If you don't want me to touch your packages for whatever reason, please let me know. As always, any help/testing/feedback is welcome. Vít [1] https://github.com/fedora-ruby/fermig [2] https://src.fedoraproject.org/rpms/ruby/pull-request/159 Thank you for preparing ruby3.3 for F-40. Now I think the leftover (not rebuilt against ruby3.3) are the following: 1 kf5-kross-interpreters-22.04.3-5.fc39.src.rpm 3 openbabel-3.1.1-21.fc39.src.rpm Umm... looks like redhat-rpm-config-273-1.fc40 change (-Wl,-z,pack-relative-relocs) is causing this: for now reported against redhat-rpm-config: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2256645 2 libsbml-5.20.2-4.fc40.src.rpm Now building (perhaps will succeed): https://koji.fedoraproject.org/koji/taskinfo?taskID=111244836 libsbml build successfully finished. 4 subversion-1.14.2-22.fc40.src.rpm Build failing, perhaps due to zlib-ng-compat switch, already reported: https://bugzilla.redhat.com/show_bug.cgi?id=2255746 After libsbml build finishes, I think we can merge ruby33 side tag into F40 build tree. Thx for the help with rebuilds. I am pondering about a few packages, e.g.: libsolv needs rebuild it seems: https://github.com/openSUSE/libsolv/issues/548 https://koji.fedoraproject.org/koji/taskinfo?taskID=111249415 And I think that VIM might fall into the same bucket. Yep, VIM cannot load vim-command-t and if somebody using the Ruby bindings. But I don't think this is major issue and VIM is updated quite often. So not a show stopper. Despite there has been some activity related to the kf5-kross-interpreters / openbabel, I'll rather wont wait and merge it now. Anybody can rebuild those later. Vít OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3 - Mass rebuild
Dne 03. 01. 24 v 17:18 Mamoru TASAKA napsal(a): Mamoru TASAKA wrote on 2024/01/04 1:06: Vít Ondruch wrote on 2024/01/03 19:20: Hi everybody, Ruby 3.3 is out and it is time for Ruby mass rebuild. First of all, I'd like to thank to Mamoru for the preparation and lot of fixes all around. I really appreciate that. I think we are well prepared for the rebuild, therefore I have requested side-tag: ~~~ $ fedpkg request-side-tag Side tag 'f40-build-side-80411' (id 80411) created. Use 'fedpkg build --target=f40-build-side-80411' to use it. Use 'koji wait-repo f40-build-side-80411' to wait for the build repo to be generated. ~~~ Ruby 3.3 is already merged [1] and build there: https://koji.fedoraproject.org/koji/builds?inherited=0=80411=-build_id=1 or using: ~~~ $ koji list-tagged f40-build-side-80411 ~~~ Now this is a list of packages, which very likely needs rebuild: ~~~ $ dnf repoquery --disablerepo=* --enablerepo=rawhide --enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' | sort | uniq ~~~ You can take the package and just fire rebuild, but please ensure that you are using f40-build-side-80411 build target, i.e. the build command should look like: ~~~ $ fedpkg build --target f40-build-side-80411 ~~~ Please be careful, because if you, by a chance, omit the f40-build-side-80411 target, you'll be building against Ruby 3.2 which is not what you want. If you won't do it by yourself, I'll be rebuilding all packages after I am finished with my packages. I'll be using fermig [2] to help me with that. If you don't want me to touch your packages for whatever reason, please let me know. As always, any help/testing/feedback is welcome. Vít [1] https://github.com/fedora-ruby/fermig [2] https://src.fedoraproject.org/rpms/ruby/pull-request/159 Thank you for preparing ruby3.3 for F-40. Now I think the leftover (not rebuilt against ruby3.3) are the following: 1 kf5-kross-interpreters-22.04.3-5.fc39.src.rpm 3 openbabel-3.1.1-21.fc39.src.rpm Umm... looks like redhat-rpm-config-273-1.fc40 change (-Wl,-z,pack-relative-relocs) is causing this: for now reported against redhat-rpm-config: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2256645 2 libsbml-5.20.2-4.fc40.src.rpm Now building (perhaps will succeed): https://koji.fedoraproject.org/koji/taskinfo?taskID=111244836 libsbml build successfully finished. 4 subversion-1.14.2-22.fc40.src.rpm Build failing, perhaps due to zlib-ng-compat switch, already reported: https://bugzilla.redhat.com/show_bug.cgi?id=2255746 After libsbml build finishes, I think we can merge ruby33 side tag into F40 build tree. Thx for the help with rebuilds. I am pondering about a few packages, e.g.: libsolv needs rebuild it seems: https://github.com/openSUSE/libsolv/issues/548 https://koji.fedoraproject.org/koji/taskinfo?taskID=111249415 And I think that VIM might fall into the same bucket. Vít OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3 - Mass rebuild
Mamoru TASAKA wrote on 2024/01/04 1:06: Vít Ondruch wrote on 2024/01/03 19:20: Hi everybody, Ruby 3.3 is out and it is time for Ruby mass rebuild. First of all, I'd like to thank to Mamoru for the preparation and lot of fixes all around. I really appreciate that. I think we are well prepared for the rebuild, therefore I have requested side-tag: ~~~ $ fedpkg request-side-tag Side tag 'f40-build-side-80411' (id 80411) created. Use 'fedpkg build --target=f40-build-side-80411' to use it. Use 'koji wait-repo f40-build-side-80411' to wait for the build repo to be generated. ~~~ Ruby 3.3 is already merged [1] and build there: https://koji.fedoraproject.org/koji/builds?inherited=0=80411=-build_id=1 or using: ~~~ $ koji list-tagged f40-build-side-80411 ~~~ Now this is a list of packages, which very likely needs rebuild: ~~~ $ dnf repoquery --disablerepo=* --enablerepo=rawhide --enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' | sort | uniq ~~~ You can take the package and just fire rebuild, but please ensure that you are using f40-build-side-80411 build target, i.e. the build command should look like: ~~~ $ fedpkg build --target f40-build-side-80411 ~~~ Please be careful, because if you, by a chance, omit the f40-build-side-80411 target, you'll be building against Ruby 3.2 which is not what you want. If you won't do it by yourself, I'll be rebuilding all packages after I am finished with my packages. I'll be using fermig [2] to help me with that. If you don't want me to touch your packages for whatever reason, please let me know. As always, any help/testing/feedback is welcome. Vít [1] https://github.com/fedora-ruby/fermig [2] https://src.fedoraproject.org/rpms/ruby/pull-request/159 Thank you for preparing ruby3.3 for F-40. Now I think the leftover (not rebuilt against ruby3.3) are the following: 1 kf5-kross-interpreters-22.04.3-5.fc39.src.rpm 3 openbabel-3.1.1-21.fc39.src.rpm Umm... looks like redhat-rpm-config-273-1.fc40 change (-Wl,-z,pack-relative-relocs) is causing this: for now reported against redhat-rpm-config: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2256645 2 libsbml-5.20.2-4.fc40.src.rpm Now building (perhaps will succeed): https://koji.fedoraproject.org/koji/taskinfo?taskID=111244836 libsbml build successfully finished. 4 subversion-1.14.2-22.fc40.src.rpm Build failing, perhaps due to zlib-ng-compat switch, already reported: https://bugzilla.redhat.com/show_bug.cgi?id=2255746 After libsbml build finishes, I think we can merge ruby33 side tag into F40 build tree. Regards, Mamoru -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3 - Mass rebuild
Vít Ondruch wrote on 2024/01/03 19:20: Hi everybody, Ruby 3.3 is out and it is time for Ruby mass rebuild. First of all, I'd like to thank to Mamoru for the preparation and lot of fixes all around. I really appreciate that. I think we are well prepared for the rebuild, therefore I have requested side-tag: ~~~ $ fedpkg request-side-tag Side tag 'f40-build-side-80411' (id 80411) created. Use 'fedpkg build --target=f40-build-side-80411' to use it. Use 'koji wait-repo f40-build-side-80411' to wait for the build repo to be generated. ~~~ Ruby 3.3 is already merged [1] and build there: https://koji.fedoraproject.org/koji/builds?inherited=0=80411=-build_id=1 or using: ~~~ $ koji list-tagged f40-build-side-80411 ~~~ Now this is a list of packages, which very likely needs rebuild: ~~~ $ dnf repoquery --disablerepo=* --enablerepo=rawhide --enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' | sort | uniq ~~~ You can take the package and just fire rebuild, but please ensure that you are using f40-build-side-80411 build target, i.e. the build command should look like: ~~~ $ fedpkg build --target f40-build-side-80411 ~~~ Please be careful, because if you, by a chance, omit the f40-build-side-80411 target, you'll be building against Ruby 3.2 which is not what you want. If you won't do it by yourself, I'll be rebuilding all packages after I am finished with my packages. I'll be using fermig [2] to help me with that. If you don't want me to touch your packages for whatever reason, please let me know. As always, any help/testing/feedback is welcome. Vít [1] https://github.com/fedora-ruby/fermig [2] https://src.fedoraproject.org/rpms/ruby/pull-request/159 Thank you for preparing ruby3.3 for F-40. Now I think the leftover (not rebuilt against ruby3.3) are the following: 1 kf5-kross-interpreters-22.04.3-5.fc39.src.rpm 3 openbabel-3.1.1-21.fc39.src.rpm Umm... looks like redhat-rpm-config-273-1.fc40 change (-Wl,-z,pack-relative-relocs) is causing this: for now reported against redhat-rpm-config: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2256645 2 libsbml-5.20.2-4.fc40.src.rpm Now building (perhaps will succeed): https://koji.fedoraproject.org/koji/taskinfo?taskID=111244836 4 subversion-1.14.2-22.fc40.src.rpm Build failing, perhaps due to zlib-ng-compat switch, already reported: https://bugzilla.redhat.com/show_bug.cgi?id=2255746 After libsbml build finishes, I think we can merge ruby33 side tag into F40 build tree. Regards, Mamoru -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
Dne 03. 01. 24 v 13:50 Jarek Prokop napsal(a): On 1/3/24 11:48, jpro...@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/86817/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 OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
On 1/3/24 11:48, jpro...@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/86817/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 -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
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/86817/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 -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
Dne 02. 01. 24 v 21:50 Pavel Valena napsal(a): On Tue, Jan 2, 2024 at 9:07 PM Pavel Valena wrote: On Tue, Jan 2, 2024 at 5:31 PM Vít Ondruch wrote: Dne 02. 01. 24 v 17:16 jpro...@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 wrote: Hi everybody and happy new year, Being back from holidays, here is Ruby 3.3.0. https://koji.fedoraproject.org/koji/taskinfo?taskID=86668 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/86817/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 OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Ruby 3.3 - Mass rebuild
Hi everybody, Ruby 3.3 is out and it is time for Ruby mass rebuild. First of all, I'd like to thank to Mamoru for the preparation and lot of fixes all around. I really appreciate that. I think we are well prepared for the rebuild, therefore I have requested side-tag: ~~~ $ fedpkg request-side-tag Side tag 'f40-build-side-80411' (id 80411) created. Use 'fedpkg build --target=f40-build-side-80411' to use it. Use 'koji wait-repo f40-build-side-80411' to wait for the build repo to be generated. ~~~ Ruby 3.3 is already merged [1] and build there: https://koji.fedoraproject.org/koji/builds?inherited=0=80411=-build_id=1 or using: ~~~ $ koji list-tagged f40-build-side-80411 ~~~ Now this is a list of packages, which very likely needs rebuild: ~~~ $ dnf repoquery --disablerepo=* --enablerepo=rawhide --enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' | sort | uniq ~~~ You can take the package and just fire rebuild, but please ensure that you are using f40-build-side-80411 build target, i.e. the build command should look like: ~~~ $ fedpkg build --target f40-build-side-80411 ~~~ Please be careful, because if you, by a chance, omit the f40-build-side-80411 target, you'll be building against Ruby 3.2 which is not what you want. If you won't do it by yourself, I'll be rebuilding all packages after I am finished with my packages. I'll be using fermig [2] to help me with that. If you don't want me to touch your packages for whatever reason, please let me know. As always, any help/testing/feedback is welcome. Vít [1] https://github.com/fedora-ruby/fermig [2] https://src.fedoraproject.org/rpms/ruby/pull-request/159 OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
On Tue, Jan 2, 2024 at 9:07 PM Pavel Valena wrote: > On Tue, Jan 2, 2024 at 5:31 PM Vít Ondruch wrote: > >> >> Dne 02. 01. 24 v 17:16 jpro...@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 wrote: >> >>> Hi everybody and happy new year, >>> >>> Being back from holidays, here is Ruby 3.3.0. >>> >>> https://koji.fedoraproject.org/koji/taskinfo?taskID=86668 >>> >>> 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/86817/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/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) > 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 >>> >> -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
On Tue, Jan 2, 2024 at 5:31 PM Vít Ondruch wrote: > > Dne 02. 01. 24 v 17:16 jpro...@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 wrote: > >> Hi everybody and happy new year, >> >> Being back from holidays, here is Ruby 3.3.0. >> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=86668 >> >> 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/86817/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/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) 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 >> > -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
Dne 02. 01. 24 v 17:16 jpro...@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 wrote: Hi everybody and happy new year, Being back from holidays, here is Ruby 3.3.0. https://koji.fedoraproject.org/koji/taskinfo?taskID=86668 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/86817/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-le...@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue -- ___ ruby-sig mailing list --ruby-sig@lists.fedoraproject.org To unsubscribe send an email toruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue -- ___ ruby-sig mailing list --ruby-sig@lists.fedoraproject.org To unsubscribe send an email toruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
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 wrote: Hi everybody and happy new year, Being back from holidays, here is Ruby 3.3.0. https://koji.fedoraproject.org/koji/taskinfo?taskID=86668 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/86817/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-le...@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue -- ___ ruby-sig mailing list --ruby-sig@lists.fedoraproject.org To unsubscribe send an email toruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue-- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
Dne 02. 01. 24 v 16:15 Pavel Valena napsal(a): On Tue, Jan 2, 2024 at 3:38 PM Vít Ondruch wrote: Hi everybody and happy new year, Being back from holidays, here is Ruby 3.3.0. https://koji.fedoraproject.org/koji/taskinfo?taskID=86668 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-le...@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
On Tue, Jan 2, 2024 at 3:38 PM Vít Ondruch wrote: > Hi everybody and happy new year, > > Being back from holidays, here is Ruby 3.3.0. > > https://koji.fedoraproject.org/koji/taskinfo?taskID=86668 > > 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! 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 to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
Hi everybody and happy new year, Being back from holidays, here is Ruby 3.3.0. https://koji.fedoraproject.org/koji/taskinfo?taskID=86668 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 OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
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: https://src.fedoraproject.org/rpms/ruby/pull-request/159 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 -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
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 OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Considering to reset the Ruby 3.3 release back to -1
Hi, Looking at the versions of subpackages, it seems that the only concerning package is rubygem-power_assert, where the version has not changed between Ruby 3.2 and Ruby 3.3. Otherwise all the versions were bumped. Looking closer at the power_assert, it seem that 1) The content is still the same, so having older version around should not be a problem. 2) We have separate rubygem-power_assert, which has higher NVR in any case. Therefore, I think it should be safe to reset the release back to -1. Is there any concern or something I am missing? Cheers, Vít OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
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 -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
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 OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
Dne 12. 12. 23 v 15:11 Mamoru TASAKA napsal(a): 9. rubygem-rubygems-mirror https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6743512/ ``` + ruby -Ilib -e 'Dir.glob "./test/test_*.rb", (:require)' :127:in `require': cannot load such file -- rubygems/indexer (LoadError) from :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 `' from :127:in `require' from :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 `' from :127:in `require' from :127:in `require' from :411:in `glob' from -e:1:in `' ``` 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 OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Current rubygem- packages rebuild failure against ruby 3.3
Dne 26. 11. 23 v 15:13 Mamoru TASAKA napsal(a): 5. rubygem-childprocess https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6695574/ Same as before. 7. rubygem-childprocess https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576582/ `Failure/Error: require 'rubygems/mock_gem_ui'` This file is removed: https://github.com/ruby/ruby/commit/74772840430fc3fca3f5fb0ad585d9cc48f512fb Need to address in childprocess side. In case I'll be asking later, I have (hopefully) fixed this one 藍 https://src.fedoraproject.org/rpms/rubygem-childprocess/c/6822cf78f6253ee136df9da7895d1ee693ed8f1c Vít OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Current rubygem- packages rebuild failure against ruby 3.3
Dne 20. 12. 23 v 14:22 Mamoru TASAKA napsal(a): Vít Ondruch wrote on 2023/12/20 18:56: Dne 15. 12. 23 v 17:03 Vít Ondruch napsal(a): Dne 15. 12. 23 v 11:10 Vít Ondruch napsal(a): Dne 26. 11. 23 v 15:13 Mamoru TASAKA napsal(a): 7. rubygem-railties https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6695576/ Testsuite is failing, but due to some different reason: ``` Failure: FullStackConsoleTest#test_sandbox [test/application/console_test.rb:133]: "> " expected, but got: Loading development environment in sandbox (Rails 7.0.8) Any modifications you make will be rolled back on exit â–½. Expected # encoding: ASCII-8BIT # valid: true "Loading development environment in sandbox (Rails 7.0.8)\r\nAny modifications you make will be rolled back on exit\r\n\e[1G\xE2\x96\xBD\e[6n" to include "> ". rails test test/application/console_test.rb:139 F Failure: FullStackConsoleTest#test_environment_option_and_irb_option [test/application/console_test.rb:133]: "> " expected, but got: Loading test environment (Rails 7.0.8) Switch to inspect mode. â–½. Expected # encoding: ASCII-8BIT # valid: true "Loading test environment (Rails 7.0.8)\r\nSwitch to inspect mode.\r\n\e[1G\xE2\x96\xBD\e[6n" to include "> ". ``` Isn't this related to the Aruba + Reline issue? https://bugs.ruby-lang.org/issues/20052 https://github.com/ruby/reline/issues/616 Vít I have tried to reproduce this with the latest version of Ruby, I have execute the console_test.rb more then 100x and I have not hit the issue. Was it fixed somehow? Not sure. Vít Well, actually with rubygem-railties-7.0.8-2 , FullStackConsoleTest#test_sandbox [test/application/console_test.rb:133] is passing, but with rubygem-railties-7.0.8-1, I still see the same error (with ruby git 7c2d819862) Failure: FullStackConsoleTest#test_sandbox [test/application/console_test.rb:133]: "> " expected, but got: /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. Loading development environment in sandbox (Rails 7.0.8) Any modifications you make will be rolled back on exit ▽. Expected # encoding: ASCII-8BIT # valid: true "/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.\r\n/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.\r\n/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.\r\nLoading development environment in sandbox (Rails 7.0.8)\r\nAny modifications you make will be rolled back on exit\r\n\e[1G\xE2\x96\xBD\e[6n" to include "> ". So comparing with 1 and 2, there is Patch4: rubygem-railties-7.1.0-Run-Rails-console-test-against-IRB-with-Reline-instead-of.patch This patch actually seems to have fixed the above issue. (You are trying to reproduce the above issue with -2?) Oh my. I have fixed it myself. Too much context switching. Sorry and thank you for reminding me. Vít OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct:
Re: Current rubygem- packages rebuild failure against ruby 3.3
Vít Ondruch wrote on 2023/12/20 18:56: Dne 15. 12. 23 v 17:03 Vít Ondruch napsal(a): Dne 15. 12. 23 v 11:10 Vít Ondruch napsal(a): Dne 26. 11. 23 v 15:13 Mamoru TASAKA napsal(a): 7. rubygem-railties https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6695576/ Testsuite is failing, but due to some different reason: ``` Failure: FullStackConsoleTest#test_sandbox [test/application/console_test.rb:133]: "> " expected, but got: Loading development environment in sandbox (Rails 7.0.8) Any modifications you make will be rolled back on exit â–½. Expected # encoding: ASCII-8BIT # valid: true "Loading development environment in sandbox (Rails 7.0.8)\r\nAny modifications you make will be rolled back on exit\r\n\e[1G\xE2\x96\xBD\e[6n" to include "> ". rails test test/application/console_test.rb:139 F Failure: FullStackConsoleTest#test_environment_option_and_irb_option [test/application/console_test.rb:133]: "> " expected, but got: Loading test environment (Rails 7.0.8) Switch to inspect mode. â–½. Expected # encoding: ASCII-8BIT # valid: true "Loading test environment (Rails 7.0.8)\r\nSwitch to inspect mode.\r\n\e[1G\xE2\x96\xBD\e[6n" to include "> ". ``` Isn't this related to the Aruba + Reline issue? https://bugs.ruby-lang.org/issues/20052 https://github.com/ruby/reline/issues/616 Vít I have tried to reproduce this with the latest version of Ruby, I have execute the console_test.rb more then 100x and I have not hit the issue. Was it fixed somehow? Not sure. Vít Well, actually with rubygem-railties-7.0.8-2 , FullStackConsoleTest#test_sandbox [test/application/console_test.rb:133] is passing, but with rubygem-railties-7.0.8-1, I still see the same error (with ruby git 7c2d819862) Failure: FullStackConsoleTest#test_sandbox [test/application/console_test.rb:133]: "> " expected, but got: /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. Loading development environment in sandbox (Rails 7.0.8) Any modifications you make will be rolled back on exit ▽. Expected # encoding: ASCII-8BIT #valid: true "/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.\r\n/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.\r\n/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.\r\nLoading development environment in sandbox (Rails 7.0.8)\r\nAny modifications you make will be rolled back on exit\r\n\e[1G\xE2\x96\xBD\e[6n" to include "> ". So comparing with 1 and 2, there is Patch4: rubygem-railties-7.1.0-Run-Rails-console-test-against-IRB-with-Reline-instead-of.patch This patch actually seems to have fixed the above issue. (You are trying to reproduce the above issue with -2?) Regards, Mamoru -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam,
Re: Current rubygem- packages rebuild failure against ruby 3.3
Dne 15. 12. 23 v 17:03 Vít Ondruch napsal(a): Dne 15. 12. 23 v 11:10 Vít Ondruch napsal(a): Dne 26. 11. 23 v 15:13 Mamoru TASAKA napsal(a): 7. rubygem-railties https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6695576/ Testsuite is failing, but due to some different reason: ``` Failure: FullStackConsoleTest#test_sandbox [test/application/console_test.rb:133]: "> " expected, but got: Loading development environment in sandbox (Rails 7.0.8) Any modifications you make will be rolled back on exit â–½. Expected # encoding: ASCII-8BIT # valid: true "Loading development environment in sandbox (Rails 7.0.8)\r\nAny modifications you make will be rolled back on exit\r\n\e[1G\xE2\x96\xBD\e[6n" to include "> ". rails test test/application/console_test.rb:139 F Failure: FullStackConsoleTest#test_environment_option_and_irb_option [test/application/console_test.rb:133]: "> " expected, but got: Loading test environment (Rails 7.0.8) Switch to inspect mode. â–½. Expected # encoding: ASCII-8BIT # valid: true "Loading test environment (Rails 7.0.8)\r\nSwitch to inspect mode.\r\n\e[1G\xE2\x96\xBD\e[6n" to include "> ". ``` Isn't this related to the Aruba + Reline issue? https://bugs.ruby-lang.org/issues/20052 https://github.com/ruby/reline/issues/616 Vít I have tried to reproduce this with the latest version of Ruby, I have execute the console_test.rb more then 100x and I have not hit the issue. Was it fixed somehow? Not sure. Vít OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
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! OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Current rubygem- packages rebuild failure against ruby 3.3
Dne 15. 12. 23 v 17:57 Vít Ondruch napsal(a): There is one remaining issue: ~~~ * Test file: test/version_test.rb /usr/share/gems/gems/zeitwerk-2.6.6/lib/zeitwerk/kernel.rb:38: warning: drb/unix is found in drb, which 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 zeitwerk-2.6.6 to add drb into its gemspec. Run options: --seed 46867 # Running: .. Finished in 0.000818s, 2444.6226 runs/s, 3666.9340 assertions/s. 2 runs, 3 assertions, 0 failures, 0 errors, 0 skips ~~~ Yes, the warning. I am testing with modified rubygem-activesupport [1], which is adding the dependency : ~~~ $ rpm -qR rubygem-activesupport (rubygem(concurrent-ruby) >= 1.0 with rubygem(concurrent-ruby) < 2 with rubygem(concurrent-ruby) >= 1.0.2) (rubygem(i18n) >= 1.6 with rubygem(i18n) < 2) (rubygem(tzinfo) >= 2.0 with rubygem(tzinfo) < 3) rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsZstd) <= 5.4.18-1 rpmlib(RichDependencies) <= 4.12.0-1 ruby(rubygems) rubygem(base64) rubygem(bigdecimal) rubygem(bigdecimal) rubygem(drb) rubygem(json) rubygem(minitest) >= 5.1 rubygem(mutex_m) tzdata $ cat /usr/share/gems/specifications/activesupport-7.0.8.gemspec | grep drb s.add_runtime_dependency(%q.freeze, [">= 0".freeze]) ~~~ And that should be enough. But it is not. Strange ... Vít This seems to be fixed now. Likely by PRs referred here: https://bugs.ruby-lang.org/issues/20065#change-105723 V. OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Current rubygem- packages rebuild failure against ruby 3.3
Dne 15. 12. 23 v 17:57 Vít Ondruch napsal(a): Dne 15. 12. 23 v 17:03 Vít Ondruch napsal(a): Dne 15. 12. 23 v 11:10 Vít Ondruch napsal(a): Dne 26. 11. 23 v 15:13 Mamoru TASAKA napsal(a): 7. rubygem-railties https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6695576/ Testsuite is failing, but due to some different reason: ``` Failure: FullStackConsoleTest#test_sandbox [test/application/console_test.rb:133]: "> " expected, but got: Loading development environment in sandbox (Rails 7.0.8) Any modifications you make will be rolled back on exit â–½. Expected # encoding: ASCII-8BIT # valid: true "Loading development environment in sandbox (Rails 7.0.8)\r\nAny modifications you make will be rolled back on exit\r\n\e[1G\xE2\x96\xBD\e[6n" to include "> ". rails test test/application/console_test.rb:139 F Failure: FullStackConsoleTest#test_environment_option_and_irb_option [test/application/console_test.rb:133]: "> " expected, but got: Loading test environment (Rails 7.0.8) Switch to inspect mode. â–½. Expected # encoding: ASCII-8BIT # valid: true "Loading test environment (Rails 7.0.8)\r\nSwitch to inspect mode.\r\n\e[1G\xE2\x96\xBD\e[6n" to include "> ". ``` Isn't this related to the Aruba + Reline issue? https://bugs.ruby-lang.org/issues/20052 https://github.com/ruby/reline/issues/616 Luckily, there seems to be fix: https://github.com/rails/rails/pull/48369/commits/cf45394d104b00679c900e9d2dd09154cadcbe11 The fix is in Rawhide: https://src.fedoraproject.org/rpms/rubygem-railties/c/3c1796f9c84c0b0c9eb0628364c24f850ba3c3af https://koji.fedoraproject.org/koji/taskinfo?taskID=110386448 But unfortunately, to pass the test suite with Ruby 3.3, the modified rubygem-activesupport is needed (as discussed elsewhere). Vít There is one remaining issue: ~~~ * Test file: test/version_test.rb /usr/share/gems/gems/zeitwerk-2.6.6/lib/zeitwerk/kernel.rb:38: warning: drb/unix is found in drb, which 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 zeitwerk-2.6.6 to add drb into its gemspec. Run options: --seed 46867 # Running: .. Finished in 0.000818s, 2444.6226 runs/s, 3666.9340 assertions/s. 2 runs, 3 assertions, 0 failures, 0 errors, 0 skips ~~~ Yes, the warning. I am testing with modified rubygem-activesupport [1], which is adding the dependency : ~~~ $ rpm -qR rubygem-activesupport (rubygem(concurrent-ruby) >= 1.0 with rubygem(concurrent-ruby) < 2 with rubygem(concurrent-ruby) >= 1.0.2) (rubygem(i18n) >= 1.6 with rubygem(i18n) < 2) (rubygem(tzinfo) >= 2.0 with rubygem(tzinfo) < 3) rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsZstd) <= 5.4.18-1 rpmlib(RichDependencies) <= 4.12.0-1 ruby(rubygems) rubygem(base64) rubygem(bigdecimal) rubygem(bigdecimal) rubygem(drb) rubygem(json) rubygem(minitest) >= 5.1 rubygem(mutex_m) tzdata $ cat /usr/share/gems/specifications/activesupport-7.0.8.gemspec | grep drb s.add_runtime_dependency(%q.freeze, [">= 0".freeze]) ~~~ And that should be enough. But it is not. Strange ... Vít [1] https://src.fedoraproject.org/rpms/rubygem-activesupport/pull-request/4 OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
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 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 路♂️ 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
Re: Current rubygem- packages rebuild failure against ruby 3.3
Dne 15. 12. 23 v 17:03 Vít Ondruch napsal(a): Dne 15. 12. 23 v 11:10 Vít Ondruch napsal(a): Dne 26. 11. 23 v 15:13 Mamoru TASAKA napsal(a): 7. rubygem-railties https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6695576/ Testsuite is failing, but due to some different reason: ``` Failure: FullStackConsoleTest#test_sandbox [test/application/console_test.rb:133]: "> " expected, but got: Loading development environment in sandbox (Rails 7.0.8) Any modifications you make will be rolled back on exit â–½. Expected # encoding: ASCII-8BIT # valid: true "Loading development environment in sandbox (Rails 7.0.8)\r\nAny modifications you make will be rolled back on exit\r\n\e[1G\xE2\x96\xBD\e[6n" to include "> ". rails test test/application/console_test.rb:139 F Failure: FullStackConsoleTest#test_environment_option_and_irb_option [test/application/console_test.rb:133]: "> " expected, but got: Loading test environment (Rails 7.0.8) Switch to inspect mode. â–½. Expected # encoding: ASCII-8BIT # valid: true "Loading test environment (Rails 7.0.8)\r\nSwitch to inspect mode.\r\n\e[1G\xE2\x96\xBD\e[6n" to include "> ". ``` Isn't this related to the Aruba + Reline issue? https://bugs.ruby-lang.org/issues/20052 https://github.com/ruby/reline/issues/616 Luckily, there seems to be fix: https://github.com/rails/rails/pull/48369/commits/cf45394d104b00679c900e9d2dd09154cadcbe11 There is one remaining issue: ~~~ * Test file: test/version_test.rb /usr/share/gems/gems/zeitwerk-2.6.6/lib/zeitwerk/kernel.rb:38: warning: drb/unix is found in drb, which 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 zeitwerk-2.6.6 to add drb into its gemspec. Run options: --seed 46867 # Running: .. Finished in 0.000818s, 2444.6226 runs/s, 3666.9340 assertions/s. 2 runs, 3 assertions, 0 failures, 0 errors, 0 skips ~~~ Yes, the warning. I am testing with modified rubygem-activesupport [1], which is adding the dependency : ~~~ $ rpm -qR rubygem-activesupport (rubygem(concurrent-ruby) >= 1.0 with rubygem(concurrent-ruby) < 2 with rubygem(concurrent-ruby) >= 1.0.2) (rubygem(i18n) >= 1.6 with rubygem(i18n) < 2) (rubygem(tzinfo) >= 2.0 with rubygem(tzinfo) < 3) rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsZstd) <= 5.4.18-1 rpmlib(RichDependencies) <= 4.12.0-1 ruby(rubygems) rubygem(base64) rubygem(bigdecimal) rubygem(bigdecimal) rubygem(drb) rubygem(json) rubygem(minitest) >= 5.1 rubygem(mutex_m) tzdata $ cat /usr/share/gems/specifications/activesupport-7.0.8.gemspec | grep drb s.add_runtime_dependency(%q.freeze, [">= 0".freeze]) ~~~ And that should be enough. But it is not. Strange ... Vít [1] https://src.fedoraproject.org/rpms/rubygem-activesupport/pull-request/4 OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Current rubygem- packages rebuild failure against ruby 3.3
Dne 15. 12. 23 v 11:10 Vít Ondruch napsal(a): Dne 26. 11. 23 v 15:13 Mamoru TASAKA napsal(a): 7. rubygem-railties https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6695576/ Testsuite is failing, but due to some different reason: ``` Failure: FullStackConsoleTest#test_sandbox [test/application/console_test.rb:133]: "> " expected, but got: Loading development environment in sandbox (Rails 7.0.8) Any modifications you make will be rolled back on exit â–½. Expected # encoding: ASCII-8BIT # valid: true "Loading development environment in sandbox (Rails 7.0.8)\r\nAny modifications you make will be rolled back on exit\r\n\e[1G\xE2\x96\xBD\e[6n" to include "> ". rails test test/application/console_test.rb:139 F Failure: FullStackConsoleTest#test_environment_option_and_irb_option [test/application/console_test.rb:133]: "> " expected, but got: Loading test environment (Rails 7.0.8) Switch to inspect mode. â–½. Expected # encoding: ASCII-8BIT # valid: true "Loading test environment (Rails 7.0.8)\r\nSwitch to inspect mode.\r\n\e[1G\xE2\x96\xBD\e[6n" to include "> ". ``` Isn't this related to the Aruba + Reline issue? https://bugs.ruby-lang.org/issues/20052 https://github.com/ruby/reline/issues/616 Vít OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
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 OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
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 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 路♂️ 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.
Re: Ruby 3.3
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-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Current rubygem- packages rebuild failure against ruby 3.3
Dne 15. 12. 23 v 11:10 Vít Ondruch napsal(a): Dne 26. 11. 23 v 15:13 Mamoru TASAKA napsal(a): 7. rubygem-railties https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6695576/ Testsuite is failing, but due to some different reason: ``` Failure: FullStackConsoleTest#test_sandbox [test/application/console_test.rb:133]: "> " expected, but got: Loading development environment in sandbox (Rails 7.0.8) Any modifications you make will be rolled back on exit â–½. Expected # encoding: ASCII-8BIT # valid: true "Loading development environment in sandbox (Rails 7.0.8)\r\nAny modifications you make will be rolled back on exit\r\n\e[1G\xE2\x96\xBD\e[6n" to include "> ". rails test test/application/console_test.rb:139 F Failure: FullStackConsoleTest#test_environment_option_and_irb_option [test/application/console_test.rb:133]: "> " expected, but got: Loading test environment (Rails 7.0.8) Switch to inspect mode. â–½. Expected # encoding: ASCII-8BIT # valid: true "Loading test environment (Rails 7.0.8)\r\nSwitch to inspect mode.\r\n\e[1G\xE2\x96\xBD\e[6n" to include "> ". ``` 12. rubygem-railties https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576593/ ``` Failure: ApplicationTests::AssetsTest#test_precompile_shouldn't_use_the_digests_present_in_manifest.json [test/application/assets_test.rb:299]: Expected "application-c56ef81d122dffa8b257b0546ba1b09bd2d8b97e4aef881de8db9f760b903af6.css" to not be equal to "application-c56ef81d122dffa8b257b0546ba1b09bd2d8b97e4aef881de8db9f760b903af6.css". ``` Not sure what this means. This one ^^ is reproducible even with Ruby 3.2. I have reported it here: https://github.com/rails/rails/issues/50364 Vít This seems to be flaky test suite, while it might be also due to Ruby 3.3. So far, I have 14 builds in my Copr and all failed, with one of the failures above. Trying to reproduce locally, the first build passed right away, while the second failed on the AssetsTest. I'll try to look around if there are by a chance some changes in the upstream repo. Vít OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
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 -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Current rubygem- packages rebuild failure against ruby 3.3
Dne 26. 11. 23 v 15:13 Mamoru TASAKA napsal(a): 7. rubygem-railties https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6695576/ Testsuite is failing, but due to some different reason: ``` Failure: FullStackConsoleTest#test_sandbox [test/application/console_test.rb:133]: "> " expected, but got: Loading development environment in sandbox (Rails 7.0.8) Any modifications you make will be rolled back on exit â–½. Expected # encoding: ASCII-8BIT # valid: true "Loading development environment in sandbox (Rails 7.0.8)\r\nAny modifications you make will be rolled back on exit\r\n\e[1G\xE2\x96\xBD\e[6n" to include "> ". rails test test/application/console_test.rb:139 F Failure: FullStackConsoleTest#test_environment_option_and_irb_option [test/application/console_test.rb:133]: "> " expected, but got: Loading test environment (Rails 7.0.8) Switch to inspect mode. â–½. Expected # encoding: ASCII-8BIT # valid: true "Loading test environment (Rails 7.0.8)\r\nSwitch to inspect mode.\r\n\e[1G\xE2\x96\xBD\e[6n" to include "> ". ``` 12. rubygem-railties https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576593/ ``` Failure: ApplicationTests::AssetsTest#test_precompile_shouldn't_use_the_digests_present_in_manifest.json [test/application/assets_test.rb:299]: Expected "application-c56ef81d122dffa8b257b0546ba1b09bd2d8b97e4aef881de8db9f760b903af6.css" to not be equal to "application-c56ef81d122dffa8b257b0546ba1b09bd2d8b97e4aef881de8db9f760b903af6.css". ``` Not sure what this means. This seems to be flaky test suite, while it might be also due to Ruby 3.3. So far, I have 14 builds in my Copr and all failed, with one of the failures above. Trying to reproduce locally, the first build passed right away, while the second failed on the AssetsTest. I'll try to look around if there are by a chance some changes in the upstream repo. Vít OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Current rubygem- packages rebuild failure against ruby 3.3
Dne 26. 11. 23 v 15:13 Mamoru TASAKA napsal(a):
rubygem-shoulda-matchers is FIXED:
With some discussion, this is fixed on ruby side:
https://github.com/ruby/ruby/commit/e34e8b93f8fac3ef40ab5ed8672fa003f3b4d9c0
ref: https://github.com/rubygems/rubygems/pull/7128
14.
rubygem-shoulda-matchers
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576601/
Lots of:
```
An error occurred while loading
./spec/unit/shoulda/matchers/action_controller/callback_matcher_spec.rb.
Failure/Error: require 'unit_spec_helper'
NoMethodError:
undefined method `tr' for an instance of Pathname
```
Not sure what this means.
There is unfortunately another issue with shoulda-matchers:
~~~
1) shoulda-matchers integrates with Rails in a project that uses Spring
Failure/Error: run_rake_tasks!('db:drop', 'db:create', 'db:migrate')
RuntimeError:
Command
"BUNDLE_GEMFILE=\"/tmp/shoulda-matchers-acceptance/test-project/Gemfile\"
bundle _2.5.0.dev_ exec rake db:drop db:create db:migrate --trace"
exited with status 1.
Output:
---START
bundler: failed to load command: rake (/usr/bin/rake)
/usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:451:in
`validate_ruby!': Your Ruby version is 3.3.0.dev, but your Gemfile
specified 3.3.0 (Bundler::RubyVersionMismatch)
from
/usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:426:in
`validate_runtime!'
from
/usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler.rb:157:in `setup'
from
/usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/setup.rb:23:in `block
in '
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 `(required)>'
from
/usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/cli/exec.rb:56:in
`require_relative'
from
/usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/cli/exec.rb:56:in
`kernel_load'
from
/usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/cli/exec.rb:23:in `run'
from
/usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/cli.rb:491:in `exec'
from
/usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/vendor/thor/lib/thor/command.rb:28:in
`run'
from
/usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in
`invoke_command'
from
/usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/vendor/thor/lib/thor.rb:527:in
`dispatch'
from
/usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/cli.rb:34:in `dispatch'
from
/usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/vendor/thor/lib/thor/base.rb:584:in
`start'
from
/usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/cli.rb:28:in `start'
from
/usr/share/gems/gems/bundler-2.5.0.dev/libexec/bundle:28:in `block in
'
from
/usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/friendly_errors.rb:117:in
`with_friendly_errors'
from
/usr/share/gems/gems/bundler-2.5.0.dev/libexec/bundle:20:in `(required)>'
from /usr/bin/bundle:25:in `load'
from /usr/bin/bundle:25:in `'
---END--
#
/builddir/build/BUILD/spec/support/tests/command_runner.rb:111:in `fail!'
# /builddir/build/BUILD/spec/support/tests/command_runner.rb:69:in
`block (2 levels) in call'
#
/builddir/build/BUILD/spec/support/tests/command_runner.rb:196:in
`possibly_running_quickly'
# /builddir/build/BUILD/spec/support/tests/command_runner.rb:65:in
`block in call'
#
/builddir/build/BUILD/spec/support/tests/command_runner.rb:202:in
`possibly_retrying'
# /builddir/build/BUILD/spec/support/tests/command_runner.rb:64:in
`call'
# /builddir/build/BUILD/spec/support/tests/command_runner.rb:11:in
`block in run'
# /builddir/build/BUILD/spec/support/tests/command_runner.rb:9:in
`run'
#
/builddir/build/BUILD/spec/support/acceptance/helpers/command_helpers.rb:10:in
`run_command'
#
/builddir/build/BUILD/spec/support/acceptance/helpers/command_helpers.rb:24:in
`run_command_isolated_from_bundle'
#
/builddir/build/BUILD/spec/support/acceptance/helpers/command_helpers.rb:41:in
`run_command_within_bundle'
#
/builddir/build/BUILD/spec/support/acceptance/helpers/command_helpers.rb:50:in
`run_command_within_bundle!'
#
/builddir/build/BUILD/spec/support/acceptance/helpers/command_helpers.rb:65:in
`run_rake_tasks!'
# ./spec/acceptance/rails_integration_spec.rb:17:in `block (2
levels) in '
# /usr/share/gems/gems/bundler-2.5.0.dev/libexec/bundle:28:in
`block in '
# /usr/share/gems/gems/bundler-2.5.0.dev/libexec/bundle:20:in
Re: Ruby 3.3
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 OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
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", (: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 ' 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 `' from :127:in `require' from :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 `' 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 `' 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 `' 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 `' from :127:in `require' from :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 `' from :127:in `require' from :127:in `require' from :411:in `glob' from -e:1:in `' /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/build/6752051/ 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/build/6751386/ ) I'll take a close look a bit later. However, from top of my head, there were also other changes, such as this:
Re: Ruby 3.3
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", (: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 ' 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 `' from :127:in `require' from :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 `' 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 `' 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 `' 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 `' from :127:in `require' from :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 `' from :127:in `require' from :127:in `require' from :411:in `glob' from -e:1:in `' /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/build/6752051/ 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/build/6751386/ ) 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
Re: Ruby 3.3
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", (: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 ' 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 `' from :127:in `require' from :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 `' 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 `' 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 `' 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 `' from :127:in `require' from :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 `' from :127:in `require' from :127:in `require' from :411:in `glob' from -e:1:in `' /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/build/6752051/ 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/build/6751386/ ) 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
Re: Ruby 3.3
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", (: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 ' 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 `' from :127:in `require' from :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 `' 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 `' 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 `' 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 `' from :127:in `require' from :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 `' from :127:in `require' from :127:in `require' from :411:in `glob' from -e:1:in `' /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/build/6752051/ 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/build/6751386/ ) * 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
Re: Ruby 3.3
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/build/6743508/ ``` 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, 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/06adecc349381e906c481c3296045ba2dd8850e6 OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
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/5fd12c42e7911fe5a07db3f92167983bd6e78008/f/operating_system.rb#_102-104
[3] https://github.com/rubygems/rubygems/pull/7243
[4]
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/d3eaae9cc22d725b74dfdef3446b12d09fb1d9d1
OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
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
`': 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
`'
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
`'
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
`'
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
`'
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
`'
from -e:1:in `require'
from -e:1:in `'
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...75f4a687ed54e3b1863ba1767c666a0bea809c8a
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-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email t
Re: Ruby 3.3
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
`': 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
`'
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
`'
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
`'
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
`'
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
`'
from -e:1:in `require'
from -e:1:in `'
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...75f4a687ed54e3b1863ba1767c666a0bea809c8a
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-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
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
`': 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
`'
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
`'
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 `'
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
`'
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
`'
from -e:1:in `require'
from -e:1:in `'
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...75f4a687ed54e3b1863ba1767c666a0bea809c8a
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
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
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/build/6743508/ ``` 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, 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/206942674e5fb16e90d777de6e3debc842fe9b6c 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?collection=f40 I wish Koschei notifications were back ... 9. rubygem-rubygems-mirror https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6743512/ ``` + ruby -Ilib -e 'Dir.glob "./test/test_*.rb", (:require)' :127:in `require': cannot load such file -- rubygems/indexer (LoadError) from :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 `' from :127:in `require' from :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 `' from :127:in `require' from :127:in `require' from :411:in `glob' from -e:1:in `' ``` 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 OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
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/build/6743492/ 2. rubygem-aruba https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6743493/ 3. rubygem-async_sinatra https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6743494/ 4. rubygem-byebug https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6743496/ 5. rubygem-childprocess https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6743497/ 6. rubygem-ronn-ng https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6743511/ 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/build/6743510/ 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/build/6743508/ ``` 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/206942674e5fb16e90d777de6e3debc842fe9b6c 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?collection=f40 9. rubygem-rubygems-mirror https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6743512/ ``` + ruby -Ilib -e 'Dir.glob "./test/test_*.rb", (:require)' :127:in `require': cannot load such file -- rubygems/indexer (LoadError) from :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 `' from :127:in `require' from :127:in `require' from /builddir/build/BUIL
Re: Ruby 3.3
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 OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
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/5bd6a6753bdf406a2ce63cb6012a979ab4357ab5?branch=private-ruby-2.5 [2] https://github.com/rubygems/rubygems/pull/2841 [3] https://github.com/rubygems/rubygems/pull/7212 OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
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 U 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 ' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/local_address_spec.rb:4:in `' 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 ' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/local_address_spec.rb:4:in `' 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 ' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/remote_address_spec.rb:4:in `' 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 ' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/remote_address_spec.rb:4:in `' 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 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 OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
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 U 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 ' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/local_address_spec.rb:4:in `' 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 ' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/local_address_spec.rb:4:in `' 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 ' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/remote_address_spec.rb:4:in `' 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 ' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/remote_address_spec.rb:4:in `' 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 -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Current rubygem- packages rebuild failure against ruby 3.3
Dne 28. 11. 23 v 17:04 Vít Ondruch napsal(a): Dne 26. 11. 23 v 15:13 Mamoru TASAKA napsal(a): 5. rubygem-childprocess https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6695574/ Same as before. 7. rubygem-childprocess https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576582/ `Failure/Error: require 'rubygems/mock_gem_ui'` This file is removed: https://github.com/ruby/ruby/commit/74772840430fc3fca3f5fb0ad585d9cc48f512fb Need to address in childprocess side. Just FTR, this affects one test case which is already half disabled: https://src.fedoraproject.org/rpms/rubygem-childprocess/blob/19e16da4314f06781113fd270e32edbf67225ee2/f/rubygem-childprocess.spec#_50 Actually it is completely disabled, not just half disabled. It does not anything meaningful with the line commented out. Vít I have reported the issue upstream: https://github.com/enkessler/childprocess/issues/190 Vít OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Current rubygem- packages rebuild failure against ruby 3.3
Dne 26. 11. 23 v 15:13 Mamoru TASAKA napsal(a): 5. rubygem-childprocess https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6695574/ Same as before. 7. rubygem-childprocess https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576582/ `Failure/Error: require 'rubygems/mock_gem_ui'` This file is removed: https://github.com/ruby/ruby/commit/74772840430fc3fca3f5fb0ad585d9cc48f512fb Need to address in childprocess side. Just FTR, this affects one test case which is already half disabled: https://src.fedoraproject.org/rpms/rubygem-childprocess/blob/19e16da4314f06781113fd270e32edbf67225ee2/f/rubygem-childprocess.spec#_50 I have reported the issue upstream: https://github.com/enkessler/childprocess/issues/190 Vít OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
Dne 09. 11. 23 v 19:09 jpro...@redhat.com napsal(a):
On 11/9/23 18:27, Vít Ondruch wrote:
Dne 07. 11. 23 v 12:56 jpro...@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.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.
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
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 ;)
2) 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/5fd12c42e7911fe5a07db3f92167983bd6e78008/f/rubygems.prov#_12
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.
3) 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.
After all, I went for much simpler solution ;)
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/bb3a95723018cc892089b8bc9fd8f67f3eb94594
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
Re: Current rubygem- packages rebuild failure against ruby 3.3
Hello again, all:
Now with again I tried to rebuild all rubygem-foo pacakages on Fedora with
ruby 3.3.0dev:
The packages failing to build with:
https://github.com/ruby/ruby/commit/9cd086ba4b559153864ab924723a665a4ddfb5d8
are listed below. (Commented inline between my previous post.)
8 packages are still failing to build.
Mamoru TASAKA wrote on 2023/10/29 17:09:
Hello, all:
With wonderful work by Vít and friends, again I tried to rebuild all rubygem-foo
packages on Fedora against ruby 3.3.0dev.
For the below failure reports,
https://github.com/ruby/ruby/commit/83ecdd1dce18246de631eb3b5d8308145bb269f5
is used.
Among ~455 packages, now 16 packages see build failure. Please check what is
going,
thank you.
Regards,
Mamoru
1. rubygem-actionview
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6695570/
Same as before.
1.
rubygem-actionview
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576506/
```
Failure:
RipperTrackerTest#test_finds_dependencies_with_extra_spaces
[test/template/dependency_tracker_test.rb:191]:
--- expected
+++ actual
@@ -1 +1 @@
-["spaces/header", "spaces/form", "messages/message", "events/event",
"comments/comment"]
+["spaces/header", "spaces/form", "messages/message", "comments/comment"]
```
Discussed on:
https://src.fedoraproject.org/rpms/rubygem-actionview/pull-request/4
rubygem-addressable is FIXED: as reported before, this is fixed with
https://github.com/ruby/ruby/pull/8813
https://bugs.ruby-lang.org/issues/19992
2.
rubygem-addressable
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576510/
Test suite segfaults constantly...
2. rubygem-aruba
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6695571/
Same as before.
3.
rubygem-aruba
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576568/
Cucumber testsuite fails. Some test failures are due to removed
irb/ext/save-history,
some are due to pry behaving badly? on ruby3.3 (not knowing in details), others
I don't know.
Already reported https://github.com/cucumber/aruba/issues/910 , no response.
3. rubygem-async_sinatra
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6695572/
Same as before.
4.
rubygem-async_sinatra
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576572/
`test/test_async.rb:28:in `': uninitialized constant MiniTest (NameError)`
Fixing this will perhaps be easy, leaving this to maintainer for now.
rubygem-bootsnap is FIXED: https://github.com/Shopify/bootsnap/pull/460
5.
rubygem-bootsnap
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576574/
```
1) Failure:
Bootsnap::KernelRequireTest#test_uses_the_same_duck_type_as_require
[/builddir/build/BUILD/bootsnap-1.15.0/usr/share/gems/gems/bootsnap-1.15.0/test/load_path_cache/core_ext/kernel_require_test.rb:26]:
Expected # to be success?.
```
I don't know what this means. With ruby 7b8d472100 (around 2023-10-06) test was
successful,
but with ruby 55c5ebe0a0 (around 2023-10-14) test test fails, not sure what
ruby change caused
this.
4. rubygem-byebug
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6695573/
Same as before.
Note that as I posted before, I've already orphaned rubygem-byebug.
It seems rubygem-pry-byebug only depends on rubygem-byebug.
6.
rubygem-byebug
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576577/
As discussed before, I don't expect that rubygem-byebug comes to work with
ruby3.3.
Probably I am going to orphan this.
5. rubygem-childprocess
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6695574/
Same as before.
7.
rubygem-childprocess
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576582/
`Failure/Error: require 'rubygems/mock_gem_ui'`
This file is removed:
https://github.com/ruby/ruby/commit/74772840430fc3fca3f5fb0ad585d9cc48f512fb
Need to address in childprocess side.
6. NEW: rubygem-liquid
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6695575/
```
1) Failure:
StandardFiltersTest#test_sort_when_property_is_sometimes_missing_puts_nils_last
[/builddir/build/BUILD/liquid-4.0.3/usr/share/gems/gems/liquid-4.0.3/test/integration/standard_filter_test.rb:220]:
--- expected
+++ actual
@@ -1 +1 @@
-[{"price"=>1, "handle"=>"gamma"}, {"price"=>2, "handle"=>"epsilon"}, {"price"=>4, "handle"=>"alpha"},
{"handle"=>"delta"}, {"handle"=>"beta"}]
+[{"price"=>1, "handle"=>"gamma"}, {"price"=>2, "handle"=>"epsilon"}, {"price"=>4, "handle"=>"alpha"},
{"handle"=>"beta"}, {"handle"=>"delta"}]
2) Failure:
StandardFiltersTest#test_sort_natural_when_property_is_sometimes_missing_puts_nils_last
[/builddir/build/BUILD/liquid-4.0.3/usr/share/gems/gems/liquid-4.0.3/test/integration/standard_filter_test.rb:248]:
---
Re: Ruby 3.3
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 OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
On 11/9/23 18:27, Vít Ondruch wrote:
Dne 07. 11. 23 v 12:56 jpro...@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.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.
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
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
~~~
2) 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/5fd12c42e7911fe5a07db3f92167983bd6e78008/f/rubygems.prov#_12
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.
3) 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
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
Dne 07. 11. 23 v 12:56 jpro...@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.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. 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 OpenPGP_signature.asc Description: OpenPGP digital signature ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Current rubygem- packages rebuild failure against ruby 3.3
Dne 08. 11. 23 v 16:13 Mamoru TASAKA napsal(a): Vít Ondruch wrote on 2023/10/30 19:37: Nice, thx for the summary and a few remarks inline. Dne 29. 10. 23 v 9:09 Mamoru TASAKA napsal(a): 2. rubygem-addressable https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576510/ Test suite segfaults constantly... Isn't this some RegExp / GC thing seeint this part of backtrace: ~~~ /lib64/libruby.so.3.3(rb_st_foreach+0x85) [0x7f2fc3b24285] /lib64/libruby.so.3.3(onig_names_free+0x27) [0x7f2fc3b10807] /lib64/libruby.so.3.3(onig_free+0x1a) [0x7f2fc3b035fa] /lib64/libruby.so.3.3(0x7f2fc3a24022) [0x7f2fc3a24022] /lib64/libruby.so.3.3(0x7f2fc3c1e048) [0x7f2fc3c1e048] /lib64/libruby.so.3.3(0x7f2fc3a21f23) [0x7f2fc3a21f23] /lib64/libruby.so.3.3(0x7f2fc3a2a39b) [0x7f2fc3a2a39b] /lib64/libruby.so.3.3(0x7f2fc3a2a7be) [0x7f2fc3a2a7be] /lib64/libruby.so.3.3(rb_wb_protected_newobj_of+0x74) [0x7f2fc3a2b0a4] Actually as you said this turned out to be GC issue on ruby regexp and is fixed with: https://github.com/ruby/ruby/pull/8813 https://bugs.ruby-lang.org/issues/19992 Now with f694bd158c rubygem-addressable test suite passes and builds successfully. Very nice. Thx a lot. I have just pushed out changes for ad3db6711c, so that should also include this fix. Vít OpenPGP_signature.asc Description: OpenPGP digital signature ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
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 OpenPGP_signature.asc Description: OpenPGP digital signature ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Current rubygem- packages rebuild failure against ruby 3.3
Vít Ondruch wrote on 2023/10/30 19:37: Nice, thx for the summary and a few remarks inline. Dne 29. 10. 23 v 9:09 Mamoru TASAKA napsal(a): 2. rubygem-addressable https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576510/ Test suite segfaults constantly... Isn't this some RegExp / GC thing seeint this part of backtrace: ~~~ /lib64/libruby.so.3.3(rb_st_foreach+0x85) [0x7f2fc3b24285] /lib64/libruby.so.3.3(onig_names_free+0x27) [0x7f2fc3b10807] /lib64/libruby.so.3.3(onig_free+0x1a) [0x7f2fc3b035fa] /lib64/libruby.so.3.3(0x7f2fc3a24022) [0x7f2fc3a24022] /lib64/libruby.so.3.3(0x7f2fc3c1e048) [0x7f2fc3c1e048] /lib64/libruby.so.3.3(0x7f2fc3a21f23) [0x7f2fc3a21f23] /lib64/libruby.so.3.3(0x7f2fc3a2a39b) [0x7f2fc3a2a39b] /lib64/libruby.so.3.3(0x7f2fc3a2a7be) [0x7f2fc3a2a7be] /lib64/libruby.so.3.3(rb_wb_protected_newobj_of+0x74) [0x7f2fc3a2b0a4] Actually as you said this turned out to be GC issue on ruby regexp and is fixed with: https://github.com/ruby/ruby/pull/8813 https://bugs.ruby-lang.org/issues/19992 Now with f694bd158c rubygem-addressable test suite passes and builds successfully. Mamoru ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
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 ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Current rubygem- packages rebuild failure against ruby 3.3
Mamoru TASAKA wrote on 2023/10/29 17:09: Hello, all: With wonderful work by Vít and friends, again I tried to rebuild all rubygem-foo packages on Fedora against ruby 3.3.0dev. For the below failure reports, https://github.com/ruby/ruby/commit/83ecdd1dce18246de631eb3b5d8308145bb269f5 is used. Among ~455 packages, now 16 packages see build failure. Please check what is going, thank you. Regards, Mamoru 6. rubygem-byebug https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576577/ As discussed before, I don't expect that rubygem-byebug comes to work with ruby3.3. Probably I am going to orphan this. 7. rubygem-childprocess https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576582/ `Failure/Error: require 'rubygems/mock_gem_ui'` This file is removed: https://github.com/ruby/ruby/commit/74772840430fc3fca3f5fb0ad585d9cc48f512fb Need to address in childprocess side. 10. rubygem-power_assert https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576589/ %check needs BR: rubygem-byebug , which doesn't build. Discussed on: https://github.com/ruby/power_assert/issues/47 , I may try to remove byebug dependency myself. Looking closely, it turned out that rubygem-power_assert does not strictly need rubygem-byebug: In both runtime and %check, power_assert tries to load byebug and if LoadError happens, it is just rescued and procedure continues. So I've now orphaned rubygem-byebug. Unless no one takes, it will be retired after 6 weeks or so. The packages which depends on rubygem-byebug (for Requires or BuildRequires) seems rubygem-pry-byebug only (maintainer CCed), which will become FTI and will be retired for Fedora 40 unless someone takes rubygem-byebug. Regards, Mamoru ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3 change proposal
Dne 02. 11. 23 v 11:15 jpro...@redhat.com napsal(a): On 11/1/23 11:17, Vít Ondruch wrote: Hi Rubyists, The release of Ruby 3.3 is coming close and to be ready for rebuild after Christmas, I have submitted the Ruby 3.3 change proposal [1]. It is already in `ChangeReadyForWrangler` state, since I don't expect any controversy (it is mostly copy paste of Ruby 3.2 change [2]). But anyway, please review and let me know if you have any concerns (or feel free to address them in the proposal). I don't see mentions of the new macro(s). I think we'd want them to also gain visibility via the Change. And this reminded me that once this lands, the documentation for Ruby packaging guidelines [3] will also deserve an update for this packaging macro extensions. The previous paragraph IMO means that there is a scope needed for guidelines update (only extension though, so nothing serious). I am not convinced yet that the changes are substantial enough to be worth of mentioning in the change proposal or in the guidelines. So far there is only new `%gem_name_version` and it is more utility for the other `%gem_*` macros then anything else. However, the time for guidelines might yet to come if `gem2rpm` adopts usage of these changes. PR could actually be convincing argument ;) I'll try to keep this in mind and don't hesitate to remind me this topic. Vít Jarek Also, I wonder if somebody wants to join me as an owner? Mamoru? You have been very helpful with this effort. Vít [1] https://fedoraproject.org/wiki/Changes/Ruby_3.3 [2] https://fedoraproject.org/wiki/Changes/Ruby_3.2 [3] https://docs.fedoraproject.org/en-US/packaging-guidelines/Ruby/ ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue OpenPGP_signature.asc Description: OpenPGP digital signature ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3 change proposal
On 11/1/23 11:17, Vít Ondruch wrote: Hi Rubyists, The release of Ruby 3.3 is coming close and to be ready for rebuild after Christmas, I have submitted the Ruby 3.3 change proposal [1]. It is already in `ChangeReadyForWrangler` state, since I don't expect any controversy (it is mostly copy paste of Ruby 3.2 change [2]). But anyway, please review and let me know if you have any concerns (or feel free to address them in the proposal). I don't see mentions of the new macro(s). I think we'd want them to also gain visibility via the Change. And this reminded me that once this lands, the documentation for Ruby packaging guidelines [3] will also deserve an update for this packaging macro extensions. The previous paragraph IMO means that there is a scope needed for guidelines update (only extension though, so nothing serious). Jarek Also, I wonder if somebody wants to join me as an owner? Mamoru? You have been very helpful with this effort. Vít [1] https://fedoraproject.org/wiki/Changes/Ruby_3.3 [2] https://fedoraproject.org/wiki/Changes/Ruby_3.2 [3] https://docs.fedoraproject.org/en-US/packaging-guidelines/Ruby/ ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
Dne 01. 11. 23 v 14:31 Pavel Valena napsal(a): On Wed, Nov 1, 2023 at 10:07 AM Vít Ondruch 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 >> wrote: >> >>> >>> Dne 26. 10. 23 v 18:26 Pavel Valena napsal(a): >>> >>> >>> >>> On Wed, Oct 25, 2023 at 4:31 PM Vít Ondruch >>> 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 > (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
Re: Ruby 3.3
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 OpenPGP_signature.asc Description: OpenPGP digital signature ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
On 11/1/23 15:01, Vít Ondruch wrote:
Dne 01. 11. 23 v 11:27 jpro...@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/c514f5f13c709dc289754663ba31491617d83811
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/05c3b37d1f8f91c3face5eeafe8d4c76fbdda495/docs/manual/macros.md?plain=1#L95
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/de...@lists.fedoraproject.org/thread/3MHROKOM53HM6NF7RGGLFBIQFG5IEIQG/
and in practice, this will look like:
<...snip>
Regards,
Jarek
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
Dne 01. 11. 23 v 11:27 jpro...@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/c514f5f13c709dc289754663ba31491617d83811
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/05c3b37d1f8f91c3face5eeafe8d4c76fbdda495/docs/manual/macros.md?plain=1#L95
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/de...@lists.fedoraproject.org/thread/3MHROKOM53HM6NF7RGGLFBIQFG5IEIQG/
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-le...@lists.fedoraproject.org
Fedora Code of
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List
Archives:https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report
it:https://pagure.io/fedora-infrastructure/new_issue
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3 change proposal
Dne 01. 11. 23 v 12:28 Mamoru TASAKA napsal(a): Vít Ondruch wrote on 2023/11/01 19:17: Hi Rubyists, The release of Ruby 3.3 is coming close and to be ready for rebuild after Christmas, I have submitted the Ruby 3.3 change proposal [1]. It is already in `ChangeReadyForWrangler` state, since I don't expect any controversy (it is mostly copy paste of Ruby 3.2 change [2]). But anyway, please review and let me know if you have any concerns (or feel free to address them in the proposal). Also, I wonder if somebody wants to join me as an owner? Mamoru? You have been very helpful with this effort. Thanks for inviting me! I am happy to become changeset co-owner with you. Thx! Feel free to adjust if I got something wrong: https://fedoraproject.org/w/index.php?title=Changes/Ruby_3.3=693729=693711 As before, I will do my best effort for Ruby 3.3 on Fedora. Appreciate that. Vít Regards, Mamoru Vít [1] https://fedoraproject.org/wiki/Changes/Ruby_3.3 [2] https://fedoraproject.org/wiki/Changes/Ruby_3.2 ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue OpenPGP_signature.asc Description: OpenPGP digital signature ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
On Wed, Nov 1, 2023 at 10:07 AM Vít Ondruch 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 > >> wrote: > >> > >>> > >>> Dne 26. 10. 23 v 18:26 Pavel Valena napsal(a): > >>> > >>> > >>> > >>> On Wed, Oct 25, 2023 at 4:31 PM Vít Ondruch > >>> 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 >> (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
Re: Current rubygem- packages rebuild failure against ruby 3.3
Vít Ondruch wrote on 2023/10/30 20:43: Dne 29. 10. 23 v 9:09 Mamoru TASAKA napsal(a): 14. rubygem-shoulda-matchers https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576601/ Lots of: ``` An error occurred while loading ./spec/unit/shoulda/matchers/action_controller/callback_matcher_spec.rb. Failure/Error: require 'unit_spec_helper' NoMethodError: undefined method `tr' for an instance of Pathname ``` Not sure what this means. This could be workaround: ~~~ $ git diff diff --git a/spec/support/unit/rails_application.rb b/spec/support/unit/rails_application.rb index b55b12ce..3d5609a1 100644 --- a/spec/support/unit/rails_application.rb +++ b/spec/support/unit/rails_application.rb @@ -184,7 +184,7 @@ end end def load_environment - require environment_file_path + require environment_file_path.to_s end def run_migrations ~~~ IOW it seems like there used to be conversion from Pathname to String somewhere, but it is not anymore. Vít Thank you. After looking at your comment above, it seems that it is indended that "require" (in bundler) supports Pathname, once it is modified so: https://github.com/rubygems/rubygems/pull/6837 This says "**Restore** support for Pathname objects in the replaced require" , so it used to support Pathname, but it got broken at some time, then modified again at this time. But looks like this got broken again by this commit: https://github.com/rubygems/rubygems/pull/7056 So may this this is wanted, but I am not sure. ``` diff --git a/lib/bundler/rubygems_integration.rb b/lib/bundler/rubygems_integration.rb index f420934ceb..59d32e68f3 100644 --- a/lib/bundler/rubygems_integration.rb +++ b/lib/bundler/rubygems_integration.rb @@ -244,6 +244,7 @@ def replace_require(specs) [::Kernel.singleton_class, ::Kernel].each do |kernel_class| kernel_class.send(:alias_method, :no_warning_require, :require) kernel_class.send(:define_method, :require) do |name| + name = File.path(name) if message = ::Gem::BUNDLED_GEMS.warning?(name, specs: specs) # rubocop:disable Style/HashSyntax warn message, :uplevel => 1 end ``` ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3 change proposal
Vít Ondruch wrote on 2023/11/01 19:17: Hi Rubyists, The release of Ruby 3.3 is coming close and to be ready for rebuild after Christmas, I have submitted the Ruby 3.3 change proposal [1]. It is already in `ChangeReadyForWrangler` state, since I don't expect any controversy (it is mostly copy paste of Ruby 3.2 change [2]). But anyway, please review and let me know if you have any concerns (or feel free to address them in the proposal). Also, I wonder if somebody wants to join me as an owner? Mamoru? You have been very helpful with this effort. Thanks for inviting me! I am happy to become changeset co-owner with you. As before, I will do my best effort for Ruby 3.3 on Fedora. Regards, Mamoru Vít [1] https://fedoraproject.org/wiki/Changes/Ruby_3.3 [2] https://fedoraproject.org/wiki/Changes/Ruby_3.2 ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
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/c514f5f13c709dc289754663ba31491617d83811
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/05c3b37d1f8f91c3face5eeafe8d4c76fbdda495/docs/manual/macros.md?plain=1#L95
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/de...@lists.fedoraproject.org/thread/3MHROKOM53HM6NF7RGGLFBIQFG5IEIQG/
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 to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Ruby 3.3 change proposal
Hi Rubyists, The release of Ruby 3.3 is coming close and to be ready for rebuild after Christmas, I have submitted the Ruby 3.3 change proposal [1]. It is already in `ChangeReadyForWrangler` state, since I don't expect any controversy (it is mostly copy paste of Ruby 3.2 change [2]). But anyway, please review and let me know if you have any concerns (or feel free to address them in the proposal). Also, I wonder if somebody wants to join me as an owner? Mamoru? You have been very helpful with this effort. Vít [1] https://fedoraproject.org/wiki/Changes/Ruby_3.3 [2] https://fedoraproject.org/wiki/Changes/Ruby_3.2 OpenPGP_signature.asc Description: OpenPGP digital signature ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
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 wrote: Dne 26. 10. 23 v 18:26 Pavel Valena napsal(a): On Wed, Oct 25, 2023 at 4:31 PM Vít Ondruch 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 (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? :D Vít Mamoru ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Ruby 3.3
Pavel Valena wrote on 2023/11/01 3:42: On Fri, Oct 27, 2023 at 12:36 PM Vít Ondruch wrote: Dne 26. 10. 23 v 18:26 Pavel Valena napsal(a): On Wed, Oct 25, 2023 at 4:31 PM Vít Ondruch 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. 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 ' ~~~ 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 ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
On Fri, Oct 27, 2023 at 12:36 PM Vít Ondruch wrote: > > Dne 26. 10. 23 v 18:26 Pavel Valena napsal(a): > > > > On Wed, Oct 25, 2023 at 4:31 PM Vít Ondruch 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. > > > 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 ' ~~~ 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 >> >> > > ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Current rubygem- packages rebuild failure against ruby 3.3
Dne 29. 10. 23 v 9:09 Mamoru TASAKA napsal(a): 14. rubygem-shoulda-matchers https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576601/ Lots of: ``` An error occurred while loading ./spec/unit/shoulda/matchers/action_controller/callback_matcher_spec.rb. Failure/Error: require 'unit_spec_helper' NoMethodError: undefined method `tr' for an instance of Pathname ``` Not sure what this means. This could be workaround: ~~~ $ git diff diff --git a/spec/support/unit/rails_application.rb b/spec/support/unit/rails_application.rb index b55b12ce..3d5609a1 100644 --- a/spec/support/unit/rails_application.rb +++ b/spec/support/unit/rails_application.rb @@ -184,7 +184,7 @@ end end def load_environment - require environment_file_path + require environment_file_path.to_s end def run_migrations ~~~ IOW it seems like there used to be conversion from Pathname to String somewhere, but it is not anymore. Vít OpenPGP_signature.asc Description: OpenPGP digital signature ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Current rubygem- packages rebuild failure against ruby 3.3
Nice, thx for the summary and a few remarks inline. Dne 29. 10. 23 v 9:09 Mamoru TASAKA napsal(a): 2. rubygem-addressable https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576510/ Test suite segfaults constantly... Isn't this some RegExp / GC thing seeint this part of backtrace: ~~~ /lib64/libruby.so.3.3(rb_st_foreach+0x85) [0x7f2fc3b24285] /lib64/libruby.so.3.3(onig_names_free+0x27) [0x7f2fc3b10807] /lib64/libruby.so.3.3(onig_free+0x1a) [0x7f2fc3b035fa] /lib64/libruby.so.3.3(0x7f2fc3a24022) [0x7f2fc3a24022] /lib64/libruby.so.3.3(0x7f2fc3c1e048) [0x7f2fc3c1e048] /lib64/libruby.so.3.3(0x7f2fc3a21f23) [0x7f2fc3a21f23] /lib64/libruby.so.3.3(0x7f2fc3a2a39b) [0x7f2fc3a2a39b] /lib64/libruby.so.3.3(0x7f2fc3a2a7be) [0x7f2fc3a2a7be] /lib64/libruby.so.3.3(rb_wb_protected_newobj_of+0x74) [0x7f2fc3a2b0a4] ~~~ 5. rubygem-bootsnap https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576574/ ``` 1) Failure: Bootsnap::KernelRequireTest#test_uses_the_same_duck_type_as_require [/builddir/build/BUILD/bootsnap-1.15.0/usr/share/gems/gems/bootsnap-1.15.0/test/load_path_cache/core_ext/kernel_require_test.rb:26]: Expected # to be success?. ``` I don't know what this means. With ruby 7b8d472100 (around 2023-10-06) test was successful, but with ruby 55c5ebe0a0 (around 2023-10-14) test test fails, not sure what ruby change caused this. Looking at the test case, wouldn't it be enough to remove the `fork` [1] to get more information? Of course it would fail the rest of test suite [1] https://github.com/Shopify/bootsnap/blob/c78981903d958ceacdaec843b9832addf87cbdb8/test/load_path_cache/core_ext/kernel_require_test.rb#L14 7. rubygem-childprocess https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576582/ `Failure/Error: require 'rubygems/mock_gem_ui'` This file is removed: https://github.com/ruby/ruby/commit/74772840430fc3fca3f5fb0ad585d9cc48f512fb Need to address in childprocess side. Seems to be just one test case: https://github.com/enkessler/childprocess/blob/44227922488765ebad0c0bed0fbec586ef9f5c26/spec/childprocess_spec.rb#L14 We could skip the test temporary. 8. rubygem-clockwork https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576583/ `:128:in `require': cannot load such file -- mocha/setup (LoadError)` This mocha issue is already fixed in https://github.com/Rykian/clockwork/pull/64/ . Looks like in addition Minitest issue needs fixing. And leaf package. I am fine breaking and have it removed afterwards, unless @Pavel Valena cares ... Vít OpenPGP_signature.asc Description: OpenPGP digital signature ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Current rubygem- packages rebuild failure against ruby 3.3
Hello, all: With wonderful work by Vít and friends, again I tried to rebuild all rubygem-foo packages on Fedora against ruby 3.3.0dev. For the below failure reports, https://github.com/ruby/ruby/commit/83ecdd1dce18246de631eb3b5d8308145bb269f5 is used. Among ~455 packages, now 16 packages see build failure. Please check what is going, thank you. Regards, Mamoru 1. rubygem-actionview https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576506/ ``` Failure: RipperTrackerTest#test_finds_dependencies_with_extra_spaces [test/template/dependency_tracker_test.rb:191]: --- expected +++ actual @@ -1 +1 @@ -["spaces/header", "spaces/form", "messages/message", "events/event", "comments/comment"] +["spaces/header", "spaces/form", "messages/message", "comments/comment"] ``` Discussed on: https://src.fedoraproject.org/rpms/rubygem-actionview/pull-request/4 2. rubygem-addressable https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576510/ Test suite segfaults constantly... 3. rubygem-aruba https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576568/ Cucumber testsuite fails. Some test failures are due to removed irb/ext/save-history, some are due to pry behaving badly? on ruby3.3 (not knowing in details), others I don't know. Already reported https://github.com/cucumber/aruba/issues/910 , no response. 4. rubygem-async_sinatra https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576572/ `test/test_async.rb:28:in `': uninitialized constant MiniTest (NameError)` Fixing this will perhaps be easy, leaving this to maintainer for now. 5. rubygem-bootsnap https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576574/ ``` 1) Failure: Bootsnap::KernelRequireTest#test_uses_the_same_duck_type_as_require [/builddir/build/BUILD/bootsnap-1.15.0/usr/share/gems/gems/bootsnap-1.15.0/test/load_path_cache/core_ext/kernel_require_test.rb:26]: Expected # to be success?. ``` I don't know what this means. With ruby 7b8d472100 (around 2023-10-06) test was successful, but with ruby 55c5ebe0a0 (around 2023-10-14) test test fails, not sure what ruby change caused this. 6. rubygem-byebug https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576577/ As discussed before, I don't expect that rubygem-byebug comes to work with ruby3.3. Probably I am going to orphan this. 7. rubygem-childprocess https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576582/ `Failure/Error: require 'rubygems/mock_gem_ui'` This file is removed: https://github.com/ruby/ruby/commit/74772840430fc3fca3f5fb0ad585d9cc48f512fb Need to address in childprocess side. 8. rubygem-clockwork https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576583/ `:128:in `require': cannot load such file -- mocha/setup (LoadError)` This mocha issue is already fixed in https://github.com/Rykian/clockwork/pull/64/ . Looks like in addition Minitest issue needs fixing. 9. rubygem-curb https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576585/ ``` Error: test_curlopt_stderr_with_file(TestCurbCurlEasy): Errno::ENOENT: No such file or directory @ rb_sysopen - /tmp/curb_test_curlopt_stderr20231028-3388-1r4xk0 /builddir/build/BUILD/curb-1.0.1/usr/share/gems/gems/curb-1.0.1/tests/tc_curl_easy.rb:30:in `read' /builddir/build/BUILD/curb-1.0.1/usr/share/gems/gems/curb-1.0.1/tests/tc_curl_easy.rb:30:in `test_curlopt_stderr_with_file' ``` Well, successful on x86_64, failing on s390x. But even on s390x this was successful with ruby 7b8d472100 (around 2023-10-06), seeing failure with ruby 55c5ebe0a0 (around 20231014). 10. rubygem-power_assert https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576589/ %check needs BR: rubygem-byebug , which doesn't build. Discussed on: https://github.com/ruby/power_assert/issues/47 , I may try to remove byebug dependency myself. 11. rubygem-puppet-lint https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576591/ ``` No matching package to install: 'rubygem(rspec-collection_matchers) >= 1.0' ``` The above package is already retired. 12. rubygem-railties https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576593/ ``` Failure: ApplicationTests::AssetsTest#test_precompile_shouldn't_use_the_digests_present_in_manifest.json [test/application/assets_test.rb:299]: Expected "application-c56ef81d122dffa8b257b0546ba1b09bd2d8b97e4aef881de8db9f760b903af6.css" to not be equal to "application-c56ef81d122dffa8b257b0546ba1b09bd2d8b97e4aef881de8db9f760b903af6.css". ``` Not sure what this means. 13. rubygem-ronn-ng https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/build/6576596/ ``` Failure: test_angle_bracket_syntax_HTML(RonnTest): ---
Re: Ruby 3.3
Dne 26. 10. 23 v 18:26 Pavel Valena napsal(a): On Wed, Oct 25, 2023 at 4:31 PM Vít Ondruch 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. 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-le...@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue OpenPGP_signature.asc Description: OpenPGP digital signature ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
On Wed, Oct 25, 2023 at 4:31 PM Vít Ondruch 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 > > ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
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 OpenPGP_signature.asc Description: OpenPGP digital signature ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
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 ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
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 OpenPGP_signature.asc Description: OpenPGP digital signature ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
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/555691277a4134a9779084c3d2bba5da89332534
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/682a0ee3599884734f7ad6c45955173586cb331f
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
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
Re: Ruby 3.3
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.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
-
For the beginning, I have reported this here:
https://github.com/rubygems/rubygems/issues/7083
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/68e54df6f95dfca1c634dc383e32a311c3f6d138?branch=private-ruby-2.3
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-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
Re: Ruby 3.3
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.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
-
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
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby 3.3
BTW, the question also is, what is the influence of PR5327 on our settings:
https://src.fedoraproject.org/rpms/ruby/blob/5bf57b1504871230600103083d77ff3502255e2e/f/operating_system.rb#_103
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.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
-
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/c514f5f13c709dc289754663ba31491617d83811
Please note that this commit
Re: Ruby 3.3
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.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
-
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/c514f5f13c709dc289754663ba31491617d83811
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:
