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&tagID=80411&order=-build_id&latest=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&tagID=80411&order=-build_id&latest=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&tagID=80411&order=-build_id&latest=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&tagID=80411&order=-build_id&latest=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&tagID=80411&order=-build_id&latest=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&tagID=80411&order=-build_id&latest=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&tagID=80411&order=-build_id&latest=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&tagID=80411&order=-build_id&latest=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&tagID=80411&order=-build_id&latest=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
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
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", &method(: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: 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: 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 longe
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. A
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: 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: 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", &method(:require)' /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/resolver.rb:116:in `rescue in solve_versions': Could not find compatible versions (Bundler::SolveFailure) Because every version of actionmailer depends on net-imap >= 0 and every version of net-imap depends on net-protocol >= 0, every version of actionmailer requires net-protocol >= 0. So, because net-protocol >= 0 could not be found in locally installed gems and Gemfile depends on actionmailer >= 0, version solving has failed. from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/resolver.rb:79:in `solve_versions' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/resolver.rb:32:in `start' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:595:in `start_resolution' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:311:in `resolve' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:548:in `materialize' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:203:in `specs' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:270:in `specs_for' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/runtime.rb:18:in `setup' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler.rb:164:in `setup' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/setup.rb:23:in `block in ' 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/rubyg
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", &method(:require)' /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/resolver.rb:116:in `rescue in solve_versions': Could not find compatible versions (Bundler::SolveFailure) Because every version of actionmailer depends on net-imap >= 0 and every version of net-imap depends on net-protocol >= 0, every version of actionmailer requires net-protocol >= 0. So, because net-protocol >= 0 could not be found in locally installed gems and Gemfile depends on actionmailer >= 0, version solving has failed. from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/resolver.rb:79:in `solve_versions' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/resolver.rb:32:in `start' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:595:in `start_resolution' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:311:in `resolve' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:548:in `materialize' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:203:in `specs' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:270:in `specs_for' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/runtime.rb:18:in `setup' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler.rb:164:in `setup' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/setup.rb:23:in `block in ' 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
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", &method(:require)' /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/resolver.rb:116:in `rescue in solve_versions': Could not find compatible versions (Bundler::SolveFailure) Because every version of actionmailer depends on net-imap >= 0 and every version of net-imap depends on net-protocol >= 0, every version of actionmailer requires net-protocol >= 0. So, because net-protocol >= 0 could not be found in locally installed gems and Gemfile depends on actionmailer >= 0, version solving has failed. from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/resolver.rb:79:in `solve_versions' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/resolver.rb:32:in `start' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:595:in `start_resolution' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:311:in `resolve' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:548:in `materialize' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:203:in `specs' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:270:in `specs_for' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/runtime.rb:18:in `setup' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler.rb:164:in `setup' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/setup.rb:23:in `block in ' 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 Gemfi
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", &method(:require)' /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/resolver.rb:116:in `rescue in solve_versions': Could not find compatible versions (Bundler::SolveFailure) Because every version of actionmailer depends on net-imap >= 0 and every version of net-imap depends on net-protocol >= 0, every version of actionmailer requires net-protocol >= 0. So, because net-protocol >= 0 could not be found in locally installed gems and Gemfile depends on actionmailer >= 0, version solving has failed. from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/resolver.rb:79:in `solve_versions' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/resolver.rb:32:in `start' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:595:in `start_resolution' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:311:in `resolve' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:548:in `materialize' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:203:in `specs' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/definition.rb:270:in `specs_for' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/runtime.rb:18:in `setup' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler.rb:164:in `setup' from /usr/share/gems/gems/bundler-2.5.0.dev/lib/bundler/setup.rb:23:in `block in ' 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 su
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 to ruby-sig-le...@lists.fedoraproject.org
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", &method(: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", &method(: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/rub
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: 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 be that great (I prefer option 1 fo
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: 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: 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: 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 though..
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&diff=693729&oldid=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 provid
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
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: 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: https://fedoraproject.org/wiki/Mailing_list_gu
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: https://fedoraproject.org/wik
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 a
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:
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/
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.
https://github.com/rubygems/rubygems/issues/7082
Testing with e.g. rubygem-json, this would be the workaround I guess:
~~~
$ sed -i '/^Defaulting to user installation/d' json-2.6.3.gemspec
~~~
Vít
[B]
Also, even if I workaround this, %gem_install , i.e.
$ gem install -V --local --build-root . --force --document=ri,rdoc
%{gem_name}-%{version}.gem
now installs files under $HOME/.local:
-
+ gem install -V --local --build-root . --force --document=ri,rdoc
Ascii85-1.1.0.gem
Defaulting to user installation because default GEM_HOME
(/usr/share/gems) is not writable.
WARNING: You build with buildroot.
Build root: /builddir/build/BUILD/Ascii85-1.1.0
Bin dir:
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/bin
Gem home:
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby
Plugins dir:
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/plugins
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/.travis.yml
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Ascii85.gemspec
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Gemfile
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/History.txt
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/LICENSE
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/README.md
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Rakefile
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/bin/ascii85
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/lib/Ascii85/version.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/lib/ascii85.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/spec/lib/ascii85_spec.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/bin/ascii85
-
So for now, I essentially reverted the above PR5327 changes on my
local ruby.src (based on
your ruby.src) and it looks working as before, so again I am going to
do trial rebuild for
all rubygem- packages.
(Well, when I saw these lots of git changelog related to rubygems part
on ruby.git,
I had a bad feeling about this.)
Regards,
Mamoru
https://src.fedoraproject.org/rpms/ruby/pull-request/159
And the scratch build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=107409961
From upstream POV, there is nothing particularly interesting, except
of the rename of the new Ruby source code parser from YART to prism
and on strange JIT test failure.
From changes in the .spec file, I have migrated every custom
reference of gem path to the %gem_ macros. This was enabled by this
commit:
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/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:
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/3MHROKOM53HM6NF7RGGLFBIQFG5IEIQG/
and in practice, this will look like:
~~~
$ git diff
diff --git a/ruby.spec b/ruby.spec
index 1aea20b..51f30
Re: Ruby 3.3
And this is now used in Ruby. Please see the changes in the PR:
https://src.fedoraproject.org/rpms/ruby/pull-request/159
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/6d8ecfca02947b5f1ce48cc51943e5f127d93be2
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/865f5b3a896ed1b423add7ffe0601707155828ef
And the associated build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=107710823
Yes, this is the latest snapshot. So please give it a proper test. And
thx for all the feedback (yes, I remember I have to check the RubyGems,
but I wanted to finish the generators first).
Vít
Dne 16. 10. 23 v 16:19 Vít Ondruch napsal(a):
Dne 12. 10. 23 v 17:20 Vít Ondruch napsal(a):
Next on my table is allow usage of generators on default/bundled
gems. More details on this approach is here:
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/3MHROKOM53HM6NF7RGGLFBIQFG5IEIQG/
and in practice, this will look like:
~~~
$ git diff
diff --git a/ruby.spec b/ruby.spec
index 1aea20b..51f3065 100644
--- a/ruby.spec
+++ b/ruby.spec
@@ -196,6 +196,11 @@ Source15: test_openssl_fips.rb
%{load:%{SOURCE4}}
%{load:%{SOURCE5}}
+%global __local_generator_requires make -C
%{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby
TESTRUN_SCRIPT="--enable-gems %{SOURCE9}"
+%global __local_generator_provides make -C
%{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby
TESTRUN_SCRIPT="--enable-gems %{SOURCE10}"
+%global __local_generator_conflicts make -C
%{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby
TESTRUN_SCRIPT="--enable-gems %{SOURCE11}"
+%global __local_generator_path ^%{gem_dir}/specifications/.*\.gemspec$
+
# Fix ruby_version abuse.
# https://bugs.ruby-lang.org/issues/11002
Patch0: ruby-2.3.0-ruby_version.patch
@@ -229,6 +234,7 @@ Requires: %{name}-libs%{?_isa} =
%{version}-%{release}
Recommends: ruby(rubygems) >= %{rubygems_version}
Recommends: rubygem(bigdecimal) >= %{bigdecimal_version}
+BuildRequires: rpm-local-generator-support
# Build dependencies
BuildRequires: autoconf
BuildRequires: gcc
~~~
But to enable this, I'll soon need help with a review of:
https://copr.fedorainfracloud.org/coprs/vondruch/rpm-local-generator/package/rpm-local-generator-support/
I have submitted this package for a review. Can somebody help me
please? The package can't be simpler.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2244428
Thx in advance
BTW it shaves off ~60 lines of the ruby.spec
Vít
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. 10. 23 v 17:20 Vít Ondruch napsal(a):
Next on my table is allow usage of generators on default/bundled gems.
More details on this approach is here:
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/3MHROKOM53HM6NF7RGGLFBIQFG5IEIQG/
and in practice, this will look like:
~~~
$ git diff
diff --git a/ruby.spec b/ruby.spec
index 1aea20b..51f3065 100644
--- a/ruby.spec
+++ b/ruby.spec
@@ -196,6 +196,11 @@ Source15: test_openssl_fips.rb
%{load:%{SOURCE4}}
%{load:%{SOURCE5}}
+%global __local_generator_requires make -C
%{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby
TESTRUN_SCRIPT="--enable-gems %{SOURCE9}"
+%global __local_generator_provides make -C
%{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby
TESTRUN_SCRIPT="--enable-gems %{SOURCE10}"
+%global __local_generator_conflicts make -C
%{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby
TESTRUN_SCRIPT="--enable-gems %{SOURCE11}"
+%global __local_generator_path ^%{gem_dir}/specifications/.*\.gemspec$
+
# Fix ruby_version abuse.
# https://bugs.ruby-lang.org/issues/11002
Patch0: ruby-2.3.0-ruby_version.patch
@@ -229,6 +234,7 @@ Requires: %{name}-libs%{?_isa} =
%{version}-%{release}
Recommends: ruby(rubygems) >= %{rubygems_version}
Recommends: rubygem(bigdecimal) >= %{bigdecimal_version}
+BuildRequires: rpm-local-generator-support
# Build dependencies
BuildRequires: autoconf
BuildRequires: gcc
~~~
But to enable this, I'll soon need help with a review of:
https://copr.fedorainfracloud.org/coprs/vondruch/rpm-local-generator/package/rpm-local-generator-support/
I have submitted this package for a review. Can somebody help me please?
The package can't be simpler.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2244428
Thx in advance
BTW it shaves off ~60 lines of the ruby.spec
Vít
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
It is on my TODO list, but I am still postponing feedback, because I did
not have high hopes this will go right. Oh well.
Thx for spotting this.
Vít
In ruby.git , these are imported from
7aebe2a52bac2a925c475c511640ad13a7d20490 to
9dcaa832592af0125ba6407a506b2b3953b2f81c , I guess.
Perhaps due to the above changes:
[A] now "gem build ../foo-version.spec" as we usually do in
rubygem-foo.spec fails like:
-
+ gem build ../Ascii85-1.1.0.gemspec
Defaulting to user installation because default GEM_HOME
(/usr/share/gems) is not writable.
Invalid gemspec in [../Ascii85-1.1.0.gemspec]:
../Ascii85-1.1.0.gemspec:1: unknown regexp options - har
...se default GEM_HOME (/usr/share/gems) is not writable.
... ^~
../Ascii85-1.1.0.gemspec:1: syntax error, unexpected local variable or
method, expecting end-of-input
...t GEM_HOME (/usr/share/gems) is not writable.
... ^~
ERROR: Error loading gemspec. Aborting.
error: Bad exit status from /var/tmp/rpm-tmp.Cvl7rH (%build)
-
So this affects (breaks) almost all of Fedora rubygem- packages.
[B]
Also, even if I workaround this, %gem_install , i.e.
$ gem install -V --local --build-root . --force --document=ri,rdoc
%{gem_name}-%{version}.gem
now installs files under $HOME/.local:
-
+ gem install -V --local --build-root . --force --document=ri,rdoc
Ascii85-1.1.0.gem
Defaulting to user installation because default GEM_HOME
(/usr/share/gems) is not writable.
WARNING: You build with buildroot.
Build root: /builddir/build/BUILD/Ascii85-1.1.0
Bin dir:
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/bin
Gem home:
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby
Plugins dir:
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/plugins
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/.travis.yml
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Ascii85.gemspec
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Gemfile
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/History.txt
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/LICENSE
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/README.md
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Rakefile
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/bin/ascii85
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/lib/Ascii85/version.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/lib/ascii85.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/spec/lib/ascii85_spec.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/bin/ascii85
-
So for now, I essentially reverted the above PR5327 changes on my
local ruby.src (based on
your ruby.src) and it looks working as before, so again I am going to
do trial rebuild for
all rubygem- packages.
(Well, when I saw these lots of git changelog related to rubygems part
on ruby.git,
I had a bad feeling about this.)
Regards,
Mamoru
https://src.fedoraproject.org/rpms/ruby/pull-request/159
And the scratch build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=107409961
From upstream POV, there is nothing particularly interesting, except
of the rename of the new Ruby source code parser from YART to prism
and on strange JIT test failure.
From changes in the .spec file, I have migrated every custom
reference of gem path to the %gem_ macros. This was enabled by this
commit:
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/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:
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/3MHROKOM53HM6NF7RGGLFBIQFG5IEIQG/
and in practice, this will look like:
~~~
$ git diff
diff --git a/ruby.spec b/ruby.spec
index 1aea20b..51f3065 100644
--- a/ruby.spec
+++ b/ruby.spec
@@ -196
Re: Ruby 3.3
Vít Ondruch wrote on 2023/10/13 0:20:
Hi,
I am back again with yet another update, this time to e029375a7d. The changes
are in the PR:
Vít, would you take a look at this change?
https://github.com/rubygems/rubygems/pull/5327
In ruby.git , these are imported from 7aebe2a52bac2a925c475c511640ad13a7d20490
to
9dcaa832592af0125ba6407a506b2b3953b2f81c , I guess.
Perhaps due to the above changes:
[A] now "gem build ../foo-version.spec" as we usually do in rubygem-foo.spec
fails like:
-
+ gem build ../Ascii85-1.1.0.gemspec
Defaulting to user installation because default GEM_HOME (/usr/share/gems) is
not writable.
Invalid gemspec in [../Ascii85-1.1.0.gemspec]: ../Ascii85-1.1.0.gemspec:1:
unknown regexp options - har
...se default GEM_HOME (/usr/share/gems) is not writable.
... ^~
../Ascii85-1.1.0.gemspec:1: syntax error, unexpected local variable or method,
expecting end-of-input
...t GEM_HOME (/usr/share/gems) is not writable.
... ^~
ERROR: Error loading gemspec. Aborting.
error: Bad exit status from /var/tmp/rpm-tmp.Cvl7rH (%build)
-
So this affects (breaks) almost all of Fedora rubygem- packages.
[B]
Also, even if I workaround this, %gem_install , i.e.
$ gem install -V --local --build-root . --force --document=ri,rdoc
%{gem_name}-%{version}.gem
now installs files under $HOME/.local:
-
+ gem install -V --local --build-root . --force --document=ri,rdoc
Ascii85-1.1.0.gem
Defaulting to user installation because default GEM_HOME (/usr/share/gems) is
not writable.
WARNING: You build with buildroot.
Build root: /builddir/build/BUILD/Ascii85-1.1.0
Bin dir:
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/bin
Gem home: /builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby
Plugins dir:
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/plugins
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/.travis.yml
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Ascii85.gemspec
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Gemfile
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/History.txt
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/LICENSE
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/README.md
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/Rakefile
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/bin/ascii85
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/lib/Ascii85/version.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/lib/ascii85.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/gems/Ascii85-1.1.0/spec/lib/ascii85_spec.rb
/builddir/build/BUILD/Ascii85-1.1.0/builddir/.local/share/gem/ruby/bin/ascii85
-
So for now, I essentially reverted the above PR5327 changes on my local
ruby.src (based on
your ruby.src) and it looks working as before, so again I am going to do trial
rebuild for
all rubygem- packages.
(Well, when I saw these lots of git changelog related to rubygems part on
ruby.git,
I had a bad feeling about this.)
Regards,
Mamoru
https://src.fedoraproject.org/rpms/ruby/pull-request/159
And the scratch build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=107409961
From upstream POV, there is nothing particularly interesting, except of the
rename of the new Ruby source code parser from YART to prism and on strange JIT
test failure.
From changes in the .spec file, I have migrated every custom reference of gem
path to the %gem_ macros. This was enabled by this commit:
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/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:
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/3MHROKOM53HM6NF7RGGLFBIQFG5IEIQG/
and in practice, this will look like:
~~~
$ git diff
diff --git a/ruby.spec b/ruby.spec
index 1aea20b..51f3065 100644
--- a/ruby.spec
+++ b/ruby.spec
@@ -196,6 +196,11 @@ Source15: test_openssl_fips.rb
%{load:%{SOURCE4}}
%{load:%{SOURCE5}}
+%global __local_generator_requires make -C
%{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby
TESTRUN_SCRIPT="--enable-gems %{SOURCE9}"
+%global __local_gen
Re: Ruby 3.3
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}`.
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:
~~~
$ git diff
diff --git a/ruby.spec b/ruby.spec
index 1aea20b..51f3065 100644
--- a/ruby.spec
+++ b/ruby.spec
@@ -196,6 +196,11 @@ Source15: test_openssl_fips.rb
%{load:%{SOURCE4}}
%{load:%{SOURCE5}}
+%global __local_generator_requires make -C
%{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby
TESTRUN_SCRIPT="--enable-gems %{SOURCE9}"
+%global __local_generator_provides make -C
%{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby
TESTRUN_SCRIPT="--enable-gems %{SOURCE10}"
+%global __local_generator_conflicts make -C
%{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby
TESTRUN_SCRIPT="--enable-gems %{SOURCE11}"
+%global __local_generator_path ^%{gem_dir}/specifications/.*\.gemspec$
+
# Fix ruby_version abuse.
# https://bugs.ruby-lang.org/issues/11002
Patch0: ruby-2.3.0-ruby_version.patch
@@ -229,6 +234,7 @@ Requires: %{name}-libs%{?_isa} = %{version}-%{release}
Recommends: ruby(rubygems) >= %{rubygems_version}
Recommends: rubygem(bigdecimal) >= %{bigdecimal_version}
+BuildRequires: rpm-local-generator-support
# Build dependencies
BuildRequires: autoconf
BuildRequires: gcc
~~~
But to enable this, I'll soon need help with a review of:
https://copr.fedorainfracloud.org/coprs/vondruch/rpm-local-generator/package/rpm-local-generator-support/
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
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 with new update, this time it is rev 3c11cdbcfe. The changes are in the PR: https://src.fedoraproject.org/rpms/ruby/pull-request/159 and build (in progress ATM) is here: https://koji.fedoraproject.org/koji/taskinfo?taskID=106474426 The main reason I have prepared this update is this change: https://github.com/ruby/ruby/commit/647390308239fbf82d159ecd83ed8df090af518d Which hopefully resolves the issue we were seeing with SystemTap and enables removal of the workaround patch. If somebody has some cycles to experiment with the SystemTap test case, that would be super cool (adding Lukáš from QE on CC, if he gets interested by a chance ;) ). Vít 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/20/23 19:41, Pavel Valena wrote:
Hello,
I decided to do some more testing, and found out that gem install
doesn't work:
```
<...snip...>
$ gem install rails
:128:in
`require': libruby.so.3.2: cannot open shared object file: No such
file or directory - /usr/lib64/gems/ruby/stringio-3.0.8/stringio.so
(LoadError)
^ Not sure how, but stringio is probably the wrong binary version? Some
env pollution?
Trying locally in a rawhide Fedora container with your copr (skipping
setting up the copr...):
```
$ podman run --rm -it registry.fedoraproject.org/fedora:rawhide
# dnf install -y ruby.3.3.0~20230905git7c8932365f-182.fc40
# gem install rails
Fetching zeitwerk-2.6.11.gem
Successfully installed zeitwerk-2.6.11
Fetching thor-1.2.2.gem
Successfully installed thor-1.2.2
<...snip... It fails later due to missing build deps>
```
Regards,
Jarek
from
:128:in
`require'
<...snip...>
I didn't try with your latest version.
Regards,
Pavel
On Mon, Sep 18, 2023 at 6:24 PM Vít Ondruch wrote:
Hi,
Ruby 3.3 Preview 2 was released last week and here I am with the
updated
version. You can find the changes in my PR:
https://src.fedoraproject.org/rpms/ruby/pull-request/159
and here is the associated scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=106353657
I have not noticed anything particularly interesting in that release.
However, I have fixed and improved the macros I was talking about.
For
clarity (and probably backport), I have extracted them into
separate commit:
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/d500de24cdcb4d848ab3df29d76f711104b3683e
This commit introduces `%{gem_name_version}` macro, which by default
does `%{gem_name}-%{version}%{?prerelease}`. Or if called with custom
gem name, such as `%gem_name_version foo`, the action is
`%{1}-%{expand:%{%{1}_version}}%{?prerelease}`. This assumes that
there
is `%{foo_version}` defined for correct output.
This macro is later reused in all `%gem_` macros, which now also
accept
custom gem name.
There is also additional `-d` option for `%gem_spec` macro, which
refers
to the .gemspec of default gems.
As always, feedback is appreciated via all common channels.
Vít
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-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: cookiejar status (was: Re: Ruby 3.3)
Looks great, thanks!
I think the switch should rather occur on rubygems.org ...
https://rubygems.org/gems/cookiejar2 - the naming difference might create
some issues.
Alternatively, we could package it as rubygem-cookiejar2, and let it
provide Cookiejar.
Pavel
On Tue, Sep 19, 2023 at 1:22 PM Mamoru TASAKA
wrote:
> Hello all, again:
>
> Mamoru TASAKA wrote on 2023/09/17 22:42:
> >
> > Okay, so with my initial builds for rubygem- packages, among 456
> packages,
> > 50 packages failed to build (1 just fixed one of them, so currently 49).
> >
> >
> https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/packages/
> >
> > Some types of errors (I noticed) which is affecting several packages are:
> >
> >
> > * Regexp.new now rejects 3rd argument:
> >example:
> >wrong number of arguments (given 3, expected 1..2)
> >https://github.com/ruby/ruby/pull/7039
>
>
> rubygem-cookiejar hits this issue:
>
>
> Failure/Error: PARAM2 = Regexp.new
> "(#{PATTERN::TOKEN})(?:=(#{PATTERN::VALUE2}))?(?:\\Z|;)", '', 'n'
>
> ArgumentError:
>wrong number of arguments (given 3, expected 1..2)
>
>
> It looks like the following packages need rubygem-cookiejar when
> rebuilding,
> and when rebuilding the same error when (in cookiejar internal):
>
> * rubygem-em-http-request
> * rubygem-em-websocket
> * rubygem-faraday
> * rubygem-webmock
>
> Now rubygem-cookiejar upstream got archived:
> https://github.com/dwaite/cookiejar
>
> while there is the fork named "cookiejar2":
> https://github.com/dorianmariefr/cookiejar2
>
> It seems cookiejar upstream is very responsive, actually the PR I've
> submitted
> about the above Regexp issue was merged very quickly:
> https://github.com/dorianmariefr/cookiejar2/pull/2
>
> Now I've applied the above PR to Fedora rubygem-cookiejar, but in the
> future
> perhaps we should switch to use cookiejar2 instead of cookiejar.
>
> ( CCing pvalena )
>
> Regards,
> Mamoru
>
>
___
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
Hello, I decided to do some more testing, and found out that gem install doesn't work: ``` # Rawhide, all updated $ sudo dnf install ruby Last metadata expiration check: 0:06:58 ago on Wed 20 Sep 2023 05:31:53 PM UTC. Dependencies resolved. Package Arch Version Repository Size Installing: ruby x86_64 3.3.0~20230905git7c8932365f-182.fc40 copr:copr.fedorainfracloud.org:pvalena:ruby-testing 42 k Installing dependencies: ruby-default-gems noarch 3.3.0~20230905git7c8932365f-182.fc40 copr:copr.fedorainfracloud.org:pvalena:ruby-testing 32 k ruby-libs x86_64 3.3.0~20230905git7c8932365f-182.fc40 copr:copr.fedorainfracloud.org:pvalena:ruby-testing 3.8 M rubygem-io-console x86_64 0.6.0-182.fc40 copr:copr.fedorainfracloud.org:pvalena:ruby-testing 25 k rubygem-json x86_64 2.6.3-182.fc40 copr:copr.fedorainfracloud.org:pvalena:ruby-testing 53 k rubygem-psych x86_64 5.1.0-182.fc40 copr:copr.fedorainfracloud.org:pvalena:ruby-testing 51 k rubypick noarch 1.1.1-19.fc39 rawhide 9.9 k Installing weak dependencies: rubygem-bigdecimal x86_64 3.1.4-182.fc40 copr:copr.fedorainfracloud.org:pvalena:ruby-testing 69 k rubygem-bundler noarch 2.5.0.dev-182.fc40 copr:copr.fedorainfracloud.org:pvalena:ruby-testing 382 k rubygem-rdoc noarch 6.5.0-182.fc40 copr:copr.fedorainfracloud.org:pvalena:ruby-testing 464 k rubygems noarch 3.5.0.dev-182.fc40 copr:copr.fedorainfracloud.org:pvalena:ruby-testing 260 k Transaction Summary Install 11 Packages Total download size: 5.2 M Installed size: 18 M Is this ok [y/N]: y Downloading Packages: (1/11): ruby-3.3.0~20230905git7c8932365f-182.fc40.x86_64.rp 269 kB/s | 42 kB 00:00 (2/11): ruby-default-gems-3.3.0~20230905git7c8932365f-182.f 195 kB/s | 32 kB 00:00 (3/11): rubygem-bigdecimal-3.1.4-182.fc40.x86_64.rpm1.2 MB/s | 69 kB 00:00 (4/11): rubygem-bundler-2.5.0.dev-182.fc40.noarch.rpm 2.9 MB/s | 382 kB 00:00 (5/11): rubygem-io-console-0.6.0-182.fc40.x86_64.rpm296 kB/s | 25 kB 00:00 (6/11): ruby-libs-3.3.0~20230905git7c8932365f-182.fc40.x86_ 12 MB/s | 3.8 MB 00:00 (7/11): rubygem-json-2.6.3-182.fc40.x86_64.rpm 1.3 MB/s | 53 kB 00:00 (8/11): rubygem-psych-5.1.0-182.fc40.x86_64.rpm 1.2 MB/s | 51 kB 00:00 (9/11): rubygem-rdoc-6.5.0-182.fc40.noarch.rpm 6.6 MB/s | 464 kB 00:00 (10/11): rubygems-3.5.0.dev-182.fc40.noarch.rpm 3.3 MB/s | 260 kB 00:00 (11/11): rubypick-1.1.1-19.fc39.noarch.rpm 85 kB/s | 9.9 kB 00:00 Total 8.9 MB/s | 5.2 MB 00:00 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing: 1/1 Installing : ruby-libs-3.3.0~20230905git7c8932365f-182.fc40.x86_64 1/11 Installing : rubygem-bigdecimal-3.1.4-182.fc40.x86_64 2/11 Installing : ruby-default-gems-3.3.0~20230905git7c8932365f-182.fc40.noarch 3/11 Installing : rubygem-bundler-2.5.0.dev-182.fc40.noarch 4/11 Installing : rubygem-io-console-0.6.0-182.fc40.x86_64 5/11 Installing : rubygem-json-2.6.3-182.fc40.x86_64 6/11 Installing : rubygem-psych-5.1.0-182.fc40.x86_64 7/11 Installing : rubygem-rdoc-6.5.0-182.fc40.noarch 8/11 Installing : rubygems-3.5.0.dev-182.fc40.noarch 9/11 Installing : rubypick-1.1.1-19.fc39.noarch 10/11 Installing : ruby-3.3.0~20230905git7c8932365f-182.fc40.x86_64 11/11 Running scriptlet: ruby-3.3.0~20230905git7c8932365f-182.fc40.x86_64 11/11 Verifying: ruby-3.3.0~20230905git7c8932365f-182.fc40.x86_64 1/11 Verifying: ruby-default-gems-3.3.0~20230905git7c8932365f-182.fc40.noarch 2/11 Verifying: ruby-libs-3.3.0~20230905git7c8932365f-182.fc40.x86_64 3/11 Verifying: rubygem-bigdecimal-3.1.4-182.fc40.x86_64 4/11 Verifying: rubygem-bundler-2.5.0.dev-182.fc40.noarch 5/11 Verifying: rubygem-io-console-0.6.0-182.fc40.x86_64 6/11 Verifying: rubygem-json-2.6.3-182.fc40.x86_64 7/11 Verifying: rubygem-psych-5.1.0-182.fc40.x86_64 8/11 Verifying: rubygem-rdoc-6.5.0-182.fc40.noarch 9/11 Verifying: rubygems-3.5.0.dev-182.fc40.noarch
cookiejar status (was: Re: Ruby 3.3)
Hello all, again:
Mamoru TASAKA wrote on 2023/09/17 22:42:
Okay, so with my initial builds for rubygem- packages, among 456 packages,
50 packages failed to build (1 just fixed one of them, so currently 49).
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/packages/
Some types of errors (I noticed) which is affecting several packages are:
* Regexp.new now rejects 3rd argument:
example:
wrong number of arguments (given 3, expected 1..2)
https://github.com/ruby/ruby/pull/7039
rubygem-cookiejar hits this issue:
Failure/Error: PARAM2 = Regexp.new
"(#{PATTERN::TOKEN})(?:=(#{PATTERN::VALUE2}))?(?:\\Z|;)", '', 'n'
ArgumentError:
wrong number of arguments (given 3, expected 1..2)
It looks like the following packages need rubygem-cookiejar when rebuilding,
and when rebuilding the same error when (in cookiejar internal):
* rubygem-em-http-request
* rubygem-em-websocket
* rubygem-faraday
* rubygem-webmock
Now rubygem-cookiejar upstream got archived:
https://github.com/dwaite/cookiejar
while there is the fork named "cookiejar2":
https://github.com/dorianmariefr/cookiejar2
It seems cookiejar upstream is very responsive, actually the PR I've submitted
about the above Regexp issue was merged very quickly:
https://github.com/dorianmariefr/cookiejar2/pull/2
Now I've applied the above PR to Fedora rubygem-cookiejar, but in the future
perhaps we should switch to use cookiejar2 instead of cookiejar.
( CCing pvalena )
Regards,
Mamoru
___
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,
Ruby 3.3 Preview 2 was released last week and here I am with the updated
version. You can find the changes in my PR:
https://src.fedoraproject.org/rpms/ruby/pull-request/159
and here is the associated scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=106353657
I have not noticed anything particularly interesting in that release.
However, I have fixed and improved the macros I was talking about. For
clarity (and probably backport), I have extracted them into separate commit:
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/d500de24cdcb4d848ab3df29d76f711104b3683e
This commit introduces `%{gem_name_version}` macro, which by default
does `%{gem_name}-%{version}%{?prerelease}`. Or if called with custom
gem name, such as `%gem_name_version foo`, the action is
`%{1}-%{expand:%{%{1}_version}}%{?prerelease}`. This assumes that there
is `%{foo_version}` defined for correct output.
This macro is later reused in all `%gem_` macros, which now also accept
custom gem name.
There is also additional `-d` option for `%gem_spec` macro, which refers
to the .gemspec of default gems.
As always, feedback is appreciated via all common channels.
Vít
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
Follow up: Mamoru TASAKA wrote on 2023/09/18 20:16: Hello, again: Vít Ondruch wrote on 2023/09/18 17:24: Dne 17. 09. 23 v 15:42 Mamoru TASAKA napsal(a): Some topics: * rubygem-nifti sees test failure on s390x, this is perhaps big endian issue. Interesting. nifti failed during mass rebuild, but later it was update by its maintainer. So it would probably deserve bug report and maybe some `ExcludeArch`? Okay, I will check rubygem-nifti commit on Fedora dist-git (and perhaps I will probably file bugzilla ticket for rubygem-nifti). Reported: https://bugzilla.redhat.com/show_bug.cgi?id=2239481 (Well, rubygem-nifti is actually noarch, but I often wonder if we should always try to build packages for all arches even if the srpm itself is noarch: sometimes I see endian issue like this, for example.) * rubygem-byebug fails to build (on test suite), however it seems this needs the undestanding of ruby internal change, and seems very difficult for me Is there any future in byebug? Wasn't it obsoleted/replaced by the `debug` gem which is shipped with Ruby? Thank you for info. Well, it seems that actually my usage of byebug gem can be enough satisfied with debug gem. So now I incline to orphan byebug rather than spending time to fix byebug test failure... but what I've found is that power_assert testsuite depends on byebug: https://github.com/ruby/power_assert/blob/297fa68908c45c4ca6c41e0940ebcc069744d580/power_assert.gemspec#L26 Before I orphan byebug, first I will try to contact with power_assert upstream. (As Vít already noticed) reported: https://github.com/ruby/power_assert/issues/47 Mamoru ___ 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
Hello, again: Vít Ondruch wrote on 2023/09/18 17:24: Dne 17. 09. 23 v 15:42 Mamoru TASAKA napsal(a): Okay, so with my initial builds for rubygem- packages, among 456 packages, 50 packages failed to build (1 just fixed one of them, so currently 49). https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/packages/ Some types of errors (I noticed) which is affecting several packages are: * minitest 5.19 side change: MiniTest class support deprecated: example: test/test_async.rb:28:in `': uninitialized constant MiniTest (NameError) https://github.com/minitest/minitest/commit/a2c6c18570f6f0a1bf6af70fe3b6d9599a13fdd6 While I am aware of this issue in rubygem-async_sinatra, I have let this package deliberately unfixed, because I don't think it is maintained. So either their maintainer will fix it or it will be later automatically removed from Fedora. I don't really intend to prolong life of such packages. * ruby logger change. example: NoMethodError: undefined method `[]' for nil https://github.com/ruby/logger/pull/85 -> affects like https://github.com/resque/resque/issues/1856 * Regexp.new now rejects 3rd argument: example: wrong number of arguments (given 3, expected 1..2) https://github.com/ruby/ruby/pull/7039 * mocha being updated from 1.15.0 to 2.1 - perhaps some adjustment is needed example: `require': cannot load such file -- mocha/setup (LoadError) Assuming this is about rubygem-rack-cors, this is similar case to the rubygem-async_sinatra. I have submitted fix upstream: https://github.com/cyu/rack-cors/pull/266 and put @valtri on CC. So he should be aware. * Some packages expect that there are no warnings, but now with ruby3.3 when trying to load default gems which are going to be gemified, warnings are generated like: $ ruby -e "require 'csv'" -e:1: warning: csv which will be not part of the default gems since Ruby 3.4.0 I think that this was reported here: https://bugs.ruby-lang.org/issues/19885 Thank you for info. This is actually what I want to track. https://github.com/ruby/ruby/pull/8126 , and the above warnings cause some tests fail. So this may mean that we have to package those default gems into separated rubygem-XXX srpm , at least before ruby 3.4 lands. * And, currently some tests segfault. * (Just note that there are some other reasons which cause test failure: I have not investigated them yet.) Some topics: * rubygem-nifti sees test failure on s390x, this is perhaps big endian issue. Interesting. nifti failed during mass rebuild, but later it was update by its maintainer. So it would probably deserve bug report and maybe some `ExcludeArch`? Okay, I will check rubygem-nifti commit on Fedora dist-git (and perhaps I will probably file bugzilla ticket for rubygem-nifti). (Well, rubygem-nifti is actually noarch, but I often wonder if we should always try to build packages for all arches even if the srpm itself is noarch: sometimes I see endian issue like this, for example.) * rubygem-byebug fails to build (on test suite), however it seems this needs the undestanding of ruby internal change, and seems very difficult for me Is there any future in byebug? Wasn't it obsoleted/replaced by the `debug` gem which is shipped with Ruby? Thank you for info. Well, it seems that actually my usage of byebug gem can be enough satisfied with debug gem. So now I incline to orphan byebug rather than spending time to fix byebug test failure... but what I've found is that power_assert testsuite depends on byebug: https://github.com/ruby/power_assert/blob/297fa68908c45c4ca6c41e0940ebcc069744d580/power_assert.gemspec#L26 Before I orphan byebug, first I will try to contact with power_assert upstream. I may post some detailed results (if I have time), however as I wrote above the results can be shown on: https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/packages/ Thank you for the initial tests. I'll look into your findings later in more detail. These were just quick notes mostly just from my memory :) Vít Mamoru ___ 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 17. 09. 23 v 15:42 Mamoru TASAKA napsal(a):
Mamoru TASAKA wrote on 2023/09/14 21:13:
Hello, Vít:
Thank you for initial work for ruby 3.3 .
Vít Ondruch wrote on 2023/09/12 17:08:
* `%gem_spec` macro with options:
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/blob/77c580dfa85f921d969a8da68eaf6e88987aab8a/f/macros.rubygems#_10
This is my initial version, just to enable to use this macro in
ruby.spec. I think I'll similarly modify all the related macros.
While they'll be more complex, their use in ruby.spec will outweigh
that. And I should add some documentation ...
BTW there are several possibilities in choosing how complex/flexible
this macro will be and I think this is one of the changes which
could be backported to Ruby 3.2. So feedback is appreciated. Looking
at the macro, this bit
`%{?1:%{expand:%{%{1}_version}}}%{!?1:%{version}}` is probably not
very good idea for possible use in rubygem-*.gemspec.
I think this should be :
%gem_spec(d)
%{gem_dir}/specifications%{?-d:/default}/%{?1}%{!?1:%{gem_name}}-%{?1:%{expand:%{%{1}_version}}}%{!?1:%{version}}%{?prerelease}.gemspec
(instead of %gem_spec(d)
%{gem_dir}/specifications%{?-d:/default}/%{1}. )
Otherwise, for example trying to build rubygem-json fails like:
---
Processing files: rubygem-json-2.6.3-204.fc40.x86_64
error: File not found:
/builddir/build/BUILDROOT/rubygem-json-2.6.3-204.fc40.101.x86_64/usr/share/gems/specifications/%{1}json-2.6.3.gemspec
File not found:
/builddir/build/BUILDROOT/rubygem-json-2.6.3-204.fc40.101.x86_64/usr/share/gems/specifications/%{1}json-2.6.3.gemspec
---
Now I am trying to rebuild gem related pkgs depending on libruby.3.2
(with using %{?1} for %gem_spec macro)
Okay, so with my initial builds for rubygem- packages, among 456
packages,
50 packages failed to build (1 just fixed one of them, so currently 49).
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/packages/
Some types of errors (I noticed) which is affecting several packages are:
* minitest 5.19 side change: MiniTest class support deprecated:
example:
test/test_async.rb:28:in `': uninitialized constant MiniTest
(NameError)
https://github.com/minitest/minitest/commit/a2c6c18570f6f0a1bf6af70fe3b6d9599a13fdd6
While I am aware of this issue in rubygem-async_sinatra, I have let this
package deliberately unfixed, because I don't think it is maintained. So
either their maintainer will fix it or it will be later automatically
removed from Fedora. I don't really intend to prolong life of such packages.
* ruby logger change.
example:
NoMethodError: undefined method `[]' for nil
https://github.com/ruby/logger/pull/85
-> affects like https://github.com/resque/resque/issues/1856
* Regexp.new now rejects 3rd argument:
example:
wrong number of arguments (given 3, expected 1..2)
https://github.com/ruby/ruby/pull/7039
* mocha being updated from 1.15.0 to 2.1 - perhaps some adjustment is
needed
example:
`require': cannot load such file -- mocha/setup (LoadError)
Assuming this is about rubygem-rack-cors, this is similar case to the
rubygem-async_sinatra. I have submitted fix upstream:
https://github.com/cyu/rack-cors/pull/266
and put @valtri on CC. So he should be aware.
* Some packages expect that there are no warnings, but now with ruby3.3
when trying to load default gems which are going to be gemified,
warnings are generated like:
$ ruby -e "require 'csv'"
-e:1: warning: csv which will be not part of the default gems since
Ruby 3.4.0
I think that this was reported here:
https://bugs.ruby-lang.org/issues/19885
https://github.com/ruby/ruby/pull/8126 , and the above warnings cause
some tests fail.
So this may mean that we have to package those default gems into
separated
rubygem-XXX srpm , at least before ruby 3.4 lands.
* And, currently some tests segfault.
* (Just note that there are some other reasons which cause test failure:
I have not investigated them yet.)
Some topics:
* rubygem-nifti sees test failure on s390x, this is perhaps big endian
issue.
Interesting. nifti failed during mass rebuild, but later it was update
by its maintainer. So it would probably deserve bug report and maybe
some `ExcludeArch`?
* rubygem-byebug fails to build (on test suite), however it seems this
needs
the undestanding of ruby internal change, and seems very difficult
for me
Is there any future in byebug? Wasn't it obsoleted/replaced by the
`debug` gem which is shipped with Ruby?
I may post some detailed results (if I have time), however as I wrote
above
the results can be shown on:
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/packages/
Thank you for the initial tests. I'll look into your findings later in
more detail. These were just quick notes mostly just from my memory :)
Vít
Re: Ruby 3.3
Mamoru TASAKA wrote on 2023/09/14 21:13:
Hello, Vít:
Thank you for initial work for ruby 3.3 .
Vít Ondruch wrote on 2023/09/12 17:08:
* `%gem_spec` macro with options:
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/blob/77c580dfa85f921d969a8da68eaf6e88987aab8a/f/macros.rubygems#_10
This is my initial version, just to enable to use this macro in ruby.spec. I
think I'll similarly modify all the related macros. While they'll be more
complex, their use in ruby.spec will outweigh that. And I should add some
documentation ...
BTW there are several possibilities in choosing how complex/flexible this macro
will be and I think this is one of the changes which could be backported to
Ruby 3.2. So feedback is appreciated. Looking at the macro, this bit
`%{?1:%{expand:%{%{1}_version}}}%{!?1:%{version}}` is probably not very good
idea for possible use in rubygem-*.gemspec.
I think this should be :
%gem_spec(d)
%{gem_dir}/specifications%{?-d:/default}/%{?1}%{!?1:%{gem_name}}-%{?1:%{expand:%{%{1}_version}}}%{!?1:%{version}}%{?prerelease}.gemspec
(instead of %gem_spec(d) %{gem_dir}/specifications%{?-d:/default}/%{1}. )
Otherwise, for example trying to build rubygem-json fails like:
---
Processing files: rubygem-json-2.6.3-204.fc40.x86_64
error: File not found:
/builddir/build/BUILDROOT/rubygem-json-2.6.3-204.fc40.101.x86_64/usr/share/gems/specifications/%{1}json-2.6.3.gemspec
File not found:
/builddir/build/BUILDROOT/rubygem-json-2.6.3-204.fc40.101.x86_64/usr/share/gems/specifications/%{1}json-2.6.3.gemspec
---
Now I am trying to rebuild gem related pkgs depending on libruby.3.2 (with
using %{?1} for %gem_spec macro)
Okay, so with my initial builds for rubygem- packages, among 456 packages,
50 packages failed to build (1 just fixed one of them, so currently 49).
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/packages/
Some types of errors (I noticed) which is affecting several packages are:
* minitest 5.19 side change: MiniTest class support deprecated:
example:
test/test_async.rb:28:in `': uninitialized constant MiniTest (NameError)
https://github.com/minitest/minitest/commit/a2c6c18570f6f0a1bf6af70fe3b6d9599a13fdd6
* ruby logger change.
example:
NoMethodError: undefined method `[]' for nil
https://github.com/ruby/logger/pull/85
-> affects like https://github.com/resque/resque/issues/1856
* Regexp.new now rejects 3rd argument:
example:
wrong number of arguments (given 3, expected 1..2)
https://github.com/ruby/ruby/pull/7039
* mocha being updated from 1.15.0 to 2.1 - perhaps some adjustment is needed
example:
`require': cannot load such file -- mocha/setup (LoadError)
* Some packages expect that there are no warnings, but now with ruby3.3
when trying to load default gems which are going to be gemified,
warnings are generated like:
$ ruby -e "require 'csv'"
-e:1: warning: csv which will be not part of the default gems since Ruby 3.4.0
https://github.com/ruby/ruby/pull/8126 , and the above warnings cause
some tests fail.
So this may mean that we have to package those default gems into separated
rubygem-XXX srpm , at least before ruby 3.4 lands.
* And, currently some tests segfault.
* (Just note that there are some other reasons which cause test failure:
I have not investigated them yet.)
Some topics:
* rubygem-nifti sees test failure on s390x, this is perhaps big endian issue.
* rubygem-byebug fails to build (on test suite), however it seems this needs
the undestanding of ruby internal change, and seems very difficult for me
I may post some detailed results (if I have time), however as I wrote above
the results can be shown on:
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/packages/
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 14. 09. 23 v 14:13 Mamoru TASAKA napsal(a):
Hello, Vít:
Thank you for initial work for ruby 3.3 .
Vít Ondruch wrote on 2023/09/12 17:08:
* `%gem_spec` macro with options:
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/blob/77c580dfa85f921d969a8da68eaf6e88987aab8a/f/macros.rubygems#_10
This is my initial version, just to enable to use this macro in
ruby.spec. I think I'll similarly modify all the related macros.
While they'll be more complex, their use in ruby.spec will outweigh
that. And I should add some documentation ...
BTW there are several possibilities in choosing how complex/flexible
this macro will be and I think this is one of the changes which could
be backported to Ruby 3.2. So feedback is appreciated. Looking at the
macro, this bit `%{?1:%{expand:%{%{1}_version}}}%{!?1:%{version}}` is
probably not very good idea for possible use in rubygem-*.gemspec.
I think this should be :
%gem_spec(d)
%{gem_dir}/specifications%{?-d:/default}/%{?1}%{!?1:%{gem_name}}-%{?1:%{expand:%{%{1}_version}}}%{!?1:%{version}}%{?prerelease}.gemspec
(instead of %gem_spec(d)
%{gem_dir}/specifications%{?-d:/default}/%{1}. )
Otherwise, for example trying to build rubygem-json fails like:
---
Processing files: rubygem-json-2.6.3-204.fc40.x86_64
error: File not found:
/builddir/build/BUILDROOT/rubygem-json-2.6.3-204.fc40.101.x86_64/usr/share/gems/specifications/%{1}json-2.6.3.gemspec
File not found:
/builddir/build/BUILDROOT/rubygem-json-2.6.3-204.fc40.101.x86_64/usr/share/gems/specifications/%{1}json-2.6.3.gemspec
---
Oh, right, sorry. I knew it is incomplete, but I have not realized this
is immediately going to break other packages 🙈
My initial change included two options. There was also option to specify
the version. I have later thought it is overcomplicated to have two
options, if I could defer the macro name, but I have missed the original
use case. And we were fine without this possibilities up to now.
Still, would there be some value in the option enabling to specify
version? Should it be named or positional? The `%{prerelease}` does not
make this question any easier.
Vít
Now I am trying to rebuild gem related pkgs depending on libruby.3.2
(with using %{?1} for %gem_spec macro)
Regards,
Mamoru
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-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
Hello, Vít:
Thank you for initial work for ruby 3.3 .
Vít Ondruch wrote on 2023/09/12 17:08:
* `%gem_spec` macro with options:
https://src.fedoraproject.org/fork/vondruch/rpms/ruby/blob/77c580dfa85f921d969a8da68eaf6e88987aab8a/f/macros.rubygems#_10
This is my initial version, just to enable to use this macro in ruby.spec. I
think I'll similarly modify all the related macros. While they'll be more
complex, their use in ruby.spec will outweigh that. And I should add some
documentation ...
BTW there are several possibilities in choosing how complex/flexible this macro
will be and I think this is one of the changes which could be backported to
Ruby 3.2. So feedback is appreciated. Looking at the macro, this bit
`%{?1:%{expand:%{%{1}_version}}}%{!?1:%{version}}` is probably not very good
idea for possible use in rubygem-*.gemspec.
I think this should be :
%gem_spec(d)
%{gem_dir}/specifications%{?-d:/default}/%{?1}%{!?1:%{gem_name}}-%{?1:%{expand:%{%{1}_version}}}%{!?1:%{version}}%{?prerelease}.gemspec
(instead of %gem_spec(d) %{gem_dir}/specifications%{?-d:/default}/%{1}. )
Otherwise, for example trying to build rubygem-json fails like:
---
Processing files: rubygem-json-2.6.3-204.fc40.x86_64
error: File not found:
/builddir/build/BUILDROOT/rubygem-json-2.6.3-204.fc40.101.x86_64/usr/share/gems/specifications/%{1}json-2.6.3.gemspec
File not found:
/builddir/build/BUILDROOT/rubygem-json-2.6.3-204.fc40.101.x86_64/usr/share/gems/specifications/%{1}json-2.6.3.gemspec
---
Now I am trying to rebuild gem related pkgs depending on libruby.3.2 (with
using %{?1} for %gem_spec macro)
Regards,
Mamoru
___
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
Well, this is kind of expected and the `--best --allowerasing` (actually
the `--best` could be enough) is probably the right solution in this
situation. Let me explain.
If we build Ruby 3.3 as an official build for Fedora, the first step
after building Ruby would be to take the independent rubygem-json, bump
it and build against Ruby 3.3. That would resolve the issue. However,
this is just test build, so I don't do that. But it would be probably
the right thing to do for your Copr repo. That would be helpful for two
reasons:
1) Given the above, it is important to ensure that the rubygem-json
rebuild is possible and that there is e.g. no circular dependency which
would prohibit this.
2) It would allow to test the upgrade scenario as you did.
Vít
Dne 13. 09. 23 v 18:38 Pavel Valena napsal(a):
Testing upgrade, I get:
```
# dnf update ruby
Last metadata expiration check: 3:45:31 ago on Wed 13 Sep 2023
12:42:06 PM UTC.
Dependencies resolved.
Problem: problem with installed package
rubygem-json-2.6.3-204.fc39.x86_64
- package rubygem-json-2.6.3-204.fc39.x86_64 from @System requires
libruby.so.3.2()(64bit), but none of the providers can be installed
- package rubygem-json-2.6.3-204.fc39.x86_64 from rawhide requires
libruby.so.3.2()(64bit), but none of the providers can be installed
- cannot install both
ruby-libs-3.3.0~20230905git7c8932365f-182.fc40.x86_64 from
copr:copr.fedorainfracloud.org:pvalena:ruby-testing and
ruby-libs-3.2.2-181.fc39.x86_64 from @System
- cannot install both ruby-libs-3.2.2-181.fc39.x86_64 from rawhide
and ruby-libs-3.3.0~20230905git7c8932365f-182.fc40.x86_64 from
copr:copr.fedorainfracloud.org:pvalena:ruby-testing
- package ruby-3.3.0~20230905git7c8932365f-182.fc40.x86_64 from
copr:copr.fedorainfracloud.org:pvalena:ruby-testing requires
libruby.so.3.3()(64bit), but none of the providers can be installed
- package ruby-3.3.0~20230905git7c8932365f-182.fc40.x86_64 from
copr:copr.fedorainfracloud.org:pvalena:ruby-testing requires
ruby-libs(x86-64) = 3.3.0~20230905git7c8932365f-182.fc40, but none of
the providers can be installed
- cannot install the best update candidate for package
ruby-3.2.2-181.fc39.x86_64
=
Package Arch Version Repository
Size
=
Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
ruby-libs x86_64 3.3.0~20230905git7c8932365f-182.fc40
copr:copr.fedorainfracloud.org:pvalena:ruby-testing 3.8 M
Skipping packages with broken dependencies:
ruby x86_64 3.3.0~20230905git7c8932365f-182.fc40
copr:copr.fedorainfracloud.org:pvalena:ruby-testing 42 k
Transaction Summary
=
Skip 2 Packages
Nothing to do.
Complete!
```
While using suggested options ('--allowerasing --best') installs ruby
3.3, json gem is downgraded and then next update says:
```
# dnf update 'ruby*'
Last metadata expiration check: 3:49:05 ago on Wed 13 Sep 2023
12:42:06 PM UTC.
Dependencies resolved.
Problem: package rubygem-json-2.6.3-204.fc39.x86_64 from rawhide
requires libruby.so.3.2()(64bit), but none of the providers can be
installed
- cannot install both ruby-libs-3.2.2-181.fc39.x86_64 from rawhide
and ruby-libs-3.3.0~20230905git7c8932365f-182.fc40.x86_64 from @System
- cannot install the best update candidate for package
rubygem-json-2.6.3-182.fc40.x86_64
- cannot install the best update candidate for package
ruby-libs-3.3.0~20230905git7c8932365f-182.fc40.x86_64
=
Package Arch Version Repository
Size
=
Upgrading:
rubygem-bundler noarch 2.5.0.dev-182.fc40
copr:copr.fedorainfracloud.org:pvalena:ruby-testing 382 k
rubygem-rdoc noarch 6.5.0-182.fc40
copr:copr.fedorainfracloud.org:pvalena:ruby-testing 464 k
Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
ruby-libs x86_64 3.2.2-181.fc39 rawhide
4.0 M
Skipping packages with broken dependencies:
rubygem-json x86_64 2.6.3-204.fc39 rawhide
69 k
Transaction Summary
=
Upgrade 2 Packages
Skip 2 Packages
```
Note the bundler and rdoc gems were not updated with the ruby update
(I hope they would still work ok).
Standalone install works fine & the test suite even passes (or f
Re: Ruby 3.3
Testing upgrade, I get:
```
# dnf update ruby
Last metadata expiration check: 3:45:31 ago on Wed 13 Sep 2023 12:42:06 PM
UTC.
Dependencies resolved.
Problem: problem with installed package rubygem-json-2.6.3-204.fc39.x86_64
- package rubygem-json-2.6.3-204.fc39.x86_64 from @System requires
libruby.so.3.2()(64bit), but none of the providers can be installed
- package rubygem-json-2.6.3-204.fc39.x86_64 from rawhide requires
libruby.so.3.2()(64bit), but none of the providers can be installed
- cannot install both
ruby-libs-3.3.0~20230905git7c8932365f-182.fc40.x86_64 from
copr:copr.fedorainfracloud.org:pvalena:ruby-testing and
ruby-libs-3.2.2-181.fc39.x86_64 from @System
- cannot install both ruby-libs-3.2.2-181.fc39.x86_64 from rawhide and
ruby-libs-3.3.0~20230905git7c8932365f-182.fc40.x86_64 from
copr:copr.fedorainfracloud.org:pvalena:ruby-testing
- package ruby-3.3.0~20230905git7c8932365f-182.fc40.x86_64 from
copr:copr.fedorainfracloud.org:pvalena:ruby-testing requires
libruby.so.3.3()(64bit), but none of the providers can be installed
- package ruby-3.3.0~20230905git7c8932365f-182.fc40.x86_64 from
copr:copr.fedorainfracloud.org:pvalena:ruby-testing requires
ruby-libs(x86-64) = 3.3.0~20230905git7c8932365f-182.fc40, but none of the
providers can be installed
- cannot install the best update candidate for package
ruby-3.2.2-181.fc39.x86_64
=
Package Arch Version Repository
Size
=
Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
ruby-libs x86_64 3.3.0~20230905git7c8932365f-182.fc40
copr:copr.fedorainfracloud.org:pvalena:ruby-testing
3.8 M
Skipping packages with broken dependencies:
ruby x86_64 3.3.0~20230905git7c8932365f-182.fc40
copr:copr.fedorainfracloud.org:pvalena:ruby-testing
42 k
Transaction Summary
=
Skip 2 Packages
Nothing to do.
Complete!
```
While using suggested options ('--allowerasing --best') installs ruby 3.3,
json gem is downgraded and then next update says:
```
# dnf update 'ruby*'
Last metadata expiration check: 3:49:05 ago on Wed 13 Sep 2023 12:42:06 PM
UTC.
Dependencies resolved.
Problem: package rubygem-json-2.6.3-204.fc39.x86_64 from rawhide requires
libruby.so.3.2()(64bit), but none of the providers can be installed
- cannot install both ruby-libs-3.2.2-181.fc39.x86_64 from rawhide and
ruby-libs-3.3.0~20230905git7c8932365f-182.fc40.x86_64 from @System
- cannot install the best update candidate for package
rubygem-json-2.6.3-182.fc40.x86_64
- cannot install the best update candidate for package
ruby-libs-3.3.0~20230905git7c8932365f-182.fc40.x86_64
=
Package Arch VersionRepository
Size
=
Upgrading:
rubygem-bundler noarch 2.5.0.dev-182.fc40
copr:copr.fedorainfracloud.org:pvalena:ruby-testing
382 k
rubygem-rdocnoarch 6.5.0-182.fc40
copr:copr.fedorainfracloud.org:pvalena:ruby-testing
464 k
Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
ruby-libs x86_64 3.2.2-181.fc39 rawhide
4.0 M
Skipping packages with broken dependencies:
rubygem-jsonx86_64 2.6.3-204.fc39 rawhide
69 k
Transaction Summary
=
Upgrade 2 Packages
Skip 2 Packages
```
Note the bundler and rdoc gems were not updated with the ruby update (I
hope they would still work ok).
Standalone install works fine & the test suite even passes (or fails or
errors the same as with Ruby 3.2).
Regards,
Pavel
On Tue, Sep 12, 2023 at 5:53 PM Pavel Valena wrote:
> Hello,
>
> I've checked the PR as well - all checks out :)
>
> I'll build it in my COPR ruby-testing repo... will keep you posted.
>
> On Tue, Sep 12, 2023 at 10:17 AM Vít Ondruch wrote:
>
>>
>> Dne 12. 09. 23 v 10:08 Vít Ondruch napsal(a):
>> >
>> > * Racc is now bundled gem instead of default gem. That means it will
>> > live in ruby-bundled-gems. I don't think this should have impact on
>> > anything.
>>
>>
>> Actually, this might be problem:
>>
>> https://github.com/ruby/rdoc/pull/1019
>>
>> I have not verified the changes, but it seems that has the capability in
>> embedding itself into code generated by it. There are several issues I
>> can see:
>>
>> 1) The RDoc will essentially bundle Racc, therefore it should have
>> bundled provide.
>>
>
> I see.
>
>
>>
>> 2) The generated code wil
Re: Ruby 3.3
Hello, I've checked the PR as well - all checks out :) I'll build it in my COPR ruby-testing repo... will keep you posted. On Tue, Sep 12, 2023 at 10:17 AM Vít Ondruch wrote: > > Dne 12. 09. 23 v 10:08 Vít Ondruch napsal(a): > > > > * Racc is now bundled gem instead of default gem. That means it will > > live in ruby-bundled-gems. I don't think this should have impact on > > anything. > > > Actually, this might be problem: > > https://github.com/ruby/rdoc/pull/1019 > > I have not verified the changes, but it seems that has the capability in > embedding itself into code generated by it. There are several issues I > can see: > > 1) The RDoc will essentially bundle Racc, therefore it should have > bundled provide. > I see. > > 2) The generated code will be bigger. > > 3) If there is some problem with Racc, we will need to regenerate the > libraries (OTOH, not sure what was backward compatibility of Racc with > the generated code ...) > Oh no... > > > Vít > > Otherwise it sounds great! Thanks for the work! Pavel ___ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email 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. 09. 23 v 10:08 Vít Ondruch napsal(a): * Racc is now bundled gem instead of default gem. That means it will live in ruby-bundled-gems. I don't think this should have impact on anything. Actually, this might be problem: https://github.com/ruby/rdoc/pull/1019 I have not verified the changes, but it seems that has the capability in embedding itself into code generated by it. There are several issues I can see: 1) The RDoc will essentially bundle Racc, therefore it should have bundled provide. 2) The generated code will be bigger. 3) If there is some problem with Racc, we will need to regenerate the libraries (OTOH, not sure what was backward compatibility of Racc with the generated code ...) Vít 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
