Ruby 2.8

[Vít Ondruch]

Hi everybody,

I started early this time and therefore, there is already PR with
changes for upcoming Ruby version:

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

and the build should be available (if succeeds) here:

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

So far, there are changes in bundled gems. The RSS and REXML gems are
not bundled gems, therefore I extracted them into separate subpackages,
while Net::Telnet and XMLRPC were dropped from Ruby and therefore
ruby-libs now obsoletes these two packages.

As always, any feedback is welcome.


Vít

[Vít Ondruch]

Hi all,

Another update is here. There is nothing particularly exciting except
upstream bugs which I had to constantly hunt around. Anyway, the sources
are available in the PR and the scratch build is currently running here:

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

Any feedback is welcome.


Vít


Dne 24. 02. 20 v 16:26 Vít Ondruch napsal(a):
>  Hi everybody,
>
>  I started early this time and therefore, there is already PR with
>  changes for upcoming Ruby version:
>
>  https://src.fedoraproject.org/rpms/ruby/pull-request/55
>
>  and the build should be available (if succeeds) here:
>
>  https://koji.fedoraproject.org/koji/taskinfo?taskID=41848663
>
>  So far, there are changes in bundled gems. The RSS and REXML gems are
>  not bundled gems, therefore I extracted them into separate subpackages,
>  while Net::Telnet and XMLRPC were dropped from Ruby and therefore
>  ruby-libs now obsoletes these two packages.
>
>  As always, any feedback is welcome.
>
>
>  Vít
>  _______________________________________________
>  ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org
>  To unsubscribe send an email to ruby-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/[e-mail]...

Ruby 3.0

[Vít Ondruch]

Hi all,

After quite long hiatus, I am back with preview of next Ruby, which
seems to be Ruby 3.0. Therefore I have closed the original PR and opened
new one:

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

From private-ruby-3.0 branch, which is branched from private-ruby-2.8
branch. The build triggered by simple-koji-ci should be soon(ish)
available here:

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

I have not done any real testing of anything. So this package builds,
but that is all I can say about it ;) Please, give it a try and let me
know if it worked for you or not.

From the things I have noticed, it seems that apart from the
introduction of RBS (Type signature for Ruby) bundled gem, there was not
anything really groundbreaking.


Cheers,


Vít

Ruby 3.0

[Vít Ondruch]

Hi all,

Another update to the most recent version of Ruby 3.0 is here:

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

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

The main difference is RubyGems patch fixing issues with build of
rubygem- packages pvalena encountered in Copr. Apart of that, there is
ongoing StdLib gemification.

As always, I'm looking for any feedback.


Vít

Ruby 3.0

[Pavel Valena]

----- Original Message -----
>  From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
>  To: ruby-sig(a)lists.fedoraproject.org
>  Sent: Friday, October 9, 2020 1:52:07 PM
>  Subject: Re: Ruby 3.0
>  
>  Hi all,
>  
>  Another update to the most recent version of Ruby 3.0 is here:
>  
>  https://src.fedoraproject.org/rpms/ruby/pull-request/70
>  
>  https://koji.fedoraproject.org/koji/taskinfo?taskID=53075655
>  
>  The main difference is RubyGems patch fixing issues with build of
>  rubygem- packages pvalena encountered in Copr. Apart of that, there is
>  ongoing StdLib gemification.
>  
>  As always, I'm looking for any feedback. 
Hello,

I've rebuilt your ruby in my ruby-testing copr repo, and I'm building (almost) all
rubygem-* packages on top of it in my rubygems-testing corp repo.

This time, it was more successful. I only had to remove `racc` requirement from Nokogiri
so far (colliding with ruby-default-gems).
 
https://download.copr.fedorainfracloud.org/results/pvalena/rubygems-testi...

All build results can be found here:
  https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/builds/

I'm looking into the failed ones, and rebuilding those which can be, as their
dependencies got fullfiled.

One 'interesting' failure is a gem with native extension:
 
https://download.copr.fedorainfracloud.org/results/pvalena/rubygems-testi...
  (It builds fine in rawhide.)

Pavel

>  
>  
>  Vít
>

Ruby 3.0

[Mamoru TASAKA]

Pavel Valena wrote on 2020/10/13 21:00:
>  ----- Original Message -----
> > From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
> > To: ruby-sig(a)lists.fedoraproject.org
> > Sent: Friday, October 9, 2020 1:52:07 PM
> > Subject: Re: Ruby 3.0
> >
> > Hi all,
> >
> > Another update to the most recent version of Ruby 3.0 is here:
> >
> > https://src.fedoraproject.org/rpms/ruby/pull-request/70
> >
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=53075655
> >
> > The main difference is RubyGems patch fixing issues with build of
> > rubygem- packages pvalena encountered in Copr. Apart of that, there is
> > ongoing StdLib gemification.
> >
> > As always, I'm looking for any feedback.
>  
>  Hello,
>  
>  I've rebuilt your ruby in my ruby-testing copr repo, and I'm building (almost)
> all rubygem-* packages on top of it in my rubygems-testing corp repo.
>  
>  This time, it was more successful. I only had to remove `racc` requirement from Nokogiri
> so far (colliding with ruby-default-gems).
>    
> https://download.copr.fedorainfracloud.org/results/pvalena/rubygems-testi...
>  
>  All build results can be found here:
>     https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/builds/
>  
>  I'm looking into the failed ones, and rebuilding those which can be, as their
> dependencies got fullfiled.
>  
>  One 'interesting' failure is a gem with native extension:
>    
> https://download.copr.fedorainfracloud.org/results/pvalena/rubygems-testi...
>     (It builds fine in rawhide.)
>  
>  Pavel 
Looks like with Vít's ruby 3.0 scratch build (taskID=53075655),
CONFIG["CXX"] is not set ( in /usr/lib64/ruby/rbconfig.rb on x86_64), while
with ruby-libs-2.7.1-134.fc33.x86_64, CONFIG["CXX"] is correctly set as g++.

rubygem-eventmachine uses CONFIG["CXX"] to find c++ compiler, so it seems
currently eventmachine cannot find c++ compiler.


> > Vít
> > 
Regards,
Mamoru

Ruby 3.0

[Vít Ondruch]

Dne 13. 10. 20 v 14:29 Mamoru TASAKA napsal(a):
>  Pavel Valena wrote on 2020/10/13 21:00:
> > ----- Original Message -----
> >> From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
> >> To: ruby-sig(a)lists.fedoraproject.org
> >> Sent: Friday, October 9, 2020 1:52:07 PM
> >> Subject: Re: Ruby 3.0
> >>
> >> Hi all,
> >>
> >> Another update to the most recent version of Ruby 3.0 is here:
> >>
> >> https://src.fedoraproject.org/rpms/ruby/pull-request/70
> >>
> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=53075655
> >>
> >> The main difference is RubyGems patch fixing issues with build of
> >> rubygem- packages pvalena encountered in Copr. Apart of that, there is
> >> ongoing StdLib gemification.
> >>
> >> As always, I'm looking for any feedback.
> >
> > Hello,
> >
> > I've rebuilt your ruby in my ruby-testing copr repo, and I'm building
> > (almost) all rubygem-* packages on top of it in my rubygems-testing
> > corp repo. 

Appreciate that!


> >
> > This time, it was more successful. I only had to remove `racc`
> > requirement from Nokogiri so far (colliding with ruby-default-gems).
> >   
> >
> https://download.copr.fedorainfracloud.org/results/pvalena/rubygems-testi...

Interesting. I have already dropped the %{_bindir}/racc, I should
probably drop also the bin/racc directrly from the package. Good catch.


> >
> > All build results can be found here:
> >   
> > https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/builds/
> >
> > I'm looking into the failed ones, and rebuilding those which can be,
> > as their dependencies got fullfiled.
> >
> > One 'interesting' failure is a gem with native extension:
> >   
> >
> https://download.copr.fedorainfracloud.org/results/pvalena/rubygems-testi...
> >    (It builds fine in rawhide.)
> >
> > Pavel
>
>  Looks like with Vít's ruby 3.0 scratch build (taskID=53075655),
>  CONFIG["CXX"] is not set ( in /usr/lib64/ruby/rbconfig.rb on x86_64),
>  while
>  with ruby-libs-2.7.1-134.fc33.x86_64, CONFIG["CXX"] is correctly set
>  as g++.
>
>  rubygem-eventmachine uses CONFIG["CXX"] to find c++ compiler, so it seems
>  currently eventmachine cannot find c++ compiler. 

Mamoru, thx for analysis. Very interesting. We don't have installed g++
during build of Ruby, that might be the reason for the issue. But the
question is what have changed. I will need to take a closer look.


Vít

Ruby 3.0

[Vít Ondruch]

Hi all,

Here is once again freshly updated Ruby. The changes are available here:

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

and you can find the scratch build in Koji:

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

 From the notable changes, there is ongoing effort to gemify StdLib.

As always, please let me know if you encounter any issues with the package.

Thx


Vít

Ruby 3.0

[Dan Čermák]

Hi Vít,

Vít Ondruch <vondruch(a)redhat.com&gt; writes:

>  Hi all,
>
>  Here is once again freshly updated Ruby. The changes are available here:
>
>  https://src.fedoraproject.org/rpms/ruby/pull-request/70
>
>  and you can find the scratch build in Koji:
>
>  https://koji.fedoraproject.org/koji/taskinfo?taskID=54978639
>
>   From the notable changes, there is ongoing effort to gemify StdLib.
>
>  As always, please let me know if you encounter any issues with the
>  package. 
Any idea what is the state of vagrant w.r.t Ruby 3.0? I know upstream
struggled quite a bit with 2.7 already.


Cheers,

Dan

Ruby 3.0

[Pavel Valena]

----- Original Message -----
>  From: "Dan Čermák" <dan.cermak(a)cgc-instruments.com&gt;
>  To: "Vít Ondruch" <vondruch(a)redhat.com&gt;
>  Cc: ruby-sig(a)lists.fedoraproject.org
>  Sent: Thursday, November 5, 2020 4:41:46 PM
>  Subject: Re: Ruby 3.0
>  
>  Hi Vít,
>  
>  Vít Ondruch <vondruch(a)redhat.com&gt; writes:
>  
>  > Hi all,
>  >
>  > Here is once again freshly updated Ruby. The changes are available here:
>  >
>  > https://src.fedoraproject.org/rpms/ruby/pull-request/70
>  >
>  > and you can find the scratch build in Koji:
>  >
>  > https://koji.fedoraproject.org/koji/taskinfo?taskID=54978639
>  >
>  >  From the notable changes, there is ongoing effort to gemify StdLib.
>  >
>  > As always, please let me know if you encounter any issues with the
>  > package.
>  
>  Any idea what is the state of vagrant w.r.t Ruby 3.0? I know upstream
>  struggled quite a bit with 2.7 already.
>  
>  
>  Cheers,
>  
>  Dan
>   
Hello Dan,

that's a good point!

Let me investigate / check in my vagrant-testing COPR repo, similarly to what I've
done in rubygems-testing repo (for which I'll run the previuosly failed builds as
well).

  https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/
  https://copr.fedorainfracloud.org/coprs/pvalena/vagrant-testing/

I'll write a summary here once some the builds finish (~1week).

Regards,

-- 
Pavel Valena
Software Engineer, Red Hat
Brno, Czech Republic

Ruby 3.0

[Pavel Valena]

----- Original Message -----
>  From: "Pavel Valena" <pvalena(a)redhat.com&gt;
>  To: "Dan Čermák" <dan.cermak(a)cgc-instruments.com&gt;
>  Cc: "Ruby SIG mailing list" <ruby-sig(a)lists.fedoraproject.org&gt;
>  Sent: Thursday, November 5, 2020 8:30:25 PM
>  Subject: Re: Ruby 3.0
>  
>  ----- Original Message -----
>  > From: "Dan Čermák" <dan.cermak(a)cgc-instruments.com&gt;
>  > To: "Vít Ondruch" <vondruch(a)redhat.com&gt;
>  > Cc: ruby-sig(a)lists.fedoraproject.org
>  > Sent: Thursday, November 5, 2020 4:41:46 PM
>  > Subject: Re: Ruby 3.0
>  > 
>  > Hi Vít,
>  > 
>  > Vít Ondruch <vondruch(a)redhat.com&gt; writes:
>  > 
>  > > Hi all,
>  > >
>  > > Here is once again freshly updated Ruby. The changes are available here:
>  > >
>  > > https://src.fedoraproject.org/rpms/ruby/pull-request/70
>  > >
>  > > and you can find the scratch build in Koji:
>  > >
>  > > https://koji.fedoraproject.org/koji/taskinfo?taskID=54978639
>  > >
>  > >  From the notable changes, there is ongoing effort to gemify StdLib.
>  > >
>  > > As always, please let me know if you encounter any issues with the
>  > > package. 
It seems I'm still not able to build gems like eventmachine:

  
https://download.copr.fedorainfracloud.org/results/pvalena/rubygems-testi...
   https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/build/17...

Error I'm getting is
``` make: I.: No such file or directory ```
 note the missing -

( The same gem succeeds all other Fedoras:
https://copr.fedorainfracloud.org/coprs/pvalena/rubygems/build/1767304/ )

Pavel


>  > 
>  > Any idea what is the state of vagrant w.r.t Ruby 3.0? I know upstream
>  > struggled quite a bit with 2.7 already.
>  > 
>  > 
>  > Cheers,
>  > 
>  > Dan
>  > 
>  
>  Hello Dan,
>  
>  that's a good point!
>  
>  Let me investigate / check in my vagrant-testing COPR repo, similarly to what
>  I've done in rubygems-testing repo (for which I'll run the previuosly failed
>  builds as well).
>  
>    https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/
>    https://copr.fedorainfracloud.org/coprs/pvalena/vagrant-testing/
>  
>  I'll write a summary here once some the builds finish (~1week).
>  
>  Regards,
>  
>  --
>  Pavel Valena
>  Software Engineer, Red Hat
>  Brno, Czech Republic

Ruby 3.0

[Vít Ondruch]

Dne 13. 11. 20 v 3:56 Pavel Valena napsal(a):
>  ----- Original Message -----
> > From: "Pavel Valena" <pvalena(a)redhat.com&gt;
> > To: "Dan Čermák" <dan.cermak(a)cgc-instruments.com&gt;
> > Cc: "Ruby SIG mailing list" <ruby-sig(a)lists.fedoraproject.org&gt;
> > Sent: Thursday, November 5, 2020 8:30:25 PM
> > Subject: Re: Ruby 3.0
> >
> > ----- Original Message -----
> >> From: "Dan Čermák" <dan.cermak(a)cgc-instruments.com&gt;
> >> To: "Vít Ondruch" <vondruch(a)redhat.com&gt;
> >> Cc: ruby-sig(a)lists.fedoraproject.org
> >> Sent: Thursday, November 5, 2020 4:41:46 PM
> >> Subject: Re: Ruby 3.0
> >>
> >> Hi Vít,
> >>
> >> Vít Ondruch <vondruch(a)redhat.com&gt; writes:
> >>
> >>> Hi all,
> >>>
> >>> Here is once again freshly updated Ruby. The changes are available here:
> >>>
> >>> https://src.fedoraproject.org/rpms/ruby/pull-request/70
> >>>
> >>> and you can find the scratch build in Koji:
> >>>
> >>> https://koji.fedoraproject.org/koji/taskinfo?taskID=54978639
> >>>
> >>>   From the notable changes, there is ongoing effort to gemify StdLib.
> >>>
> >>> As always, please let me know if you encounter any issues with the
> >>> package.
>  It seems I'm still not able to build gems like eventmachine: 

I wonder what precisely is "gems like eventmachine"


>     
> https://download.copr.fedorainfracloud.org/results/pvalena/rubygems-testi...
>      https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/build/17...
>
>  Error I'm getting is
>  ``` make: I.: No such file or directory ```
>    note the missing - 

I think the issue is not in the `-` but in what is missing prior it. If 
you see this line, isn't there something strange?

~~~

I. -I/usr/include -I/usr/include/ruby/backward -I/usr/include -I.  
-DHAVE_OPENSSL_SSL_H -DHAVE_OPENSSL_ERR_H -DWITH_SSL -DBUILD_FOR_RUBY 
-DHAVE_RB_THREAD_CALL_WITHOUT_GVL -DHAVE_RB_THREAD_FD_SELECT 
-DHAVE_TYPE_RB_FDSET_T -DHAVE_RB_WAIT_FOR_SINGLE_FD -DHAVE_RB_TIME_NEW 
-DHAVE_INOTIFY_INIT -DHAVE_INOTIFY -DHAVE_WRITEV -DHAVE_PIPE2 
-DHAVE_ACCEPT4 -DHAVE_CONST_SOCK_CLOEXEC -DOS_UNIX -DHAVE_EPOLL_CREATE 
-DHAVE_EPOLL -DHAVE_CLOCK_GETTIME -DHAVE_CONST_CLOCK_MONOTONIC_RAW 
-DHAVE_CONST_CLOCK_MONOTONIC -fPIC -O2 -flto=auto -ffat-lto-objects 
-fexceptions -g -grecord-gcc-switches -pipe -Wall 
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
-m64 -mtune=generic -fasynchronous-unwind-tables 
-fstack-clash-protection -fcf-protection  -m64 -o binder.o -c binder.cpp

~~~


For comparison, the same line from last official Fedora build:


~~~

g++ -I. -I/usr/include -I/usr/include/ruby/backward -I/usr/include -I.  
-DHAVE_OPENSSL_SSL_H -DHAVE_OPENSSL_ERR_H -DWITH_SSL -DBUILD_FOR_RUBY 
-DHAVE_RB_THREAD_CALL_WITHOUT_GVL -DHAVE_RB_THREAD_FD_SELECT 
-DHAVE_TYPE_RB_FDSET_T -DHAVE_RB_WAIT_FOR_SINGLE_FD -DHAVE_RB_TIME_NEW 
-DHAVE_INOTIFY_INIT -DHAVE_INOTIFY -DHAVE_WRITEV -DHAVE_PIPE2 
-DHAVE_ACCEPT4 -DHAVE_CONST_SOCK_CLOEXEC -DOS_UNIX -DHAVE_EPOLL_CREATE 
-DHAVE_EPOLL -DHAVE_CLOCK_GETTIME -DHAVE_CONST_CLOCK_MONOTONIC_RAW 
-DHAVE_CONST_CLOCK_MONOTONIC -DHAVE_MAKE_PAIR    -fPIC -O2 -flto=auto 
-ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall 
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
-m64 -mtune=generic -fasynchronous-unwind-tables 
-fstack-clash-protection -fcf-protection  -m64 -o binder.o -c binder.cpp

~~~


If you checked the Makefile, these are the corresponding lines:


~~~

.cpp.o:
     $(ECHO) compiling $(<)
     $(Q) $(CXX) $(INCFLAGS) $(CPPFLAGS) $(CXXFLAGS) $(COUTFLAG)$@ -c 
$(CSRCFLAG)$<

~~~


And


~~~

CXX =

~~~


So one of the reasons is that we don't have C++ compiler available 
during Ruby build and therefore there are not stored the appropriate 
values into RbConfig (I mildly remember, that there could have been also 
patch to remove the need for C++ or it was reported somewhere, but I 
don't remember more details).

The other reason is that somebody changed something somewhere and 
apparently something relies on it. The question is what. I would 
appreciate if somebody helped me to understand what have changed.

One could also expect, that the extconf.rb + mkmf would include check 
for compiler availability and let the compilation fail earlier, but this 
is not the case unfortunately. So if somebody could investigate, if 
eventmachine and possibly also other package could check on compiler 
availability, that could help to prevent non-obvious issues like this.

Checking the mkmf.log, it is also interesting to see, that most of the 
configuration check are done using `gcc`, while there also other checks:

~~~

" -o conftest -I/usr/include -I/usr/include/ruby/backward -I/usr/include 
-I.     -O2 -flto=auto -ffat-lto-objects -fexceptions -g 
-grecord-gcc-switches -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection  
conftest.c  -L. -L/usr/lib64 -L. -Wl,-z,relro -Wl,--as-needed  
-Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld 
-fstack-protector-strong -rdynamic -Wl,-export-dynamic   -m64 -lssl 
-lcrypto -lcrypto -lssl -lruby -Wall -lm   -lc"
checked program was:
/* begin */
1: #include "ruby.h"
2:
3: int main() {return 0;}
/* end */

~~~

They are missing the `gcc` on the beginning and they appears to be 
silently ignored. But these corresponds to:

https://github.com/eventmachine/eventmachine/blob/b50c135dfdd4e7b20c8e0b7...

https://github.com/eventmachine/eventmachine/blob/b50c135dfdd4e7b20c8e0b7...

So these are somehow expected to fail, but they should probably fail in 
different way.


Vít


>  ( The same gem succeeds all other Fedoras:
> https://copr.fedorainfracloud.org/coprs/pvalena/rubygems/build/1767304/ )
>
>  Pavel
>
>
> >> Any idea what is the state of vagrant w.r.t Ruby 3.0? I know upstream
> >> struggled quite a bit with 2.7 already.
> >>
> >>
> >> Cheers,
> >>
> >> Dan
> >>
> > Hello Dan,
> >
> > that's a good point!
> >
> > Let me investigate / check in my vagrant-testing COPR repo, similarly to what
> > I've done in rubygems-testing repo (for which I'll run the previuosly failed
> > builds as well).
> >
> >    https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/
> >    https://copr.fedorainfracloud.org/coprs/pvalena/vagrant-testing/
> >
> > I'll write a summary here once some the builds finish (~1week).
> >
> > Regards,
> >
> > --
> > Pavel Valena
> > Software Engineer, Red Hat
> > Brno, Czech Republic

Ruby 3.0

[Mamoru TASAKA]

Vít Ondruch wrote on 2020/11/13 17:46:
>  
>  Dne 13. 11. 20 v 3:56 Pavel Valena napsal(a):
> > ----- Original Message -----
> >> From: "Pavel Valena" <pvalena(a)redhat.com&gt;
> >> To: "Dan Čermák" <dan.cermak(a)cgc-instruments.com&gt;
> >> Cc: "Ruby SIG mailing list" <ruby-sig(a)lists.fedoraproject.org&gt;
> >> Sent: Thursday, November 5, 2020 8:30:25 PM
> >> Subject: Re: Ruby 3.0
> >>
> >> ----- Original Message -----
> >>> From: "Dan Čermák" <dan.cermak(a)cgc-instruments.com&gt;
> >>> To: "Vít Ondruch" <vondruch(a)redhat.com&gt;
> >>> Cc: ruby-sig(a)lists.fedoraproject.org
> >>> Sent: Thursday, November 5, 2020 4:41:46 PM
> >>> Subject: Re: Ruby 3.0
> >>>
> >>> Hi Vít,
> >>>
> >>> Vít Ondruch <vondruch(a)redhat.com&gt; writes:
> >>>
> >>>> Hi all,
> >>>>
> >>>> Here is once again freshly updated Ruby. The changes are available here:
> >>>>
> >>>> https://src.fedoraproject.org/rpms/ruby/pull-request/70
> >>>>
> >>>> and you can find the scratch build in Koji:
> >>>>
> >>>> https://koji.fedoraproject.org/koji/taskinfo?taskID=54978639
> >>>>
> >>>>   From the notable changes, there is ongoing effort to gemify StdLib.
> >>>>
> >>>> As always, please let me know if you encounter any issues with the
> >>>> package.
> > It seems I'm still not able to build gems like eventmachine:
>  
>  
>  I wonder what precisely is "gems like eventmachine"
>  
>  
> >
> >    
> https://download.copr.fedorainfracloud.org/results/pvalena/rubygems-testi...
> >     https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/build/17...
> >
> > Error I'm getting is
> > ``` make: I.: No such file or directory ```
> >   note the missing -
>  
>  
>  I think the issue is not in the `-` but in what is missing prior it. If you see this
> line, isn't there something strange?
>  
>  ~~~
>  
>  I. -I/usr/include -I/usr/include/ruby/backward -I/usr/include -I. -DHAVE_OPENSSL_SSL_H
> -DHAVE_OPENSSL_ERR_H -DWITH_SSL -DBUILD_FOR_RUBY -DHAVE_RB_THREAD_CALL_WITHOUT_GVL
> -DHAVE_RB_THREAD_FD_SELECT -DHAVE_TYPE_RB_FDSET_T -DHAVE_RB_WAIT_FOR_SINGLE_FD
> -DHAVE_RB_TIME_NEW -DHAVE_INOTIFY_INIT -DHAVE_INOTIFY -DHAVE_WRITEV -DHAVE_PIPE2
> -DHAVE_ACCEPT4 -DHAVE_CONST_SOCK_CLOEXEC -DOS_UNIX -DHAVE_EPOLL_CREATE -DHAVE_EPOLL
> -DHAVE_CLOCK_GETTIME -DHAVE_CONST_CLOCK_MONOTONIC_RAW -DHAVE_CONST_CLOCK_MONOTONIC -fPIC
> -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall
> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection  -m64 -o binder.o -c
> binder.cpp
>  
>  ~~~
>  
>  
>  For comparison, the same line from last official Fedora build:
>  
>  
>  ~~~
>  
>  g++ -I. -I/usr/include -I/usr/include/ruby/backward -I/usr/include -I.
> -DHAVE_OPENSSL_SSL_H -DHAVE_OPENSSL_ERR_H -DWITH_SSL -DBUILD_FOR_RUBY
> -DHAVE_RB_THREAD_CALL_WITHOUT_GVL -DHAVE_RB_THREAD_FD_SELECT -DHAVE_TYPE_RB_FDSET_T
> -DHAVE_RB_WAIT_FOR_SINGLE_FD -DHAVE_RB_TIME_NEW -DHAVE_INOTIFY_INIT -DHAVE_INOTIFY
> -DHAVE_WRITEV -DHAVE_PIPE2 -DHAVE_ACCEPT4 -DHAVE_CONST_SOCK_CLOEXEC -DOS_UNIX
> -DHAVE_EPOLL_CREATE -DHAVE_EPOLL -DHAVE_CLOCK_GETTIME -DHAVE_CONST_CLOCK_MONOTONIC_RAW
> -DHAVE_CONST_CLOCK_MONOTONIC -DHAVE_MAKE_PAIR    -fPIC -O2 -flto=auto -ffat-lto-objects
> -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security
> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection  -m64 -o binder.o -c
> binder.cpp
>  
>  ~~~
>  
>  
>  If you checked the Makefile, these are the corresponding lines:
>  
>  
>  ~~~
>  
>  .cpp.o:
>       $(ECHO) compiling $(<)
>       $(Q) $(CXX) $(INCFLAGS) $(CPPFLAGS) $(CXXFLAGS) $(COUTFLAG)$@ -c $(CSRCFLAG)$<
>  
>  ~~~
>  
>  
>  And
>  
>  
>  ~~~
>  
>  CXX =
>  
>  ~~~
>  
>  
>  So one of the reasons is that we don't have C++ compiler available during Ruby build
> and therefore there are not stored the appropriate values into RbConfig (I mildly
> remember, that there could have been also patch to remove the need for C++ or it was
> reported somewhere, but I don't remember more details).
>  
>  The other reason is that somebody changed something somewhere and apparently something
> relies on it. The question is what. I would appreciate if somebody helped me to understand
> what have changed.
>  
>  One could also expect, that the extconf.rb + mkmf would include check for compiler
> availability and let the compilation fail earlier, but this is not the case unfortunately.
> So if somebody could investigate, if eventmachine and possibly also other package could
> check on compiler availability, that could help to prevent non-obvious issues like this.
>  
>  Checking the mkmf.log, it is also interesting to see, that most of the configuration
> check are done using `gcc`, while there also other checks:
>  
>  ~~~
>  
>  " -o conftest -I/usr/include -I/usr/include/ruby/backward -I/usr/include -I.     -O2
> -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall
> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection conftest.c  -L.
> -L/usr/lib64 -L. -Wl,-z,relro -Wl,--as-needed -Wl,-z,now
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fstack-protector-strong -rdynamic
> -Wl,-export-dynamic   -m64 -lssl -lcrypto -lcrypto -lssl -lruby -Wall -lm   -lc"
>  checked program was:
>  /* begin */
>  1: #include "ruby.h"
>  2:
>  3: int main() {return 0;}
>  /* end */
>  
>  ~~~
>  
>  They are missing the `gcc` on the beginning and they appears to be silently ignored. But
> these corresponds to:
>  
>
> https://github.com/eventmachine/eventmachine/blob/b50c135dfdd4e7b20c8e0b7...
>  
>
> https://github.com/eventmachine/eventmachine/blob/b50c135dfdd4e7b20c8e0b7...
>  
>  So these are somehow expected to fail, but they should probably fail in different way.
>  
>  
>  Vít
>   
So CONFIG["CXX"] is not yet set ( in /usr/lib64/ruby/rbconfig.rb on x86_64)
(see:
https://lists.fedoraproject.org/archives/list/[e-mail]...
) and still rubygem-eventmachine fails to find CXX compiler, while
rawhide ruby-libs rpm has CONFIG["CXX"] value.

Regards,
Mamoru

Ruby 3.0

[Mamoru TASAKA]

Mamoru TASAKA wrote on 2020/11/13 19:18:
>  Vít Ondruch wrote on 2020/11/13 17:46:
> >
> > Dne 13. 11. 20 v 3:56 Pavel Valena napsal(a):
> >> ----- Original Message -----
> >>> From: "Pavel Valena" <pvalena(a)redhat.com&gt;
> >>> To: "Dan Čermák" <dan.cermak(a)cgc-instruments.com&gt;
> >>> Cc: "Ruby SIG mailing list"
> <ruby-sig(a)lists.fedoraproject.org&gt;
> >>> Sent: Thursday, November 5, 2020 8:30:25 PM
> >>> Subject: Re: Ruby 3.0
> >>>
> >>> ----- Original Message -----
> >>>> From: "Dan Čermák" <dan.cermak(a)cgc-instruments.com&gt;
> >>>> To: "Vít Ondruch" <vondruch(a)redhat.com&gt;
> >>>> Cc: ruby-sig(a)lists.fedoraproject.org
> >>>> Sent: Thursday, November 5, 2020 4:41:46 PM
> >>>> Subject: Re: Ruby 3.0
> >>>>
> >>>> Hi Vít,
> >>>>
> >>>> Vít Ondruch <vondruch(a)redhat.com&gt; writes:
> >>>>
> >>>>> Hi all,
> >>>>>
> >>>>> Here is once again freshly updated Ruby. The changes are available
> here:
> >>>>>
> >>>>> https://src.fedoraproject.org/rpms/ruby/pull-request/70
> >>>>>
> >>>>> and you can find the scratch build in Koji:
> >>>>>
> >>>>> https://koji.fedoraproject.org/koji/taskinfo?taskID=54978639
> >>>>>
> >>>>>   From the notable changes, there is ongoing effort to gemify
> StdLib.
> >>>>>
> >>>>> As always, please let me know if you encounter any issues with the
> >>>>> package.
> >> It seems I'm still not able to build gems like eventmachine:
> >
> >
> > I wonder what precisely is "gems like eventmachine"
> >
> >
> >>
> >>    
> https://download.copr.fedorainfracloud.org/results/pvalena/rubygems-testi...
> >>    
> https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/build/17...
> >>
> >> Error I'm getting is
> >> ``` make: I.: No such file or directory ```
> >>   note the missing -
> >
> >
> > I think the issue is not in the `-` but in what is missing prior it. If you see this
> line, isn't there something strange?
> >
> > ~~~
> >
> > I. -I/usr/include -I/usr/include/ruby/backward -I/usr/include -I.
> -DHAVE_OPENSSL_SSL_H -DHAVE_OPENSSL_ERR_H -DWITH_SSL -DBUILD_FOR_RUBY
> -DHAVE_RB_THREAD_CALL_WITHOUT_GVL -DHAVE_RB_THREAD_FD_SELECT -DHAVE_TYPE_RB_FDSET_T
> -DHAVE_RB_WAIT_FOR_SINGLE_FD -DHAVE_RB_TIME_NEW -DHAVE_INOTIFY_INIT -DHAVE_INOTIFY
> -DHAVE_WRITEV -DHAVE_PIPE2 -DHAVE_ACCEPT4 -DHAVE_CONST_SOCK_CLOEXEC -DOS_UNIX
> -DHAVE_EPOLL_CREATE -DHAVE_EPOLL -DHAVE_CLOCK_GETTIME -DHAVE_CONST_CLOCK_MONOTONIC_RAW
> -DHAVE_CONST_CLOCK_MONOTONIC -fPIC -O2 -flto=auto -ffat-lto-objects -fexceptions -g
> -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection  -m64 -o binder.o -c
> binder.cpp
> >
> > ~~~
> >
> >
> > For comparison, the same line from last official Fedora build:
> >
> >
> > ~~~
> >
> > g++ -I. -I/usr/include -I/usr/include/ruby/backward -I/usr/include -I.
> -DHAVE_OPENSSL_SSL_H -DHAVE_OPENSSL_ERR_H -DWITH_SSL -DBUILD_FOR_RUBY
> -DHAVE_RB_THREAD_CALL_WITHOUT_GVL -DHAVE_RB_THREAD_FD_SELECT -DHAVE_TYPE_RB_FDSET_T
> -DHAVE_RB_WAIT_FOR_SINGLE_FD -DHAVE_RB_TIME_NEW -DHAVE_INOTIFY_INIT -DHAVE_INOTIFY
> -DHAVE_WRITEV -DHAVE_PIPE2 -DHAVE_ACCEPT4 -DHAVE_CONST_SOCK_CLOEXEC -DOS_UNIX
> -DHAVE_EPOLL_CREATE -DHAVE_EPOLL -DHAVE_CLOCK_GETTIME -DHAVE_CONST_CLOCK_MONOTONIC_RAW
> -DHAVE_CONST_CLOCK_MONOTONIC -DHAVE_MAKE_PAIR    -fPIC -O2 -flto=auto -ffat-lto-objects
> -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security
> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection  -m64 -o binder.o -c
> binder.cpp
> >
> > ~~~
> >
> >
> > If you checked the Makefile, these are the corresponding lines:
> >
> >
> > ~~~
> >
> > .cpp.o:
> >      $(ECHO) compiling $(<)
> >      $(Q) $(CXX) $(INCFLAGS) $(CPPFLAGS) $(CXXFLAGS) $(COUTFLAG)$@ -c
> $(CSRCFLAG)$<
> >
> > ~~~
> >
> >
> > And
> >
> >
> > ~~~
> >
> > CXX =
> >
> > ~~~
> >
> >
> > So one of the reasons is that we don't have C++ compiler available during Ruby
> build and therefore there are not stored the appropriate values into RbConfig (I mildly
> remember, that there could have been also patch to remove the need for C++ or it was
> reported somewhere, but I don't remember more details).
> >
> > The other reason is that somebody changed something somewhere and apparently
> something relies on it. The question is what. I would appreciate if somebody helped me to
> understand what have changed.
> >
> > One could also expect, that the extconf.rb + mkmf would include check for compiler
> availability and let the compilation fail earlier, but this is not the case unfortunately.
> So if somebody could investigate, if eventmachine and possibly also other package could
> check on compiler availability, that could help to prevent non-obvious issues like this.
> >
> > Checking the mkmf.log, it is also interesting to see, that most of the configuration
> check are done using `gcc`, while there also other checks:
> >
> > ~~~
> >
> > " -o conftest -I/usr/include -I/usr/include/ruby/backward -I/usr/include -I.    
> -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall
> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection conftest.c  -L.
> -L/usr/lib64 -L. -Wl,-z,relro -Wl,--as-needed -Wl,-z,now
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fstack-protector-strong -rdynamic
> -Wl,-export-dynamic   -m64 -lssl -lcrypto -lcrypto -lssl -lruby -Wall -lm   -lc"
> > checked program was:
> > /* begin */
> > 1: #include "ruby.h"
> > 2:
> > 3: int main() {return 0;}
> > /* end */
> >
> > ~~~
> >
> > They are missing the `gcc` on the beginning and they appears to be silently ignored.
> But these corresponds to:
> >
> >
> https://github.com/eventmachine/eventmachine/blob/b50c135dfdd4e7b20c8e0b7...
> >
> >
> https://github.com/eventmachine/eventmachine/blob/b50c135dfdd4e7b20c8e0b7...
> >
> > So these are somehow expected to fail, but they should probably fail in different
> way.
> >
> >
> > Vít
> >
>  
>  So CONFIG["CXX"] is not yet set ( in /usr/lib64/ruby/rbconfig.rb on x86_64)
> (see:
>
> https://lists.fedoraproject.org/archives/list/[e-mail]...
>  ) and still rubygem-eventmachine fails to find CXX compiler, while
>  rawhide ruby-libs rpm has CONFIG["CXX"] value. 
Apparently this commit changed CXX value:
https://github.com/ruby/ruby/commit/50b18e81295ad2d45975e4d8ea1e0c7e85140b97

Regards,
Mamoru

Ruby 3.0

[Vít Ondruch]

Dne 13. 11. 20 v 11:25 Mamoru TASAKA napsal(a):
>  Mamoru TASAKA wrote on 2020/11/13 19:18:
> > Vít Ondruch wrote on 2020/11/13 17:46:
> >>
> >> Dne 13. 11. 20 v 3:56 Pavel Valena napsal(a):
> >>> ----- Original Message -----
> >>>> From: "Pavel Valena" <pvalena(a)redhat.com&gt;
> >>>> To: "Dan Čermák" <dan.cermak(a)cgc-instruments.com&gt;
> >>>> Cc: "Ruby SIG mailing list"
> <ruby-sig(a)lists.fedoraproject.org&gt;
> >>>> Sent: Thursday, November 5, 2020 8:30:25 PM
> >>>> Subject: Re: Ruby 3.0
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Dan Čermák" <dan.cermak(a)cgc-instruments.com&gt;
> >>>>> To: "Vít Ondruch" <vondruch(a)redhat.com&gt;
> >>>>> Cc: ruby-sig(a)lists.fedoraproject.org
> >>>>> Sent: Thursday, November 5, 2020 4:41:46 PM
> >>>>> Subject: Re: Ruby 3.0
> >>>>>
> >>>>> Hi Vít,
> >>>>>
> >>>>> Vít Ondruch <vondruch(a)redhat.com&gt; writes:
> >>>>>
> >>>>>> Hi all,
> >>>>>>
> >>>>>> Here is once again freshly updated Ruby. The changes are 
> >>>>>> available here:
> >>>>>>
> >>>>>> https://src.fedoraproject.org/rpms/ruby/pull-request/70
> >>>>>>
> >>>>>> and you can find the scratch build in Koji:
> >>>>>>
> >>>>>> https://koji.fedoraproject.org/koji/taskinfo?taskID=54978639
> >>>>>>
> >>>>>>   From the notable changes, there is ongoing effort to gemify 
> >>>>>> StdLib.
> >>>>>>
> >>>>>> As always, please let me know if you encounter any issues with
> the
> >>>>>> package.
> >>> It seems I'm still not able to build gems like eventmachine:
> >>
> >>
> >> I wonder what precisely is "gems like eventmachine"
> >>
> >>
> >>>
> >>>
> https://download.copr.fedorainfracloud.org/results/pvalena/rubygems-testi...
> >>>
> https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/build/17...
> >>>
> >>> Error I'm getting is
> >>> ``` make: I.: No such file or directory ```
> >>>   note the missing -
> >>
> >>
> >> I think the issue is not in the `-` but in what is missing prior it. 
> >> If you see this line, isn't there something strange?
> >>
> >> ~~~
> >>
> >> I. -I/usr/include -I/usr/include/ruby/backward -I/usr/include -I. 
> >> -DHAVE_OPENSSL_SSL_H -DHAVE_OPENSSL_ERR_H -DWITH_SSL 
> >> -DBUILD_FOR_RUBY -DHAVE_RB_THREAD_CALL_WITHOUT_GVL 
> >> -DHAVE_RB_THREAD_FD_SELECT -DHAVE_TYPE_RB_FDSET_T 
> >> -DHAVE_RB_WAIT_FOR_SINGLE_FD -DHAVE_RB_TIME_NEW -DHAVE_INOTIFY_INIT 
> >> -DHAVE_INOTIFY -DHAVE_WRITEV -DHAVE_PIPE2 -DHAVE_ACCEPT4 
> >> -DHAVE_CONST_SOCK_CLOEXEC -DOS_UNIX -DHAVE_EPOLL_CREATE -DHAVE_EPOLL 
> >> -DHAVE_CLOCK_GETTIME -DHAVE_CONST_CLOCK_MONOTONIC_RAW 
> >> -DHAVE_CONST_CLOCK_MONOTONIC -fPIC -O2 -flto=auto -ffat-lto-objects 
> >> -fexceptions -g -grecord-gcc-switches -pipe -Wall 
> >> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> >> -Wp,-D_GLIBCXX_ASSERTIONS 
> >> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> >> -fstack-protector-strong 
> >> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
> >> -fasynchronous-unwind-tables -fstack-clash-protection 
> >> -fcf-protection  -m64 -o binder.o -c binder.cpp
> >>
> >> ~~~
> >>
> >>
> >> For comparison, the same line from last official Fedora build:
> >>
> >>
> >> ~~~
> >>
> >> g++ -I. -I/usr/include -I/usr/include/ruby/backward -I/usr/include 
> >> -I. -DHAVE_OPENSSL_SSL_H -DHAVE_OPENSSL_ERR_H -DWITH_SSL 
> >> -DBUILD_FOR_RUBY -DHAVE_RB_THREAD_CALL_WITHOUT_GVL 
> >> -DHAVE_RB_THREAD_FD_SELECT -DHAVE_TYPE_RB_FDSET_T 
> >> -DHAVE_RB_WAIT_FOR_SINGLE_FD -DHAVE_RB_TIME_NEW -DHAVE_INOTIFY_INIT 
> >> -DHAVE_INOTIFY -DHAVE_WRITEV -DHAVE_PIPE2 -DHAVE_ACCEPT4 
> >> -DHAVE_CONST_SOCK_CLOEXEC -DOS_UNIX -DHAVE_EPOLL_CREATE -DHAVE_EPOLL 
> >> -DHAVE_CLOCK_GETTIME -DHAVE_CONST_CLOCK_MONOTONIC_RAW 
> >> -DHAVE_CONST_CLOCK_MONOTONIC -DHAVE_MAKE_PAIR    -fPIC -O2 
> >> -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches 
> >> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> >> -Wp,-D_GLIBCXX_ASSERTIONS 
> >> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> >> -fstack-protector-strong 
> >> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
> >> -fasynchronous-unwind-tables -fstack-clash-protection 
> >> -fcf-protection  -m64 -o binder.o -c binder.cpp
> >>
> >> ~~~
> >>
> >>
> >> If you checked the Makefile, these are the corresponding lines:
> >>
> >>
> >> ~~~
> >>
> >> .cpp.o:
> >>      $(ECHO) compiling $(<)
> >>      $(Q) $(CXX) $(INCFLAGS) $(CPPFLAGS) $(CXXFLAGS) $(COUTFLAG)$@ 
> >> -c $(CSRCFLAG)$<
> >>
> >> ~~~
> >>
> >>
> >> And
> >>
> >>
> >> ~~~
> >>
> >> CXX =
> >>
> >> ~~~
> >>
> >>
> >> So one of the reasons is that we don't have C++ compiler available 
> >> during Ruby build and therefore there are not stored the appropriate 
> >> values into RbConfig (I mildly remember, that there could have been 
> >> also patch to remove the need for C++ or it was reported somewhere, 
> >> but I don't remember more details).
> >>
> >> The other reason is that somebody changed something somewhere and 
> >> apparently something relies on it. The question is what. I would 
> >> appreciate if somebody helped me to understand what have changed.
> >>
> >> One could also expect, that the extconf.rb + mkmf would include 
> >> check for compiler availability and let the compilation fail 
> >> earlier, but this is not the case unfortunately. So if somebody 
> >> could investigate, if eventmachine and possibly also other package 
> >> could check on compiler availability, that could help to prevent 
> >> non-obvious issues like this.
> >>
> >> Checking the mkmf.log, it is also interesting to see, that most of 
> >> the configuration check are done using `gcc`, while there also other 
> >> checks:
> >>
> >> ~~~
> >>
> >> " -o conftest -I/usr/include -I/usr/include/ruby/backward 
> >> -I/usr/include -I.     -O2 -flto=auto -ffat-lto-objects -fexceptions 
> >> -g -grecord-gcc-switches -pipe -Wall -Werror=format-security 
> >> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
> >> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> >> -fstack-protector-strong 
> >> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -mtune=generic 
> >> -fasynchronous-unwind-tables -fstack-clash-protection 
> >> -fcf-protection conftest.c  -L. -L/usr/lib64 -L. -Wl,-z,relro 
> >> -Wl,--as-needed -Wl,-z,now 
> >> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld 
> >> -fstack-protector-strong -rdynamic -Wl,-export-dynamic   -m64 -lssl 
> >> -lcrypto -lcrypto -lssl -lruby -Wall -lm   -lc"
> >> checked program was:
> >> /* begin */
> >> 1: #include "ruby.h"
> >> 2:
> >> 3: int main() {return 0;}
> >> /* end */
> >>
> >> ~~~
> >>
> >> They are missing the `gcc` on the beginning and they appears to be 
> >> silently ignored. But these corresponds to:
> >>
> >>
> https://github.com/eventmachine/eventmachine/blob/b50c135dfdd4e7b20c8e0b7...
>
> >>
> >>
> >>
> https://github.com/eventmachine/eventmachine/blob/b50c135dfdd4e7b20c8e0b7...
>
> >>
> >>
> >> So these are somehow expected to fail, but they should probably fail 
> >> in different way.
> >>
> >>
> >> Vít
> >>
> >
> > So CONFIG["CXX"] is not yet set ( in /usr/lib64/ruby/rbconfig.rb on 
> > x86_64) (see:
> >
> https://lists.fedoraproject.org/archives/list/[e-mail]...
>
> >
> > ) and still rubygem-eventmachine fails to find CXX compiler, while
> > rawhide ruby-libs rpm has CONFIG["CXX"] value.
>  
Thx for reminder :)


>  Apparently this commit changed CXX value:
>  https://github.com/ruby/ruby/commit/50b18e81295ad2d45975e4d8ea1e0c7e85140b97 
>  

This kind of commits does not make me happy :( While the intention is 
good, they don't take into consideration any distribution. It is 
tailored to the old fashion way of "download tarball & configure & make 
& make install", everything runs on single machine :/

Does anybody have a tip how to convince upstream, that this does not 
scale? Does anybody want to ask upstream to revert this commit on my behalf?


Vít


>  Regards,
>  Mamoru
>
>  _______________________________________________
>  ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org
>  To unsubscribe send an email to ruby-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/[e-mail]...

Ruby 3.0

[Pavel Valena]

----- Original Message -----
>  From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
>  To: ruby-sig(a)lists.fedoraproject.org
>  Sent: Friday, November 13, 2020 2:23:55 PM
>  Subject: Re: Ruby 3.0
>  
>  
>  Dne 13. 11. 20 v 11:25 Mamoru TASAKA napsal(a):
>  > Mamoru TASAKA wrote on 2020/11/13 19:18:
>  >> Vít Ondruch wrote on 2020/11/13 17:46:
>  >>>
>  >>> Dne 13. 11. 20 v 3:56 Pavel Valena napsal(a):
>  >>>> ----- Original Message -----
>  >>>>> From: "Pavel Valena" <pvalena(a)redhat.com&gt;
>  >>>>> To: "Dan Čermák" <dan.cermak(a)cgc-instruments.com&gt;
>  >>>>> Cc: "Ruby SIG mailing list"
> <ruby-sig(a)lists.fedoraproject.org&gt;
>  >>>>> Sent: Thursday, November 5, 2020 8:30:25 PM
>  >>>>> Subject: Re: Ruby 3.0
>  >>>>>
>  >>>>> ----- Original Message -----
>  >>>>>> From: "Dan Čermák"
> <dan.cermak(a)cgc-instruments.com&gt;
>  >>>>>> To: "Vít Ondruch" <vondruch(a)redhat.com&gt;
>  >>>>>> Cc: ruby-sig(a)lists.fedoraproject.org
>  >>>>>> Sent: Thursday, November 5, 2020 4:41:46 PM
>  >>>>>> Subject: Re: Ruby 3.0
>  >>>>>>
>  >>>>>> Hi Vít,
>  >>>>>>
>  >>>>>> Vít Ondruch <vondruch(a)redhat.com&gt; writes:
>  >>>>>>
>  >>>>>>> Hi all,
>  >>>>>>>
>  >>>>>>> Here is once again freshly updated Ruby. The changes are
>  >>>>>>> available here:
>  >>>>>>>
>  >>>>>>> https://src.fedoraproject.org/rpms/ruby/pull-request/70
>  >>>>>>>
>  >>>>>>> and you can find the scratch build in Koji:
>  >>>>>>>
>  >>>>>>>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=54978639
>  >>>>>>>
>  >>>>>>>   From the notable changes, there is ongoing effort to
> gemify
>  >>>>>>> StdLib.
>  >>>>>>>
>  >>>>>>> As always, please let me know if you encounter any issues
> with the
>  >>>>>>> package.
>  >>>> It seems I'm still not able to build gems like eventmachine:
>  >>>
>  >>>
>  >>> I wonder what precisely is "gems like eventmachine" 
Sorry, I've made a mistake- eventmachine's error is different than before, and now
it's the only one of this nature (AFAIK).

Current stats:

 113 failed-all.txt
  - all failed logs

  29 failed-deps.txt
  - missing dependent packages (Ruby 3.0 rebuild)

   3 failed-extens.txt
  - extensions could not be built

   6 failed-rspec.txt
  - rspec could not be installed

  75 failed-unknown.txt
  - unknown reason of failure (I'm doing automatic rebases on this set of packages as
well, so the failure could be one of those)

Now I'm working on those rspec ones (also testing enhanced rspec specs, which probably
caused this failure, PRs comming), as well as on the 'unknown' errors. I'll
keep you posted.

>  >>>
>  >>>
>  >>>>
>  >>>>
> https://download.copr.fedorainfracloud.org/results/pvalena/rubygems-testi...
>  >>>>
> https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/build/17...
>  >>>>
>  >>>> Error I'm getting is
>  >>>> ``` make: I.: No such file or directory ```
>  >>>>   note the missing -
>  >>>
>  >>>
>  >>> I think the issue is not in the `-` but in what is missing prior it.
>  >>> If you see this line, isn't there something strange? 
Right, I didn't realize :). Sorry for not investigating first, but I didn't have
enough time, and I wanted to give you feedback soon.

>  >>>
>  >>> ~~~
>  >>>
>  >>> I. -I/usr/include -I/usr/include/ruby/backward -I/usr/include -I.
>  >>> -DHAVE_OPENSSL_SSL_H -DHAVE_OPENSSL_ERR_H -DWITH_SSL
>  >>> -DBUILD_FOR_RUBY -DHAVE_RB_THREAD_CALL_WITHOUT_GVL
>  >>> -DHAVE_RB_THREAD_FD_SELECT -DHAVE_TYPE_RB_FDSET_T
>  >>> -DHAVE_RB_WAIT_FOR_SINGLE_FD -DHAVE_RB_TIME_NEW -DHAVE_INOTIFY_INIT
>  >>> -DHAVE_INOTIFY -DHAVE_WRITEV -DHAVE_PIPE2 -DHAVE_ACCEPT4
>  >>> -DHAVE_CONST_SOCK_CLOEXEC -DOS_UNIX -DHAVE_EPOLL_CREATE -DHAVE_EPOLL
>  >>> -DHAVE_CLOCK_GETTIME -DHAVE_CONST_CLOCK_MONOTONIC_RAW
>  >>> -DHAVE_CONST_CLOCK_MONOTONIC -fPIC -O2 -flto=auto -ffat-lto-objects
>  >>> -fexceptions -g -grecord-gcc-switches -pipe -Wall
>  >>> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
>  >>> -Wp,-D_GLIBCXX_ASSERTIONS
>  >>> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
>  >>> -fstack-protector-strong
>  >>> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
>  >>> -fasynchronous-unwind-tables -fstack-clash-protection
>  >>> -fcf-protection  -m64 -o binder.o -c binder.cpp
>  >>>
>  >>> ~~~
>  >>>
>  >>>
>  >>> For comparison, the same line from last official Fedora build:
>  >>>
>  >>>
>  >>> ~~~
>  >>>
>  >>> g++ -I. -I/usr/include -I/usr/include/ruby/backward -I/usr/include
>  >>> -I. -DHAVE_OPENSSL_SSL_H -DHAVE_OPENSSL_ERR_H -DWITH_SSL
>  >>> -DBUILD_FOR_RUBY -DHAVE_RB_THREAD_CALL_WITHOUT_GVL
>  >>> -DHAVE_RB_THREAD_FD_SELECT -DHAVE_TYPE_RB_FDSET_T
>  >>> -DHAVE_RB_WAIT_FOR_SINGLE_FD -DHAVE_RB_TIME_NEW -DHAVE_INOTIFY_INIT
>  >>> -DHAVE_INOTIFY -DHAVE_WRITEV -DHAVE_PIPE2 -DHAVE_ACCEPT4
>  >>> -DHAVE_CONST_SOCK_CLOEXEC -DOS_UNIX -DHAVE_EPOLL_CREATE -DHAVE_EPOLL
>  >>> -DHAVE_CLOCK_GETTIME -DHAVE_CONST_CLOCK_MONOTONIC_RAW
>  >>> -DHAVE_CONST_CLOCK_MONOTONIC -DHAVE_MAKE_PAIR    -fPIC -O2
>  >>> -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
>  >>> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
>  >>> -Wp,-D_GLIBCXX_ASSERTIONS
>  >>> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
>  >>> -fstack-protector-strong
>  >>> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
>  >>> -fasynchronous-unwind-tables -fstack-clash-protection
>  >>> -fcf-protection  -m64 -o binder.o -c binder.cpp
>  >>>
>  >>> ~~~
>  >>>
>  >>>
>  >>> If you checked the Makefile, these are the corresponding lines:
>  >>>
>  >>>
>  >>> ~~~
>  >>>
>  >>> .cpp.o:
>  >>>      $(ECHO) compiling $(<)
>  >>>      $(Q) $(CXX) $(INCFLAGS) $(CPPFLAGS) $(CXXFLAGS) $(COUTFLAG)$@
>  >>> -c $(CSRCFLAG)$<
>  >>>
>  >>> ~~~
>  >>>
>  >>>
>  >>> And
>  >>>
>  >>>
>  >>> ~~~
>  >>>
>  >>> CXX =
>  >>>
>  >>> ~~~
>  >>>
>  >>>
>  >>> So one of the reasons is that we don't have C++ compiler available
>  >>> during Ruby build and therefore there are not stored the appropriate
>  >>> values into RbConfig (I mildly remember, that there could have been
>  >>> also patch to remove the need for C++ or it was reported somewhere,
>  >>> but I don't remember more details).
>  >>>
>  >>> The other reason is that somebody changed something somewhere and
>  >>> apparently something relies on it. The question is what. I would
>  >>> appreciate if somebody helped me to understand what have changed.
>  >>>
>  >>> One could also expect, that the extconf.rb + mkmf would include
>  >>> check for compiler availability and let the compilation fail
>  >>> earlier, but this is not the case unfortunately. So if somebody
>  >>> could investigate, if eventmachine and possibly also other package
>  >>> could check on compiler availability, that could help to prevent
>  >>> non-obvious issues like this. 
Yes, that's strange, I know there was such a check, let me investigate.

>  >>>
>  >>> Checking the mkmf.log, it is also interesting to see, that most of
>  >>> the configuration check are done using `gcc`, while there also other
>  >>> checks:
>  >>>
>  >>> ~~~
>  >>>
>  >>> " -o conftest -I/usr/include -I/usr/include/ruby/backward
>  >>> -I/usr/include -I.     -O2 -flto=auto -ffat-lto-objects -fexceptions
>  >>> -g -grecord-gcc-switches -pipe -Wall -Werror=format-security
>  >>> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
>  >>> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
>  >>> -fstack-protector-strong
>  >>> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -mtune=generic
>  >>> -fasynchronous-unwind-tables -fstack-clash-protection
>  >>> -fcf-protection conftest.c  -L. -L/usr/lib64 -L. -Wl,-z,relro
>  >>> -Wl,--as-needed -Wl,-z,now
>  >>> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
>  >>> -fstack-protector-strong -rdynamic -Wl,-export-dynamic   -m64 -lssl
>  >>> -lcrypto -lcrypto -lssl -lruby -Wall -lm   -lc"
>  >>> checked program was:
>  >>> /* begin */
>  >>> 1: #include "ruby.h"
>  >>> 2:
>  >>> 3: int main() {return 0;}
>  >>> /* end */
>  >>>
>  >>> ~~~
>  >>>
>  >>> They are missing the `gcc` on the beginning and they appears to be
>  >>> silently ignored. But these corresponds to:
>  >>>
>  >>>
> https://github.com/eventmachine/eventmachine/blob/b50c135dfdd4e7b20c8e0b7...
>  >>>
>  >>>
>  >>>
> https://github.com/eventmachine/eventmachine/blob/b50c135dfdd4e7b20c8e0b7...
>  >>>
>  >>>
>  >>> So these are somehow expected to fail, but they should probably fail
>  >>> in different way.
>  >>>
>  >>>
>  >>> Vít
>  >>>
>  >>
>  >> So CONFIG["CXX"] is not yet set ( in /usr/lib64/ruby/rbconfig.rb on
>  >> x86_64) (see:
>  >>
> https://lists.fedoraproject.org/archives/list/[e-mail]...
>  >>
>  >> ) and still rubygem-eventmachine fails to find CXX compiler, while
>  >> rawhide ruby-libs rpm has CONFIG["CXX"] value.
>  >
>  
>  Thx for reminder :)
>  
>  
>  > Apparently this commit changed CXX value:
>  > https://github.com/ruby/ruby/commit/50b18e81295ad2d45975e4d8ea1e0c7e85140b97
>  >
>  
>  
>  This kind of commits does not make me happy :( While the intention is
>  good, they don't take into consideration any distribution. It is
>  tailored to the old fashion way of "download tarball & configure & make
>  & make install", everything runs on single machine :/
>  
>  Does anybody have a tip how to convince upstream, that this does not
>  scale? Does anybody want to ask upstream to revert this commit on my behalf? 
Sure, I can do the poking. I'll CC you as well.


Thanks all for the analysis!

Regards,
Pavel

>  
>  
>  Vít
>  
>  
>  >
>  > Regards,
>  > Mamoru
>  >

Ruby 3.0

[Pavel Valena]

----- Original Message -----
>  From: "Pavel Valena" <pvalena(a)redhat.com&gt;
>  To: "Ruby SIG mailing list" <ruby-sig(a)lists.fedoraproject.org&gt;
>  Sent: Friday, November 13, 2020 9:39:36 PM
>  Subject: Re: Ruby 3.0
>  
>  ----- Original Message -----
>  > From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
>  > To: ruby-sig(a)lists.fedoraproject.org
>  > Sent: Friday, November 13, 2020 2:23:55 PM
>  > Subject: Re: Ruby 3.0
>  > 
>  > 
>  > Dne 13. 11. 20 v 11:25 Mamoru TASAKA napsal(a):
>  > > Mamoru TASAKA wrote on 2020/11/13 19:18:
>  > >> Vít Ondruch wrote on 2020/11/13 17:46:
>  > >>>
>  > >>> Dne 13. 11. 20 v 3:56 Pavel Valena napsal(a):
>  > >>>> ----- Original Message -----
>  > >>>>> From: "Pavel Valena" <pvalena(a)redhat.com&gt;
>  > >>>>> To: "Dan Čermák"
> <dan.cermak(a)cgc-instruments.com&gt;
>  > >>>>> Cc: "Ruby SIG mailing list"
> <ruby-sig(a)lists.fedoraproject.org&gt;
>  > >>>>> Sent: Thursday, November 5, 2020 8:30:25 PM
>  > >>>>> Subject: Re: Ruby 3.0
>  > >>>>>
>  > >>>>> ----- Original Message -----
>  > >>>>>> From: "Dan Čermák"
> <dan.cermak(a)cgc-instruments.com&gt;
>  > >>>>>> To: "Vít Ondruch" <vondruch(a)redhat.com&gt;
>  > >>>>>> Cc: ruby-sig(a)lists.fedoraproject.org
>  > >>>>>> Sent: Thursday, November 5, 2020 4:41:46 PM
>  > >>>>>> Subject: Re: Ruby 3.0
>  > >>>>>>
>  > >>>>>> Hi Vít,
>  > >>>>>>
>  > >>>>>> Vít Ondruch <vondruch(a)redhat.com&gt; writes:
>  > >>>>>>
>  > >>>>>>> Hi all,
>  > >>>>>>>
>  > >>>>>>> Here is once again freshly updated Ruby. The changes
> are
>  > >>>>>>> available here:
>  > >>>>>>>
>  > >>>>>>>
> https://src.fedoraproject.org/rpms/ruby/pull-request/70
>  > >>>>>>>
>  > >>>>>>> and you can find the scratch build in Koji:
>  > >>>>>>>
>  > >>>>>>>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=54978639
>  > >>>>>>>
>  > >>>>>>>   From the notable changes, there is ongoing effort to
> gemify
>  > >>>>>>> StdLib.
>  > >>>>>>>
>  > >>>>>>> As always, please let me know if you encounter any
> issues with the
>  > >>>>>>> package.
>  > >>>> It seems I'm still not able to build gems like eventmachine:
>  > >>>
>  > >>>
>  > >>> I wonder what precisely is "gems like eventmachine"
>  
>  Sorry, I've made a mistake- eventmachine's error is different than before,
>  and now it's the only one of this nature (AFAIK).
>  
>  Current stats:
>  
>   113 failed-all.txt
>    - all failed logs
>  
>    29 failed-deps.txt
>    - missing dependent packages (Ruby 3.0 rebuild)
>  
>     3 failed-extens.txt
>    - extensions could not be built
>  
>     6 failed-rspec.txt
>    - rspec could not be installed
>  
>    75 failed-unknown.txt
>    - unknown reason of failure (I'm doing automatic rebases on this set of
>    packages as well, so the failure could be one of those)
>  
>  Now I'm working on those rspec ones (also testing enhanced rspec specs, which
>  probably caused this failure, PRs comming), as well as on the 'unknown'
>  errors. I'll keep you posted.
>  
>  > >>>
>  > >>>
>  > >>>>
>  > >>>>
> https://download.copr.fedorainfracloud.org/results/pvalena/rubygems-testi...
>  > >>>>
> https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/build/17...
>  > >>>>
>  > >>>> Error I'm getting is
>  > >>>> ``` make: I.: No such file or directory ```
>  > >>>>   note the missing -
>  > >>>
>  > >>>
>  > >>> I think the issue is not in the `-` but in what is missing prior it.
>  > >>> If you see this line, isn't there something strange?
>  
>  Right, I didn't realize :). Sorry for not investigating first, but I didn't
>  have enough time, and I wanted to give you feedback soon.
>   
Additionally, 'st.h' is missing for rubygem-ruby-libvirt: 

https://copr.fedorainfracloud.org/coprs/build/1768458

gcc -I. -I/usr/include -I/usr/include/ruby/backward -I/usr/include -I. 
-DRUBY_EXTCONF_H=\"extconf.h\"    -fPIC -O2 -flto=auto -ffat-lto-objects
-fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection  -m64 -o common.o -c
common.c
common.c:27:10: fatal error: st.h: No such file or directory
   27 | #include <st.h>
      |          ^~~~~~

>  > >>>
>  > >>> ~~~
>  > >>>
>  > >>> I. -I/usr/include -I/usr/include/ruby/backward -I/usr/include -I.
>  > >>> -DHAVE_OPENSSL_SSL_H -DHAVE_OPENSSL_ERR_H -DWITH_SSL
>  > >>> -DBUILD_FOR_RUBY -DHAVE_RB_THREAD_CALL_WITHOUT_GVL
>  > >>> -DHAVE_RB_THREAD_FD_SELECT -DHAVE_TYPE_RB_FDSET_T
>  > >>> -DHAVE_RB_WAIT_FOR_SINGLE_FD -DHAVE_RB_TIME_NEW -DHAVE_INOTIFY_INIT
>  > >>> -DHAVE_INOTIFY -DHAVE_WRITEV -DHAVE_PIPE2 -DHAVE_ACCEPT4
>  > >>> -DHAVE_CONST_SOCK_CLOEXEC -DOS_UNIX -DHAVE_EPOLL_CREATE -DHAVE_EPOLL
>  > >>> -DHAVE_CLOCK_GETTIME -DHAVE_CONST_CLOCK_MONOTONIC_RAW
>  > >>> -DHAVE_CONST_CLOCK_MONOTONIC -fPIC -O2 -flto=auto -ffat-lto-objects
>  > >>> -fexceptions -g -grecord-gcc-switches -pipe -Wall
>  > >>> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
>  > >>> -Wp,-D_GLIBCXX_ASSERTIONS
>  > >>> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
>  > >>> -fstack-protector-strong
>  > >>> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
>  > >>> -fasynchronous-unwind-tables -fstack-clash-protection
>  > >>> -fcf-protection  -m64 -o binder.o -c binder.cpp
>  > >>>
>  > >>> ~~~
>  > >>>
>  > >>>
>  > >>> For comparison, the same line from last official Fedora build:
>  > >>>
>  > >>>
>  > >>> ~~~
>  > >>>
>  > >>> g++ -I. -I/usr/include -I/usr/include/ruby/backward -I/usr/include
>  > >>> -I. -DHAVE_OPENSSL_SSL_H -DHAVE_OPENSSL_ERR_H -DWITH_SSL
>  > >>> -DBUILD_FOR_RUBY -DHAVE_RB_THREAD_CALL_WITHOUT_GVL
>  > >>> -DHAVE_RB_THREAD_FD_SELECT -DHAVE_TYPE_RB_FDSET_T
>  > >>> -DHAVE_RB_WAIT_FOR_SINGLE_FD -DHAVE_RB_TIME_NEW -DHAVE_INOTIFY_INIT
>  > >>> -DHAVE_INOTIFY -DHAVE_WRITEV -DHAVE_PIPE2 -DHAVE_ACCEPT4
>  > >>> -DHAVE_CONST_SOCK_CLOEXEC -DOS_UNIX -DHAVE_EPOLL_CREATE -DHAVE_EPOLL
>  > >>> -DHAVE_CLOCK_GETTIME -DHAVE_CONST_CLOCK_MONOTONIC_RAW
>  > >>> -DHAVE_CONST_CLOCK_MONOTONIC -DHAVE_MAKE_PAIR    -fPIC -O2
>  > >>> -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
>  > >>> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
>  > >>> -Wp,-D_GLIBCXX_ASSERTIONS
>  > >>> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
>  > >>> -fstack-protector-strong
>  > >>> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
>  > >>> -fasynchronous-unwind-tables -fstack-clash-protection
>  > >>> -fcf-protection  -m64 -o binder.o -c binder.cpp
>  > >>>
>  > >>> ~~~
>  > >>>
>  > >>>
>  > >>> If you checked the Makefile, these are the corresponding lines:
>  > >>>
>  > >>>
>  > >>> ~~~
>  > >>>
>  > >>> .cpp.o:
>  > >>>      $(ECHO) compiling $(<)
>  > >>>      $(Q) $(CXX) $(INCFLAGS) $(CPPFLAGS) $(CXXFLAGS) $(COUTFLAG)$@
>  > >>> -c $(CSRCFLAG)$<
>  > >>>
>  > >>> ~~~
>  > >>>
>  > >>>
>  > >>> And
>  > >>>
>  > >>>
>  > >>> ~~~
>  > >>>
>  > >>> CXX =
>  > >>>
>  > >>> ~~~
>  > >>>
>  > >>>
>  > >>> So one of the reasons is that we don't have C++ compiler available
>  > >>> during Ruby build and therefore there are not stored the appropriate
>  > >>> values into RbConfig (I mildly remember, that there could have been
>  > >>> also patch to remove the need for C++ or it was reported somewhere,
>  > >>> but I don't remember more details).
>  > >>>
>  > >>> The other reason is that somebody changed something somewhere and
>  > >>> apparently something relies on it. The question is what. I would
>  > >>> appreciate if somebody helped me to understand what have changed.
>  > >>>
>  > >>> One could also expect, that the extconf.rb + mkmf would include
>  > >>> check for compiler availability and let the compilation fail
>  > >>> earlier, but this is not the case unfortunately. So if somebody
>  > >>> could investigate, if eventmachine and possibly also other package
>  > >>> could check on compiler availability, that could help to prevent
>  > >>> non-obvious issues like this.
>  
>  Yes, that's strange, I know there was such a check, let me investigate.
>  
>  > >>>
>  > >>> Checking the mkmf.log, it is also interesting to see, that most of
>  > >>> the configuration check are done using `gcc`, while there also other
>  > >>> checks:
>  > >>>
>  > >>> ~~~
>  > >>>
>  > >>> " -o conftest -I/usr/include -I/usr/include/ruby/backward
>  > >>> -I/usr/include -I.     -O2 -flto=auto -ffat-lto-objects -fexceptions
>  > >>> -g -grecord-gcc-switches -pipe -Wall -Werror=format-security
>  > >>> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
>  > >>> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
>  > >>> -fstack-protector-strong
>  > >>> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -mtune=generic
>  > >>> -fasynchronous-unwind-tables -fstack-clash-protection
>  > >>> -fcf-protection conftest.c  -L. -L/usr/lib64 -L. -Wl,-z,relro
>  > >>> -Wl,--as-needed -Wl,-z,now
>  > >>> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
>  > >>> -fstack-protector-strong -rdynamic -Wl,-export-dynamic   -m64 -lssl
>  > >>> -lcrypto -lcrypto -lssl -lruby -Wall -lm   -lc"
>  > >>> checked program was:
>  > >>> /* begin */
>  > >>> 1: #include "ruby.h"
>  > >>> 2:
>  > >>> 3: int main() {return 0;}
>  > >>> /* end */
>  > >>>
>  > >>> ~~~
>  > >>>
>  > >>> They are missing the `gcc` on the beginning and they appears to be
>  > >>> silently ignored. But these corresponds to:
>  > >>>
>  > >>>
> https://github.com/eventmachine/eventmachine/blob/b50c135dfdd4e7b20c8e0b7...
>  > >>>
>  > >>>
>  > >>>
> https://github.com/eventmachine/eventmachine/blob/b50c135dfdd4e7b20c8e0b7...
>  > >>>
>  > >>>
>  > >>> So these are somehow expected to fail, but they should probably fail
>  > >>> in different way.
>  > >>>
>  > >>>
>  > >>> Vít
>  > >>>
>  > >>
>  > >> So CONFIG["CXX"] is not yet set ( in /usr/lib64/ruby/rbconfig.rb
> on
>  > >> x86_64) (see:
>  > >>
> https://lists.fedoraproject.org/archives/list/[e-mail]...
>  > >>
>  > >> ) and still rubygem-eventmachine fails to find CXX compiler, while
>  > >> rawhide ruby-libs rpm has CONFIG["CXX"] value.
>  > >
>  > 
>  > Thx for reminder :)
>  > 
>  > 
>  > > Apparently this commit changed CXX value:
>  > > https://github.com/ruby/ruby/commit/50b18e81295ad2d45975e4d8ea1e0c7e85140b97
>  > >
>  > 
>  > 
>  > This kind of commits does not make me happy :( While the intention is
>  > good, they don't take into consideration any distribution. It is
>  > tailored to the old fashion way of "download tarball & configure &
> make
>  > & make install", everything runs on single machine :/
>  > 
>  > Does anybody have a tip how to convince upstream, that this does not
>  > scale? Does anybody want to ask upstream to revert this commit on my
>  > behalf?
>  
>  Sure, I can do the poking. I'll CC you as well.
>  
>  
>  Thanks all for the analysis!
>  
>  Regards,
>  Pavel
>  
>  > 
>  > 
>  > Vít
>  > 
>  > 
>  > >
>  > > Regards,
>  > > Mamoru
>  > > 
-- 
Pavel Valena
Software Engineer, Red Hat
Brno, Czech Republic

Ruby 3.0

[Vít Ondruch]

Dne 13. 11. 20 v 22:18 Pavel Valena napsal(a):
>  Additionally, 'st.h' is missing for rubygem-ruby-libvirt:
>
>  https://copr.fedorainfracloud.org/coprs/build/1768458
>
>  gcc -I. -I/usr/include -I/usr/include/ruby/backward -I/usr/include -I. 
> -DRUBY_EXTCONF_H=\"extconf.h\"    -fPIC -O2 -flto=auto -ffat-lto-objects
> -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security
> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection  -m64 -o common.o -c
> common.c
>  common.c:27:10: fatal error: st.h: No such file or directory
>      27 | #include <st.h>
>         |          ^~~~~~ 

Comparing to Ruby 2.7, this is probably issue on ruby-libvirt side:


~~~

gcc -I. -I/usr/include -I/usr/include/ruby/backward -I/usr/include -I.  
-DRUBY_EXTCONF_H=\"extconf.h\"    -fPIC -O2 -flto -ffat-lto-objects 
-fexceptions -g -grecord-gcc-switches -pipe -Wall 
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
-m64 -mtune=generic -fasynchronous-unwind-tables 
-fstack-clash-protection -fcf-protection  -m64 -o common.o -c common.c
In file included from common.c:27:
/usr/include/ruby/backward/st.h:2:2: warning: #warning use "ruby/st.h" 
instead of bare "st.h" [-Wcpp]
     2 | #warning use "ruby/st.h" instead of bare "st.h"
       |  ^~~~~~~

~~~


Vít

Ruby 3.0

[Jun Aruga]

>  This kind of commits does not make me happy :( While the intention
> is
>  good, they don't take into consideration any distribution. It is
>  tailored to the old fashion way of "download tarball & configure & make
>  & make install", everything runs on single machine :/
>
>  Does anybody have a tip how to convince upstream, that this does not
>  scale? Does anybody want to ask upstream to revert this commit on my behalf? 
The solution is like this?

This commit's comment explains "AC_PROG_CXX sets $CXX to "g++" when it
purposefully finds that there is _no_ g++".
But for the implementation, the condition " there is no g++" is not considered.
I think reporting there is a mismatch between the explanation and
implementation, convinces the upstream.

So, we just need to add the condition "there is no g++".
In the case of Mamoru, there is g++ possibly on the environment. So,
he can avoid unset CXX.
https://github.com/ruby/ruby/commit/50b18e81295ad2d45975e4d8ea1e0c7e85140b97

```
$ git diff
diff --git a/configure.ac b/configure.ac
index 4e4a52f066..ecc70846d8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -190,7 +190,7 @@ AC_CHECK_TOOLS([STRIP],   [gstrip strip], [:])
 AS_IF([test ! $rb_test_CFLAGS], [AS_UNSET(CFLAGS)]); AS_UNSET(rb_test_CFLAGS)
 AS_IF([test ! $rb_test_CXXFLAGS], [AS_UNSET(CXXFLAGS)]);
AS_UNSET(rb_save_CXXFLAGS)

-AS_IF([test "${CXX}" = "g++" -a -z "${GXX}"], [
+AS_IF([test "${CXX}" = "g++" -a -z "${GXX}" && !
command -v g++ > /dev/null], [
     # AC_PROG_CXX sets $CXX to "g++" when it purposefully finds that there is
     # _no_ g++.  This brain-damaged design must be worked around.  Thankfully,
     # similar thing doesn't happen for AC_PROG_CC.
```

-- 
Jun | He - His - Him

Ruby 3.0

[Vít Ondruch]

Dne 19. 11. 20 v 16:52 Jun Aruga napsal(a):
> > This kind of commits does not make me happy :( While the
> intention is
> > good, they don't take into consideration any distribution. It is
> > tailored to the old fashion way of "download tarball & configure & make
> > & make install", everything runs on single machine :/
> >
> > Does anybody have a tip how to convince upstream, that this does not
> > scale? Does anybody want to ask upstream to revert this commit on my behalf?
>  The solution is like this?
>
>  This commit's comment explains "AC_PROG_CXX sets $CXX to "g++" when
> it
>  purposefully finds that there is _no_ g++".
>  But for the implementation, the condition " there is no g++" is not
> considered.
>  I think reporting there is a mismatch between the explanation and
>  implementation, convinces the upstream.
>
>  So, we just need to add the condition "there is no g++".
>  In the case of Mamoru, there is g++ possibly on the environment. So,
>  he can avoid unset CXX.
>  https://github.com/ruby/ruby/commit/50b18e81295ad2d45975e4d8ea1e0c7e85140b97
>
>  ```
>  $ git diff
>  diff --git a/configure.ac b/configure.ac
>  index 4e4a52f066..ecc70846d8 100644
>  --- a/configure.ac
>  +++ b/configure.ac
>  @@ -190,7 +190,7 @@ AC_CHECK_TOOLS([STRIP],   [gstrip strip], [:])
>    AS_IF([test ! $rb_test_CFLAGS], [AS_UNSET(CFLAGS)]); AS_UNSET(rb_test_CFLAGS)
>    AS_IF([test ! $rb_test_CXXFLAGS], [AS_UNSET(CXXFLAGS)]);
>  AS_UNSET(rb_save_CXXFLAGS)
>
>  -AS_IF([test "${CXX}" = "g++" -a -z "${GXX}"], [
>  +AS_IF([test "${CXX}" = "g++" -a -z "${GXX}" && !
> command -v g++ > /dev/null], [
>        # AC_PROG_CXX sets $CXX to "g++" when it purposefully finds that there
> is
>        # _no_ g++.  This brain-damaged design must be worked around.  Thankfully,
>        # similar thing doesn't happen for AC_PROG_CC.
>  ```
>  
This is not about fixing this specific case. This is more about the Ruby 
upstream misconception that the system configuration is static and it is 
the same when Ruby is build as when the extensions are installed. This 
is generally not true. So even if g++ was available during Ruby build, 
it might not be available during Eventmachine installation or vice versa.

In this case, the system used to build Ruby is completely different 
machine then the system where Eventmachine is build. The similar issue 
would be when user installed the Eventmachine via `gem install`. And it 
falls to the same category as [1].


Vít



[1] https://bugzilla.redhat.com/show_bug.cgi?id=1284684

Ruby 3.0

[Vít Ondruch]

Dne 19. 11. 20 v 18:22 Vít Ondruch napsal(a):
>  Dne 19. 11. 20 v 16:52 Jun Aruga napsal(a):
> >> This kind of commits does not make me happy :( While the intention is
> >> good, they don't take into consideration any distribution. It is
> >> tailored to the old fashion way of "download tarball & configure &
> make
> >> & make install", everything runs on single machine :/
> >>
> >> Does anybody have a tip how to convince upstream, that this does not
> >> scale? Does anybody want to ask upstream to revert this commit on my 
> >> behalf? 

I have opened this upstream ticket:

https://bugs.ruby-lang.org/issues/17337


Vít


> > The solution is like this?
> >
> > This commit's comment explains "AC_PROG_CXX sets $CXX to "g++"
> when it
> > purposefully finds that there is _no_ g++".
> > But for the implementation, the condition " there is no g++" is not 
> > considered.
> > I think reporting there is a mismatch between the explanation and
> > implementation, convinces the upstream.
> >
> > So, we just need to add the condition "there is no g++".
> > In the case of Mamoru, there is g++ possibly on the environment. So,
> > he can avoid unset CXX.
> > https://github.com/ruby/ruby/commit/50b18e81295ad2d45975e4d8ea1e0c7e85140b97 
> >
> >
> > ```
> > $ git diff
> > diff --git a/configure.ac b/configure.ac
> > index 4e4a52f066..ecc70846d8 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -190,7 +190,7 @@ AC_CHECK_TOOLS([STRIP],   [gstrip strip], [:])
> >   AS_IF([test ! $rb_test_CFLAGS], [AS_UNSET(CFLAGS)]); 
> > AS_UNSET(rb_test_CFLAGS)
> >   AS_IF([test ! $rb_test_CXXFLAGS], [AS_UNSET(CXXFLAGS)]);
> > AS_UNSET(rb_save_CXXFLAGS)
> >
> > -AS_IF([test "${CXX}" = "g++" -a -z "${GXX}"], [
> > +AS_IF([test "${CXX}" = "g++" -a -z "${GXX}" &&
> ! command -v g++ > 
> > /dev/null], [
> >       # AC_PROG_CXX sets $CXX to "g++" when it purposefully finds 
> > that there is
> >       # _no_ g++.  This brain-damaged design must be worked around.  
> > Thankfully,
> >       # similar thing doesn't happen for AC_PROG_CC.
> > ```
> >
>
>  This is not about fixing this specific case. This is more about the 
>  Ruby upstream misconception that the system configuration is static 
>  and it is the same when Ruby is build as when the extensions are 
>  installed. This is generally not true. So even if g++ was available 
>  during Ruby build, it might not be available during Eventmachine 
>  installation or vice versa.
>
>  In this case, the system used to build Ruby is completely different 
>  machine then the system where Eventmachine is build. The similar issue 
>  would be when user installed the Eventmachine via `gem install`. And 
>  it falls to the same category as [1].
>
>
>  Vít
>
>
>
>  [1] https://bugzilla.redhat.com/show_bug.cgi?id=1284684
>
>  _______________________________________________
>  ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org
>  To unsubscribe send an email to ruby-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/[e-mail]...

Ruby 3.0

[Vít Ondruch]

@Pavel, could you please try to add `%{set_build_flags}` call prior 
calling the `%gem_install`? That sets the `CXX` env variable. Does it help?


Vít



>  So CONFIG["CXX"] is not yet set ( in
> /usr/lib64/ruby/rbconfig.rb on 
>  x86_64) (see:
>
> https://lists.fedoraproject.org/archives/list/[e-mail]...
>
>
>  ) and still rubygem-eventmachine fails to find CXX compiler, while
>  rawhide ruby-libs rpm has CONFIG["CXX"] value.
>
>  Regards,
>  Mamoru
>  _______________________________________________
>  ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org
>  To unsubscribe send an email to ruby-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/[e-mail]...

Ruby 3.0

[Pavel Valena]

----- Original Message -----
>  From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
>  To: ruby-sig(a)lists.fedoraproject.org
>  Sent: Thursday, November 19, 2020 6:12:01 PM
>  Subject: Re: Ruby 3.0
>  
>  @Pavel, could you please try to add `%{set_build_flags}` call prior
>  calling the `%gem_install`? That sets the `CXX` env variable. Does it help? 
Sure, -

https://copr.fedorainfracloud.org/coprs/build/1775666
https://copr.fedorainfracloud.org/coprs/build/1775665

I'm afraid it didn't help. I've also tried setting CXX explicitly, and/or
adding this:

+sed -i "1i RbConfig::MAKEFILE_CONFIG['CXX'] = 'g++'" \
+  ext/extconf.rb

But it fails all the same. Here's another try, using CONFIG['CXX'] =
'g++':

https://copr.fedorainfracloud.org/coprs/build/1775762

Pavel

>  
>  
>  Vít
>  
>  
>  
>  > So CONFIG["CXX"] is not yet set ( in /usr/lib64/ruby/rbconfig.rb on
>  > x86_64) (see:
>  >
> https://lists.fedoraproject.org/archives/list/[e-mail]...
>  >
>  > ) and still rubygem-eventmachine fails to find CXX compiler, while
>  > rawhide ruby-libs rpm has CONFIG["CXX"] value.
>  >
>  > Regards,
>  > Mamoru

Ruby 3.0

[Vít Ondruch]

What if we provided `%{ruby_vendorlibdir}/rbconfig.rb`, which would fix 
the `CXX` as well as the rhbz#1284684? WDYT?


Vít



Dne 20. 11. 20 v 1:59 Pavel Valena napsal(a):
>  ----- Original Message -----
> > From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
> > To: ruby-sig(a)lists.fedoraproject.org
> > Sent: Thursday, November 19, 2020 6:12:01 PM
> > Subject: Re: Ruby 3.0
> >
> > @Pavel, could you please try to add `%{set_build_flags}` call prior
> > calling the `%gem_install`? That sets the `CXX` env variable. Does it help?
>  Sure, -
>
>  https://copr.fedorainfracloud.org/coprs/build/1775666
>  https://copr.fedorainfracloud.org/coprs/build/1775665
>
>  I'm afraid it didn't help. I've also tried setting CXX explicitly, and/or
> adding this:
>
>  +sed -i "1i RbConfig::MAKEFILE_CONFIG['CXX'] = 'g++'" \
>  +  ext/extconf.rb
>
>  But it fails all the same. Here's another try, using CONFIG['CXX'] =
> 'g++':
>
>  https://copr.fedorainfracloud.org/coprs/build/1775762
>
>  Pavel
>
> >
> > Vít
> >
> >
> >
> >> So CONFIG["CXX"] is not yet set ( in /usr/lib64/ruby/rbconfig.rb on
> >> x86_64) (see:
> >>
> https://lists.fedoraproject.org/archives/list/[e-mail]...
> >>
> >> ) and still rubygem-eventmachine fails to find CXX compiler, while
> >> rawhide ruby-libs rpm has CONFIG["CXX"] value.
> >>
> >> Regards,
> >> Mamoru
>  _______________________________________________
>  ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org
>  To unsubscribe send an email to ruby-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/[e-mail]...

Ruby 3.0

[Pavel Valena]

----- Original Message -----
>  Sent: Friday, November 20, 2020 10:51:46 AM
>  Subject: Re: Ruby 3.0
>  
>  What if we provided `%{ruby_vendorlibdir}/rbconfig.rb`, which would fix
>  the `CXX` as well as the rhbz#1284684? WDYT? 
I'm not entirely sure how that'd work TBH.

Would it override the original `rbconfig.rb`? Would it just override some entries? Or
completely replace it?

What's the advantage compared to modifying `rbconfig.rb`?

Anyway, if unsure, is there something (prefered solution) I could test at least? (I'm
not sure what's the best way to address that issue- more bellow.)

I don't feel like just simply overriding `rbconfig.rb` file in `%install` for ruby.
Also I'm not sure what would be the implications? (Apart from those test packages
building again.)

>  
>  
>  Vít
>  
>  
>  
>  Dne 20. 11. 20 v 1:59 Pavel Valena napsal(a):
>  > ----- Original Message -----
>  >> From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
>  >> To: ruby-sig(a)lists.fedoraproject.org
>  >> Sent: Thursday, November 19, 2020 6:12:01 PM
>  >> Subject: Re: Ruby 3.0
>  >>
>  >> @Pavel, could you please try to add `%{set_build_flags}` call prior
>  >> calling the `%gem_install`? That sets the `CXX` env variable. Does it
>  >> help?
>  > Sure, -
>  >
>  > https://copr.fedorainfracloud.org/coprs/build/1775666
>  > https://copr.fedorainfracloud.org/coprs/build/1775665
>  >
>  > I'm afraid it didn't help. I've also tried setting CXX explicitly,
> and/or
>  > adding this:
>  >
>  > +sed -i "1i RbConfig::MAKEFILE_CONFIG['CXX'] = 'g++'" \
>  > +  ext/extconf.rb
>  >
>  > But it fails all the same. Here's another try, using CONFIG['CXX'] =
> 'g++':
>  >
>  > https://copr.fedorainfracloud.org/coprs/build/1775762 
This one has failed as well. Any ideas on what I can modify in the gem package build to
make it work? (Without recreating whole `rbconfig.rb`.)

Regards,
Pavel

>  >
>  > Pavel
>  >
>  >>
>  >> Vít
>  >>
>  >>
>  >>
>  >>> So CONFIG["CXX"] is not yet set ( in /usr/lib64/ruby/rbconfig.rb
> on
>  >>> x86_64) (see:
>  >>>
> https://lists.fedoraproject.org/archives/list/[e-mail]...
>  >>>
>  >>> ) and still rubygem-eventmachine fails to find CXX compiler, while
>  >>> rawhide ruby-libs rpm has CONFIG["CXX"] value.
>  >>>
>  >>> Regards,
>  >>> Mamoru

Ruby 3.0

[Vít Ondruch]

Dne 20. 11. 20 v 17:02 Pavel Valena napsal(a):
>  ----- Original Message -----
> > Sent: Friday, November 20, 2020 10:51:46 AM
> > Subject: Re: Ruby 3.0
> >
> > What if we provided `%{ruby_vendorlibdir}/rbconfig.rb`, which would fix
> > the `CXX` as well as the rhbz#1284684? WDYT?
>  I'm not entirely sure how that'd work TBH.
>
>  Would it override the original `rbconfig.rb`? Would it just override some entries? Or
> completely replace it? 

The original rbconfig.rb would stay in place. But the `vendorlibdir` 
gets precedence on load patch, so it would be loaded first, later 
loading the original rbconfig and modifying what is necessary. It could 
possibly return values according to the current setup, i.e. provide 
`CONFIG['CXX']` when c++ compiler is installed, modifying the 
configuration options depending if the rpm-redhat-config is installed etc.


>  What's the advantage compared to modifying `rbconfig.rb`? 

Modifying anything is problematic. Sed silently fails, patch fails to 
apply, etc ... But it would be options of course.


>  Anyway, if unsure, is there something (prefered solution) I could test at least? (I'm
> not sure what's the best way to address that issue- more bellow.)
>
>  I don't feel like just simply overriding `rbconfig.rb` file in `%install` for ruby.
> Also I'm not sure what would be the implications? (Apart from those test packages
> building again.)
>
> >
> > Vít
> >
> >
> >
> > Dne 20. 11. 20 v 1:59 Pavel Valena napsal(a):
> >> ----- Original Message -----
> >>> From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
> >>> To: ruby-sig(a)lists.fedoraproject.org
> >>> Sent: Thursday, November 19, 2020 6:12:01 PM
> >>> Subject: Re: Ruby 3.0
> >>>
> >>> @Pavel, could you please try to add `%{set_build_flags}` call prior
> >>> calling the `%gem_install`? That sets the `CXX` env variable. Does it
> >>> help?
> >> Sure, -
> >>
> >> https://copr.fedorainfracloud.org/coprs/build/1775666
> >> https://copr.fedorainfracloud.org/coprs/build/1775665
> >>
> >> I'm afraid it didn't help. I've also tried setting CXX explicitly,
> and/or
> >> adding this:
> >>
> >> +sed -i "1i RbConfig::MAKEFILE_CONFIG['CXX'] = 'g++'"
> \
> >> +  ext/extconf.rb
> >>
> >> But it fails all the same. Here's another try, using CONFIG['CXX'] =
> 'g++':
> >>
> >> https://copr.fedorainfracloud.org/coprs/build/1775762
>  This one has failed as well. Any ideas on what I can modify in the gem package build to
> make it work? (Without recreating whole `rbconfig.rb`.) 

There are two extensions in Eventmachine. You have fixed extconf.rb just 
for one (should you choose go this path).


Vít


>  Regards,
>  Pavel
>
> >> Pavel
> >>
> >>> Vít
> >>>
> >>>
> >>>
> >>>> So CONFIG["CXX"] is not yet set ( in
> /usr/lib64/ruby/rbconfig.rb on
> >>>> x86_64) (see:
> >>>>
> https://lists.fedoraproject.org/archives/list/[e-mail]...
> >>>>
> >>>> ) and still rubygem-eventmachine fails to find CXX compiler, while
> >>>> rawhide ruby-libs rpm has CONFIG["CXX"] value.
> >>>>
> >>>> Regards,
> >>>> Mamoru
>  _______________________________________________
>  ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org
>  To unsubscribe send an email to ruby-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/[e-mail]...

Ruby 3.0

[Vít Ondruch]

Hi,

Another ~2 weeks passed, so here is yet another updated Ruby 3.0 
snapshot. The changes are available here:

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

And the build is running here:

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

I have not noticed anything particularly interesting, unless you are 
interested in `un` library, which was extracted as default gem. As 
always, please give it a try and let me know if you have any issues.

I think I should also put together change proposal ...


Vít

Ruby 3.0

[Vít Ondruch]

Dne 20. 11. 20 v 15:07 Vít Ondruch napsal(a):
>  Hi,
>
>  Another ~2 weeks passed, so here is yet another updated Ruby 3.0 
>  snapshot. The changes are available here:
>
>  https://src.fedoraproject.org/rpms/ruby/pull-request/70
>
>  And the build is running here:
>
>  https://koji.fedoraproject.org/koji/taskinfo?taskID=55942586 

It hands in test suite, I need to investigate this :/


Vít


>  I have not noticed anything particularly interesting, unless you are 
>  interested in `un` library, which was extracted as default gem. As 
>  always, please give it a try and let me know if you have any issues.
>
>  I think I should also put together change proposal ...
>
>
>  Vít
>
>
>
>
>  _______________________________________________
>  ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org
>  To unsubscribe send an email to ruby-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/[e-mail]...

Ruby 3.0

[Vít Ondruch]

Dne 20. 11. 20 v 16:21 Vít Ondruch napsal(a):
>  Dne 20. 11. 20 v 15:07 Vít Ondruch napsal(a):
> > Hi,
> >
> > Another ~2 weeks passed, so here is yet another updated Ruby 3.0 
> > snapshot. The changes are available here:
> >
> > https://src.fedoraproject.org/rpms/ruby/pull-request/70
> >
> > And the build is running here:
> >
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=55942586
>
>
>  It hands in test suite, I need to investigate this :/
>  
New build is running here after I disabled one test case:


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


Vít



>  Vít
>
>
> >
> > I have not noticed anything particularly interesting, unless you are 
> > interested in `un` library, which was extracted as default gem. As 
> > always, please give it a try and let me know if you have any issues.
> >
> > I think I should also put together change proposal ...
> >
> >
> > Vít
> >
> >
> >
> >
> > _______________________________________________
> > 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/[e-mail]...
>
>  _______________________________________________
>  ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org
>  To unsubscribe send an email to ruby-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/[e-mail]...

Ruby 3.0

[Vít Ondruch]

Hi everybody,

Here is another snapshot build:

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

All changes are in private-ruby-3.0 branch.

I think I should be able to prepare one more snapshot tomorrow and that 
should be it prior Ruby 3.0 release. This is the last change to upstream 
your changes ;)


Vít

Ruby 3.0

[Pavel Valena]

----- Original Message -----
>  From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
>  To: ruby-sig(a)lists.fedoraproject.org
>  Sent: Tuesday, December 22, 2020 1:16:12 PM
>  Subject: Re: Ruby 3.0
>  
>  Hi everybody,
>  
>  Here is another snapshot build:
>  
>  https://koji.fedoraproject.org/koji/taskinfo?taskID=58026964 
Hello,

TL;DR: Build failures occuring with Ruby 3.0.
Important: please check the end of my email, even if your package does not fail.

I've rebuilt ruby in my COPR, and with it the rubygem packages. I've analyzed
changes needed / builds failing, as follows.
I've focused on packages, which depend on ruby-devel, and also some additional
failures detected while doing mass test-rebuilds. Sucessful rebuilds are not mentioned.

You can look up the package build in pvalena/rubygems-testing COPR, f.e. for
eventmachine:
 
https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/package/...


This error message (in tests):
```
<internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in
`require': /usr/lib64/gems/ruby/glib2-3.4.3/glib2.so: undefined symbol: rb_cData -
/usr/lib64/gems/ruby/glib2-3.4.3/glib2.so (LoadError)
        from
<internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in
`require'
        from /usr/share/gems/gems/glib2-3.4.3/lib/glib2.rb:117:in `<top
(required)>'
        from
<internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in
`require'
        from
/usr/share/gems/gems/gobject-introspection-3.4.3/lib/gobject-introspection.rb:17:in
`<top (required)>'
```
  rubygem-atk
  rubygem-gio2
  rubygem-gobject-introspection
  rubygem-gstreamer


Bootstrapping needed (I didn't have time to resolve the bootstrap for my test repo):
  rubygem-cairo
  rubygem-cairo-gobject
  rubygem-gdk3
  rubygem-pango
  rubygem-poppler
  rubygem-gdk_pixbuf2
  rubygem-goocanvas1
  rubygem-goocanvas
  rubygem-gtk2
  rubygem-gtk3
  rubygem-gtksourceview2
  rubygem-gtksourceview3
  rubygem-rsvg2
  rubygem-vte3
  rubygem-vte


Webrick needed (new package in review):
  rubygem-ethon
  rubygem-curb
  rubygem-httpclient
  rubygem-typhoeus
  rubygem-rack
  rubygem-jekyll
  rubygem-excon
  rubygem-rubygems-mirror
  rubygem-mechanize
  rubygem-yard


Test failure (inspection needed):
  rubygem-eventmachine
  rubygem-mysql2

```
NoMethodError: undefined method `encode' for URI:Module                               
                │
```
  rubygem-sup


```
Error: test_range(Func): FrozenError: can't modify frozen Range: 0..0 
```
  rubygem-ox


gem build issues (with extension):
  rubygem-posix-spawn
  rubygem-syck


```
TypeError: no implicit conversion of Hash into Integer
```
  rubygem-raindrops


https://src.fedoraproject.org/rpms/rubygem-ruby-libvirt/pull-request/2
  rubygem-ruby-libvirt


```
LoadError: cannot load such file -- rexml/
```
  rubygem-webrobots
  rubygem-selenium-webdriver
  rubygem-faraday
  rubygem-rest-client
  rubygem-mini_magick
  rubygem-webmock
  rubygem-crack
  rubygem-activesupport
  rubygem-cucumber-core
  rubygem-maruku
  rubygem-actionpack
  rubygem-actionmailbox
  rubygem-kramdown-parser-gfm


>  
>  All changes are in private-ruby-3.0 branch.
>  
>  I think I should be able to prepare one more snapshot tomorrow and that
>  should be it prior Ruby 3.0 release. This is the last change to upstream
>  your changes ;) 
I'm preparing pull requests with changes on src.fedoraproject.org for some of the
packages. Some of them are not created yet. Please check it before you start fixing the
package yourself.

One question for the "sucessful" rebuilds, for all: should I create pull
requests with the rebuild release bump?

Benefits are:
  - Can be subsequently picked up, after merge (or "LGTM", with permissions
granted to me), and automatically rebuilt by my script.
  - CI runs, either custom or at least simple-koji-ci. Also, you know it was pre-tested by
me in COPR.
  - Less work for packagers.)

Which packages? (Failed packages included.)
  https://gist.github.com/pvalena/422c77868e929fe38c8bc325a765f8a8

Generated using script:
  https://gist.github.com/pvalena/76560097815fe6544c9bc4905e6bf7a1
  

Regards,
Pavel

>  
>  
>  Vít
>  
>

Ruby 3.0

[Vít Ondruch]

Dne 23. 12. 20 v 11:06 Pavel Valena napsal(a):
>  ----- Original Message -----
> > From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
> > To: ruby-sig(a)lists.fedoraproject.org
> > Sent: Tuesday, December 22, 2020 1:16:12 PM
> > Subject: Re: Ruby 3.0
> >
> > Hi everybody,
> >
> > Here is another snapshot build:
> >
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=58026964
>  Hello,
>
>  TL;DR: Build failures occuring with Ruby 3.0.
>  Important: please check the end of my email, even if your package does not fail. 

Nice, thx a lot!


>  I've rebuilt ruby in my COPR, and with it the rubygem packages. I've analyzed
> changes needed / builds failing, as follows.
>  I've focused on packages, which depend on ruby-devel, and also some additional
> failures detected while doing mass test-rebuilds. Sucessful rebuilds are not mentioned.
>
>  You can look up the package build in pvalena/rubygems-testing COPR, f.e. for
> eventmachine:
>    
> https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/package/...
>
>
>  This error message (in tests):
>  ```
>  <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in
> `require': /usr/lib64/gems/ruby/glib2-3.4.3/glib2.so: undefined symbol: rb_cData -
> /usr/lib64/gems/ruby/glib2-3.4.3/glib2.so (LoadError)
>           from
> <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in
> `require'
>           from /usr/share/gems/gems/glib2-3.4.3/lib/glib2.rb:117:in `<top
> (required)>'
>           from
> <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in
> `require'
>           from
> /usr/share/gems/gems/gobject-introspection-3.4.3/lib/gobject-introspection.rb:17:in
> `<top (required)>'
>  ```
>     rubygem-atk
>     rubygem-gio2
>     rubygem-gobject-introspection
>     rubygem-gstreamer
>
>
>  Bootstrapping needed (I didn't have time to resolve the bootstrap for my test repo):
>     rubygem-cairo
>     rubygem-cairo-gobject
>     rubygem-gdk3
>     rubygem-pango
>     rubygem-poppler
>     rubygem-gdk_pixbuf2
>     rubygem-goocanvas1
>     rubygem-goocanvas
>     rubygem-gtk2
>     rubygem-gtk3
>     rubygem-gtksourceview2
>     rubygem-gtksourceview3
>     rubygem-rsvg2
>     rubygem-vte3
>     rubygem-vte
>
>
>  Webrick needed (new package in review):
>     rubygem-ethon
>     rubygem-curb
>     rubygem-httpclient
>     rubygem-typhoeus
>     rubygem-rack
>     rubygem-jekyll
>     rubygem-excon
>     rubygem-rubygems-mirror
>     rubygem-mechanize
>     rubygem-yard
>
>
>  Test failure (inspection needed):
>     rubygem-eventmachine
>     rubygem-mysql2
>
>  ```
>  NoMethodError: undefined method `encode' for URI:Module                              
>                  │
>  ```
>     rubygem-sup
>
>
>  ```
>  Error: test_range(Func): FrozenError: can't modify frozen Range: 0..0
>  ```
>     rubygem-ox
>
>
>  gem build issues (with extension):
>     rubygem-posix-spawn
>     rubygem-syck
>
>
>  ```
>  TypeError: no implicit conversion of Hash into Integer
>  ```
>     rubygem-raindrops
>
>
>  https://src.fedoraproject.org/rpms/rubygem-ruby-libvirt/pull-request/2
>     rubygem-ruby-libvirt
>
>
>  ```
>  LoadError: cannot load such file -- rexml/
>  ```
>     rubygem-webrobots
>     rubygem-selenium-webdriver
>     rubygem-faraday
>     rubygem-rest-client
>     rubygem-mini_magick
>     rubygem-webmock
>     rubygem-crack
>     rubygem-activesupport
>     rubygem-cucumber-core
>     rubygem-maruku
>     rubygem-actionpack
>     rubygem-actionmailbox
>     rubygem-kramdown-parser-gfm 

It would be helpful to open upstream tickets for these, because 
upstreams will need to cope with this as well. While ReXml is going to 
be available with all Ruby installations, it has to be mentioned in 
.gemspec files otherwise Bundler won't load it. Would you mind to check 
with upstreams prior we take any action?

And there are certainly upstream which are dealing with the issues already:

https://github.com/rails/rails/commit/f624ed09abba4a0bae64eb699c9fc2e3f9b...

In such cases we should cherry pick the patches rather then blindly 
adding the dependencies.


> > All changes are in private-ruby-3.0 branch.
> >
> > I think I should be able to prepare one more snapshot tomorrow and that
> > should be it prior Ruby 3.0 release. This is the last change to upstream
> > your changes ;)
>  I'm preparing pull requests with changes on src.fedoraproject.org for some of the
> packages. Some of them are not created yet. Please check it before you start fixing the
> package yourself.
>
>  One question for the "sucessful" rebuilds, for all: should I create pull
> requests with the rebuild release bump? 

I don't think it would help, because creating PRs now won't test the 
packages against Ruby 3.0 and at the time of mass rebuild, it would slow 
down the rebuild.


Vít


>  Benefits are:
>     - Can be subsequently picked up, after merge (or "LGTM", with permissions
> granted to me), and automatically rebuilt by my script.
>     - CI runs, either custom or at least simple-koji-ci. Also, you know it was pre-tested
> by me in COPR.
>     - Less work for packagers.)
>
>  Which packages? (Failed packages included.)
>     https://gist.github.com/pvalena/422c77868e929fe38c8bc325a765f8a8
>
>  Generated using script:
>     https://gist.github.com/pvalena/76560097815fe6544c9bc4905e6bf7a1
>     
>
>  Regards,
>  Pavel
>
> >
> > Vít
> >
> >
>  _______________________________________________
>  ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org
>  To unsubscribe send an email to ruby-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/[e-mail]...

Ruby 3.0

[Vít Ondruch]

Dne 23. 12. 20 v 11:47 Vít Ondruch napsal(a):
>  Dne 23. 12. 20 v 11:06 Pavel Valena napsal(a):
> > ----- Original Message -----
> >> From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
> >> To: ruby-sig(a)lists.fedoraproject.org
> >> Sent: Tuesday, December 22, 2020 1:16:12 PM
> >> Subject: Re: Ruby 3.0
> >>
> >> Hi everybody,
> >>
> >> Here is another snapshot build:
> >>
> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=58026964
> > Hello,
> >
> > TL;DR: Build failures occuring with Ruby 3.0.
> > Important: please check the end of my email, even if your package 
> > does not fail.
>
>
>  Nice, thx a lot!
>
>
> >
> > I've rebuilt ruby in my COPR, and with it the rubygem packages. I've 
> > analyzed changes needed / builds failing, as follows.
> > I've focused on packages, which depend on ruby-devel, and also some 
> > additional failures detected while doing mass test-rebuilds. 
> > Sucessful rebuilds are not mentioned.
> >
> > You can look up the package build in pvalena/rubygems-testing COPR, 
> > f.e. for eventmachine:
> >
> https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/package/...
> >
> >
> > This error message (in tests):
> > ```
> > <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in 
> > `require': /usr/lib64/gems/ruby/glib2-3.4.3/glib2.so: undefined 
> > symbol: rb_cData - /usr/lib64/gems/ruby/glib2-3.4.3/glib2.so (LoadError)
> >          from 
> > <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in 
> > `require'
> >          from /usr/share/gems/gems/glib2-3.4.3/lib/glib2.rb:117:in 
> > `<top (required)>'
> >          from 
> > <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in 
> > `require'
> >          from 
> > /usr/share/gems/gems/gobject-introspection-3.4.3/lib/gobject-introspection.rb:17:in 
> > `<top (required)>'
> > ```
> >    rubygem-atk
> >    rubygem-gio2
> >    rubygem-gobject-introspection
> >    rubygem-gstreamer
> >
> >
> > Bootstrapping needed (I didn't have time to resolve the bootstrap for 
> > my test repo):
> >    rubygem-cairo
> >    rubygem-cairo-gobject
> >    rubygem-gdk3
> >    rubygem-pango
> >    rubygem-poppler
> >    rubygem-gdk_pixbuf2
> >    rubygem-goocanvas1
> >    rubygem-goocanvas
> >    rubygem-gtk2
> >    rubygem-gtk3
> >    rubygem-gtksourceview2
> >    rubygem-gtksourceview3
> >    rubygem-rsvg2
> >    rubygem-vte3
> >    rubygem-vte
> >
> >
> > Webrick needed (new package in review):
> >    rubygem-ethon
> >    rubygem-curb
> >    rubygem-httpclient
> >    rubygem-typhoeus
> >    rubygem-rack
> >    rubygem-jekyll
> >    rubygem-excon
> >    rubygem-rubygems-mirror
> >    rubygem-mechanize
> >    rubygem-yard
> >
> >
> > Test failure (inspection needed):
> >    rubygem-eventmachine
> >    rubygem-mysql2
> >
> > ```
> > NoMethodError: undefined method `encode' for 
> > URI:Module                                                │
> > ```
> >    rubygem-sup
> >
> >
> > ```
> > Error: test_range(Func): FrozenError: can't modify frozen Range: 0..0
> > ```
> >    rubygem-ox
> >
> >
> > gem build issues (with extension):
> >    rubygem-posix-spawn
> >    rubygem-syck
> >
> >
> > ```
> > TypeError: no implicit conversion of Hash into Integer
> > ```
> >    rubygem-raindrops
> >
> >
> > https://src.fedoraproject.org/rpms/rubygem-ruby-libvirt/pull-request/2
> >    rubygem-ruby-libvirt
> >
> >
> > ```
> > LoadError: cannot load such file -- rexml/
> > ```
> >    rubygem-webrobots
> >    rubygem-selenium-webdriver
> >    rubygem-faraday
> >    rubygem-rest-client
> >    rubygem-mini_magick
> >    rubygem-webmock
> >    rubygem-crack
> >    rubygem-activesupport
> >    rubygem-cucumber-core
> >    rubygem-maruku
> >    rubygem-actionpack
> >    rubygem-actionmailbox
> >    rubygem-kramdown-parser-gfm
>
>
>  It would be helpful to open upstream tickets for these, because 
>  upstreams will need to cope with this as well. While ReXml is going to 
>  be available with all Ruby installations, it has to be mentioned in 
>  .gemspec files otherwise Bundler won't load it. Would you mind to 
>  check with upstreams prior we take any action?
>
>  And there are certainly upstream which are dealing with the issues 
>  already:
>
>  https://github.com/rails/rails/commit/f624ed09abba4a0bae64eb699c9fc2e3f9b... 
>
>
>  In such cases we should cherry pick the patches rather then blindly 
>  adding the dependencies.
>
>
> >
> >
> >> All changes are in private-ruby-3.0 branch.
> >>
> >> I think I should be able to prepare one more snapshot tomorrow and that
> >> should be it prior Ruby 3.0 release. This is the last change to 
> >> upstream
> >> your changes ;)
> > I'm preparing pull requests with changes on src.fedoraproject.org for 
> > some of the packages. Some of them are not created yet. Please check 
> > it before you start fixing the package yourself.
> >
> > One question for the "sucessful" rebuilds, for all: should I create 
> > pull requests with the rebuild release bump?
>
>
>  I don't think it would help, because creating PRs now won't test the 
>  packages against Ruby 3.0 and at the time of mass rebuild, it would 
>  slow down the rebuild.
>
>
>  Vít
>
>
> >
> > Benefits are:
> >    - Can be subsequently picked up, after merge (or "LGTM", with 
> > permissions granted to me), and automatically rebuilt by my script.
> >    - CI runs, either custom or at least simple-koji-ci. Also, you 
> > know it was pre-tested by me in COPR.
> >    - Less work for packagers.)
> >
> > Which packages? (Failed packages included.)
> > https://gist.github.com/pvalena/422c77868e929fe38c8bc325a765f8a8 

BTW I have updated rubygem-bindex, so that should be fine and orphaned 
rubygem-debug_inspector, since we don't need it anymore (it used to be 
dependency of rubygem-web-console).


Vít


> >
> > Generated using script:
> > https://gist.github.com/pvalena/76560097815fe6544c9bc4905e6bf7a1
> >
> > Regards,
> > Pavel
> >
> >>
> >> Vít
> >>
> >>
> > _______________________________________________
> > ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org
> > To unsubscribe send an email to ruby-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/[e-mail]...
>
>  _______________________________________________
>  ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org
>  To unsubscribe send an email to ruby-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/[e-mail]...

Ruby 3.0

[Pavel Valena]

----- Original Message -----
>  Sent: Wednesday, December 23, 2020 11:47:24 AM
>  Subject: Re: Ruby 3.0
>  
>  
>  Dne 23. 12. 20 v 11:06 Pavel Valena napsal(a):
>  > ----- Original Message -----
>  >> From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
>  >> To: ruby-sig(a)lists.fedoraproject.org
>  >> Sent: Tuesday, December 22, 2020 1:16:12 PM
>  >> Subject: Re: Ruby 3.0
>  >>
>  >> Hi everybody,
>  >>
>  >> Here is another snapshot build:
>  >>
>  >> https://koji.fedoraproject.org/koji/taskinfo?taskID=58026964
>  > Hello,
>  >
>  > TL;DR: Build failures occuring with Ruby 3.0.
>  > Important: please check the end of my email, even if your package does not
>  > fail.
>  
>  
>  Nice, thx a lot!
>  
>  
>  >
>  > I've rebuilt ruby in my COPR, and with it the rubygem packages. I've
>  > analyzed changes needed / builds failing, as follows.
>  > I've focused on packages, which depend on ruby-devel, and also some
>  > additional failures detected while doing mass test-rebuilds. Sucessful
>  > rebuilds are not mentioned.
>  >
>  > You can look up the package build in pvalena/rubygems-testing COPR, f.e.
>  > for eventmachine:
>  >   
> https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/package/...
>  >
>  >
>  > This error message (in tests):
>  > ```
>  > <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in
>  > `require': /usr/lib64/gems/ruby/glib2-3.4.3/glib2.so: undefined symbol:
>  > rb_cData - /usr/lib64/gems/ruby/glib2-3.4.3/glib2.so (LoadError)
>  >          from
>  >         
> <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in
>  >          `require'
>  >          from /usr/share/gems/gems/glib2-3.4.3/lib/glib2.rb:117:in `<top
>  >          (required)>'
>  >          from
>  >         
> <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in
>  >          `require'
>  >          from
>  >         
> /usr/share/gems/gems/gobject-introspection-3.4.3/lib/gobject-introspection.rb:17:in
>  >          `<top (required)>'
>  > ```
>  >    rubygem-atk
>  >    rubygem-gio2
>  >    rubygem-gobject-introspection
>  >    rubygem-gstreamer
>  >
>  >
>  > Bootstrapping needed (I didn't have time to resolve the bootstrap for my
>  > test repo):
>  >    rubygem-cairo
>  >    rubygem-cairo-gobject
>  >    rubygem-gdk3
>  >    rubygem-pango
>  >    rubygem-poppler
>  >    rubygem-gdk_pixbuf2
>  >    rubygem-goocanvas1
>  >    rubygem-goocanvas
>  >    rubygem-gtk2
>  >    rubygem-gtk3
>  >    rubygem-gtksourceview2
>  >    rubygem-gtksourceview3
>  >    rubygem-rsvg2
>  >    rubygem-vte3
>  >    rubygem-vte
>  >
>  >
>  > Webrick needed (new package in review):
>  >    rubygem-ethon
>  >    rubygem-curb
>  >    rubygem-httpclient
>  >    rubygem-typhoeus
>  >    rubygem-rack
>  >    rubygem-jekyll
>  >    rubygem-excon
>  >    rubygem-rubygems-mirror
>  >    rubygem-mechanize
>  >    rubygem-yard
>  >
>  >
>  > Test failure (inspection needed):
>  >    rubygem-eventmachine
>  >    rubygem-mysql2
>  >
>  > ```
>  > NoMethodError: undefined method `encode' for URI:Module
>  > │
>  > ```
>  >    rubygem-sup
>  >
>  >
>  > ```
>  > Error: test_range(Func): FrozenError: can't modify frozen Range: 0..0
>  > ```
>  >    rubygem-ox
>  >
>  >
>  > gem build issues (with extension):
>  >    rubygem-posix-spawn
>  >    rubygem-syck
>  >
>  >
>  > ```
>  > TypeError: no implicit conversion of Hash into Integer
>  > ```
>  >    rubygem-raindrops
>  >
>  >
>  > https://src.fedoraproject.org/rpms/rubygem-ruby-libvirt/pull-request/2
>  >    rubygem-ruby-libvirt
>  >
>  >
>  > ```
>  > LoadError: cannot load such file -- rexml/
>  > ```
>  >    rubygem-webrobots
>  >    rubygem-selenium-webdriver
>  >    rubygem-faraday
>  >    rubygem-rest-client
>  >    rubygem-mini_magick
>  >    rubygem-webmock
>  >    rubygem-crack
>  >    rubygem-activesupport
>  >    rubygem-cucumber-core
>  >    rubygem-maruku
>  >    rubygem-actionpack
>  >    rubygem-actionmailbox
>  >    rubygem-kramdown-parser-gfm
>  
>  
>  It would be helpful to open upstream tickets for these, because
>  upstreams will need to cope with this as well. While ReXml is going to
>  be available with all Ruby installations, it has to be mentioned in
>  .gemspec files otherwise Bundler won't load it. Would you mind to check
>  with upstreams prior we take any action? 
Sure, creating upstream tickets is the plan.

>  
>  And there are certainly upstream which are dealing with the issues already:
>  
>  https://github.com/rails/rails/commit/f624ed09abba4a0bae64eb699c9fc2e3f9b... 
Thanks!

I'll build Ruby on Rails separately, after Ruby 3.0 is built in a sidetag as well.
  https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_6.1

>  
>  In such cases we should cherry pick the patches rather then blindly
>  adding the dependencies.
>  
>  
>  >
>  >
>  >> All changes are in private-ruby-3.0 branch.
>  >>
>  >> I think I should be able to prepare one more snapshot tomorrow and that
>  >> should be it prior Ruby 3.0 release. This is the last change to upstream
>  >> your changes ;)
>  > I'm preparing pull requests with changes on src.fedoraproject.org for some
>  > of the packages. Some of them are not created yet. Please check it before
>  > you start fixing the package yourself.
>  >
>  > One question for the "sucessful" rebuilds, for all: should I create pull
>  > requests with the rebuild release bump?
>  
>  
>  I don't think it would help, because creating PRs now won't test the
>  packages against Ruby 3.0 and at the time of mass rebuild, it would slow
>  down the rebuild. 
Ok, I won't then, if you insist. It's a different workflow, I guess. Well, it
would be tested with Ruby 3.0 in my COPR repo- see the benefits bellow. But you're
right the CI runs don't know about side-tags.

Additionally, here's an overview of all currenlty failing packages, in case you're
insterested:
  https://gist.github.com/pvalena/83c18610a02153a6500c11c9e58e17e4


Pavel

>  
>  
>  Vít
>  
>  
>  >
>  > Benefits are:
>  >    - Can be subsequently picked up, after merge (or "LGTM", with
>  >    permissions granted to me), and automatically rebuilt by my script.
>  >    - CI runs, either custom or at least simple-koji-ci. Also, you know it
>  >    was pre-tested by me in COPR.
>  >    - Less work for packagers.)
>  >
>  > Which packages? (Failed packages included.)
>  >    https://gist.github.com/pvalena/422c77868e929fe38c8bc325a765f8a8
>  >
>  > Generated using script:
>  >    https://gist.github.com/pvalena/76560097815fe6544c9bc4905e6bf7a1
>  >    
>  >
>  > Regards,
>  > Pavel
>  >
>  >>
>  >> Vít
>  >>

Ruby 3.0

[Vít Ondruch]

Dne 22. 12. 20 v 13:16 Vít Ondruch napsal(a):
>  Hi everybody,
>
>  Here is another snapshot build:
>
>  https://koji.fedoraproject.org/koji/taskinfo?taskID=58026964
>
>  All changes are in private-ruby-3.0 branch.
>
>  I think I should be able to prepare one more snapshot tomorrow and 
>  that should be it prior Ruby 3.0 release. 

As I promised, the build of latest snapshot is running here:

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


Vít



>  This is the last change to upstream your changes ;)
>
>
>  Vít
>
>
>  _______________________________________________
>  ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org
>  To unsubscribe send an email to ruby-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/[e-mail]...

Ruby 3.0

[Vít Ondruch]

Hi everybody,

Here is yet another update:

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

The changes are available in private-ruby-3.0 branch, but nothing really 
stands out. Please give a test and let me know should you find any issue.


Thx


Vít

Ruby 3.0

[Pavel Valena]

----- Original Message -----
>  From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
>  To: ruby-sig(a)lists.fedoraproject.org
>  Sent: Friday, December 4, 2020 5:10:07 PM
>  Subject: Re: Ruby 3.0
>  
>  Hi everybody,
>  
>  Here is yet another update:
>  
>  https://koji.fedoraproject.org/koji/taskinfo?taskID=56776529
>  
>  The changes are available in private-ruby-3.0 branch, but nothing really
>  stands out. Please give a test and let me know should you find any issue.
>  
>  
>  Thx
>  
>  
>  Vít
>  
>   
Hello,

I was unable to rebuild in my testing repo:

https://copr.fedorainfracloud.org/coprs/build/1818226

Tests fail due warnings, when using RBIMPL_CAST:

```
/builddir/build/BUILD/ruby-3.0.0-1cfc6e7b7a/include/ruby/internal/core/rbasic.h:40:59:
warning: expression does not compute the number of elements in this array; element type is
'VALUE' {aka 'long unsigned int'}, not 'char'
[-Wsizeof-array-div]
   40 |     RBIMPL_CAST((int)(sizeof(VALUE[RVALUE_EMBED_LEN_MAX]) / sizeof(T)))
```

I suspect this is new gcc warning. Or should we report this upstream?

Regards,
Pavel

Ruby 3.0

[Jun Aruga]

Note that Ruby 3.0.0 preview2 was released yesterday on December 8th.
https://www.ruby-lang.org/en/news/2020/12/08/ruby-3-0-0-preview2-released/


-- 
Jun | He - His - Him

Ruby 3.0

[Jun Aruga]

>  Hello,
>
>  I was unable to rebuild in my testing repo:
>
>  https://copr.fedorainfracloud.org/coprs/build/1818226
>
>  Tests fail due warnings, when using RBIMPL_CAST:
>
>  ```
>  /builddir/build/BUILD/ruby-3.0.0-1cfc6e7b7a/include/ruby/internal/core/rbasic.h:40:59:
> warning: expression does not compute the number of elements in this array; element type is
> 'VALUE' {aka 'long unsigned int'}, not 'char'
> [-Wsizeof-array-div]
>     40 |     RBIMPL_CAST((int)(sizeof(VALUE[RVALUE_EMBED_LEN_MAX]) / sizeof(T)))
>  ```
>
>  I suspect this is new gcc warning. Or should we report this upstream? 
Here is the failure of the scratch build on the private-ruby-3.0 branch.
https://koji.fedoraproject.org/koji/taskinfo?taskID=57140928
https://kojipkgs.fedoraproject.org//work/tasks/928/57140928/build.log

Yes, I think we should report it. identifying the version of the gcc
by comparing the build on f33 or f32 or finding and pointing out the
official document of the new warning.

-- 
Jun | He - His - Him

Ruby 3.0

[Jun Aruga]

On Wed, Dec 9, 2020 at 8:45 PM Jun Aruga <jaruga(a)redhat.com&gt; wrote:
>  > Hello,
>  >
>  > I was unable to rebuild in my testing repo:
>  >
>  > https://copr.fedorainfracloud.org/coprs/build/1818226
>  >
>  > Tests fail due warnings, when using RBIMPL_CAST:
>  >
>  > ```
>  >
> /builddir/build/BUILD/ruby-3.0.0-1cfc6e7b7a/include/ruby/internal/core/rbasic.h:40:59:
> warning: expression does not compute the number of elements in this array; element type is
> 'VALUE' {aka 'long unsigned int'}, not 'char'
> [-Wsizeof-array-div]
>  >    40 |     RBIMPL_CAST((int)(sizeof(VALUE[RVALUE_EMBED_LEN_MAX]) / sizeof(T)))
>  > ```
>  >
>  > I suspect this is new gcc warning. Or should we report this upstream?
>
>  Here is the failure of the scratch build on the private-ruby-3.0 branch.
>  https://koji.fedoraproject.org/koji/taskinfo?taskID=57140928
>  https://kojipkgs.fedoraproject.org//work/tasks/928/57140928/build.log
>
>  Yes, I think we should report it. identifying the version of the gcc
>  by comparing the build on f33 or f32 or finding and pointing out the
>  official document of the new warning. 
I investigated more to report it to upstream.
On the rawhide, the gcc version is 11.0.0-0.7.fc34

According to the gcc 11 release note, the new warning
-Wsizeof-array-div causing the error was added.
https://gcc.gnu.org/gcc-11/changes.html

>  C family
>  New warnings:
>  -Wsizeof-array-div, enabled by -Wall, warns about divisions of two sizeof operators when
> the first one is applied to an array and the divisor does not equal the size of the array
> element. 
Here is the ticket with the examples.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91741

I will report it to the upstream, and let you know the result here.

I am running the SRPM on the private-ruby-3.0 branch for f33 too just in case.

```
$ koji build --scratch --nowait --arch-override=x86_64 f33
ruby-3.0.0-0.1.20201204git1cfc6e7b7a.fc34.src.rpm
https://koji.fedoraproject.org/koji/taskinfo?taskID=57179644
```

-- 
Jun | He - His - Him

Ruby 3.0

[Jun Aruga]

>  I will report it to the upstream, and let you know the result here.
Here is the upstream ticket I opened now.
https://bugs.ruby-lang.org/issues/17385

>  I am running the SRPM on the private-ruby-3.0 branch for f33 too just
> in case.
>
>  ```
>  $ koji build --scratch --nowait --arch-override=x86_64 f33
>  ruby-3.0.0-0.1.20201204git1cfc6e7b7a.fc34.src.rpm
>  https://koji.fedoraproject.org/koji/taskinfo?taskID=57179644
>  ``` 
The build succeeded with gcc 10.2.1-9.fc33 on f33.

-- 
Jun | He - His - Him

Ruby 3.0

[Jun Aruga]

On Thu, Dec 10, 2020 at 12:32 PM Jun Aruga <jaruga(a)redhat.com&gt; wrote:
>  > I will report it to the upstream, and let you know the result here.
>
>  Here is the upstream ticket I opened now.
>  https://bugs.ruby-lang.org/issues/17385 
The patch was merged to the upstream ruby's master branch.
https://src.fedoraproject.org/fork/jaruga/rpms/ruby/c/ae692f4f294ac4f3e47...

Here is my patch for the private-ruby-3.0 branch
https://src.fedoraproject.org/fork/jaruga/rpms/ruby/c/ae692f4f294ac4f3e47...

It seems that the scratch build works.
https://koji.fedoraproject.org/koji/taskinfo?taskID=57437861

But the mock build fails with the following one.

```
  1) Failure:
TestBundledCA#test_accessing_rubygems
[/builddir/build/BUILD/ruby-3.0.0-1cfc6e7b7a/test/rubygems/test_bundled_ca.rb:46]:
rubygems.org is not verifiable using the included certificates. Error
was: SSL_connect returned=1 errno=0 state=error: certificate verify
failed (unable to get local issuer certificate)

Finished tests in 670.500927s, 31.2244 tests/s, 3975.4993 assertions/s.
20936 tests, 2665576 assertions, 1 failures, 0 errors, 48 skips

ruby -v: ruby 3.0.0dev (2020-12-04 master 1cfc6e7b7a) [x86_64-linux]
make: *** [uncommon.mk:801: yes-test-all] Error 1
```

Any idea to fix?
Thanks.

-- 
Jun | He - His - Him

Ruby 3.0

[Jun Aruga]

>  All build results can be found here:
>    https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/builds/ 
Hi Pavel,
You might need to build the packages on your copr f34 (rawhide) now
again if it is easy to do.
Because there is new gcc-11 on rawhide now. And for example the
rubygem-mysql2 fails actually, but it was shown as a success on your
copr.
https://koschei.fedoraproject.org/package/rubygem-mysql2

-- 
Jun | He - His - Him

Ruby 3.0

[Vít Ondruch]

Hi,

Another snapshot is available in private-ruby-3.0 branch and the build 
is running here:

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

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?

Vít


P.S. @jaruga + @pvalena thx for handling the GCC11 issues.

Ruby 3.0

[Jaroslav Prokop]

Hi,

WEBrick is default in some applications, IIRC - e.g Sinatra [0] 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
that.

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.

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.

Jarek


[0] 
https://github.com/sinatra/sinatra/blob/a9649b4f18a9059de3161906c9c6e95ec...


On 16/12/2020 18:39, Vít Ondruch wrote:
> Hi,
>
> Another snapshot is available in private-ruby-3.0 branch and the build 
> is running here:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=57585626
>
> 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?
>
> Vít
>
>
> P.S. @jaruga + @pvalena thx for handling the GCC11 issues.
>

Ruby 3.0

[Pavel Valena]

----- Original Message -----
>  From: "Jaroslav Prokop" <jar.prokop(a)volny.cz&gt;
>  To: ruby-sig(a)lists.fedoraproject.org
>  Sent: Wednesday, December 16, 2020 7:05:03 PM
>  Subject: Re: Ruby 3.0
>  
>  Hi,
>  
>  WEBrick is default in some applications, IIRC - e.g Sinatra [0] 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
>  that. 
Hello,

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?

>  
>  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: 
  https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/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.
>  
>  Jarek
>  
>  
>  [0]
>
> https://github.com/sinatra/sinatra/blob/a9649b4f18a9059de3161906c9c6e95ec...
>  
>  
>  On 16/12/2020 18:39, Vít Ondruch wrote:
>  > Hi,
>  >
>  > Another snapshot is available in private-ruby-3.0 branch and the build
>  > is running here: 
FYI it's not synced with PR#70. 

>  >
>  > https://koji.fedoraproject.org/koji/taskinfo?taskID=57585626 
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?
>  >
>  > Vít
>  >
>  >
>  > P.S. @jaruga + @pvalena thx for handling the GCC11 issues.
>  > 
Regards,
-- 
Pavel Valena
Software Engineer, Red Hat
Brno, Czech Republic

Ruby 3.0

[Vít Ondruch]

Dne 17. 12. 20 v 3:16 Pavel Valena napsal(a):
>  ----- Original Message -----
> > From: "Jaroslav Prokop" <jar.prokop(a)volny.cz&gt;
> > To: ruby-sig(a)lists.fedoraproject.org
> > Sent: Wednesday, December 16, 2020 7:05:03 PM
> > Subject: Re: Ruby 3.0
> >
> > Hi,
> >
> > WEBrick is default in some applications, IIRC - e.g Sinatra [0] 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
> > that.
>  Hello,
>
>  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.


> > 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:
>     https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/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.
> >
> > Jarek
> >
> >
> > [0]
> >
> https://github.com/sinatra/sinatra/blob/a9649b4f18a9059de3161906c9c6e95ec...
> >
> >
> > On 16/12/2020 18:39, Vít Ondruch wrote:
> >> Hi,
> >>
> >> 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:

https://github.com/ruby/ruby/pull/3907


Thx


Vít


> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=57585626
>  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?
> >>
> >> Vít
> >>
> >>
> >> P.S. @jaruga + @pvalena thx for handling the GCC11 issues.
> >>
>  Regards,

Ruby 3.0

[Pavel Valena]

----- Original Message -----
>  From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
>  To: ruby-sig(a)lists.fedoraproject.org
>  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&gt;
>  >> To: ruby-sig(a)lists.fedoraproject.org
>  >> Sent: Wednesday, December 16, 2020 7:05:03 PM
>  >> Subject: Re: Ruby 3.0
>  >>
>  >> Hi,
>  >>
>  >> WEBrick is default in some applications, IIRC - e.g Sinatra [0] 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
>  >> that.
>  > Hello,
>  >
>  > 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
Webrick).
Apart from that I'm good without (FDP can switch easily, Bughunting has alerady
switched AFAIK).

>  
>  
>  >
>  >> 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:
>  >    https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/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.
>  >>
>  >> Jarek
>  >>
>  >>
>  >> [0]
>  >>
> https://github.com/sinatra/sinatra/blob/a9649b4f18a9059de3161906c9c6e95ec...
>  >>
>  >>
>  >> On 16/12/2020 18:39, Vít Ondruch wrote:
>  >>> Hi,
>  >>>
>  >>> 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 :).

Thanks!

>  
>  https://github.com/ruby/ruby/pull/3907
>  
>  
>  Thx
>  
>  
>  Vít
>  
>  
>  >
>  >>> https://koji.fedoraproject.org/koji/taskinfo?taskID=57585626
>  > 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?
>  >>>
>  >>> Vít
>  >>>
>  >>>
>  >>> P.S. @jaruga + @pvalena thx for handling the GCC11 issues.
>  >>>
>  > Regards,
>   
Pavel

Ruby 3.0

[Jun Aruga]

>  Another snapshot is available in private-ruby-3.0 branch and the
> build
>  is running here:
>
>  https://koji.fedoraproject.org/koji/taskinfo?taskID=57585626
>
>  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?
>
>  Vít
>
>
>  P.S. @jaruga + @pvalena thx for handling the GCC11 issues. 
Thanks for another snapshot, Vit.
I confirmed the new snapshot's SRPM works on my mock build rawhide.
I also confirmed the following failure I reported above disappeared now.

```
  1) Failure:
TestBundledCA#test_accessing_rubygems
[/builddir/build/BUILD/ruby-3.0.0-1cfc6e7b7a/test/rubygems/test_bundled_ca.rb:46]:
rubygems.org is not verifiable using the included certificates. Error
was: SSL_connect returned=1 errno=0 state=error: certificate verify
failed (unable to get local issuer certificate)

Finished tests in 670.500927s, 31.2244 tests/s, 3975.4993 assertions/s.
20936 tests, 2665576 assertions, 1 failures, 0 errors, 48 skips

ruby -v: ruby 3.0.0dev (2020-12-04 master 1cfc6e7b7a) [x86_64-linux]
make: *** [uncommon.mk:801: yes-test-all] Error 1
```

-- 
Jun | He - His - Him

Ruby 3.0

[Jun Aruga]

On Fri, Dec 18, 2020 at 4:06 PM Jun Aruga <jaruga(a)redhat.com&gt; wrote:
>  > Another snapshot is available in private-ruby-3.0 branch and the build
>  > is running here:
>  >
>  > https://koji.fedoraproject.org/koji/taskinfo?taskID=57585626
>  >
>  > 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? 
I find the .gitignore is outdated, as we have ruby-3.*.tar.xz. Maybe
we can update be like this.

```
$ git diff
diff --git a/.gitignore b/.gitignore
index 3523d77..a59f941 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,4 +1,3 @@
 /*/
-/ruby-2.*.tar.bz2
-/ruby-2.*.tar.xz
+/ruby-*.tar.xz
 /*.rpm
```

-- 
Jun | He - His - Him

Ruby 3.0

[Vít Ondruch]

Hi everybody,

The ruby 3.0.0.rc1 was released over the weekend, so here is the scratch 
build:

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

And I already updated to the latest snapshot. The build is runnig here:

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

I don't think there was anything significant. So please do some testing, 
since the official release should be just in 4 days!


Vít

Ruby 3.0

[Vít Ondruch]

Hi and happy new year!

So Ruby 3.0 were released over Christmas and therefore I closed the old 
PR and created a new one, which should be the final version:

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

The scratch build is running here:

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

Please give it some test and provide final feedback.

I think I should be able to kick of the official build and rebuild of 
packages on Wednesday if everything goes well.


Vít