Dne 17. 06. 25 v 19:01 Vít Ondruch napsal(a):
Dne 16. 06. 25 v 10:57 Vít Ondruch napsal(a):Dne 09. 06. 25 v 18:17 Vít Ondruch napsal(a):Dne 09. 06. 25 v 16:29 Vít Ondruch napsal(a):Hi,I am slowly working toward update of Ruby on Rails to version 8. The updated packages are available here for testing:https://copr.fedorainfracloud.org/coprs/vondruch/ror8/packages/and I hope that all of them have opened PR with a changes. Also, I have put together change proposal:https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_8.0Feel free to provide feedback and I'd be more then happy if anybody else join the effort. Right now, I try to rebuild all the packages and check what the updated Rails are going to break. Started the MPB rebuild here:https://copr.fedorainfracloud.org/coprs/vondruch/ror8-mpb/packages/Trying to rebuild dependencies, so far struggling with Rack 3.x, which is required by RoR8. E.g.:https://bugzilla.redhat.com/show_bug.cgi?id=2371181 https://bugzilla.redhat.com/show_bug.cgi?id=2371179but there is more. Fixing rubygem-puma right now, which is similar issue to YARD due to `rackup` command being split into separate package.If somebody had some spare time, I'd appreciate help with rubygem-ethon: https://github.com/typhoeus/ethon/issues/243I am kind of out of ideas, where the `body` content is lost. To me, it seems unlikely to be lost on "sender" side (how the data are fed into CURL is a bit tricky), but as far as I can see, it is lost already somewhere in WEBRick on the "server" side.Ok, have made some progress. It seems this might be issue somewhere between Sinatra and Rackup WEBrick handler. More details are here:https://github.com/sinatra/sinatra/issues/2112It seems that Sinatra has tried to drop WEBrick support as well as Rack tried to deprecate WEBrick, so who knows what is the best solution:https://github.com/sinatra/sinatra/commit/3f6c57780b4f77c1439004a949ea2b3d807423ffhttps://github.com/rack/rackup/pull/23 But in any case, it seems more to be test error then anything else.
Thinking about this further, I think this is test issue on Ethon side and it is reasonably safe to disable the failing tests for now. However, another option is also to get rid of Ethon entirely, because
1) it is not clear if it is properly maintained: https://github.com/typhoeus/ethon/issues/241 https://github.com/typhoeus/ethon/graphs/contributors 2) The only real dependency IMHO is pcs: ~~~ $ ~/scripts/whatrequires ethon Updating and loading repositories: Repositories loaded. pcs-0:0.12.0-1.fc42.noarch pcs-0:0.12.0-1.fc42.src rubygem-ethon-doc-0:0.15.0-9.fc42.noarch rubygem-typhoeus-0:1.4.0-13.fc42.noarch rubygem-typhoeus-0:1.4.0-13.fc42.src ~~~ Because Typhoeus is typically just build dependency ~~~ $ ~/scripts/whatrequires typhoeus Updating and loading repositories: Repositories loaded. rubygem-faraday-0:1.0.1-16.fc42.src rubygem-jekyll-feed-0:0.17.0-7.fc42.src rubygem-typhoeus-doc-0:1.4.0-13.fc42.noarch rubygem-webmock-0:3.23.1-3.fc42.src ~~~The test in e.g. jekyll-feed fails anyway. Webmock uses Typhoeus as one of many adapters. Similarly to Faraday. I think that the Typhoeus was extracted in to separate library for Faraday 2. And maybe we should even get rid of Faraday, which is used only by vagrant-digitalocean and that might be just for historic reasons.
But let me also check Typhoeus first, which currently fails in my testing. It seems because the `Rackup` split.
Vít
VítVítVítBut I am not really sure how well this proceed. 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
