ruby-sig December 2013

ruby-sig@lists.fedoraproject.org

8 participants
8 discussions

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

RubyGems packaging with Ruby 2.1.0
by Vít Ondruch 21 Jan '14

21 Jan '14

Hi rubyists, Working toward Ruby 2.1.0 in Fedora, there are going to be necessary some changes to gems with binary extensions. In short, the extensions are not installed into %{buildroot}%{gem_extdir_mri}/REQUIRE_PATHS/ anymore, but %{buildroot}%{gem_extdir_mri}/ will be used for the future. This is improvement and this change is coming from RubyGems upstream. It should also simplify the guidelines a bit [1] (on the first look). Unfortunately, although the resulting rubygem- packages are much nicer and closer to upstream then they used to be, the way how to create them got uglier :/ You can see changes needed to make rubygem-bcrypt-ruby compatible with new RubyGems in attached diff. Since I am not happy about the situation, I'd like to ask you for your feedback, how would you envision to simplify this process. I am thinking about several possibilities: 1) Modify our operating_system.rb and let it treat gem installation into %{buildroot} specially 2) Use some environment variable, to let RubyGems know, that we need to treat %{buildroot} similarly to system directories 3) Introduce some additional parameter to gem install command, which will modify the --install-dir option to install extensions properly 4) Introduce some RPM macros which will handle all this stuff for us. Please let me know if you have another bright idea :) Thanks Vít [1] https://fedoraproject.org/wiki/Packaging:Ruby#Building_gems

2 3

gem package review swaps
by Ken Dreyer 31 Dec '13

31 Dec '13

I've submitted several gems up for review, and I'm happy to swap package reviews with someone. These are all in the dependency chain for Gitorious. [1] http://bugzilla.redhat.com/1036901 - org-ruby http://bugzilla.redhat.com/1037278 - resque-cleaner http://bugzilla.redhat.com/1037900 - resque-job-stats http://bugzilla.redhat.com/1039818 - wikicloth http://bugzilla.redhat.com/1040180 - virtus http://bugzilla.redhat.com/1046956 - posix-spawn The following gems are not hard dependencies for Gitorious, so I consider them secondary in importance, but they'd still be nice to get into Fedora: https://bugzilla.redhat.com/1046807 - activerecord-nulldb-adapter https://bugzilla.redhat.com/1046992 - rubygem-gemnasium-parser https://bugzilla.redhat.com/1038274 - liquid (a dep for jekyll) - Ken [1] https://fedoraproject.org/wiki/User:Ktdreyer/Gitorious

2 1

Ruby 2.1.0
by Vít Ondruch 23 Dec '13

23 Dec '13

Hi Rubyists! I have pushed .spec file for Ruby 2.1.0 preview1 into private-ruby-2.1 [1] branch of Ruby's dist-git repository and I'll be pushing there further changes leading into Ruby 2.1.0 package for Fedora 21. However: * ATM, it doesn't build in Koji unfortunately, since there seems to be some deadlock in test suite. Nevertheless, it builds (almost) fine in mock on my computer. * preview1 ships with preview version of RubyGems 2.2 and RDoc 4.1.0 which produces nonconforming package names such as "rubygems-2.2.0.preview.1-0.15.preview1.fc21.noarch.rpm". Since I expect that final version will ship non-preview versions, I don't care much about the names. Please test the package if you like. Any feedback (and help/patches ;) is welcome. Thanks Vít [1] http://pkgs.fedoraproject.org/cgit/ruby.git/log/?h=private-ruby-2.1

2 5

heads up: relocated recent ruby tools
by Mo Morsi 20 Dec '13

20 Dec '13

Hey all just a heads up that the gem_dependency_checker and other scripts recently sent out can now be found in the 'Polisher' project here [1]. Polisher is a library and toolset aimed at providing a reusable/extensible integration point between upstream Ruby projects and downstream vendor resources. The project has been organized into the standard ruby project layout and the code refactored into reusable modules that can be leveraged to interface with various systems in the Ruby post-upstream-publishing workflow (for both gems and gemfile/bundler based projects). I also migrated the gemspec from the original polisher project and updated the gem on rubygems.org so the library and utilities are available with a simple 'gem install polisher' (make sure to install curl-devel and other 'curb' deps beforehand). Also of possible interest are inflight updates to the bundler_ext project [3] which refactor the code and add a BundlerExt#system_setup method analogous to the Bundler#setup method. Thus a Ruby developer or admin can even more tightly couple their Ruby and/or Rails application to a supported platform without a large upfront module-inclusion cost. Also be sure to checkout recent updates to the linux_admin project [4] which has seen alot of improvements and new cool features added recently. Hope everyone enjoys the holidays, -Mo [1] https://github.com/ManageIQ/polisher [2] http://rubygems.org/gems/polisher [3] https://github.com/bundlerext/bundler_ext/pull/14 [4] https://github.com/ManageIQ/linux_admin

1 0

excluding dot files from gems
by Ken Dreyer 13 Dec '13

13 Dec '13

Lots of gems ship dot files, like .gitignore or .travis.yml. These are basically useless to users, and in our RPMs, we have to exclude these files by hand. The problem is that a lot of gems do something like this in the gemspec: s.files = `git ls-files`.split("\n") I end up repeating the same exclusions over and over in the RPM packaging. I've been brainstorming about the best way to push the dot file exclusions upstream. What do you think about something like this? --- a/pkgwat.gemspec +++ b/pkgwat.gemspec @@ -26,6 +26,7 @@ Gem::Specification.new do |s| s.add_development_dependency("debugger") s.files = `git ls-files`.split("\n") + s.files -= `git ls-files -- .??*`.split("\n") s.test_files = `git ls-files -- {test,spec,features}/*`.split("\n") s.executables = `git ls-files -- bin/*`.split("\n").map{ |f| File.basename( s.require_paths = ["lib"] It seems like this would be a good pattern to propose to the various upstreams, but I wanted to get others' opinions first. - Ken

4 3

broken Rails in Rawhide
by Ken Dreyer 11 Dec '13

11 Dec '13

It looks like Rails was recently broken in Rawhide when activesupport and activemodel 4.0.2 went out a couple days ago. Here's the bug against activesupport: https://bugzilla.redhat.com/1040214 . (Later I discovered that activemodel has a similar issue.) To see the problem, try "yum install rubygem-rails" on a Rawhide box. Some of the gems require 4.0.1, and some require 4.0.2. - Ken

1 0

Rubygem macros avilable in EPLE6!
by Vít Ondruch 05 Dec '13

05 Dec '13

Hi, Now I realized that I should not forgot to announce, that in RHEL 6.5 was released rubygems errata [1], which adds rubygems-devel subpackage with all rubygems macros you are used to already for several releases of Fedora. Namely, you should be able to use %gem_dir %gem_instdir %gem_libdir %gem_cache %gem_spec %gem_docdir %gem_install Enjoy. Special thanks goes to Ken Dreyer for pushing this update forward via RH customer support ;) If somebody cares to backport these macros into EPEL 5, feel free to assign yourself to [2]. BTW I opened FPC ticket to update the Ruby packaging guidelines. Vít [1] http://rhn.redhat.com/errata/RHBA-2013-1694.html [2] https://bugzilla.redhat.com/show_bug.cgi?id=1036085 [3] https://fedorahosted.org/fpc/ticket/370

4 5

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

ruby-sig December 2013