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,
You probably noticed, that there is ongoing build of all Python packages
in Copr [1] and today, I was approached by Miroslav Suchý, that he'd
like to do the same for rubygems. And this in turn triggered these
questions:
1) Would you be interested to create ruby-sig group in FAS? We could
make the group owner of some packages and in turn, the members of the
group could maintain the packages, without explicitly asking for some ACLs.
2) For the Copr rebuild of rubygems, there needs to be some FAS group
again. Python guys are asking for "pypi-builds-sig" group [2], hence
following their lead, I'd like to ask for "rubygems-builds-sig" group
(note that although I don't like the '-sig' suffix in this case, it is
mandated by the infrastructure ticket template).
So what are your thoughts?
Vít
[1]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
[2] https://fedorahosted.org/fedora-infrastructure/ticket/5311
Hi everybody,
I spent last few days working on gem2rpm. There got some nice improvements:
* Better handling %files section.
* Improved handling of {Build,}Requires.
* Basic detection of test frameworks.
* Updated and simplified templates for Fedora 26+.
Due to this changes, I decided it is about the time to release version
1.0.0. You can get the package from RubyGems.org or from Fedora/EPEL
updates-testing packages.
Thanks everybody who helped with this release!
Vít
Hi all,
For ages, there is Bash/Zsh completion support available for the default
OptParser [1]. That means quite some Ruby application could provide some
basic command completion out of the box. However, the setup is a bit
clumsy. The steps necessary to enable the command completion for single
executable are described her [2]. Any ideas, how we could benefit from
this feature? Should we store the "rb_optparse.bash" somewhere? Where to
load it and how to enable the completion for specific executables?
Should we try to enable the bash completion for every Ruby executable?
Should we have some macro for this?
Vít
[1]
https://github.com/ruby/ruby/commit/644f0445e86034dde399d6db8261c82cf34b8e07
[2] https://github.com/ruby/ruby/blob/trunk/misc/rb_optparse.bash
I'm seeing the following message in the build failure in the gem I
maintain, asciidoctor:
+ rm Rakefile
+ sed -i 's|"Rakefile",||g' asciidoctor.gemspec
+ exit 0
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.0fctL3
+ umask 022
+ cd /builddir/build/BUILD
+ cd asciidoctor-1.5.4
+ gem build asciidoctor.gemspec
WARNING: See http://guides.rubygems.org/specification-reference/ for help
ERROR: While executing gem ... (Gem::InvalidSpecificationException)
["Rakefile"] are not files
That sed expression is highly dependent on how files are specified in a
gemspec, and it doesn't match how the asciidoctor gemspec defines files.
Can this alteration be updated to be more robust?
One way would be to look for the files assignment and subtract an entry
from it. Something like:
sed -i "s|\.files *=.*|& - ['Rakefile']|" asciidoctor.gemspec
Until this is fixed, my gem is going to fail in rawhide because I can't
change the already released gem. I suspect there are others that are
failing as well.
-Dan
--
Dan Allen | @mojavelinux | https://twitter.com/mojavelinux