Re: Ruby 3.4 - Mass rebuild

[Vít Ondruch via ruby-sig]

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,





~~~

$ fedpkg request-side-tag
Side tag 'f42-build-side-103200' (id 103200) created.
Use 'fedpkg build --target=f42-build-side-103200' to use it.


~~~


Ruby 3.4 is already merged [1] and build there:

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: Use 'koji wait-repo f42-build-side-103200' to wait for the build repo to be generated. https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=103200&order=-build_id&latest=1

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.

Packages which had depedency for libruby.so.3.3 previously are now succesfully rebuilt,

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.

such package does not explicitly link against -lruby (intentionally?).


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)
...
...



$ ruby -e 'require xapian'

then executing ruby (main) binary will load libruby.so.3.X at that time,

already loaded.

Basically, (for example: xapian-bindings-ruby.x86_64 from xapian-bindings), So such package (or .so files in such package) does not have dependency for libruby.so But this is "okay" in the meaning that such bindings are used through something like so after that trying to dlopen() _xapian.so will succeed because libruby.so.3.X is

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")

Vít

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.

OpenPGP_signature.asc
Description: OpenPGP digital signature

-- 
_______________________________________________
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@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.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue