Ruby 2.2
by Vít Ondruch
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...
[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
5 days, 22 hours
Two stage Ruby compilation / Bootstrapping
by Vít Ondruch
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/c0513dfb8c81a228619c6142195c511...
[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-pac...
2 years, 10 months
rubygem-openssl changes in rawhide
by Pavel Valena
Hello,
it seems Ruby 2.7 came with some openssl surprise, because for some reason Vagrant testsuite breaks:
https://copr-be.cloud.fedoraproject.org/results/pvalena/vagrant/fedora-ra...
https://koji.fedoraproject.org/koji/taskinfo?taskID=41097171
f.e.:
```
An error occurred while loading ./test/unit/plugins/pushes/ftp/push_test.rb.
Failure/Error: class Cipher < Cipher; end
TypeError:
superclass mismatch for class Cipher
# /usr/share/gems/gems/openssl-2.1.2/lib/openssl/cipher.rb:64:in `<class:Cipher>'
# /usr/share/gems/gems/openssl-2.1.2/lib/openssl/cipher.rb:16:in `<module:OpenSSL>'
# /usr/share/gems/gems/openssl-2.1.2/lib/openssl/cipher.rb:15:in `<top (required)>'
# /usr/share/gems/gems/openssl-2.1.2/lib/openssl.rb:17:in `<top (required)>'
# /usr/share/ruby/net/ftp.rb:23:in `<top (required)>'
# ./plugins/pushes/ftp/push.rb:1:in `<top (required)>'
# ./test/unit/plugins/pushes/ftp/push_test.rb:4:in `<top (required)>'
```
But to my best efforts I wasn't able to trace it to the source.
Ideas?
Pavel
3 years, 8 months
Ruby 2.7 - Mass rebuild
by Vít Ondruch
Hi everybody,
This years schedule does not give us too much freedom, because the
Fedora mass rebuild is scheduled for the 22nd of January, which is in a
few days. There are also some concerns with keyword arguments, but since
I have no idea how problematic this might be, I decided to give it a go.
It seems that nowadays, everybody is able to ask for side tag via
`fedpkg` so I acquired one:
~~~
$ fedpkg request-side-tag
Side tag 'f32-build-side-17977' (id 17977) created.
Use 'fedpkg build --target=f32-build-side-17977' to use it.
Use 'koji wait-repo f32-build-side-17977' to wait for the build repo to
be generated.
~~~
The name is not really nice, but ... So now, there is a opportunity for
your help.
This is the 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 the package and just fire rebuild, but please ensure that
you are using f30-ruby build target [2], i.e. the build command should
look like:
~~~
$ fedpkg build --target f32-build-side-17977
~~~
Please be careful, because if you, by a chance, omit the
f32-build-side-17977 target, you'll be building against Ruby 2.6 which
is not what you want.
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 [1] to help me with
that. If you don't want me to touch your packages for whatever reason,
please let me know.
You can follow the progress at:
https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=17977&order=...
or using:
~~~
$ koji list-tagged f32-build-side-17977
~~~
As always, any help/testing/feedback is welcome.
Vít
[1] https://github.com/fedora-ruby/fermig
[2] https://bugs.ruby-lang.org/issues/16431
[3]
https://src.fedoraproject.org/rpms/ruby-ldap/c/9a16c79b85525ef9636aa50e17...
3 years, 8 months
Ruby 2.7
by Vít Ondruch
Hi everybody,
I have create PR with .spec file, which will eventually become Ruby 2.7
package in Fedora some time around beginning of next year:
https://src.fedoraproject.org/rpms/ruby/pull-request/48
and this is associated scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=36285060
I was considering, if I should open PR from my fork or push everything
into the main repository, but I have decided to push directly into
private-ruby-2.7 branch, so all the changes are preserved.
Now what has changed?
* Upstream move to Git, so I have updated the .spec file to use git
hashes instead of SVN releases. No upgrade path is guaranteed.
* The bundled gems now ships with RubyGems stubs, that means there
should not be conflicts between for example /usr/bin/rake shipped by
ruby and rubygem-rake. That should make it easier to install these
packages side by side (and help for example with Bundler 2.x transition).
* The bundler Racc now ships with its executable, therefore I have
decided to move it into rubygem-racc subpackage.
* I have removed support for %{rubygems_default_filter} macro. Nobody
(except rubygem-rugged) ever used this macro and it never provided any
real functionality (rhbz#1020810).
And that is it. I'll keep updating the branch as I find time.
As always, I welcome any feedback here or in the PR.
Vít
3 years, 8 months
4 steps to be get sponsored for ruby-sig
by Jun Aruga
Dear following folks who requested the approval to join ruby-sig.
* joice
* panosl1
* marcel64
* mkrzywda
* dcorking
* roca
Thank you for being interested in the ruby-sig!
Sorry for the late response.
Please allow me to send an email to your email address directly.
https://fedoraproject.org/wiki/SIGs/Ruby#Members
> The minimal requirement to get sponsored to the group is to go through all the steps above.
Please check the 4 steps to get sponsored in above page, then after
you completed, let us know.
Cheers,
Jun
--
Jun | He - His - Him
jaruga(a)redhat.com / IRC: jaruga
3 years, 8 months
