* 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
