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

Pavel Valena wrote on 2020/10/13 21:00:

----- Original Message -----

...

From: "Vít Ondruch" vondruch@redhat.com To: ruby-sig@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-testing/...

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-testing/... (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

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

----- Original Message -----

From: "Dan Čermák" dan.cermak@cgc-instruments.com To: "Vít Ondruch" vondruch@redhat.com Cc: ruby-sig@lists.fedoraproject.org Sent: Thursday, November 5, 2020 4:41:46 PM Subject: Re: Ruby 3.0

Hi Vít,

Vít Ondruch vondruch@redhat.com 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,

Dne 13. 11. 20 v 3:56 Pavel Valena napsal(a):

----- Original Message -----

...

From: "Pavel Valena" pvalena@redhat.com To: "Dan Čermák" dan.cermak@cgc-instruments.com Cc: "Ruby SIG mailing list" ruby-sig@lists.fedoraproject.org Sent: Thursday, November 5, 2020 8:30:25 PM Subject: Re: Ruby 3.0

----- Original Message -----

...

From: "Dan Čermák" dan.cermak@cgc-instruments.com To: "Vít Ondruch" vondruch@redhat.com Cc: ruby-sig@lists.fedoraproject.org Sent: Thursday, November 5, 2020 4:41:46 PM Subject: Re: Ruby 3.0

Hi Vít,

Vít Ondruch vondruch@redhat.com 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-testing/fedora-rawhide-x86_64/01767294-rubygem-eventmachine/builder-live.log.gz
https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/build/1767294/

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/b50c135dfdd4e7b20c8e0b7ce1...

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

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

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@redhat.com To: "Dan Čermák" dan.cermak@cgc-instruments.com Cc: "Ruby SIG mailing list" ruby-sig@lists.fedoraproject.org Sent: Thursday, November 5, 2020 8:30:25 PM Subject: Re: Ruby 3.0

----- Original Message -----

...

From: "Dan Čermák" dan.cermak@cgc-instruments.com To: "Vít Ondruch" vondruch@redhat.com Cc: ruby-sig@lists.fedoraproject.org Sent: Thursday, November 5, 2020 4:41:46 PM Subject: Re: Ruby 3.0

Hi Vít,

Vít Ondruch vondruch@redhat.com 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-testing/...     https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/build/17672...

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/b50c135dfdd4e7b20c8e0b7ce1...

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

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/ruby-sig@lists.fedoraproject.o... ) 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

----- Original Message -----

From: "Vít Ondruch" vondruch@redhat.com To: ruby-sig@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@redhat.com To: "Dan Čermák" dan.cermak@cgc-instruments.com Cc: "Ruby SIG mailing list" ruby-sig@lists.fedoraproject.org Sent: Thursday, November 5, 2020 8:30:25 PM Subject: Re: Ruby 3.0

----- Original Message ----- > From: "Dan Čermák" dan.cermak@cgc-instruments.com > To: "Vít Ondruch" vondruch@redhat.com > Cc: ruby-sig@lists.fedoraproject.org > Sent: Thursday, November 5, 2020 4:41:46 PM > Subject: Re: Ruby 3.0 > > Hi Vít, > > Vít Ondruch vondruch@redhat.com 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-testing/... https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/build/17672...

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/b50c135dfdd4e7b20c8e0b7ce1...

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

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/ruby-sig@lists.fedoraproject.o...

) 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

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

@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/ruby-sig@lists.fedoraproject.o...

) 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@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o...

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@redhat.com To: ruby-sig@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/ruby-sig@lists.fedoraproject.o...

) 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@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o...

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@redhat.com To: ruby-sig@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/ruby-sig@lists.fedoraproject.o...

) 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@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o...

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@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o...

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

Dne 23. 12. 20 v 11:06 Pavel Valena napsal(a):

----- Original Message -----

...

From: "Vít Ondruch" vondruch@redhat.com To: ruby-sig@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/rub...

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/f624ed09abba4a0bae64eb699c9fc2e3f9bdc2...

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@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o...

----- 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@redhat.com To: ruby-sig@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/rub...

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/f624ed09abba4a0bae64eb699c9fc2e3f9bdc2...

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

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

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/

On Wed, Dec 9, 2020 at 8:45 PM Jun Aruga jaruga@redhat.com 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 ```

On Thu, Dec 10, 2020 at 12:32 PM Jun Aruga jaruga@redhat.com 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/ae692f4f294ac4f3e47458...

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

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.

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.

----- Original Message -----

From: "Jaroslav Prokop" jar.prokop@volny.cz To: ruby-sig@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/a9649b4f18a9059de3161906c9c6e95ec06f...

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,

----- Original Message -----

From: "Vít Ondruch" vondruch@redhat.com To: ruby-sig@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@volny.cz To: ruby-sig@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/a9649b4f18a9059de3161906c9c6e95ec06f...

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

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