ruby-sig October 2009

ruby-sig@lists.fedoraproject.org

6 participants
7 discussions

ruby rails, gem packages
by John Taber 27 Oct '09

27 Oct '09

most tutorials recommend installing rails and other packages using gem - and since they change often, I'm not too sure what the value is of trying to supply Fedora packages for the gems. In fact using the Fedora gem packages might just mess things up especially between 1.8.6 and 1.9.1 because of the different way each handles gems. From our standpoint, we've always just loaded ruby via the Fedora packages and then everything via gems. This has been both easy and has worked well. I think it is better to forget making Fedora packages of the gems and concentrate on packages for the various Ruby language versions - just my $.02

5 9

Package WIshlist
by Michael Stahnke 27 Oct '09

27 Oct '09

I decided to start putting some packages I could use (and will happily package if I get around to it) on the Ruby SIG wiki page[1]. Sure you can put them on the giant Fedora Wishlist[2] too, but I thought it might call-out some extra interest from the Ruby crew here. stahnma [1]https://fedoraproject.org/wiki/SIGs/Ruby [2]https://fedoraproject.org/wiki/Package_maintainers_wishlist

2 1

new ruby 1.9.1-p243 patch for openssl error
by John Taber 25 Oct '09

25 Oct '09

thks - applied patch - compiled okay although on make install got some msgs: no definition for ossl...... no definition for sock...... not really sure what that implies

1 0

Re: Issues with rails right now
by Jeroen van Meeuwen 23 Oct '09

23 Oct '09

On 10/23/2009 11:34 AM, David Lutterkort wrote: Hi David, and others, I would like to take this discussion to the Ruby SIG list, as I think it is of interest to more people then just the rubygem- and ruby-owners I'm sorry for any duplicates this might cause, and I apologize in advance. Let me try and summarize what we've been discussing previously, and please do correct me if I'm wrong; The release of an update for rubygem-rails and it's separate gems (actionmailer, actionpack, activerecord, activeresource, activesupport, hereonafter rails gems) has been quite the pain in the ass lately, as there is a loop BuildRequirement dependency between the bunch of (now separate) packages. This has caused us (the rails gem maintainers) to reconsider packaging these gems as separate sources, or from separate CVS modules if you will. We agreed to try and determine whether using rails.tgz as one source to rule them all. This part is on my plate, and all I'm going to do is come up with a draft wiki page for all of us to shoot at. There's problems here, such as "upstream does not always release a .tgz", and I'm going to need to come up with ways to work around that, possibly upstream which is more desirable then downstream. Furthermore, we've discussed that updating rails gems would break certain applications developed on another version of rails. See also https://bugzilla.redhat.com/520843. In this particular case, it was mentioned that setting the RAILS_GEM_VERSION on the RoR application (environment) would indicate that a particular version of rails was to be used, causing the application to fail if it were to be upgraded (by using RPM packages), from 2.3.2 to 2.3.3 or 2.3.4. We decided to freeze the Major.Minor.Teeny version of rails for every release. This means that if by the time Fedora 12 is released the most recent version of rails is 2.3.4, Fedora 12 would remain on rails-2.3.4 for the remainder of its support cycle. This however introduces a different problem; bugfixes in rails-2.3.4 (compared to rails-2.3.2) are not going to find their way to a (supported) Fedora release. Hence, a set of patches needs to be shipped, and that set will probably only grow over time while a Fedora release nears the end of its life cycle. This, again, introduces yet another problem. The source for the RPM package is, say, rails-2.3.2.gem. We can patch this source, even though obviously some work might be involved, but the upstream version is and remains to be 2.3.2 (gem list will also show 2.3.2). In order for gem users to be able to upgrade to our new, patched version of rails-2.3.2, we need to bump *its* version number (and not just the RPM release). We also need to release the new, patched and bumped rails gem *through upstream*. We need to release through upstream, because Fedora is not allowed to ship its own source files essentially creating a fork. But, we cannot also not make the gem version 2.3.2.1 for the same reasons we cannot release 2.3.4 (see bug #520843). This is a problem we are going to have to overcome. This is, or at least I think this is, the current discussion. Kind regards, Jeroen van Meeuwen -kanarip

1 0

Ruby 1.9.1 (or possibly 1.9.2)
by Jeroen van Meeuwen 23 Oct '09

23 Oct '09

Hi there, Having discussed Perl packaging changes for Fedora 13 with Stepan Kasal in Brno last September, during the Red Hat Developer Conference 2009[1], I found his ideas (or the Perl SIGs ideas) sufficiently interesting to experiment with myself in the case of Ruby. I did a blog post[2] on this subject, showing off a local build of a compat-ruby-1.9.1 package I've made. I'm still working on some of the other troubles all of that introduces, but I wanted to let you know where I'm thinking it could be heading towards. Have a nice day! -- Jeroen [1] https://fedoraproject.org/wiki/DeveloperConference2009 [2] http://www.kanarip.com/node/872

2 3

Not releasing ruby-1.8.6-p383 just yet
by Jeroen van Meeuwen (OGD) 22 Oct '09

22 Oct '09

Hi there, I'm not releasing ruby-1.8.6-p383 just yet, it just built in koji[1] and it is valid as an update to Fedora 11, but as I'm unable to compile this version against Fedora 12 right now (OpenSSL), and I don't want to break the upgrade path. Kind regards, Jeroen van Meeuwen -kanarip [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=137859

1 0

Introduction: Jeroen van Meeuwen
by Jeroen van Meeuwen 22 Oct '09

22 Oct '09

Hey there, I wanted to introduce myself wrt. to what I do with Ruby, Ruby on Rails and Ruby applications; - I'm the owner of Ruby in current Fedora releases, after Akira Togah orphaned it. Various people have been helping me with it as I'm both under time constraints as well as lacking some of the more detailed technical Ruby knowledge, and one person I wanted to name in particular is Mamoru Tasaka. - I'm the owner of the puppet package for scalable, consistent and efficient configuration management, after David Lutterkort has done an awesome job in like the 5 or 6 releases before I became his successor. Amongst others, Todd Zullinger is a great help. Included amongst the packages that I own is some of the dependency stack for specific deployments (ruby-RRDtool, rubygem-mongrel, fastthread, etc, etc). As a consultant, I -to some extent- commercially benefit from these packages and so I think I should also step up and take some responsibility for those packages to be available upstream, besides it being so much more efficient and so much more fun to share and collaborate. - I package a few Ruby Gems, which, mostly, are also dependencies of a Ruby on Rails web application my company is developing (deadline Oct 31st). Again I can only emphasize that I find it very important I share the work that I do as part of it's Release Engineering team with the rest of the community. This development team uses Fedora servers (while they are targeting EL-6 for customer deployments). One of my responsibilities inherently, is to make sure that the platform that is supposedly the basis of EL-6 (along with EPEL-6) is sufficiently stable, bug-free and contains what our RoR web application requires (hopefully also rubygem-passenger/mod_passenger, a.k.a. mod_rails/mod_rack, for which I've submitted a review). Furthermore, I'm involved in various other areas of the Fedora Project such as the Ambassadors, Fedora EMEA e.V., the Spins SIG and Fedora Unity. What I hope to get from this list is actually two-fold; On the one end, like I said, I'm not at all experienced in programming RoR or even just Ruby. I want to pick brains and get people that do know how RoR and Ruby to tell me what's going on ;-) I hope to be able to ask questions and get some answers/opinions/ideas on whether something is going to work or destroy stuff, and whether the direction we're going in is the right one, to ultimately improve Fedora's performance and option value as a Ruby development platform for all of our consumers. On the other end, I have a lot of endorsement from Operator Groep Delft in the Netherlands (my employer) to make sure that what we do (need to do and thus do anyway) is available to everyone, including the not-yet-publicly-available package development on Ruby 1.9.1 -more on that later on this list, I hope. Kind regards, Jeroen van Meeuwen -kanarip

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

ruby-sig October 2009