Hi everybody,
Ruby 3.4 is out and it is time for Ruby mass rebuild. First of all, I'd like to thank to Mamoru for the preparation and lot of fixes all around. I really appreciate that.
I think we are well prepared for the rebuild, therefore I have requested side-tag:
~~~
$ fedpkg request-side-tag Side tag 'f42-build-side-103200' (id 103200) created. Use 'fedpkg build --target=f42-build-side-103200' to use it. Use 'koji wait-repo f42-build-side-103200' to wait for the build repo to be generated.
~~~
Ruby 3.4 is already merged [1] and build there:
https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=103200&...
where you can see the rebuild progress. You can alternatively also use:
~~~
$ koji list-tagged f42-build-side-103200
~~~
Now this is a list of packages, which very likely needs rebuild:
~~~ $ dnf repoquery --disablerepo=* --enablerepo=rawhide --enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' | sort | uniq ~~~
You can take such package, bump the release and just fire rebuild, but please ensure that you are using f42-build-side-103200 build target, i.e. the build command should look like:
~~~ $ fedpkg build --target f42-build-side-103200 ~~~
Please be careful, because if you, by a chance, omit the f42-build-side-103200 target, you'll be building against Ruby 3.3 which is not what you want.
I also believe, that these days, the side tag is not autorefreshed, so it needs to be requested like:
~~~
$ koji wait-repo f42-build-side-103200 --build ruby-3.4.1-19.fc42 The --request option is recommended for faster results This tag is not configured for automatic regeneration
$ koji wait-repo f42-build-side-103200 --build ruby-3.4.1-19.fc42 --request
~~~
If you won't do it by yourself, I'll be rebuilding all packages after I am finished with my packages. I'll be using fermig [2] to help me with that. If you don't want me to touch your packages for whatever reason, please let me know.
As always, any help/testing/feedback is welcome.
Vít
[1] https://src.fedoraproject.org/rpms/ruby/pull-request/196 [2] https://github.com/fedora-ruby/fermig
Dne 07. 01. 25 v 16:46 Vít Ondruch napsal(a):
I also believe, that these days, the side tag is not autorefreshed, so it needs to be requested like:
$ koji wait-repo f42-build-side-103200 --build ruby-3.4.1-19.fc42 The --request option is recommended for faster results This tag is not configured for automatic regeneration $ koji wait-repo f42-build-side-103200 --build ruby-3.4.1-19.fc42 --request
It seems that calls like this are really necessary to update the side tag repo. E.g. rubygem-mysql2 needs rubygem-eventmachine. While built, it was not available in the repo [1] until I called:
~~~
$ koji wait-repo f42-build-side-103200 --build rubygem-eventmachine-1.2.7-28.fc42 --request
~~~
Then the rubygem-mysql2 build succeeded right away.
Vít
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=127637976
Vít Ondruch via ruby-sig wrote on 2025/01/08 0:46:
Hi everybody,
Ruby 3.4 is out and it is time for Ruby mass rebuild. First of all, I'd like to thank to Mamoru for the preparation and lot of fixes all around. I really appreciate that.
I think we are well prepared for the rebuild, therefore I have requested side-tag:
$ fedpkg request-side-tag Side tag 'f42-build-side-103200' (id 103200) created. Use 'fedpkg build --target=f42-build-side-103200' to use it. Use 'koji wait-repo f42-build-side-103200' to wait for the build repo to be generated.Ruby 3.4 is already merged [1] and build there: https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=103200&...
Packages which had depedency for libruby.so.3.3 previously are now succesfully rebuilt, except for rubygem-serialport , which is now tracked on: https://bugzilla.redhat.com/show_bug.cgi?id=2329359
Now 86 pkgs (including ruby.src) have dependency for libruby.so.3.4, and I think we are ready for merging into rawhide tree.
Regards, Mamoru
Dne 08. 01. 25 v 12:17 Mamoru TASAKA via ruby-sig napsal(a):
Vít Ondruch via ruby-sig wrote on 2025/01/08 0:46:
Hi everybody,
Ruby 3.4 is out and it is time for Ruby mass rebuild. First of all, I'd like to thank to Mamoru for the preparation and lot of fixes all around. I really appreciate that.
I think we are well prepared for the rebuild, therefore I have requested side-tag:
$ fedpkg request-side-tag Side tag 'f42-build-side-103200' (id 103200) created. Use 'fedpkg build --target=f42-build-side-103200' to use it. Use 'koji wait-repo f42-build-side-103200' to wait for the build repo to be generated.Ruby 3.4 is already merged [1] and build there: https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=103200&...
Packages which had depedency for libruby.so.3.3 previously are now succesfully rebuilt, except for rubygem-serialport , which is now tracked on: https://bugzilla.redhat.com/show_bug.cgi?id=2329359
Now 86 pkgs (including ruby.src) have dependency for libruby.so.3.4, and I think we are ready for merging into rawhide tree.
Thank you for you help! Much appreciated. I am going through my last round of checks. For example now I am looking into ruby-devel depending packages and specifically into libsolv. I always wonder why the Ruby binding does not have the libruby.so dependency. In my experience, there are more packages like this. Any clue? In the worst case, these will be soon rebuilt due to Fedora mass rebuild, but I'd still like to understand.
Vít
Regards, Mamoru
Vít Ondruch via ruby-sig wrote on 2025/01/08 20:28:
Dne 08. 01. 25 v 12:17 Mamoru TASAKA via ruby-sig napsal(a):
Vít Ondruch via ruby-sig wrote on 2025/01/08 0:46:
Hi everybody,
Ruby 3.4 is out and it is time for Ruby mass rebuild. First of all, I'd like to thank to Mamoru for the preparation and lot of fixes all around. I really appreciate that.
I think we are well prepared for the rebuild, therefore I have requested side-tag:
$ fedpkg request-side-tag Side tag 'f42-build-side-103200' (id 103200) created. Use 'fedpkg build --target=f42-build-side-103200' to use it. Use 'koji wait-repo f42-build-side-103200' to wait for the build repo to be generated.Ruby 3.4 is already merged [1] and build there: https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=103200&...
Packages which had depedency for libruby.so.3.3 previously are now succesfully rebuilt, except for rubygem-serialport , which is now tracked on: https://bugzilla.redhat.com/show_bug.cgi?id=2329359
Now 86 pkgs (including ruby.src) have dependency for libruby.so.3.4, and I think we are ready for merging into rawhide tree.
Thank you for you help! Much appreciated. I am going through my last round of checks. For example now I am looking into ruby-devel depending packages and specifically into libsolv. I always wonder why the Ruby binding does not have the libruby.so dependency. In my experience, there are more packages like this. Any clue? In the worst case, these will be soon rebuilt due to Fedora mass rebuild, but I'd still like to understand.
Basically, (for example: xapian-bindings-ruby.x86_64 from xapian-bindings), such package does not explicitly link against -lruby (intentionally?).
So such package (or .so files in such package) does not have dependency for libruby.so in terms of rpm dependency, and has unresolved depdendency when trying to check by $ ldd -r <such binary>:
[root@localhost ~]# rpm -q xapian-bindings-ruby xapian-bindings-ruby-1.4.26-2.fc41.x86_64 [root@localhost ~]# ldd -r /usr/lib64/ruby/vendor_ruby/_xapian.so linux-vdso.so.1 (0x00007ffc71faa000) libxapian.so.30 => /lib64/libxapian.so.30 (0x00007f2c86200000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f2c85e00000) libm.so.6 => /lib64/libm.so.6 (0x00007f2c86449000) libc.so.6 => /lib64/libc.so.6 (0x00007f2c85c0c000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f2c8641a000) libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f2c86410000) libz.so.1 => /lib64/libz.so.1 (0x00007f2c861de000) /lib64/ld-linux-x86-64.so.2 (0x00007f2c8662c000) undefined symbol: rb_eArgError (/usr/lib64/ruby/vendor_ruby/_xapian.so) undefined symbol: rb_eNoMemError (/usr/lib64/ruby/vendor_ruby/_xapian.so) undefined symbol: rb_cFloat (/usr/lib64/ruby/vendor_ruby/_xapian.so) undefined symbol: rb_eRangeError (/usr/lib64/ruby/vendor_ruby/_xapian.so) undefined symbol: rb_eFatal (/usr/lib64/ruby/vendor_ruby/_xapian.so) undefined symbol: rb_cNilClass (/usr/lib64/ruby/vendor_ruby/_xapian.so) ... ...
But this is "okay" in the meaning that such bindings are used through something like
$ ruby -e 'require xapian'
then executing ruby (main) binary will load libruby.so.3.X at that time, so after that trying to dlopen() _xapian.so will succeed because libruby.so.3.X is already loaded.
(So there surely is the opinion that such package should explicitly make such binding linked aganist main library like libruby.so.) (And of course, such binary will fail at "runtime" when soname changed libruby.so removes some symbols which such bindings required, not at "build time")
Vít
Mamoru
Dne 08. 01. 25 v 12:57 Mamoru TASAKA via ruby-sig napsal(a):
Vít Ondruch via ruby-sig wrote on 2025/01/08 20:28:
Dne 08. 01. 25 v 12:17 Mamoru TASAKA via ruby-sig napsal(a):
Vít Ondruch via ruby-sig wrote on 2025/01/08 0:46:
Hi everybody,
Ruby 3.4 is out and it is time for Ruby mass rebuild. First of all, I'd like to thank to Mamoru for the preparation and lot of fixes all around. I really appreciate that.
I think we are well prepared for the rebuild, therefore I have requested side-tag:
$ fedpkg request-side-tag Side tag 'f42-build-side-103200' (id 103200) created. Use 'fedpkg build --target=f42-build-side-103200' to use it. Use 'koji wait-repo f42-build-side-103200' to wait for the build repo to be generated.Ruby 3.4 is already merged [1] and build there: https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=103200&...
Packages which had depedency for libruby.so.3.3 previously are now succesfully rebuilt, except for rubygem-serialport , which is now tracked on: https://bugzilla.redhat.com/show_bug.cgi?id=2329359
Now 86 pkgs (including ruby.src) have dependency for libruby.so.3.4, and I think we are ready for merging into rawhide tree.
Thank you for you help! Much appreciated. I am going through my last round of checks. For example now I am looking into ruby-devel depending packages and specifically into libsolv. I always wonder why the Ruby binding does not have the libruby.so dependency. In my experience, there are more packages like this. Any clue? In the worst case, these will be soon rebuilt due to Fedora mass rebuild, but I'd still like to understand.
Basically, (for example: xapian-bindings-ruby.x86_64 from xapian-bindings), such package does not explicitly link against -lruby (intentionally?).
So such package (or .so files in such package) does not have dependency for libruby.so in terms of rpm dependency, and has unresolved depdendency when trying to check by $ ldd -r <such binary>:
[root@localhost ~]# rpm -q xapian-bindings-ruby xapian-bindings-ruby-1.4.26-2.fc41.x86_64 [root@localhost ~]# ldd -r /usr/lib64/ruby/vendor_ruby/_xapian.so linux-vdso.so.1 (0x00007ffc71faa000) libxapian.so.30 => /lib64/libxapian.so.30 (0x00007f2c86200000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f2c85e00000) libm.so.6 => /lib64/libm.so.6 (0x00007f2c86449000) libc.so.6 => /lib64/libc.so.6 (0x00007f2c85c0c000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f2c8641a000) libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f2c86410000) libz.so.1 => /lib64/libz.so.1 (0x00007f2c861de000) /lib64/ld-linux-x86-64.so.2 (0x00007f2c8662c000) undefined symbol: rb_eArgError (/usr/lib64/ruby/vendor_ruby/_xapian.so) undefined symbol: rb_eNoMemError (/usr/lib64/ruby/vendor_ruby/_xapian.so) undefined symbol: rb_cFloat (/usr/lib64/ruby/vendor_ruby/_xapian.so) undefined symbol: rb_eRangeError (/usr/lib64/ruby/vendor_ruby/_xapian.so) undefined symbol: rb_eFatal (/usr/lib64/ruby/vendor_ruby/_xapian.so) undefined symbol: rb_cNilClass (/usr/lib64/ruby/vendor_ruby/_xapian.so) ... ...
But this is "okay" in the meaning that such bindings are used through something like
$ ruby -e 'require xapian'
then executing ruby (main) binary will load libruby.so.3.X at that time, so after that trying to dlopen() _xapian.so will succeed because libruby.so.3.X is already loaded.
Right, that makes perfect sense. Thank you for elaborating
(So there surely is the opinion that such package should explicitly make such binding linked aganist main library like libruby.so.)
If nothing else, that would make our life easier.
(And of course, such binary will fail at "runtime" when soname changed libruby.so removes some symbols which such bindings required, not at "build time")
I interpret all the above that we should rebuild these to be on the safe side. I have fired of the libsolv rebuild (and judging by the changelog, I did also previously). Granted, this would not cause broken dependencies, so it might not be considered as a blocker for merging of the side tag.
Vít
Dne 08. 01. 25 v 12:17 Mamoru TASAKA via ruby-sig napsal(a):
Vít Ondruch via ruby-sig wrote on 2025/01/08 0:46:
Hi everybody,
Ruby 3.4 is out and it is time for Ruby mass rebuild. First of all, I'd like to thank to Mamoru for the preparation and lot of fixes all around. I really appreciate that.
I think we are well prepared for the rebuild, therefore I have requested side-tag:
$ fedpkg request-side-tag Side tag 'f42-build-side-103200' (id 103200) created. Use 'fedpkg build --target=f42-build-side-103200' to use it. Use 'koji wait-repo f42-build-side-103200' to wait for the build repo to be generated.Ruby 3.4 is already merged [1] and build there: https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=103200&...
Packages which had depedency for libruby.so.3.3 previously are now succesfully rebuilt, except for rubygem-serialport , which is now tracked on: https://bugzilla.redhat.com/show_bug.cgi?id=2329359
Now 86 pkgs (including ruby.src) have dependency for libruby.so.3.4, and I think we are ready for merging into rawhide tree.
The update is here:
https://bodhi.fedoraproject.org/updates/FEDORA-2025-dbf6ae505d
Last time, there were some gating failures needed some waiving, so this might need some babysitting.
Vít
ruby-sig@lists.fedoraproject.org
-
Mamoru TASAKA -
Vít Ondruch