ruby-sig December 2014

ruby-sig@lists.fedoraproject.org

6 participants
9 discussions

Ruby 2.2
by Vít Ondruch 22 Sep '23

22 Sep '23

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

4 19

BASH completion for Ruby
by Vít Ondruch 25 May '16

25 May '16

Hi guys, Anybody have any experience with some scripts for bash completion? Have you tried any? Should we integrate any? Just a quick googling gave me two results: https://github.com/mernen/completion-ruby https://github.com/pdkl95/rubygems-completion And there are probably others. I did not tried them yet. Have you? Do you have other/better tips? Thank you Vit

2 3

Ruby 2.2 change proposal
by Vít Ondruch 17 Dec '14

17 Dec '14

Hi rubyists, I put together change proposal for Ruby 2.2 in Fedora 22 [1]. Any feedback is welcome. If no feedback, I'll propose this change to package wrangler in a week or so ... Vít [1] https://fedoraproject.org/wiki/Changes/Ruby_2.2

1 1

DBM build against gdbm?
by Vít Ondruch 17 Dec '14

17 Dec '14

Hi, The DBM module of Ruby [1] used to be built against db4 and later against libdb packages. However, for some while already, it is compatible even with gdbm. I'm thinking about dropping the BuildRequires: libdb-devel and keep just the BuildRequires: gdbm-devel (this is used for GDBM module anyway). Pros: * One less dependency * I've heard from libdb packager, that libdb should be dropped from Fedora sooner or later, so it would not cause any future issues. Cons: * Although the DBM Ruby interface does not change, the data files will change due to this, i.e. if you are using DBM and you'll update from F21 to F22, this will be incompatible change. I am not aware of any SW, which depends on DBM, so I am in favor for this switch for Ruby 2.2 and F22. Furthermore, the above mentioned transition from db4 to libdb went unnoticed. But please, let me know if you have any concern. Thanks Vít [1] http://www.rubydoc.info/stdlib/dbm/index

1 0

updating jruby in fedora
by Mo Morsi 16 Dec '14

16 Dec '14

Greetings, we're currently looking at fixing the broken JRuby build and updating it to the latest release in rawhide. See the following tracker bug: https://bugzilla.redhat.com/show_bug.cgi?id=1152249 Four new dependencies have been submitted, reviews are needed (swaps are welcome): unsafe-mock: https://bugzilla.redhat.com/show_bug.cgi?id=1152244 jsr292-mock: https://bugzilla.redhat.com/show_bug.cgi?id=1152245 joda-timezones: https://bugzilla.redhat.com/show_bug.cgi?id=1152246 options: https://bugzilla.redhat.com/show_bug.cgi?id=1152247 Additionally the following will need to be updated (I can do this once things start moving along): jffi -> 1.2.7 nailgun -> 0.9.1 yecht -> 1.0 Any help w/ this would be appreciated, -Mo

2 2

Continuous integration with Koschei
by Ken Dreyer 16 Dec '14

16 Dec '14

This looks like it would be a great resource for the Ruby SIG, particularly with the tight version coupling I see in a lot of gemspecs. http://blog.famillecollet.com/post/2014/08/12/Koschei-continuous-integratio… I see there are some ruby and gem packages here: http://koschei.cloud.fedoraproject.org/search?q=ruby Who's coordinating this for Ruby in Fedora? It's a little hard to figure out usernames with this tool (unlike Koji) - Ken

2 1

rspec-its
by Ken Dreyer 10 Dec '14

10 Dec '14

I've got a gem (rubygem-virtus) that uses rspec/its in its test suite. Is it worth packaging rubygem-rspec-its? Or is there a replacement that virtus upstream ought to be using? - Ken

2 4

RbConfig::CONFIG["ruby_version"]
by Darryl L. Pierce 04 Dec '14

04 Dec '14

I have a gem I package for Fedora [1] that has a new feature coming with our next release. That feature depends on being able to release the GIL for blocking operations so that other threads in the app can get interpreter time. The determination as to which GIL-releasing API to call is determined at install time via extconf.rb: ---8<[snip]--- # set the ruby version compiler flag runtime_version = RbConfig::CONFIG["ruby_version"].gsub(/\./,"")[0,2] $CFLAGS << " -DRUBY#{runtime_version}" ---8<[snip]--- And in the native code is decides based on whether RUBY19, RUBY20 or RUBY21 is defined (RUBY18 is a noop in this case). However, on Fedora 19+ and RHEL7 this fails. The reason is because the Ruby package for F19-F22/EL7 returns an empty string for the above value in RbConfig::CONFIG. On Windows, Ubuntu, Debian and the Mac it outputs the version info for the VM. I filed a BZ for this (BZ#1170282) and would consider this a blocker since I won't be able to release an updated RPM for my gem when we have our next release due to this bug. Any proven packager here who could give this BZ some lovin' and get a fix pushed? -- Darryl L. Pierce <mcpierce(a)gmail.com> http://mcpierce.blogspot.com/ Famous last words: "I wonder what happens if we do it this way?"

2 1

rspec 3.1.x in rawhide
by Mamoru TASAKA 02 Dec '14

02 Dec '14

Hello, all After a long delay I finally pushed rspec 3.1.x into rawhide (F-22) build tree. Also I pushed rubygem-rspec2 (and so on) into rawhide tree. So: - If your srpm already handles rspec 3.1.x, please use BuildRequires: rubygem(rspec) - Or not, you can use BuildRequires(rspec2). Note that 2.x version rspec (script) is renamed to %_bindir/rspec2, you'll probably have to do $ rspec2 spec/ for example. Please try and test them. Note: this change is only for F-22. Regards, Mamoru

4 10

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

ruby-sig December 2014