ruby-sig April 2010

ruby-sig@lists.fedoraproject.org

5 participants
5 discussions

EPEL 5 and Ruby on Rails
by Michael Stahnke 30 Apr '10

30 Apr '10

After reviewing this bug https://bugzilla.redhat.com/show_bug.cgi?id=522162 and the links contained therein, it appears that we should move the rails stack on EPEL 5 to at least 2.2.3, and possibly later. Since this is rails, it will likely cause breakage for existing applications. Thoughts and/or ideas? stahnma

2 2

rubygem based rawhide packages stats on 2010-04-09
by Mamoru Tasaka 17 Apr '10

17 Apr '10

Among rubygem related rawhide packages on Fedora, the following packages are not using the latest gems provided by the upstream. Please consider to update these. Note that only rpms based on gems hosted on gems.rubyforge.org are reported in this mail. Owner srpm latest Fedora hpejakle rubygem-coderay 0.9.2 0.8.312-4.fc12 hpejakle rubygem-term-ansicolor 1.0.5 1.0.3-4.fc12 hpejakle rubygem-trollop 1.16.2 1.15-1.fc13 kanarip rubygem-calendar_date_select 1.16.1 1.15-4.fc13 kanarip rubygem-facets 2.8.2 2.8.0-2.fc13 kanarip rubygem-fattr 2.1.0 1.0.3-3.fc12 kanarip rubygem-gemcutter 0.5.0 0.3.0-3.fc14 kanarip rubygem-highline 1.5.2 1.5.1-1.fc13 kanarip rubygem-main 4.2.0 4.0.0-1.fc13 kanarip rubygem-mocha 0.9.8 0.9.7-2.fc12 kanarip rubygem-picnic 0.8.1.20100201 0.8.1-2.fc12 kanarip rubygem-restr 0.5.2 0.5.0-2.fc12 kanarip rubygem-reststop 0.4.1 0.4.0-2.fc12 kanarip rubygem-sqlite3-ruby 1.2.5 1.2.4-5.fc12 laxathom rubygem-json 1.2.4 1.1.9-1.fc13 lkundrak rubygem-configuration 1.1.0 0.0.5-5.fc14 lkundrak rubygem-cucumber 0.6.4 0.4.0-1.fc13 lkundrak rubygem-polyglot 0.3.1 0.2.5-4.fc12 lkundrak rubygem-rack-test 0.5.3 0.4.0-2.fc12 lkundrak rubygem-rubigen 1.5.4 1.5.2-5.fc12 lkundrak rubygem-shotgun 0.6 0.4-1.fc12 lkundrak rubygem-treetop 1.4.5 1.3.0-1.fc12 mfojtik rubygem-rest-client 1.4.2 1.4.0-6.fc14 mfojtik rubygem-thin 1.2.7 1.2.5-5.fc13 mkent rubygem-ParseTree 3.0.5 3.0.4-4.fc13 mkent rubygem-ZenTest 4.3.1 4.2.1-1.fc13 mkent rubygem-extlib 0.9.14 0.9.13-5.fc13 mkent rubygem-haml 2.2.22 2.2.20-1.fc14 mkent rubygem-merb-core 1.1.0 1.0.15-1.fc13 mkent rubygem-merb-gen 1.1.0 1.0.15-2.fc14 mkent rubygem-merb-slices 1.1.0 1.0.15-1.fc13 mkent rubygem-minitest 1.6.0 1.4.2-3.fc13 mkent rubygem-mixlib-cli 1.2.0 1.1.0-1.fc14 mkent rubygem-newgem 1.5.3 1.5.2-3.fc13 mkent rubygem-rcov 0.9.8 0.9.6-2.fc13 mkent rubygem-sexp_processor 3.0.4 3.0.3-1.fc13 mkent rubygem-thor 0.13.4 0.12.0-2.fc13 mmorsi rubygem-yard 0.5.4 0.5.3-3.fc14 mtasaka rubygem-hoe 2.6.0 2.5.0-3.fc13 mtasaka rubygem-htmlentities 4.2.1 4.2.0-2.fc13.respin1 orphaned rubygem-RedCloth 4.2.3 4.2.2-1.fc13 orphaned rubygem-rufus-scheduler 2.0.5 2.0.4-1.fc13 orphaned rubygem-state_machine 0.8.1 0.8.0-1.fc12 robert rubygem-fastercsv 1.5.3 1.5.1-1.fc14 stahnma rubygem-rspec 1.3.0 1.2.9-1.fc13 stahnma rubygem-simple-rss 1.2.2 1.1-6.fc12 tremble rubygem-icalendar 1.1.3 1.1.0-4.fc13 wakko666 rubygem-pathname2 1.6.3 1.6.2-6.fc13 Regards, Mamoru

2 2

Rails/Rack version issue
by jason.guiditta 16 Apr '10

16 Apr '10

I am running Fedora 12 with Rails 2.3.4 installed. Everything was working fine, then last night I got an update from yum for Rack 1.1. After installing that, my working rails apps failed to load. Creating a new test app yielded: /usr/lib/ruby/site_ruby/1.8/rubygems.rb:827:in `report_activate_error': RubyGem version error: rack(1.1.0 not ~> 1.0.0) (Gem::LoadError) Has anyone else hit this issue? If more detail is needed, let me know. Thanks, -j

7 12

Ruby / Fedora Testing Repos
by Mo Morsi 14 Apr '10

14 Apr '10

Hey just a quick update w/ some work I've been doing towards getting a platform which to test Ruby on Fedora. I've pushed many updates to Polisher (http://github.com/movitto/polisher) the focus of which has been expanded to manage any generic upstream project release process. Special cases have also been added to make use of the gemcutter API and gem2rpm for gem based projects. I've also added a Ruby DSL which can be used to descibe any number of projects w/ sources, and setup post-processing workflows to be executed on releases. I've grabbed several popular Ruby related packages in Fedora, made some small modifications to the specs, and setup Polisher scripts (http://github.com/movitto/polisher-scripts) to run through simulated releases of various versions, setting up the following yum repos (http://projects.morsi.org/polisher/repos) in the process: * stable - same packages that are currently in Fedora updates * maintenance - later releases in the same major version branch of the packages currently in stable * devel - packages that work w/ Ruby 1.9 (great <a href="http://isitruby19.com/">resource</a>) * rawhide - all latest ruby project versions By tweaking the Polisher scripts and rpm spec file templates, the contents of these repos can be changed and new ones can be setup for any target software stack. You can simply point a yum repo entry towards any of those repos beforing running a yum update to get all the latest Ruby packages provided by that repo, through there most likely will be breakage as Polisher and the scripts themselves are a work in progress. I'm also setting up various virt appliances, each pointing at a different Polisher generated repo by default, so that anyone can just download a VM image containing Fedora and a complete Ruby stack for whichever version of Ruby they want to use. It's a work in progress, I will put links up on my blog (http://mo.morsi.org/blog) as I upload the images. Obviously this is all a work in progress and it is quite a bit of effort to get Polisher scripts written for every Ruby related package, but if this thing starts rolling, I can see this as being a useful tool in the "upstream project to Fedora repo" process as mass parallel source releases can be triggered and handled easily in a committable / reproducible / reliable fashion. If anyone has any cycles I'd appreciate any help (patches, testing, etc). Stay tuned for more updates. -Mo

1 0

Opinions on rubygem subpackages
by Matthew Kent 01 Apr '10

01 Apr '10

Hello ruby-sig! I'm currently working on packaging Chef (http://wiki.opscode.com/display/chef/Home) which has presented some some interesting challenges and I need some advice. Currently their primary distribution method and focus is rubygems, though they have produced Debian packages. When using Chef via rubygems the actual setup is done by downloading and running a 'bootstrap' tar.gz which does a number of things all over the system (putting configs in place, installing more gems etc). The goal of packaging Chef is to avoid this arbitrary 'bootstrap' step and contain everything required to run Chef within packages. Packaging the gems is easy enough, but the daemons, configs and directories it requires seem to fall outside of the scope of what the current rubygems packages do (as far as I can tell). For my first target, the Chef client, my thinking is to produce 2 packages - the main rubygem then a 'chef' subpackage that ships the binaries, man pages, init scripts etc. Check it out here: http://magoazul.com/wip/SPECS/rubygem-chef.spec I couldn't find anything in the wiki about *not* doing this with subpackages but I'm unsure if it would be frowned upon. Thoughts? -- Matthew Kent | http://magoazul.com

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

ruby-sig April 2010