Puma 6.x

[Vít Ondruch]

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 🤷)

While the former is low impact, I lean towards the latter, despite 
changing the generated application might put some users into risk. Thoughts?

Vít

[1]: https://copr.fedorainfracloud.org/coprs/vondruch/mpb/build/6885290/

[2]: 
https://github.com/rails/rails/blob/fc734f28e65ef8829a1a939ee6702c1f349a1d5a...

[3]: 
https://github.com/rails/rails/commit/545a9908e8f661aa391b5c8e418a5204b1eba7...

[4]: https://github.com/rails/rails/pull/46106

[Vít Ondruch]

Dne 11. 01. 24 v 16:37 Vít Ondruch napsal(a):
> 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:
>
> Relax the dependency in rubygem-should-matchers.
>
> 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 🤷)

This is the PR:

https://src.fedoraproject.org/rpms/rubygem-railties/pull-request/3

Vít
> While the former is low impact, I lean towards the latter, despite 
> changing the generated application might put some users into risk. 
> Thoughts?
>
> Vít

[Pavel Valena]

On Thu, Jan 11, 2024 at 4:38 PM Vít Ondruch  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:
>
> Relax the dependency in rubygem-should-matchers.
>
> 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....

They've mentioned it (probably) breaks capybara:
https://github.com/puma/puma/blob/master/6.0-Upgrade.md#upgrade

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/

Thanks for all the work!

Regards,
Pavel
> Vít
>
> [2]:
>
> https://github.com/rails/rails/blob/fc734f28e65ef8829a1a939ee6702c1f349a1d5a...
>
> [3]:
>
> https://github.com/rails/rails/commit/545a9908e8f661aa391b5c8e418a5204b1eba7...

[Vít Ondruch]

Dne 11. 01. 24 v 23:10 Pavel Valena napsal(a):
> On Thu, Jan 11, 2024 at 4:38 PM Vít Ondruch  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.
> 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 😉

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/fc734f28e65ef8829a1a939ee6702c1f349a1d5a/railties/lib/rails/generators/app_base.rb#L172
>
> [3]:
> https://github.com/rails/rails/commit/545a9908e8f661aa391b5c8e418a5204b1eba7f7
>
> [4]: https://github.com/rails/rails/pull/46106
>
>
> --
> _______________________________________________
> ruby-sig mailing list [e-mail]
> To unsubscribe send an email [e-mail]
> 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/[e-mail].o...
> Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue

[Pavel Valena]

On Fri, Jan 12, 2024 at 10:29 AM Vít Ondruch  wrote:
> Dne 11. 01. 24 v 23:10 Pavel Valena napsal(a):
>
> On Thu, Jan 11, 2024 at 4:38 PM Vít Ondruch  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:
> >
> > Relax the dependency in rubygem-should-matchers.
> >
> > 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)

```

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
> >
> > [2]:
> >
> > https://github.com/rails/rails/blob/fc734f28e65ef8829a1a939ee6702c1f349a1d5a...
> >
> > [3]:
> >
> > https://github.com/rails/rails/commit/545a9908e8f661aa391b5c8e418a5204b1eba7...

[Pavel Valena]

On Mon, Jan 15, 2024 at 10:57 AM Pavel Valena  wrote:
> On Fri, Jan 12, 2024 at 10:29 AM Vít Ondruch  wrote:
> > Dne 11. 01. 24 v 23:10 Pavel Valena napsal(a):
> >
> > On Thu, Jan 11, 2024 at 4:38 PM Vít Ondruch  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:
> > >
> > > Relax the dependency in rubygem-should-matchers.
> > >
> > > 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...

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
> > >
> > > [2]:
> > >
> > > https://github.com/rails/rails/blob/fc734f28e65ef8829a1a939ee6702c1f349a1d5a...
> > >
> > > [3]:
> > >
> > > https://github.com/rails/rails/commit/545a9908e8f661aa391b5c8e418a5204b1eba7...

[Vít Ondruch]

Dne 15. 01. 24 v 11:02 Pavel Valena napsal(a):
> On Mon, Jan 15, 2024 at 10:57 AM Pavel Valena  wrote:
> On Fri, Jan 12, 2024 at 10:29 AM Vít Ondruch <[e-mail]>
> wrote:
>
>
>     Dne 11. 01. 24 v 23:10 Pavel Valena napsal(a):
> >     On Thu, Jan 11, 2024 at 4:38 PM Vít Ondruch
> >     <[e-mail]> 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/fc734f28e65ef8829a1a939ee6702c1f349a1d5a/railties/lib/rails/generators/app_base.rb#L172
> >
> >         [3]:
> >         https://github.com/rails/rails/commit/545a9908e8f661aa391b5c8e418a5204b1eba7f7
> >
> >         [4]: https://github.com/rails/rails/pull/46106
>
> --
> _______________________________________________
> ruby-sig mailing list [e-mail]
> To unsubscribe send an email [e-mail]
> 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/[e-mail].o...
> Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue