Dne 15. 01. 24 v 11:02 Pavel Valena napsal(a):
On Mon, Jan 15, 2024 at 10:57 AM Pavel Valena <pvalena(a)redhat.com> wrote:
On Fri, Jan 12, 2024 at 10:29 AM Vít Ondruch <vondruch(a)redhat.com>
wrote:
Dne 11. 01. 24 v 23:10 Pavel Valena napsal(a):
> On Thu, Jan 11, 2024 at 4:38 PM Vít Ondruch
> <vondruch(a)redhat.com> wrote:
>
> Working on Puma 6.0, I have hit this [1] issue rebuilding
> rubygem-shoulda-matchers:
>
> ~~~
>
> 1) shoulda-matchers integrates with Rails in a project
> that uses Spring
> Failure/Error: run_rake_tasks!('db:drop',
> 'db:create', 'db:migrate')
>
> RuntimeError:
> Command
>
"BUNDLE_GEMFILE=\"/tmp/shoulda-matchers-acceptance/test-project/Gemfile\"
>
> bundle _2.5.3_ exec rake db:drop db:create db:migrate
> --trace" exited
> with status 1.
> Output:
>
---START----------------------------------------------------------------
> bundler: failed to load command: rake (/usr/bin/rake)
> /usr/share/gems/gems/bundler-2.5.3/lib/bundler/resolver.rb:332:in
>
> `raise_not_found!': Could not find gem 'puma (~> 5.0)'
in
> locally
> installed gems. (Bundler::GemNotFound)
>
> The source contains the following gems matching
> 'puma':
> * puma-6.4.2
> from
> /usr/share/gems/gems/bundler-2.5.3/lib/bundler/resolver.rb:392:in
> `block
> in prepare_dependencies'
> from
> /usr/share/gems/gems/bundler-2.5.3/lib/bundler/resolver.rb:377:in
> `each'
>
>
> ... snip ...
>
> ~~~
>
>
> The thing is that RoR 7.0 hardcodes `"puma", "~>
5.0"`
> dependency. Now
> there are two options:
>
> 1) Relax the dependency in rubygem-should-matchers.
>
> 2) Relax the dependency in RoR in a similar way to RoR
> 7.1 [3] (and
> maybe [4], but I have not hit any issue in anycable 🤷)
>
>
> I hope to upgrade to 7.1 soon anyways. I think it's a good
> place to fix.
👍
>
>
> While the former is low impact, I lean towards the
> latter, despite
> changing the generated application might put some users
> into risk. Thoughts?
>
>
> No severe risk expected; just the test fix [4] you've found.
> I'll ideally re-run all RoR test suites which use Puma :). If
> you haven't already....
I have used MPB, which should rebuild the first level
dependencies. I think this could be enough.
Right.
>
> They've mentioned it (probably) breaks capybara:
>
https://github.com/puma/puma/blob/master/6.0-Upgrade.md#upgrade
It does break older version of capybara, but the update you
have pushed like two days ago seems to be fine.
>
> Some testing (with the rebuild above) might be worth the
> time. Do you have some PR yet, or should I use your COPR
> build[5]?
>
> [5]
>
https://copr.fedorainfracloud.org/coprs/vondruch/mpb/build/6885218/
No PR, the Copr build should be fine (as fine and stable Puma
can be 🙈). But I'd like to land this before today EOD to get
rid of this. So please hurry 😉
Sorry, I couldn't make it. I'm however failing mock build even now:
```
1) Error:
TestPumaServer#test_form_data_encoding_windows:
NoMethodError: undefined method `split' for nil
/builddir/build/BUILD/puma-6.4.2/usr/share/gems/gems/puma-6.4.2/test/test_puma_server.rb:1791:in
`test_form_data_encoding_windows'
/builddir/build/BUILD/puma-6.4.2/usr/share/gems/gems/puma-6.4.2/test/helper.rb:91:in
`block (4 levels) in run'
/usr/share/ruby/timeout.rb:186:in `block in timeout'
/usr/share/ruby/timeout.rb:193:in `timeout'
/builddir/build/BUILD/puma-6.4.2/usr/share/gems/gems/puma-6.4.2/test/helper.rb:89:in
`block (3 levels) in run'
2) Error:
TestPumaServer#test_form_data_encoding_windows_bom:
NoMethodError: undefined method `split' for nil
/builddir/build/BUILD/puma-6.4.2/usr/share/gems/gems/puma-6.4.2/test/test_puma_server.rb:1760:in
`test_form_data_encoding_windows_bom'
/builddir/build/BUILD/puma-6.4.2/usr/share/gems/gems/puma-6.4.2/test/helper.rb:91:in
`block (4 levels) in run'
/usr/share/ruby/timeout.rb:186:in `block in timeout'
/usr/share/ruby/timeout.rb:193:in `timeout'
/builddir/build/BUILD/puma-6.4.2/usr/share/gems/gems/puma-6.4.2/test/helper.rb:89:in
`block (3 levels) in run'
566 runs, 1523 assertions, 0 failures, 2 errors, 16 skips
error: Bad exit status from /var/tmp/rpm-tmp.pYc1me (%check)
```
Sorry, forgot to check/remove the part about failing build :) before
submitting. It succeeds after scrubbing the mock buildroot...
Please note that Puma test suite is unfortunately far from 100% success
rate. Upstream is cheating using minitest-retry. I was cheating
disabling the test cases which were the flakiest.
Vít
Pavel
Smoke test runs, puma runs, but it fails on SD-notify.... not sure
why; didn't happen before (same setup).
Log:
https://gist.github.com/pvalena/978a178b72c090031af6e33895fb741e
Pavel
Vít
>
> Thanks for all the work!
>
> Regards,
> Pavel
>
>
>
> Vít
>
>
>
>
>
> [1]:
>
https://copr.fedorainfracloud.org/coprs/vondruch/mpb/build/6885290/
>
> [2]:
>
https://github.com/rails/rails/blob/fc734f28e65ef8829a1a939ee6702c1f349a1...
>
> [3]:
>
https://github.com/rails/rails/commit/545a9908e8f661aa391b5c8e418a5204b1e...
>
> [4]:
https://github.com/rails/rails/pull/46106
>
--
_______________________________________________
ruby-sig mailing list --ruby-sig(a)lists.fedoraproject.org
To unsubscribe send an email toruby-sig-leave(a)lists.fedoraproject.org
Fedora Code of
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List
Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List
Archives:https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fed...
Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue