`CC0` is not valid license identifier anymore:
~~~
$ license-validate -v CC0
No terminal matches 'C' in the current parser context, at line 1 col 1
CC0
^
Expected one of:
* __ANON_202
... snip ...
* __ANON_163
Not a valid license string
Please check https://docs.fedoraproject.org/en-US/legal/all-allowed/
~~~
Sourced from Fedora: https://src.fedoraproject.org/rpms/rubygem-rdoc/pull-request/3
and deleted the portion of the patch that edited the rdoc's tests, because the upstream
Ruby tar does not contain tests for rdoc.
Fixes case where installling multiple documents: `gem install -V hocon --document=ri,rdoc`
can result in an exception:
~~~
$ gem install -V hocon --document=ri,rdoc
....
....
Successfully installed hocon-1.4.0
Parsing documentation for hocon-1.4.0
Parsing sources...
100% [88/88] lib/hocon/version.rb
Installing ri documentation for hocon-1.4.0
Installing aliki documentation for hocon-1.4.0
ERROR: While executing gem ... (NoMethodError)
undefined method 'empty?' for an instance of RDoc::Markup::Paragraph
return '' unless first_comment && !first_comment.empty?
^^^^^^^
<...snip...>
~~~
See: https://github.com/ruby/rdoc/issues/1530
We have carried obsoletes and provides around merged or removed packages
from Fedora versions that are EOL for quite some time.
Similarly to re-numbering the SourceN: declaration to be in proper sequence,
Ruby 4.0.0 is a good break point to finally remove these old obsoletes/provides.
However, to be careful since RHEL 9 might be a destination for Ruby 4.0,
do not remove obsoletes for Ruby >= 3.0, RHEL 9 still has Ruby 3.0
which motivates the bottom version constraint on where to end.
On that distro someone might enable a ruby:4.0 module after installing system
ruby and then just run dnf update to get the new contents.
That is not recommended nor supported, but let's not check who uses
that approach by potentially breaking it.
Since upstream's 029a48176c
we can build both without the necessity of cargo or new rust
dependencies if we only care about the JITs.
Introduce `bcond_without rust`. Parts of Ruby are in Rust, which necessitates
dependencies such as the compiler, macros and so on.
Since both YJIT and ZJIT are in rust but can be built independently of
each other but not independently of present Rust support in the
buildroot, it is better to bring in rust bits when we build ruby `with_rust`.
The %%{build_rustflags} macro lives in different
packages, depending on if we are in EL or Fedora.
RUSTFLAGS could affect too much at the same time and only apply to
cargo.
The approach merged in upstream PR https://github.com/ruby/ruby/pull/15695
is to instead have a specific flag on configure script to instrument the
`rustc` compilation flags specifically when building JITs.
This ensures that we are properly providing the %%{build_rustflags} macro for rustc.
The downcased version in the configure script appends to upstream's
defaults. This way we preserve upstream's flags and overwrite any flags
that differ in Fedora from upstream, since the flag specified later on
the CLI will be taken.
For example if we have:
~~~
$ rustc -C opt-level=3 -C opt-level=2 foo.rs
~~~
Then the latter value is used, so the file is compiled with opt-level=2,
not 3, because it was specified later.
So we should always end up with Distro compliant compiler flags.
Also fixup the doc referring to supported JIT architectures in the links
in the comment near the JIT bconds.
Over the time, sources and patches are added and removed, some are
removed sooner than the source after them.
That makes it possible for us to end up in situation where the
`SourceN:` or `PatchN:` are not in sequence.
(where N is a number from the set of Natural numbers starting with 0)
After an offline discussion, it has come to attention that the numbering
was always appended and never compressed partly due to inertia, and
partly to not try to differ for RHELs, make backports/diffs between Ruby
versions easier and smaller.
At the same time, we concurred that this new Ruby version is a good
breakpoint for this type of changes.
Therefore, the Source and Patch numbering was brought back into sequence
on this break point.
* Define different expected archives macros for development.
When revision was defined, there was also timestamp appended.
That does not seem necessary for preview tarballs from upstream.
Instead split it into their own separate conditionals.
* irb and rdoc are now a bundled gem
Don't ship the %ruby_libdir parts and the symlinking for irb and rdoc.
The rdoc rubygems plugin should now be correctly present. Remove the
additional source.
* Multiple gems are now bundled gems.
Add them to ruby-bundled-gems subpackage instead of their own separate
packages.
* Split the rdoc support for ruby version directory from
ruby-2.3.0-ruby_version.patch.
After Ruby moved RDoc to bundled gems from default gems, the directory
in which RDoc is in the upstream tarball is not in the upstream source,
necessitating a patch split for the Ruby version patch.
It cannot be fully re-created including the rdoc part in a single patch
with upstream ruby/ruby github.
Instead the part is created from ruby/rdoc github.
Add bundled provides for rubygem-json + the source into comments.
Source is as described in upstream commits and in the LEGAL file
upstream. Add the respective licenses for the subpackage.
RDoc includes a new doc generator that is under the MIT license,
update the license to reflect it.
Resolves: rhbz#2425358
Use a build condition to turn the parallelization on and off when
needed. The output is slightly different from the previous approach.
The way results are collected and displayed remains the same.
This allows us to scale down build time on multiple cores better.
Chose to introduce a bcond explicitly for tests for debugging purposes.
Running tests in parallel could hide issues that would show if
everything was done in a single test-unit process.
Limiting the number of cores available to RPM via a macro would also
hinder parallelization of the compilation, which might not be desired
in the case of only wanting to serializing the tests.
Table from the associated ticket:
The time represents total seconds that a full RPM build inside mock
took from start to finish.
PARALLEL TESTS
------------------------------------------------------------------------
Cores | Runs | Avg (s) | Min (s) | Max (s) | Speedup
------------------------------------------------------------------------
2_core | 5 | 3196.0 | 3175.0 | 3218.0 | 1.00x
4_core | 5 | 3166.6 | 2949.0 | 3598.0 | 1.01x
8_core | 5 | 1129.2 | 1090.0 | 1257.0 | 2.83x
16_core | 5 | 807.4 | 794.0 | 820.0 | 3.96x
SEQUENTIAL TESTS
------------------------------------------------------------------------
Cores | Runs | Avg (s) | Min (s) | Max (s) | Speedup
------------------------------------------------------------------------
2_core | 5 | 3749.6 | 3728.0 | 3772.0 | 1.00x
4_core | 5 | 3368.8 | 3128.0 | 3539.0 | 1.11x
8_core | 5 | 1810.6 | 1764.0 | 1912.0 | 2.07x
16_core | 5 | 1612.8 | 1571.0 | 1646.0 | 2.32x
PARALLEL vs SEQUENTIAL COMPARISON
-------------------------------------------------------------------------
Cores | Sequential Avg | Parallel Avg | Difference
-------------------------------------------------------------------------
2_core | 3749.6 s | 3196.0 s | +17.3%
4_core | 3368.8 s | 3166.6 s | +6.4%
8_core | 1810.6 s | 1129.2 s | +60.3%
16_core | 1612.8 s | 807.4 s | +99.8%
Resolves: rhbz#2401230
Add `## BUNDLED_GEMS_VERSIONS` and the symmetric
`## BUNDLED_GEMS_VERSIONS_END` for a script from ferut
'bundled_lib_versions.rb'. These tags are used to easily tell the
beginning and end of the section we can and want to edit by the
automation.
Remove duplicate syslog entry.
Move out default gemified libraries out into their place
into either the bundled gems section or the default gems section.
Reducing special cases helps lower complexity and length of the script.
In this case, there does not seem a big case to have these gems
specially handled in this section.
Properly sort sections alphabetically using the ruby's `Array#sort`
method.
Fedora OpenSSL 3.5 on rawhide stopped accepting SHA-1 PSS[1] parameters.
This is different from the SHA-1 signatures which Fedora OpenSSL stopped
accepting since Fedora 41.[2]
This commit fixes the following test failures related to the SHA-1 PSS
parameters with Fedora OpenSSL 3.5.
Note these failures are the downstream Fedora OpenSSL RPM specific.
```
184) Error:
OpenSSL::TestPKeyRSA#test_sign_verify_options:
OpenSSL::PKey::PKeyError: EVP_PKEY_CTX_ctrl_str(ctx, "rsa_mgf1_md", "SHA1"): digest not allowed (digest=SHA1)
/builddir/build/BUILD/ruby-3.4.2-build/ruby-3.4.2/test/openssl/test_pkey_rsa.rb:113:in 'Hash#each'
/builddir/build/BUILD/ruby-3.4.2-build/ruby-3.4.2/test/openssl/test_pkey_rsa.rb:113:in 'OpenSSL::PKey::PKey#sign'
/builddir/build/BUILD/ruby-3.4.2-build/ruby-3.4.2/test/openssl/test_pkey_rsa.rb:113:in 'OpenSSL::TestPKeyRSA#test_sign_verify_options'
185) Error:
OpenSSL::TestPKeyRSA#test_sign_verify_pss:
OpenSSL::PKey::RSAError: digest not allowed (digest=SHA1)
/builddir/build/BUILD/ruby-3.4.2-build/ruby-3.4.2/test/openssl/test_pkey_rsa.rb:191:in 'OpenSSL::PKey::RSA#sign_pss'
/builddir/build/BUILD/ruby-3.4.2-build/ruby-3.4.2/test/openssl/test_pkey_rsa.rb:191:in 'OpenSSL::TestPKeyRSA#test_sign_verify_pss'
Finished tests in 1152.595208s, 27.9812 tests/s, 5697.0278 assertions/s.
32251 tests, 6566367 assertions, 0 failures, 2 errors, 183 skips
```
According to a maintainer of the rpms/openssl, Dmitry Belyavskiy
<dbelyavs@redhat.com>, the following patch is disabling SHA-1 PSS parameters.
5f41d6a8f5/f/0018-RH-Allow-disabling-of-SHA1-signatures.patch
Resolves: rhbz#2358256
The header is useless in C++ and it is throwing a warning when it is
being included since GCC 15. libdnf5 uses -Werror which turns the
warning into an error making it fail to build.
Delete the include in ruby sources to allow such libraries to build
again with Ruby.
https://bugs.ruby-lang.org/issues/21024https://github.com/ruby/ruby/pull/12628
Resolves: rhbz#2336567
Add tests for RPM dependency generators that execute during build.
The tests make use of methods available in tools present in the
upstream ruby tar archive to find and set up the ruby executable.
This is then used to execute the dependency generator script with
a given test input passed into the subprocess and collect the output
given out by the generator for testing.
Skip "test_generator_on_gem_with_multiple_conflict_constraints" for
now. rubygems.req is currently only capable of filtering out a single
conflict requirement that is specified on a given dependency.
Execute it in the %check section before the long-running
Ruby test suite starts. If testing the generators fails it means there
is the possibility of generating bogus requires,
which is a valuable information to get sooner rather than later.
This commit is an improvement for the past commit
<d03ac3403a>.
According to the following part at the commit[1] on systemtap rawhide,
systemtap-sdt-devel RPM requires systemtap-sdt-dtrace RPM including the
`dtrace` command. We can remove the systemtap-sdt-dtrace build dependency.
```
%package sdt-devel
...
Requires: systemtap-sdt-dtrace = %{version}-%{release}
```
[1] https://src.fedoraproject.org/rpms/systemtap/c/93948388bc54cd7a4efb1806d9787291d26b33d6?branch=rawhide
Add systemtap-sdt-devel as BuildRequires to build Ruby with systemtap sdt header
files.
The commit[1] on systemtap rawhide by the change[2] on
systemtap-5.2~pre17206355g1a07290a-2.fc41 or later versions caused the
following error in the `test_systemtap.rb`.
Because the `readelf -S "#{LIBRUBY_SO}"` in the `test_systemtap.rb` failed to
find the systemtap section headers in the `libruby.so` file.
We relied on the `BuildRequires: %{_bindir}/dtrace` BuildRequires to bring in
all required files for systemtap support. However, after the change[1] that the
systemtap package was split, now we need to require systemtap sdt header files
on top of the dtrace executable to build Ruby with systemtap support to fix the
error.
```
+ make -C redhat-linux-build runruby TESTRUN_SCRIPT=/builddir/build/SOURCES/test_systemtap.rb
make: Entering directory '/builddir/build/BUILD/ruby-3.3.4-build/ruby-3.3.4/redhat-linux-build'
RUBY_ON_BUG='gdb -x /builddir/build/BUILD/ruby-3.3.4-build/ruby-3.3.4/.gdbinit -p' ./miniruby -I/builddir/build/BUILD/ruby-3.3.4-build/ruby-3.3.4/lib -I. -I.ext/common /builddir/build/BUILD/ruby-3.3.4-build/ruby-3.3.4/tool/runruby.rb --extout=.ext -- --disable-gems /builddir/build/SOURCES/test_systemtap.rb
ERROR: SystemTap (DTrace) headers were not detected in resulting library.
```
Co-authored-by: Lumír Balhar <lbalhar@redhat.com>
[1] https://src.fedoraproject.org/rpms/systemtap/c/93948388bc54cd7a4efb1806d9787291d26b33d6?branch=rawhide
[2] https://fedoraproject.org/wiki/Changes/Separate_dtrace_package
Previously, upstream flags were overriding our configuration flags,
therefore we had two workarounds in place. This commit replaces these
workarounds by upstream solution. While it should not result in any
functional changes, it is be better to have this patch in place to make
easier to spot when it is not needed anymore.
RPM 4.20 introduce per-build directory. However, this also brings some
issues where `%{_builddir}` might have different value in different
context, leading to issues such as:
~~~
Processing files: ruby-default-gems-3.3.1-8.fc41.noarch
make: *** /builddir/build/BUILD/ruby-3.3.1/redhat-linux-build: No such file or directory. Stop.
~~~
Therefore the generators are not executed properly. Use `%define`
instead of `%global`, because those are laze evaluated and actually
suggested by RPM upstream:
https://github.com/rpm-software-management/rpm/issues/3151
This is example of current build options:
~~~
gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fPIC -m64 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fno-strict-overflow -fvisibility=hidden -fexcess-precision=standard -DRUBY_EXPORT -I. -I.ext/include/x86_64-linux -I/builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1/include -I/builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1 -I/builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1/prism -I/builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1/enc/unicode/15.0.0 -o dmyext.o -c /builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1/dmyext.c
~~~
Please note that there are included Fedora options:
~~~
-Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3
~~~
as well as upstream options:
~~~
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2
~~~
The problem is that the configure script cannot properly detect
`_FORTIFY_SOURCE=3` and instead of replacing that option, it includes
new definition \[[1]\]. This happens since Fedora started to use
`_FORTIFY_SOURCE=3` option. To mitigate this issue, upstream
fortification was disabled (this might or might not stay disabled
"forever").
These are the build options with this change applied for comparison:
~~~
gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fPIC -m64 -fstack-protector-strong -fno-strict-overflow -fvisibility=hidden -fexcess-precision=standard -DRUBY_EXPORT -I. -I.ext/include/x86_64-linux -I/builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1/include -I/builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1 -I/builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1/prism -I/builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1/enc/unicode/15.0.0 -o dmyext.o -c /builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1/dmyext.c
~~~
[1]: https://bugs.ruby-lang.org/issues/20520
`checksec` output since v2.7.0 become more nuanced. Previously, the
`FORTIFY` could become just `Yes` / `No`. Now it can have also `Partial`
state, which better describe our situation.
Currently if e.g. `Fortifiable=28` and `Fortified=11`, that means that the
fortification is just partial and another 17 functions could be
fortified.
Also, check the numbers specifically, because this seems to be the
interesting information. Unfortunatelly, the results differ between
platforms.
Last but not least, use `sed` to analyze the output, because this allows to
always display the processed text. The trick comes from \[[1]\].
On top of this, use XML formatted output, which provides more context to
reader.
[1]: https://unix.stackexchange.com/questions/366/convince-grep-to-output-all-lines-not-just-those-with-matches
Resolves: rhbz#2282953
It is causing problems when network is in certain, valid, configuration.
The point of it is to workaround a glibc bug that is not present for us.
https://bugs.ruby-lang.org/issues/20208
To reproduce, have IPv6 enabled localhost but only IPv4
interfaces (such as eth0, name and count of them may vary based on system)
to disable public interfaces via sysctl:
`$ sysctl "net.ipv6.conf.<interface>.disable_ipv6=1"`
Where <interface> is NOT lo but can be eth0 or other.
Confirm with command `$ ip addr` command that only `lo`
interface has IPv6 address.
and run the following with Ruby 3.3:
~~~
$ ruby -rnet/http -e 'http = Net::HTTP.new("localhost", 8080); http.local_host = Addrinfo.tcp("localhost", 8080).ip_address; p http.get("/")'
~~~
The error is then related to EAFNOSUPPORT:
```
Errno::EAFNOSUPPORT: Failed to open TCP connection to localhost:37337 (Address family not supported by protocol - bind(2) for "::1" port 45395)
```
running above Ruby command with `strace` suggest that
there is an attempt to bind with AF_INET6
using an AF_INET socket, however, only if the reproducer above
attempts to set the `http.local_host` with Addrinfo.
From upstream issue #20208:
"This is calling getaddrinfo to resolve "localhost" for us to use
it as the local side of the connection. Because Ruby does not know
what you intend to do with this IP address, it does not make the request
with AI_ADDRCONFIG. Thus, you get an IPv6 result returned,
since there is an IPv6 addres for localhost!"
Armv8.3+ capable CPUs might segfault with incorrect compilation options.
See related upstream report: https://bugs.ruby-lang.org/issues/20085
We have hit this on COPR which uses [0] c7g.xlarge AWS flavor for aarch64
architecture builds. This machine flavor seems to fall into the ARMv8.3+
range.
Fedora CFLAGS come with `-mbranch-protection=standard` which means that
both BTI and the PAC protections are used. The option is equivalent
to `-mbranch-protection=pac-ret+bti`.
However, since the upstream configure.ac automatically appends
`-mbranch-protection=pac-ret`, the BTI protection is not used
as the last used option seems to overwrite [1] the Fedora
default for this.
To resolve both of these issues, of BTI being skipped and the potential
segfaults a patch is applied.
To fix segfaults an upstream patch was applied [2].
To fix the issue of overridden option I have patched the
configure.ac file to check for the `=standard` first when searching for a usable
`-mbranch-protection` option.
The overriding of our options was reported upstream:
<https://bugs.ruby-lang.org/issues/20154>
In the same issue I provided the extension of compilation option as an
attachment, to showcase a workaround that fixes the situation in Fedora.
[0] <https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Y4GPCGQAZT2LJ5CE7MTIEFKGAPP6O2DW/>
[1] <https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QWLEBS4YQH73HJNNLKCCGIIOU3SSXAYK/>
[2] <02973b78f4>
Tests fail with a LANG=C environment. A new investigation into the
failing tests on x86 revealed exact commits which introduced the issue
and the commits that fixed the situation. Fix is not yet present in Ruby
3.2, therefore the conditional disabling the tests was left in.
A new re-reported ticket replaced the old one. The new upstream ticket
includes better detailed description of the environment causing the
issue.
The tests pass in Rawhide mock (F40), as the LANG there is C.UTF-8
that does not suffer from the issue.
Upstream ticket: https://bugs.ruby-lang.org/issues/20045
RubyGems do internally the same \[[1]\]. This should help with:
1) Performance (not tested)
2) Running RubyGems test suite (main motivation), which actually
overrides the `@default_dir` \[[2]\] to be able to place test content
into dedicated directory.
[1]: f8e87eba76/lib/rubygems/defaults.rb (L38)
[2]: f8e87eba76/test/rubygems/helper.rb (L372)
libffi since NVR libffi-3.4.4-3.fc39 builds with static trampolines
enabled. This fixes the failures which were the reason for disabling
the tests.
Since it recently landed in Rawhide, we can re-enable the tests.
Revert "ruby.rpmlintrc: Add a filter for "E: shared-lib-without-dependency-information"."
This reverts commit aee17a2180.
This is not needed anymore, because Zuul runs rpmlint 2.0+ already.
The rhbz#2043092 is not resolved. Nevertheless, the generation of
package notes should not break builds of rubygem- packages anymore.
Nevertheless, the additional linker options will keep making issues for
`gem install`ed gems. Nothing new here unfortunately.
Fiddle::Closure object is making use of FFI closure
from libffi. When such object is created (instantiated) in Ruby,
and then the process forks on an SELinux-enabled system, the memory
will become corrupted. That is usually not a problem until the
The garbage collector sweeps the object and tries to free it, in which case the
Ruby process will fail with signal SIGABRT.
Tests in test/fiddle/test_closure.rb, test/fiddle/test_func.rb,
and test/fiddle/test_function.rb use the `Fiddle::Closure` class
directly and fiddle/test_import.rb use the class indirectly through
`bind_function` method, therefore they are disabled to prevent
introducing the problematic object into the Ruby GC during test suite
execution instead of relying on that fork and subsequent
garbage collection will not happen.
If an FFI closure object is allocated in Ruby
and the `fork` function is used afterward, the memory
pointing to the closure gets corrupted, and if Ruby GC
tries to collect the object in that state, a SIGABRT
error occurs.
The minimal Ruby reproducer for the issue is the following:
~~~
$ cat fiddle_fork.rb
require 'fiddle/closure'
require 'fiddle/struct'
Fiddle::Closure.new(Fiddle::TYPE_VOID, [])
fork { }
GC.start
~~~
We allocate an unused Closure object,
so it is free for the GC to pick up. Before we call `GC.start`
we fork the process as that corrupts the memory.
Running this with ruby-3.1.2-167.fc37.x86_64 on SELinux enabled system:
~~~
$ ruby fiddle_fork.rb
Aborted (core dumped)
~~~
Such issues may appear at random (depending on the use of forking and GC)
in larger applications that use Fiddle::Closure but can be spotted by the
following functions appearing in the coredump backtrace:
~~~
0x00007f6284d3e5b3 in dlfree (mem=<optimized out>) at ../src/dlmalloc.c:4350
0x00007f6284d6d0b1 in dealloc () from /usr/lib64/ruby/fiddle.so
0x00007f6295e432ec in finalize_list () from /lib64/libruby.so.3.1
0x00007f6295e43420 in finalize_deferred.lto_priv () from /lib64/libruby.so.3.1
0x00007f6295e4ff1c in gc_start_internal.lto_priv () from /lib64/libruby.so.3.1
~~~
Possible solutions to prevent Ruby from crashing:
* Do not use Fiddle::Closure.
* Use the Fiddle::Closure object only in isolated subprocess that
will not fork further.
* Enable static trampolines in libffi as noted in bugzilla comment:
<https://bugzilla.redhat.com/show_bug.cgi?id=2040380#c9>
See related discussion on
<https://bugzilla.redhat.com/show_bug.cgi?id=2040380>
Ruby upstream ticket:
<https://bugs.ruby-lang.org/issues/18914>
Ruby Fiddle ticket:
<https://github.com/ruby/fiddle/issues/102>
RPM 4.18.0-beta1 or later versions remove the build directory
automatically, the build fails on removing temporary directories with
the missing 'w' bit.
RubyGems contain this patch since version 3.3.8.
This was merged to ruby_3_1 branch in upstream ruby, but it is not
included in the v3_1_2 tag, so new Ruby 3.1 release should contain this
change.
Relevant RPM upstream PR: https://github.com/rpm-software-management/rpm/pull/2080
Relevant bug: https://bugzilla.redhat.com/show_bug.cgi?id=2105393
Previous commit changed GC compaction methods to not be implemented
when not supported. However, that commit only does compile time checks,
but there are additional compaction support checks during run time.
This commit changes it so that GC compaction methods aren't defined
also during run time if the platform does not support GC compaction.
The patch is manually backported from following change set:
https://github.com/ruby/ruby/pull/60192c19086323
To apply the patch included with this commit,
first apply `ruby-3.2.0-define-unsupported-gc-compaction-methods-as-rb_f_notimplement.patch`
and then apply the `ruby-3.2.0-detect_compaction_support_during_runtime.patch`.
Related upstream issue: https://bugs.ruby-lang.org/issues/18829
The patch implements the methods as rb_f_notimplement.
To test for compaction users can now use `GC.respond_to?(:compact)`.
The upstream patch relies on the macro `GC_COMPACTION_SUPPORTED`
that is defined when the `__wasi__` is false. The define is defined by
an arch conditional in the specfile, which is not optimal but works in our case.
663833b08fhttps://bugs.ruby-lang.org/issues/18829
This also requires regenerating the gc.rbinc and miniprelude.c
since the patch touches gc.rb. This patch is available in
ruby-3.2.0-define-unsupported-gc-compaction-methods_generated-files.patch.
To regenerate the gc.rbinc and miniprelude.c files patch:
~~~
tar -Jxvf ./ruby-3.1.2.tar.xz
git clone https://github.com/ruby/ruby.git
cd ruby && git checkout v3_1_2
patch -p1 < ../ruby-3.2.0-define-unsupported-gc-compaction-methods-as-rb_f_notimplement.patch
./autogen.sh && ./configure
make gc.rbinc miniprelude.c
cd ..
diff -u {ruby-3.1.2,ruby}/gc.rbinc > ruby-3.2.0-define-unsupported-gc-compaction-methods_generated-files.patch
diff -u {ruby-3.1.2,ruby}/miniprelude.c >> ruby-3.2.0-define-unsupported-gc-compaction-methods_generated-files.patch
~~~
Uptream bug: https://bugs.ruby-lang.org/issues/18779
Upstream PR: https://github.com/ruby/ruby/pull/5934
According to the <https://bugs.ruby-lang.org/issues/18756>, the `Q=` is not
recommended. The `V=1` is recommended to output for the verbose mode.
The `make V=1` suppresses some logs that `make` without `V=1` outputs rather
than just adding verbose logs.
While the `V=1 ECHO0=echo` is more equivalent with `Q=`, the
`make V=1 ECHO0=echo` doesn't really output meaningful logs additionally.
So, the `make V=1` is the best option for us to check the compiler flags.
Because the `%make_build` macro includes the `V=1`. Note there is no actual
difference of build.log between before and after this commit.
```
$ rpm --eval %make_build
/usr/bin/make -O -j8 V=1 VERBOSE=1
```
Because the gem extensions were built in `%{buildroot}` they referred
`BUILDROOT` directory, which would be under normal circumstances
reported by RPM, but there was a bug in RPM due to changes in grep:
https://github.com/rpm-software-management/rpm/issues/1968
* Add `make test-bundler-parallel` executed on the upstream CI.
See <41a48535d1/.github/workflows/ubuntu.yml (L22)>.
* The tests are disabled as a default, as it requires the internet.
Run the Bundler tests as follows.
```
$ mock --with bundler_tests ruby-3.1.0-161.fc37.src.rpm
```
* Fix a test for `bin/bundle update --bundler` in `make test-bundler`.
This error is gone as false positive in rpmlint 2.0+. However the rpmlint
version on Zuul CI running on the Fedora 34 container is still 1.11. After Zuul
CI is upgraded to Fedora 35+ container, and uses the rpmlint 2, we can notice
this filter is not used by "E: unused-rpmlintrc-filter" error, and remove it.
This replaces the parts of the original PR with official patches which
landed in [ruby/openssl](https://github.com/ruby/openssl) repository and
should reflect the state of OpenSSL 3 support in Ruby 3.1.
In Ruby 3.0.3, a new logic with the hard-coded "libc.so.6" to detect glibc
works on PPC, both Power 8 and 9.
See <https://bugs.ruby-lang.org/issues/12666#note-13>.
Note the logic also fixes the following error on a Power 9 environment where
the path is `/lib64/glibc-hwcaps/power9/libc-2.28.so`.
```
/builddir/build/BUILD/ruby-2.6.9/.ext/common/fiddle/import.rb:299:in `import_function': cannot find the function: strcpy() (Fiddle::DLError)
from /builddir/build/BUILD/ruby-2.6.9/.ext/common/fiddle/import.rb:172:in `extern'
from /builddir/build/BUILD/ruby-2.6.9/test/fiddle/test_import.rb:17:in `<module:LIBC>'
from /builddir/build/BUILD/ruby-2.6.9/test/fiddle/test_import.rb:10:in `<module:Fiddle>'
from /builddir/build/BUILD/ruby-2.6.9/test/fiddle/test_import.rb:9:in `<top (required)>'
from /builddir/build/BUILD/ruby-2.6.9/test/lib/test/unit.rb:958:in `require'
from /builddir/build/BUILD/ruby-2.6.9/test/lib/test/unit.rb:958:in `block in non_options'
from /builddir/build/BUILD/ruby-2.6.9/test/lib/test/unit.rb:952:in `each'
from /builddir/build/BUILD/ruby-2.6.9/test/lib/test/unit.rb:952:in `non_options'
from /builddir/build/BUILD/ruby-2.6.9/test/lib/test/unit.rb:64:in `process_args'
from /builddir/build/BUILD/ruby-2.6.9/test/lib/test/unit.rb:130:in `process_args'
from /builddir/build/BUILD/ruby-2.6.9/test/lib/test/unit.rb:1136:in `process_args'
from /builddir/build/BUILD/ruby-2.6.9/test/lib/test/unit.rb:1141:in `run'
from /builddir/build/BUILD/ruby-2.6.9/test/lib/test/unit.rb:1148:in `run'
from ./test/runner.rb:33:in `<main>'
```
- Fix command injection vulnerability in RDoc.
Resolves: CVE-2021-31799
- Fix FTP PASV command response can cause Net::FTP to connect to arbitrary host.
Resolves: CVE-2021-31810
- Fix StartTLS stripping vulnerability in Net::IMAP.
Resolves: CVE-2021-32066
- Fix dependencies of gems with explicit source installed from a different
source.
Resolves: CVE-2020-36327
A result of ruby.spec file depends on how the spec file is called by rpmlint.
```
$ rpmlint ruby.spec
ruby.spec:20: E: use-of-RPM_SOURCE_DIR
..
0 packages and 1 specfiles checked; 3 errors, 4 warnings.
$ rpmlint ./ruby.spec
./ruby.spec:20: E: use-of-RPM_SOURCE_DIR
..
0 packages and 1 specfiles checked; 3 errors, 4 warnings.
```
Nothing referred and no dependency information should be no problem.
Ignore the following error.
```
ruby-libs.x86_64: E: shared-lib-without-dependency-information /usr/lib64/ruby/enc/gb2312.so
```
The `chroot` in the `dir.c` is just used as a Ruby binding `Dir.chroot`
for the function.
Ignore the following error.
```
ruby-libs.x86_64: E: missing-call-to-chdir-with-chroot /usr/lib64/libruby.so.3.0.1
```
The FTBFS has started to happen with rpm-4.16.90-0.git15395.2.fc35.
root.log
```
DEBUG util.py:444: error: line 116: Unknown tag: /chroot_tmpdir/srpm_unpacked/SOURCES/macros.ruby
```
As the `%{?load:...}` is undocumented, it is gone.
https://github.com/rpm-software-management/rpm/issues/1669
Ignore the false positive errors and warnings by the
`rpmlint --file ruby.rpmlintrc`, that is executed by Zuul CI.
You can run the command on your local like this.
```
$ rpmlint --file ruby.rpmlintrc ruby.spec /var/lib/mock/fedora-rawhide-x86_64/result/*.rpm
```
The `rpmlint` without `--file` option shows the original result.
Symlinks to StdLib provided to preserve `--disable-gems` functionality
together with `require_relative` cause double loading issues [1], e.g.:
~~~
$ ruby --disable-gems -e 'require "openssl"; require "openssl/digest"'
/usr/share/ruby/openssl/digest.rb:45: warning: already initialized constant OpenSSL::Digest::MD4
/usr/share/gems/gems/openssl-2.2.0/lib/openssl/digest.rb:45: warning: previous definition of MD4 was here
/usr/share/ruby/openssl/digest.rb:45: warning: already initialized constant OpenSSL::Digest::MD5
/usr/share/gems/gems/openssl-2.2.0/lib/openssl/digest.rb:45: warning: previous definition of MD5 was here
/usr/share/ruby/openssl/digest.rb:45: warning: already initialized constant OpenSSL::Digest::RIPEMD160
/usr/share/gems/gems/openssl-2.2.0/lib/openssl/digest.rb:45: warning: previous definition of RIPEMD160 was here
/usr/share/ruby/openssl/digest.rb:45: warning: already initialized constant OpenSSL::Digest::SHA1
/usr/share/gems/gems/openssl-2.2.0/lib/openssl/digest.rb:45: warning: previous definition of SHA1 was here
/usr/share/ruby/openssl/digest.rb:45: warning: already initialized constant OpenSSL::Digest::SHA224
/usr/share/gems/gems/openssl-2.2.0/lib/openssl/digest.rb:45: warning: previous definition of SHA224 was here
/usr/share/ruby/openssl/digest.rb:45: warning: already initialized constant OpenSSL::Digest::SHA256
/usr/share/gems/gems/openssl-2.2.0/lib/openssl/digest.rb:45: warning: previous definition of SHA256 was here
/usr/share/ruby/openssl/digest.rb:45: warning: already initialized constant OpenSSL::Digest::SHA384
/usr/share/gems/gems/openssl-2.2.0/lib/openssl/digest.rb:45: warning: previous definition of SHA384 was here
/usr/share/ruby/openssl/digest.rb:45: warning: already initialized constant OpenSSL::Digest::SHA512
/usr/share/gems/gems/openssl-2.2.0/lib/openssl/digest.rb:45: warning: previous definition of SHA512 was here
/usr/share/ruby/openssl/digest.rb:52:in `<class:Digest>': superclass mismatch for class Digest (TypeError)
from /usr/share/ruby/openssl/digest.rb:16:in `<module:OpenSSL>'
from /usr/share/ruby/openssl/digest.rb:15:in `<top (required)>'
from -e:1:in `require'
from -e:1:in `<main>'
~~~
We could maintain a downstream patch reverting the `require_relative`,
but given that how much troubles the extracted gems cause, it'll be
better to keep them bundled. This will provide similar experience to
upstream and prevent similar issues.
[1]: https://bugs.ruby-lang.org/issues/16978#note-11
When the `gem.build_complete` file is not present, Bundler treats the
package as uninstalled, therefore leaves it out from the dependency
resolution with error such as:
~~~
Could not find gem 'openssl', which is required by gem 'net-ssh', in any of the sources.
~~~
[1] 1969e8adfc/bundler/lib/bundler/source/rubygems.rb (L353-L384)
This fixes IRB failures:
~~~
$ irb
/usr/share/rubygems/rubygems/specification.rb:1398:in `rescue in block in activate_dependencies': Could not find 'io-console' (~> 0.5) among 76 total gem(s) (Gem::MissingSpecError)
Checked in 'GEM_PATH=/builddir/.local/share/gem/ruby:/usr/share/gems:/usr/local/share/gems' at: /usr/share/gems/specifications/reline-0.2.0.gemspec, execute `gem env` for more information
from /usr/share/rubygems/rubygems/specification.rb:1395:in `block in activate_dependencies'
from /usr/share/rubygems/rubygems/specification.rb:1384:in `each'
from /usr/share/rubygems/rubygems/specification.rb:1384:in `activate_dependencies'
from /usr/share/rubygems/rubygems/specification.rb:1366:in `activate'
from /usr/share/rubygems/rubygems/specification.rb:1402:in `block in activate_dependencies'
from /usr/share/rubygems/rubygems/specification.rb:1384:in `each'
from /usr/share/rubygems/rubygems/specification.rb:1384:in `activate_dependencies'
from /usr/share/rubygems/rubygems/specification.rb:1366:in `activate'
from /usr/share/rubygems/rubygems.rb:302:in `block in activate_bin_path'
from /usr/share/rubygems/rubygems.rb:301:in `synchronize'
from /usr/share/rubygems/rubygems.rb:301:in `activate_bin_path'
from /usr/bin/irb:23:in `<main>'
/usr/share/rubygems/rubygems/dependency.rb:307:in `to_specs': Could not find 'io-console' (~> 0.5) among 76 total gem(s) (Gem::MissingSpecError)
Checked in 'GEM_PATH=/builddir/.local/share/gem/ruby:/usr/share/gems:/usr/local/share/gems' , execute `gem env` for more information
from /usr/share/rubygems/rubygems/specification.rb:1396:in `block in activate_dependencies'
from /usr/share/rubygems/rubygems/specification.rb:1384:in `each'
from /usr/share/rubygems/rubygems/specification.rb:1384:in `activate_dependencies'
from /usr/share/rubygems/rubygems/specification.rb:1366:in `activate'
from /usr/share/rubygems/rubygems/specification.rb:1402:in `block in activate_dependencies'
from /usr/share/rubygems/rubygems/specification.rb:1384:in `each'
from /usr/share/rubygems/rubygems/specification.rb:1384:in `activate_dependencies'
from /usr/share/rubygems/rubygems/specification.rb:1366:in `activate'
from /usr/share/rubygems/rubygems.rb:302:in `block in activate_bin_path'
from /usr/share/rubygems/rubygems.rb:301:in `synchronize'
from /usr/share/rubygems/rubygems.rb:301:in `activate_bin_path'
from /usr/bin/irb:23:in `<main>'
~~~
RubyGems 3.2.0 rewored their plugins system for improvement performance
[[1]]. Each RubyGems plugins has now generated loader stub during
installation. This directory needs to have proper ownership.
[1]: https://github.com/rubygems/rubygems/pull/3108
* Extract RSS and REXML into separate subpackages, because they were moved from
default gems to bundled gems.
* Obsolete Net::Telnet and XMLRPC packages, because they were dropped from Ruby.
The detailed changelog leading to this release is preserved in
private-ruby-3.0 branch.
as it's needed for building (gem install ...) gems with binary extensions.
This is a workaround to have /usr/lib/rpm/redhat/redhat-hardened-cc1
on the system, as same CFLAGS are reused from when Ruby was built.
Resolves: rhbz#1905222
Because setting the option makes some tests stable that are currently randomly
failing with error on especially s390x and aarch64.
We observed the failing tests are calling `assert_in_out_err` method
calling `invoke_ruby` calling method.
Then when the `th_stdout.join(timeout)` or `th_stderr.join(timeout)` returns
`nil` as thread timeout in `invoke_ruby` method, it causes the error. [1][2]
The `test_timeout_scale` macro is to set the environment variable
`RUBY_TEST_TIMEOUT_SCALE` to increase the timeout in `apply_timeout_scale`
method as <new timeout> = <timeout> * <timeout scale>.
As an example, `TestBugReporter#test_bug_reporter_add` test's
maximum thread timeout was 56+ seconds for the default timeout 10 seconds. [3]
In this case setting `RUBY_TEST_TIMEOUT_SCALE=6` (6 * 10 = 60) is good enough
for 56+ seconds.
[1] https://github.com/ruby/ruby/blob/v2_7_1/tool/lib/envutil.rb#L149
[2] https://bugs.ruby-lang.org/issues/16492#note-8
[3] https://bugs.ruby-lang.org/issues/16492#note-4
Independent rubygems package used to provide rubygems-devel subpackages,
but this is going to change to ease the independent rubygems package
maitenance and therefore ruby package will become the ultimate source of
rubygems-devel package.
It is increasingly hard to maintain default gems extracted from StdLib
into gems. If they are overlapped by independent versions, it is even
harder, because the overlapped versions would need to provide symlinks
back to StdLib \[[1]\]. On top of that, the layout differs from
upstream, where default gems are always available.
Because these small nuances can make hard discoverable race conditions
during Ruby application loading and runtime, it will be best to keep the
default gems bundled.
[1]: https://src.fedoraproject.org/rpms/rubygem-racc/pull-request/1
From 0689147586c6cb56b91bf0f368890f19d630ece1 Mon Sep 17 00:00:00 2001
From: nobletrout <nobletrout@gmail.com>
Date: Tue, 5 Feb 2019 08:14:02 -0500
Subject: [PATCH] remove unneeded gem require for ipaddr
ipaddr is a builtin class for ruby, that is occasionally merged. If the version isn't specified by the runtime dependency, then it will default to needing the latest gem rather than the version that ships with that version of ruby. That will lead to all kinds of potential dependency fails that are most likely unneeded since this gem already requires ruby > 2.3.0