----- Original Message -----
From: "Vít Ondruch" <vondruch(a)redhat.com>
Sent: Thursday, December 17, 2020 9:23:55 AM
Subject: Re: Ruby 3.0
Dne 17. 12. 20 v 3:16 Pavel Valena napsal(a):
> ----- Original Message -----
>> From: "Jaroslav Prokop" <jar.prokop(a)volny.cz>
>> To: ruby-sig(a)lists.fedoraproject.org
>> Sent: Wednesday, December 16, 2020 7:05:03 PM
>> Subject: Re: Ruby 3.0
>> WEBrick is default in some applications, IIRC - e.g Sinatra  or
>> Jekyll - as it was a server in standard lib that came with Ruby.
>> I am not sure 100% there, as it could just be rack default to search for
>> WEBrick, either way, it'll be better to watch out for
> I think there's no need for anything else than simple declaration of
> dependency in Gemfile / gemspec. Which should be there in first place.
> Webrick is simply stand-alone gem now, right?
Well my point is that previously, when WEBRick was part of Ruby, it was
natural to used it. When it is not part of Ruby, upstreams will have to
deal with it and in case of updating Gemfile / gemspec, why not use
different server, such as Puma? This should be probably super easy for
Rack based projects. There will certainly be different projects, which
might be using WEBRick directly. But also in this case, upstreams might
decide to use different web server when they have to provide some fixes
anyway. But I guess the only way to know what fails due to removed
WEBRick is to update the Copr and rebuild everything.
Right, I'm on that.
also, you're right upstreams can switch, but that's not up to us right? We should
be prepared though...
I personally use it with from commandline: `$ ruby -run -e httpd ...` (I think it uses
Apart from that I'm good without (FDP can switch easily, Bughunting has alerady
>> Quickly scrolling through the code of Sinatra and Jekyll it seems like
>> WEBrick is used in tests as well, so it's a question if it will be just
>> a matter of
>> adding require (maybe Suggests?) to gemspec or if BuildRequires will
>> need appending too.
> Yes, there'll be more of fixing like that for Ruby, and gems upstreams
> (f.e. `rexml` require). If you want to jump in on the train, here're some
> failed pre-builds:
> Please create a PR to both gem upstream and Fedora package if you're able
> to fix some issue.
>> To answer your question, adjustments to packages might be needed and
>> packaging WEBrick might be worth it, but better inspection is needed
>> from maintainers of packages that package said software.
>> On 16/12/2020 18:39, Vít Ondruch wrote:
>>> Another snapshot is available in private-ruby-3.0 branch and the build
>>> is running here:
> FYI it's not synced with PR#70.
If this still applies to the Copr context, could you please update your
Copr and test how does it look with eventmachine? It seems the
problematic patch was reverted upstream:
I've rebuilt it from SRPM. But I forgot to bump release, so I'll add the patch and
rebuild once more :).
> I'll run COPR build in my COPR as well.
>>> Most notable change is removal of WEBRick from Ruby. I am not
>>> completely sure how much disruption this could cause in Fedora. I
>>> wonder if it is worth of packaging it as a separate package. Thoughts?
>>> P.S. @jaruga + @pvalena thx for handling the GCC11 issues.