Ruby 2.7

[Vít Ondruch]

Hi everybody,

I have create PR with .spec file, which will eventually become Ruby 2.7
package in Fedora some time around beginning of next year:

https://src.fedoraproject.org/rpms/ruby/pull-request/48

and this is associated scratch build:

https://koji.fedoraproject.org/koji/taskinfo?taskID=36285060

I was considering, if I should open PR from my fork or push everything
into the main repository, but I have decided to push directly into
private-ruby-2.7 branch, so all the changes are preserved.

Now what has changed?

* Upstream move to Git, so I have updated the .spec file to use git
hashes instead of SVN releases. No upgrade path is guaranteed.

* The bundled gems now ships with RubyGems stubs, that means there
should not be conflicts between for example /usr/bin/rake shipped by
ruby and rubygem-rake. That should make it easier to install these
packages side by side (and help for example with Bundler 2.x transition).

* The bundler Racc now ships with its executable, therefore I have
decided to move it into rubygem-racc subpackage.

* I have removed support for %{rubygems_default_filter} macro. Nobody
(except rubygem-rugged) ever used this macro and it never provided any
real functionality (rhbz#1020810).

And that is it. I'll keep updating the branch as I find time.

As always, I welcome any feedback here or in the PR.

Vít

[Vít Ondruch]

Hi again,

I have updated the .spec file to the newer release. You can see all the
changes in the #48 and the recent scratch build is available here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=37455859

Please give it a test. Any feedback is welcome.

Vít

Dne 16. 07. 19 v 14:41 Vít Ondruch napsal(a):
> Hi everybody,
>
> I have create PR with .spec file, which will eventually become Ruby 2.7
> package in Fedora some time around beginning of next year:
>
> https://src.fedoraproject.org/rpms/ruby/pull-request/48
>
> and this is associated scratch build:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=36285060
>
> I was considering, if I should open PR from my fork or push everything
> into the main repository, but I have decided to push directly into
> private-ruby-2.7 branch, so all the changes are preserved.
>
> Now what has changed?
> Upstream move to Git, so I have updated the .spec file to use git
>
> hashes instead of SVN releases. No upgrade path is guaranteed.
> The bundled gems now ships with RubyGems stubs, that means there
>
> should not be conflicts between for example /usr/bin/rake shipped by
> ruby and rubygem-rake. That should make it easier to install these
> packages side by side (and help for example with Bundler 2.x transition).
> The bundler Racc now ships with its executable, therefore I have
>
> decided to move it into rubygem-racc subpackage.
> I have removed support for %{rubygems_default_filter} macro. Nobody
>
> (except rubygem-rugged) ever used this macro and it never provided any
> real functionality (rhbz#1020810).
>
> And that is it. I'll keep updating the branch as I find time.
>
> As always, I welcome any feedback here or in the PR.
>
> Vít
>
> ruby-sig mailing list -- [e-mail]
> To unsubscribe send an email to [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...

[Vít Ondruch]

Hi all,

I updated the Ruby 2.7 package again. All the changes can be found in
#48 and here is scratch build:

https://koji.fedoraproject.org/koji/taskinfo?taskID=37685741

As always, any feedback is welcome.

Vít

Dne 04. 09. 19 v 17:12 Vít Ondruch napsal(a):
> Hi again,
>
> I have updated the .spec file to the newer release. You can see all the
> changes in the #48 and the recent scratch build is available here:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=37455859
>
> Please give it a test. Any feedback is welcome.
>
> Vít
>
> Dne 16. 07. 19 v 14:41 Vít Ondruch napsal(a):
> > Hi everybody,
> >
> > I have create PR with .spec file, which will eventually become Ruby 2.7
> > package in Fedora some time around beginning of next year:
> >
> > https://src.fedoraproject.org/rpms/ruby/pull-request/48
> >
> > and this is associated scratch build:
> >
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=36285060
> >
> > I was considering, if I should open PR from my fork or push everything
> > into the main repository, but I have decided to push directly into
> > private-ruby-2.7 branch, so all the changes are preserved.
> >
> > Now what has changed?
> > Upstream move to Git, so I have updated the .spec file to use git
> >
> > hashes instead of SVN releases. No upgrade path is guaranteed.
> > The bundled gems now ships with RubyGems stubs, that means there
> >
> > should not be conflicts between for example /usr/bin/rake shipped by
> > ruby and rubygem-rake. That should make it easier to install these
> > packages side by side (and help for example with Bundler 2.x transition).
> > The bundler Racc now ships with its executable, therefore I have
> >
> > decided to move it into rubygem-racc subpackage.
> > I have removed support for %{rubygems_default_filter} macro. Nobody
> >
> > (except rubygem-rugged) ever used this macro and it never provided any
> > real functionality (rhbz#1020810).
> >
> > And that is it. I'll keep updating the branch as I find time.
> >
> > As always, I welcome any feedback here or in the PR.
> >
> > Vít
> >
> > ruby-sig mailing list -- [e-mail]
> > To unsubscribe send an email to [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...
>
> ruby-sig mailing list -- [e-mail]
> To unsubscribe send an email to [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...

[Jun Aruga]

Thanks for preparing Ruby 2.7 package.

I just share below Ruby ticket related to Ruby 2.7.
Some standard libraries will be changed to default gems or bundled
gems on Ruby 2.7.
We can watch this ticket.

Remove the unmaintained libraries from Ruby 2.7
https://bugs.ruby-lang.org/issues/16170

[Vít Ondruch]

Hi everybody,

I have update Ruby 2.7 again. The .spec is available in dist-git and the
scratch build is here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=39204662

There are nothing major, except a StdLib ongoing gemification.

As always, feedback is welcome.

Vít

[Vít Ondruch]

Hi everybody,

Yet another update of Ruby 2.7 is available in dist-git and the scratch
build is running in Koji:

https://koji.fedoraproject.org/koji/taskinfo?taskID=39474761

I don't thing there was anything major from packagin POV. Anyway, please
let me know if you encounter any issues.

Best,

Vít

[Jun Aruga]

> Yet another update of Ruby 2.7 is available in dist-git and the scratch
> build is running in Koji:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=39474761
>
> I don't thing there was anything major from packagin POV. Anyway, please
> let me know if you encounter any issues.

Hi Vit, thanks for preparing Ruby 2.7.
Now I tried a scratch build on rpms/ruby, the latest private-ruby-2.7 branch

commit: fe89ec49cc6e09f8f308b1e8dfaf38c492c06836
Upgrade to Ruby 2.7.0 (af11efd377).

but the scratch build failed because of failed patching processes.

```
$ git checkout private-ruby-2.7
$ fedpkg srpm
$ fedpkg --release master scratch-build --srpm --nowait
```

The scratch build result:
https://koji.fedoraproject.org/koji/taskinfo?taskID=39522612

```
Patch #0 (ruby-2.3.0-ruby_version.patch):
+ echo 'Patch #0 (ruby-2.3.0-ruby_version.patch):'
+ /usr/bin/patch --no-backup-if-mismatch -p1 --fuzz=0
patching file configure.ac
Hunk #1 succeeded at 3691 (offset 1 line).
Hunk #2 succeeded at 3713 (offset 1 line).
Hunk #3 succeeded at 3785 (offset 1 line).
...

Patch #6 (ruby-2.1.0-Allow-to-specify-additional-preludes-by-configuratio.patch):
+ echo 'Patch #6
(ruby-2.1.0-Allow-to-specify-additional-preludes-by-configuratio.patch):'
+ /usr/bin/patch --no-backup-if-mismatch -p1 --fuzz=0
patching file common.mk
Hunk #1 FAILED at 163.
1 out of 1 hunk FAILED -- saving rejects to file common.mk.rej
patching file configure.ac
Hunk #1 succeeded at 3885 (offset 1 line).
patching file template/Makefile.in
error: Bad exit status from /var/tmp/rpm-tmp.nTmxK5 (%prep)
```

I created Source0: `ruby-2.7.0-af11efd377.tar.xz` file like this.

```
$ cd ~/git/ruby/ruby

$ git checkout af11efd377

$ git clean -fdx

$ git status
HEAD detached at af11efd377
nothing to commit, working tree clean

$ tool/make-snapshot -packages=xz -srcdir="$(pwd)" ~/tmp/ruby-snapshot

$ ls -l ~/tmp/ruby-snapshot/ruby-2.7.0-af11efd377.tar.xz
-rw-r--r-- 1 jaruga jaruga 11941052 Dec 13 15:35
/home/jaruga/tmp/ruby-snapshot/ruby-2.7.0-af11efd377.tar.xz

$ sha256sum ~/tmp/ruby-snapshot/ruby-2.7.0-af11efd377.tar.xz
bc5b0435e19c8b3f0f2d0300a7ed9b128ee553525b70e2bbe42ae16b42ed3b61
/home/jaruga/tmp/ruby-snapshot/ruby-2.7.0-af11efd377.tar.xz
```

Did you upload your updated *.patch files to the remote repository?

[Jun Aruga]

> Did you upload your updated *.patch files to the remote repository?

Sorry maybe my mistake. My `ruby-2.7.0-af11efd377.tar.xz` file created
by `tool/make-snapshot -packages=xz -srcdir="$(pwd)"
~/tmp/ruby-snapshot` was actually newer than the upstream af11efd377 .

Here is the `version.h` in my `ruby-2.7.0-af11efd377.tar.xz` file.
"#define RUBY_RELEASE_DAY 11" is newer than your archive and the
upstream af11efd377.

```
$ head version.h
# define RUBY_VERSION_MAJOR RUBY_API_VERSION_MAJOR
# define RUBY_VERSION_MINOR RUBY_API_VERSION_MINOR
#define RUBY_VERSION_TEENY 0
#define RUBY_RELEASE_DATE
RUBY_RELEASE_YEAR_STR"-"RUBY_RELEASE_MONTH_STR"-"RUBY_RELEASE_DAY_STR
#define RUBY_PATCHLEVEL -1

#define RUBY_RELEASE_YEAR 2019
#define RUBY_RELEASE_MONTH 12
#define RUBY_RELEASE_DAY 11
```

[Jun Aruga]

The mock build and some arch's scratch builds with your
ruby-2.7.0-af11efd377.tar.xz succeeded.

x86_64, aarch64 scratch builds failed.
I think it randomly happens, and just in case I share it here.

https://koji.fedoraproject.org/koji/taskinfo?taskID=39525059

x86_64

```
1)
Net::HTTP#request when passed request_object and request_body sends
the passed request_body when making the HTTP Request ERROR
EOFError: end of file reached
/builddir/build/BUILD/ruby-2.7.0-af11efd377/lib/net/protocol.rb:225:in
`rbuf_fill'
/builddir/build/BUILD/ruby-2.7.0-af11efd377/lib/net/protocol.rb:191:in
`readuntil'
/builddir/build/BUILD/ruby-2.7.0-af11efd377/lib/net/protocol.rb:201:in
`readline'
/builddir/build/BUILD/ruby-2.7.0-af11efd377/lib/net/http/response.rb:42:in
`read_status_line'
/builddir/build/BUILD/ruby-2.7.0-af11efd377/lib/net/http/response.rb:31:in
`read_new'
/builddir/build/BUILD/ruby-2.7.0-af11efd377/lib/net/http.rb:1528:in
`block in transport_request'
/builddir/build/BUILD/ruby-2.7.0-af11efd377/lib/net/http.rb:1519:in `catch'
/builddir/build/BUILD/ruby-2.7.0-af11efd377/lib/net/http.rb:1519:in
`transport_request'
/builddir/build/BUILD/ruby-2.7.0-af11efd377/lib/net/http.rb:1492:in `request'
/builddir/build/BUILD/ruby-2.7.0-af11efd377/spec/ruby/library/net/http/http/request_spec.rb:65:in
`block (3 levels) in <top (required)>'
/builddir/build/BUILD/ruby-2.7.0-af11efd377/spec/ruby/library/net/http/http/request_spec.rb:5:in
`<top (required)>'
Finished in 58.675157 seconds
3745 files, 30406 examples, 150000 expectations, 0 failures, 1 error, 1 tagged
```

aarch64

```
  1) Failure:
TestThreadQueue#test_thr_kill
[/builddir/build/BUILD/ruby-2.7.0-af11efd377/test/ruby/test_thread_queue.rb:153]:
only 107/250 done in 60 seconds.
  2) Error:
TestThread#test_signal_at_join:
Timeout::Error: execution of assert_separately expired timeout (120 sec)
pid 972556 killed by SIGABRT (signal 6) (core dumped)
|
    /builddir/build/BUILD/ruby-2.7.0-af11efd377/test/ruby/test_thread.rb:1341:in
`test_signal_at_join'
Finished tests in 1373.821450s, 15.2371 tests/s, 1979.2587 assertions/s.
```

[Vít Ondruch]

You can download the SRPM from Koji to save you some troubles:

https://koji.fedoraproject.org/koji/taskinfo?taskID=39474762

Vít

Dne 13. 12. 19 v 16:28 Jun Aruga napsal(a):
> > Did you upload your updated *.patch files to the remote repository?
>
> Sorry maybe my mistake. My `ruby-2.7.0-af11efd377.tar.xz` file created
> by `tool/make-snapshot -packages=xz -srcdir="$(pwd)"
> ~/tmp/ruby-snapshot` was actually newer than the upstream af11efd377 .
>
> Here is the `version.h` in my `ruby-2.7.0-af11efd377.tar.xz` file.
> "#define RUBY_RELEASE_DAY 11" is newer than your archive and the
> upstream af11efd377.
> $ head version.h
> # define RUBY_VERSION_MAJOR RUBY_API_VERSION_MAJOR
> # define RUBY_VERSION_MINOR RUBY_API_VERSION_MINOR
> #define RUBY_VERSION_TEENY 0
> #define RUBY_RELEASE_DATE
> RUBY_RELEASE_YEAR_STR"-"RUBY_RELEASE_MONTH_STR"-"RUBY_RELEASE_DAY_STR
> #define RUBY_PATCHLEVEL -1
>
> #define RUBY_RELEASE_YEAR 2019
> #define RUBY_RELEASE_MONTH 12
> #define RUBY_RELEASE_DAY 11

[Jun Aruga]

This is for your information about a note for Ruby 2.7.

The keyword argument's behavior is changed on Ruby 2.7.

Here is the detail.

Ruby 2.7 and keyword arguments
https://www.ruby-lang.org/en/news/2019/12/12/separation-of-positional-and-ke...

And how to detail with it.

Support Ruby 3 keyword arguments
https://github.com/sinatra/mustermann/pull/97

And as you may know, Ruby 2.7.0 was released.
https://www.ruby-lang.org/en/news/2019/12/25/ruby-2-7-0-released/

Cheers,
Jun

[Vít Ondruch]

Hi again,

So here I am again with updated .spec file [1] and related scratch build
[2]. Here are few remarks, because as it usually happens, the biggest
breakages are introduced shortly prior release.

1) The biggest hurdle is an integration of ABRT handler. For long time,
we were using patches, which extended "prelude" facilities and that in
turn allowed to load the ABRT hook. This was changed. Upstream now
changed the preludes to builtins. Problem of builtins is that they
cannot be patched without other Ruby available [3]. That was one of the
reasons behind my bootstrapping thread [4]. For now, I did small patch
which tries to load the ABRT hook on similar place as it used to be.

2) The rubygem-abrt is broken with Ruby 2.7. It seems that there happens
more exception handling during call of `require`. I'll fix it later.

3) Ruby now always require did_you_mean gem. This is rather unfortunate
and I complained upstream [5, 6] without any resolution. At some point,
I thought it would be worth of revert, but again, without bootstrapping
[4], I cannot simple revert this change :/ We can live with that,
however, there might be necessary to add `BR: rubygem-did_you_mean` into
some packages (e.g. VIM).

Please give it try and provide some feedback. I still have to consider
the PR comments (mainly the missing `bundled()` provides), if they are
important enough to block the rebuild.

I'll be back soon with the details about mass rebuild. Please stay tuned.

Vít

[1] https://src.fedoraproject.org/rpms/ruby/pull-request/48

[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=40230957

[3] https://bugs.ruby-lang.org/issues/15306

[4]
https://lists.fedoraproject.org/archives/list/[e-mail].o...

[5] https://bugs.ruby-lang.org/issues/16427

[6] https://bugs.ruby-lang.org/issues/16431

[Jun Aruga]

Hi Ruby SIG people,

For the releasing of Ruby 2.7 to Fedora, seeing following note in Ruby
developers community.
Ruby 2.7.1 can have a better user experience especially for the
migration from older Rubies to Ruby 2.7.
https://bugs.ruby-lang.org/issues/16454#note-12

Perhaps, this time, may we be able to wait for the new release Ruby
2.7.1 to release Ruby 2.7 on Fedora?
How do you think?

The question original comes from
https://src.fedoraproject.org/rpms/ruby/pull-request/48#comment-35755 .

[Pavel Valena]

----- Original Message -----
> From: "Jun Aruga" 
> To: "Ruby SIG mailing list" 
> Sent: Wednesday, January 8, 2020 5:50:09 PM
> Subject: Re: Ruby 2.7
>
> Hi Ruby SIG people,
>
> For the releasing of Ruby 2.7 to Fedora, seeing following note in Ruby
> developers community.
> Ruby 2.7.1 can have a better user experience especially for the
> migration from older Rubies to Ruby 2.7.
> https://bugs.ruby-lang.org/issues/16454#note-12
>
> Perhaps, this time, may we be able to wait for the new release Ruby
> 2.7.1 to release Ruby 2.7 on Fedora?
> How do you think?

Hello,

Please correct me if I'm wrong but the enhancements are adding functionality (feature?) to be used when you need to handle the flag for `ruby2_keywords` explicitly (https://bugs.ruby-lang.org/issues/16486). So either way the current code (packaged gems) needs to be fixed to work with 2.7 (and yes, we'll probably get better debugging, but gems' upstream is the place to fix those issues; not Fedora). I expect 2.7.1 to hit Rawhide before branching (it'll be soon, right?), so there should be no difference having a 2.7.0 build (esp. in a side-tag) now.

So building Ruby 2.7.0 for Rawhide is fine with me. We can upgrade to 2.7.1 when Released, or backport the needed 'Features' manualy. The upstream gems releases will come in the meantime (with the fixes for 2.7), but we can file upstream bugs/PRs to address them, when we face them in Fedora.

Regards,
Pavel
> The question original comes from
> https://src.fedoraproject.org/rpms/ruby/pull-request/48#comment-35755 .
>
> --
> Jun | He - His - Him

[Jun Aruga]

> > Perhaps, this time, may we be able to wait for the new release Ruby
> > 2.7.1 to release Ruby 2.7 on Fedora?
> > How do you think?
>
> Hello,
>
> Please correct me if I'm wrong but the enhancements are adding functionality (feature?) to be used when you need to handle the flag for `ruby2_keywords` explicitly (https://bugs.ruby-lang.org/issues/16486).

In my understanding. the referred note says there is a problem about
the way for Ruby to make users to implement ruby2_keywords to suppress
the mixed positional and keyword argument's warnings on Ruby 2.7.0.

It's not a new enhancement, but a deprecation for a case that is a
method with the mixed positional and keyword argument and the
delegation.
Because in Ruby 3.0, they want to be a syntax error for this pattern.

For example, try to run following code on both Ruby 2.7.0 and Ruby 2.6

## Case A

```
def target(*args, **kwargs)
  [args, kwargs]
end

def delegate(*args, &block)
  target(*args, &block)
end

delegate(1, b: 2)
```

On Ruby 2.6, the delegate method works.

```
delegate(1, b: 2) => [[1], {:b=>2}]
```

On Ruby 2.7.0, it shows deprecation message.

```
delegate(1, b: 2)
(irb):5: warning: Using the last argument as keyword parameters is
deprecated; maybe ** should be added to the call
(irb):1: warning: The called method `target' is defined here
=> [[1], {:b=>2}]
```

The problem is how to fix the deprecation message considering both
Ruby 2.7.0 and old Rubies.
They are recommending to use "ruby2_keywords" that is internally
implemented in Ruby 2.7.0.

## Case B

```
def target(*args, **kwargs)
  [args, kwargs]
end

ruby2_keywords def delegate(*args, &block)
  target(*args, &block)
end

delegate(1, b: 2)
```

So, this code works on Ruby 2.7.0.

```
delegate(1, b: 2) => [[1], {:b=>2}]
```

But "ruby2_keywords" is not implemented in Ruby 2.6.
Users need to install "ruby2_keywords" to run a Ruby program on older Rubies,
and need to add "require 'ruby2_keywords' to the code for the older Rubies.

Gemfile

```
gem 'ruby2_keywords'
```

The above suggestion (= note-12) says that Ruby 2.7.1 should work on
the above case A without deprecation message.
https://bugs.ruby-lang.org/issues/16454#note-12

So, I have 2 concerns for this situation.

* 1. For example we will release Ruby 2.7.0 and doing mass build.
  Then we will contribute upstream to add "ruby2_keywords" to the
candidates methods.
  But the modification might not be needed anymore again in Ruby 2.7.0.
* 2. Fedora users using Fedora Ruby might have to fix their Ruby code
for only Ruby 2.7.0.

## Case C

```
def target(*args)
  [args]
end

def delegate(*args, &block)
  target(*args, &block)
end

delegate(1, {b: 2})
```

```
delegate(1, {b: 2}) => [[1], {:b=>2}]
```

But writing this email, I got an idea. When we contribute the upstream
(such as sending pull-request) to modify Case A to Case C without
using ruby2_keywords,
it solves the above concern 1.
> So either way the current code (packaged gems) needs to be fixed to work with 2.7 (and yes, we'll probably get better debugging, but gems' upstream is the place to fix those issues; not Fedora).

We might need to patch it for only Ruby 2.7.0 on Fedora.
> I expect 2.7.1 to hit Rawhide before branching (it'll be soon, right?), so there should be no difference having a 2.7.0 build (esp. in a side-tag) now.

The Ruby 2.7.1 release date is not clear.
At least the next Ruby dev meeting is 16th January.
https://bugs.ruby-lang.org/issues/16454#note-12

--
Jun | He - His - Him

[Vít Ondruch]

Dne 10. 01. 20 v 18:24 Jun Aruga napsal(a):
> > > Perhaps, this time, may we be able to wait for the new release Ruby
> > > 2.7.1 to release Ruby 2.7 on Fedora?
> > > How do you think?
> >
> > Hello,
> >
> > Please correct me if I'm wrong but the enhancements are adding functionality (feature?) to be used when you need to handle the flag for `ruby2_keywords` explicitly (https://bugs.ruby-lang.org/issues/16486).
>
> In my understanding. the referred note says there is a problem about
> the way for Ruby to make users to implement ruby2_keywords to suppress
> the mixed positional and keyword argument's warnings on Ruby 2.7.0.
>
> It's not a new enhancement, but a deprecation for a case that is a
> method with the mixed positional and keyword argument and the
> delegation.
> Because in Ruby 3.0, they want to be a syntax error for this pattern.
>
> For example, try to run following code on both Ruby 2.7.0 and Ruby 2.6
>
> ## Case A
> def target(*args, **kwargs)
>   [args, kwargs]
> end
>
> def delegate(*args, &block)
>   target(*args, &block)
> end
>
> delegate(1, b: 2)
>
> On Ruby 2.6, the delegate method works.
> delegate(1, b: 2) => [[1], {:b=>2}]
>
> On Ruby 2.7.0, it shows deprecation message.
> delegate(1, b: 2)
> (irb):5: warning: Using the last argument as keyword parameters is
> deprecated; maybe ** should be added to the call
> (irb):1: warning: The called method `target' is defined here
> => [[1], {:b=>2}]
>
> The problem is how to fix the deprecation message considering both
> Ruby 2.7.0 and old Rubies.
> They are recommending to use "ruby2_keywords" that is internally
> implemented in Ruby 2.7.0.
>
> ## Case B
> def target(*args, **kwargs)
>   [args, kwargs]
> end
>
> ruby2_keywords def delegate(*args, &block)
>   target(*args, &block)
> end
>
> delegate(1, b: 2)
>
> So, this code works on Ruby 2.7.0.
> delegate(1, b: 2) => [[1], {:b=>2}]
>
> But "ruby2_keywords" is not implemented in Ruby 2.6.
> Users need to install "ruby2_keywords" to run a Ruby program on older Rubies,
> and need to add "require 'ruby2_keywords' to the code for the older Rubies.
>
> Gemfile
> gem 'ruby2_keywords'
>
> The above suggestion (= note-12) says that Ruby 2.7.1 should work on
> the above case A without deprecation message.
> https://bugs.ruby-lang.org/issues/16454#note-12
>
> So, I have 2 concerns for this situation.
> For example we will release Ruby 2.7.0 and doing mass build.
> Then we will contribute upstream to add "ruby2_keywords" to the
>
> candidates methods.
>   But the modification might not be needed anymore again in Ruby 2.7.0.
> Fedora users using Fedora Ruby might have to fix their Ruby code
>
> for only Ruby 2.7.0.
>
> ## Case C
> def target(*args)
>   [args]
> end
>
> def delegate(*args, &block)
>   target(*args, &block)
> end
>
> delegate(1, {b: 2})
> delegate(1, {b: 2}) => [[1], {:b=>2}]
>
> But writing this email, I got an idea. When we contribute the upstream
> (such as sending pull-request) to modify Case A to Case C without
> using ruby2_keywords,
> it solves the above concern 1.
> > So either way the current code (packaged gems) needs to be fixed to work with 2.7 (and yes, we'll probably get better debugging, but gems' upstream is the place to fix those issues; not Fedora).
>
> We might need to patch it for only Ruby 2.7.0 on Fedora.
> > I expect 2.7.1 to hit Rawhide before branching (it'll be soon, right?), so there should be no difference having a 2.7.0 build (esp. in a side-tag) now.
>
> The Ruby 2.7.1 release date is not clear.
> At least the next Ruby dev meeting is 16th January.
> https://bugs.ruby-lang.org/issues/16454#note-12

IMHO, it probably makes sense to wait for the dev meeting. If the change
is accepted, we can include the patch into Ruby 2.7.0 (of course, ti
might be accepted earlier, who knows).

OTOH, the mass rebuild should start on 22nd, which is quite early (and
it take 20 days?!?). May be we should give it a shot. See what happens
and possibly include the patch earlier.

Vít

[Vít Ondruch]

Dne 08. 01. 20 v 13:33 Vít Ondruch napsal(a):
> Hi again,
>
> So here I am again with updated .spec file [1] and related scratch build
> [2]. Here are few remarks, because as it usually happens, the biggest
> breakages are introduced shortly prior release.
> The biggest hurdle is an integration of ABRT handler. For long time,
>
> we were using patches, which extended "prelude" facilities and that in
> turn allowed to load the ABRT hook. This was changed. Upstream now
> changed the preludes to builtins. Problem of builtins is that they
> cannot be patched without other Ruby available [3]. That was one of the
> reasons behind my bootstrapping thread [4]. For now, I did small patch
> which tries to load the ABRT hook on similar place as it used to be.
> The rubygem-abrt is broken with Ruby 2.7. It seems that there happens
>
> more exception handling during call of `require`. I'll fix it later.
> Ruby now always require did_you_mean gem. This is rather unfortunate
>
> and I complained upstream [5, 6] without any resolution. At some point,
> I thought it would be worth of revert, but again, without bootstrapping
> [4], I cannot simple revert this change :/ We can live with that,
> however, there might be necessary to add `BR: rubygem-did_you_mean` into
> some packages (e.g. VIM).

I have to make this hard dependency, otherwise we would need to add it
into all packages. That is very sad :( I really have to work on the
bootstrap in near future ...

Vít
> Please give it try and provide some feedback. I still have to consider
> the PR comments (mainly the missing `bundled()` provides), if they are
> important enough to block the rebuild.
>
> I'll be back soon with the details about mass rebuild. Please stay tuned.
>
> Vít
>
> [1] https://src.fedoraproject.org/rpms/ruby/pull-request/48
>
> [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=40230957
>
> [3] https://bugs.ruby-lang.org/issues/15306
>
> [4]
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>
> [5] https://bugs.ruby-lang.org/issues/16427
>
> [6] https://bugs.ruby-lang.org/issues/16431
>
> ruby-sig mailing list -- [e-mail]
> To unsubscribe send an email to [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...