Hi everybody,
Since Ruby 2.2 is going to be released during Christmas and -preview1
release is imminent (this Wednesday?), it is probably time to start
looking into its packaging. So here is the updated .spec file [1] and
scratch build [2], which can be finally build on all platforms. Sorry,
no Copr for you, since Ruby's build fails there due to old RHEL kernel :/.
What has changed from packaging point of view? Luckily, not much, but
here are a few bullets which comes to my mind:
* RPM 4.12 introduces new %load function, which is used to load RPM
macros during RPM build. This allowed to drop my custom RPM macro [3].
On the other hand, you'll be able to build the Ruby only on F21+
(luckily, you should be able to build SRPM everywhere).
* The RubyGems filesystem was not explicit enough, so there might be
something accidentally packages. This is now more explicit, so we should
be safer.
* Ruby now ships with MiniTest and Test::Unit. The very good news is
that they are installed so far as a regular gems. This means that you
have to always specify them in your Gemfile, if you are using Bundler,
but this is generally step in good direction. I hope that upstream will
not change their mind :) Due to this change, we have new subpackages
rubygem-test-unit (and rubygem-power_assert, which is now Test::Unit's
dependency). No more %{_bindir}/testrb (but nobody is using it these
days anyway, right? ;)
* Some prevailing test failures were resolved, some others introduced,
but hopefully they'll get resolved prior stable release.
Generally, I'd say that not much has changed since 2.1, which is good news.
Please test the packaging if you can and let me know about any issues
you encountered.
Also, if you have any other suggestions about Ruby packaging in general,
what we could improve etc, this is probably good time to share. It seems
that OpenSUSE guys are improving their packaging, so you might want to
get some inspiration there [4, 5, 6] ;)
Vít
[1] http://pkgs.fedoraproject.org/cgit/ruby.git/log/?h=private-ruby-2.2
[2] http://koji.fedoraproject.org/koji/taskinfo?taskID=7578843
[3]
http://pkgs.fedoraproject.org/cgit/ruby.git/commit/?h=private-ruby-2.2&id=8…
[4] https://build.opensuse.org/package/show/home:darix:ruby/ruby-common
[5] https://build.opensuse.org/package/show/home:darix:ruby/ruby2.2
[6] https://github.com/openSUSE/gem2rpm/commits/master
Hi everybody,
I started early this time and therefore, there is already PR with
changes for upcoming Ruby version:
https://src.fedoraproject.org/rpms/ruby/pull-request/55
and the build should be available (if succeeds) here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=41848663
So far, there are changes in bundled gems. The RSS and REXML gems are
not bundled gems, therefore I extracted them into separate subpackages,
while Net::Telnet and XMLRPC were dropped from Ruby and therefore
ruby-libs now obsoletes these two packages.
As always, any feedback is welcome.
Vít
Hi all,
Ruby upstream is implementing more and more stuff directly in Ruby. We
already had issues, that build of Ruby required Ruby when we did some
modifications [1]. In subsequent ticket, one of Ruby committers said [2]:
> ... snip ...
> BASERUBY is already a build requirement
> ... snip ...
> I would like to implement more of Ruby using Ruby, so miniruby may
depend on prelude one day.
With recent changes, such as [3], I am afraid that the day has come.
Previously, if you wanted to patch lets say "gem_prelude.rb", it was
enough to patch it. But now you *need* Ruby to process it into
miniprelude.c. There are possibly 4 ways out of this.
1) Build Ruby in two stages. a) build (mini)ruby, apply patches b) build
Ruby using the previously built (mini)ruby.
2) Use previous version of Ruby available in Fedora to bootstrap Ruby.
But this does not work ATM, at least when RubyGems are installed. And
upstream is doing what they can to make RubyGems inseparable [4].
3) Prepare patches locally and apply the required changes also to the
pregenerated files. But the problem here is, that the patches might
unpredictably fail between updates. I don't think that they keep any
API/ABI promises for the tools used to generate those files.
4) Don't use the upstream tarball, but generate it from sources with
patches integrated.
I think we should probably start to take look at 1), specifically into
the *miniruby* variant if that is enough. If that is done, the 2) could
optionally blend in. And in the mean time use 3) because otherwise I
really don't know how to integrate the ABRT hook support. I don't like
4) at all, unless we have some Fedora standardized way of doing so.
On the positive side, 1(2) would allow us to stay better in line with
"Pregenerated code" guidelines [5], because there is already quite a lot
of pre-generated code shipped in Ruby release tarball.
Thoughts?
Vít
[1]
https://src.fedoraproject.org/rpms/ruby/c/c0513dfb8c81a228619c6142195c5117a…
[2] https://bugs.ruby-lang.org/issues/15306#note-1
[3] https://github.com/ruby/ruby/pull/2655
[4] https://bugs.ruby-lang.org/issues/16431
[5]
https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packa…
I tried to run the Ruby 2.7 module builds with
https://src.fedoraproject.org/modules/ruby/tree/master ruby.yaml,
using the rpms/ruby master HEAD on 22th May.
Now when running `fedpkg module-build` command, it is built on 5
builtroots f33, f32, f31, f30, el8.
Maybe the el8 target was added recently.
```
$ fepkg co modules/ruby
$ cd ruby
$ fedpkg module-build
Submitting the module build...
The builds 8964, 8965, 8966, 8967 and 8968 were submitted to the MBS
Build URLs:
https://mbs.fedoraproject.org/module-build-service/2/module-builds/8964https://mbs.fedoraproject.org/module-build-service/2/module-builds/8965https://mbs.fedoraproject.org/module-build-service/2/module-builds/8966https://mbs.fedoraproject.org/module-build-service/2/module-builds/8967https://mbs.fedoraproject.org/module-build-service/2/module-builds/8968
```
## Result
Seeing the current result of the builds, there are 3 kinds of failures.
1. s390x specific failures. Segmentation Fault in tests. (f33, f32, f31)
But when running the scratch build for rpms/ruby today 25th May, it succeeded.
https://koji.fedoraproject.org/koji/taskinfo?taskID=44954981
Do you know what is the reason for the error?
2. The failure of `checksec --file=libruby.so.2.7.1` (f30)
Possibly checksec 1.11.1-1.fc30, the old version does not support
--file option.
To avoid running checksec on f30, I am planning to set the following
macro in modules/ruby ruby.yaml.
```
buildopts:
rpms:
macros: |
%_without_hardening_test 1
```
3. error: one or more PCH files were found, but they were invalid (el8).
This is a known issue on the RHEL8 gcc setting.
https://bugzilla.redhat.com/show_bug.cgi?id=1721553
I think Fedora rawhide rpms/ruby ruby.spec needs to add a %if logic
to skip the tests on el8 target.
Or it needs to add this kind of logic:
%bcond_without jit_pch
Any opinions to fix this?
## Detail log
### f33 (rawhide)
$ fedpkg module-build-info 8965
f33: FAILED: ruby:
https://koji.fedoraproject.org/koji/taskinfo?taskID=44825779
s390x: https://kojipkgs.fedoraproject.org//work/tasks/5879/44825879/build.log
1) Error:
TestBugReporter#test_bug_reporter_add:
Timeout::Error: execution of assert_in_out_err expired timeout (30 sec)
pid 2477783 killed by SIGKILL (signal 9)
### f32
$ fedpkg module-build-info 8966
f32: FAILED: ruby:
https://koji.fedoraproject.org/koji/taskinfo?taskID=44824056
s390x: https://kojipkgs.fedoraproject.org//work/tasks/4292/44824292/build.log
1) Failure:
Fiddle::TestFunction#test_nogvl_poll
[/builddir/build/BUILD/ruby-2.7.1/test/fiddle/test_function.rb:95]:
slept amount of time.
Expected |200 - 714| (514) to be <= 180.
2) Error:
TestBugReporter#test_bug_reporter_add:
Timeout::Error: execution of assert_in_out_err expired timeout (30 sec)
pid 229068 killed by SIGKILL (signal 9)
### f31
$ fedpkg module-build-info 8967
f31: FAILED: ruby:
https://koji.fedoraproject.org/koji/taskinfo?taskID=44824127
s390x: https://kojipkgs.fedoraproject.org//work/tasks/4208/44824208/build.log
1) Error:
TestIO#test_dup_many:
Timeout::Error: execution of assert_separately expired timeout (10 sec)
pid 2679628 exit 1
2) Error:
TestProcess#test_status_quit:
Timeout::Error: execution of assert_in_out_err expired timeout (10 sec)
pid 2682640 killed by SIGKILL (signal 9)
|-
/builddir/build/BUILD/ruby-2.7.1/test/ruby/test_process.rb:1446:in
`block in test_status_quit'
/builddir/build/BUILD/ruby-2.7.1/test/ruby/test_process.rb:37:in
`block (2 levels) in with_tmpchdir'
/builddir/build/BUILD/ruby-2.7.1/test/ruby/test_process.rb:36:in `chdir'
/builddir/build/BUILD/ruby-2.7.1/test/ruby/test_process.rb:36:in
`block in with_tmpchdir'
/builddir/build/BUILD/ruby-2.7.1/lib/tmpdir.rb:89:in `mktmpdir'
/builddir/build/BUILD/ruby-2.7.1/test/ruby/test_process.rb:34:in
`with_tmpchdir'
/builddir/build/BUILD/ruby-2.7.1/test/ruby/test_process.rb:1445:in
`test_status_quit'
3) Error:
TestRubyOptions#test_segv_test:
Timeout::Error: execution of assert_in_out_err expired timeout (10 sec)
pid 2683275 killed by SIGABRT (signal 6) (core dumped)
### f30
$ fedpkg module-build-info 8964
f30: FAILED: ruby:
https://koji.fedoraproject.org/koji/taskinfo?taskID=44825807
Error on all the architectures.
x86_64, and etc:
checksec: 1.11.1-1.fc30
https://kojipkgs.fedoraproject.org//work/tasks/5913/44825913/build.log
+ cd ruby-2.7.1
+ checksec --file=libruby.so.2.7.1
+ grep 'Full RELRO.*Canary found.*NX enabled.*DSO.*No RPATH.*No
RUNPATH.*Yes.*\d*.*\d*.*libruby.so.2.7.1'
### el8
$ fedpkg module-build-info 8968
el8: FAILED: ruby:
https://koji.fedoraproject.org/koji/taskinfo?taskID=44823939https://kojipkgs.fedoraproject.org//work/tasks/4041/44824041/build.log
Error on all the architectures.
1) Failure:
TestJIT#test_attr_reader
[/builddir/build/BUILD/ruby-2.7.1/test/ruby/test_jit.rb:812]:
Expected 2 times of JIT success, but succeeded 0 times.
...
/tmp/_ruby_mjit_p2552165u0.c:1:41: error: one or more PCH files were
found, but they were invalid
#include "/tmp/_ruby_mjit_hp2552165u0.h"
^
...
Cheers,
Jun
--
Jun | He - His - Him
Hi all,
The independent "rubygems" package was retired, because it FTBFS already
for some while:
https://src.fedoraproject.org/rpms/rubygems/c/366607586d95b505277165fce54d9…
Now I wonder, do we care? Should I unretire it while there is a chance
to do it without review or we don't care and we are fine with the
bundled version shipped in Ruby? Obviously if I was convinced we really
need it, I'd did that without asking. So what are your opinions?
Vít
Hi there,
I have bumped the version of a package I maintain in Fedora and am seeing
an increase in errors from the test suite run.
https://kojipkgs.fedoraproject.org//work/tasks/6453/44116453/build.log
I'm specifically trying to understand the errors regarding being unable to
locate the binary and the eql errors as these form the majority.
I have asked about the latter upstream a while back:
https://github.com/asciidoctor/asciidoctor-pdf/issues/1542
and received comment about there possibly being a problem with rspec itself?
Any advice appreciated.
--
Christopher Brown