ruby-sig July 2010

ruby-sig@lists.fedoraproject.org

11 participants
11 discussions

Removing ruby-activerecord
by Mo Morsi 25 Aug '10

25 Aug '10

Hey, so I spent far too long over the last few days trying to get activerecord v2.3.8 to compile against Fedora before I realized that I was basing my attempt off the wrong package. Specifically, we have two activerecord rpms in Fedora, ruby-activerecord and rubygem-activerecord http://cvs.fedoraproject.org/viewvc/rpms/ruby-activerecord/ http://cvs.fedoraproject.org/viewvc/rpms/rubygem-activerecord/ https://admin.fedoraproject.org/pkgdb/acls/name/ruby-activerecord https://admin.fedoraproject.org/pkgdb/acls/name/rubygem-activerecord Obviously, conforming to standards, rubygem-activerecord is the way to go, and I can't figure out why we are keeping ruby-activerecord around, especially since its horribly out of date (pulling version 2.0.1, the package itself has not been updated since 2007). Can we orphan / remove ruby-activerecord all together? -Mo

2 3

ruby 1.8.7p299 is now rawhide build tree
by Mamoru Tasaka 13 Aug '10

13 Aug '10

Hello, all: As - F14 feature freeze is tomorrow ! - Mohammed's ruby srpm was almost complete (as far as I tried using): http://mo.morsi.org/files/rpms/ruby-1.8.7.299-3.fc13.src.rpm I slightly modified Mohammed's srpm and imported into rawhide build tree. Now it is available on http://koji.fedoraproject.org/koji/buildinfo?buildID=186570 A summary of changes from Mohammed's ruby-1.8.7.299-3.fc13: - Some cleanups - Make -irb, -rdoc subpackage noarch - Make dependencies between arch-dependent subpackages isa specific - Improve sample documentation gathering I hope the imported new ruby won't break things (so much). I appreciate all peoples' contributing to ruby 187 packages. Regards, Mamoru

4 11

Review for rubygem-rack1
by Michael Stahnke 29 Jul '10

29 Jul '10

I put together a package for rubygem-rack1 (version 1.1) for EPEL5. It is needed for things like Sinatra, Shotgun and newer versions of rails. I would love somebody could do a review so we could have it inside EPEL5. https://bugzilla.redhat.com/show_bug.cgi?id=617228 Basically, I just made it conflict with rubygem-rack. Future packages that require rack > 1.1 could just require rubygem-rack1 instead of rubygem-rack. stahnma

4 6

More passenger
by David Lutterkort 29 Jul '10

29 Jul '10

Hi, intrigued (for lack of a better word) by the state of the review of mod_passenger (BZ 470696) I spent a little time reviving Jeroen's spec file and bringing it up to date for passenger 2.2.15. Updated spec and a probably braindead mod_passenger.conf attached (sadly, the passenger SRPM seems to have vanished from Jeroen's site). As I see it, there's three issues with the spec right now: * the stance of upstream on using a stock boost. I think if we ever want to have passenger in Fedora, somebody with the spare time will need to browbeat^W handhold upstream to send their patches upstream * the scripts installed into /usr/bin (passenger-status etc.) are broken since they expect to be executed from the gemdir. We need to add wrapper scripts similar to what 'gem install' to /usr/bin * passenger is horribly broken with SELinux. I tried following the instructions from the Passenger manual[1] and somebody's SELinux policy[2] to no avail; passenger can not create its socket with that. Some of the instructions in [1] sound odd, like doing 'chcon -R httpd_sys_content_t' on the gemdir I doubt I have the time to work much more on this, thought I'll document what I did for posterity's sake. David [1] http://modrails.org/documentation/Users%20guide.html [2] http://smerpology.org/sprocket/2010/03/17/passenger-phusion-aka-mod_rails-a…

2 3

F14 Feature Ruby_1.8.7 accepted by FESCO
by Mamoru Tasaka 28 Jul '10

28 Jul '10

Hello, all: FESCO accepted Ruby_1.8.7 as Fedora 14 Feature in the meetings on 2010-07-27: http://meetbot.fedoraproject.org/fedora-meeting/2010-07-27/fesco.2010-07-27… Great news! Thanks to Mohammed for submitting feature page, and all people contributing to ruby 187 srpm. Regards, Mamoru

1 0

Ruby 1.8.7 RPM RC1
by Mo Morsi 28 Jul '10

28 Jul '10

For those who don't know, the Fedora 14 feature submission deadline is one week from today, Tuesday July 13th https://fedoraproject.org/wiki/Releases/14/Schedule I think it would be great if we can add Ruby 1.8.7 to that feature list, and I believe we are pretty much there with the latest ruby rpm http://mo.morsi.org/files/rpms/ruby-1.8.7.299-2.fc13.src.rpm This latest rpm addresses all the outstanding issues so far, including various small macro related cleanups, the readdition of the upstream ext/tk codebase, and the removal of .tk.old (courtesy of Jim). If there is anything I missed please shout out, else please test your software against it extensively so that we can push it to rawhide and add the updated Ruby to the F14 feature list before next week. To provide the lowest barrier to test Fedora / Ruby 1.8.7, I also threw together a virtual appliance with everything (Ruby 1.8.7 and Rails 2.3.8) all setup to go (simply launch the appliance, checkout your code on it, and test away). It can be downloaded here http://projects.morsi.org/polisher/appliances/fedora-ruby-187.tgz Also, once again, if you just need the updated rails rpms to test against as well, you can find those here http://mo.morsi.org/blog/node/322 -Mo

6 12

Ruby 1.8.7
by Jeroen van Meeuwen 18 Jul '10

18 Jul '10

Hi Guys, First, I wanted to say how much I appreciate all the effort going in to improving the state of Ruby in Fedora, working on Ruby 1.8.7 for Fedora 14 for now. Since this is a collaborative effort, I'm sort of amazed that I had nothing to do with it. You guys have made it all happen! Don't get me wrong, I mean that to be a positive thing ;-) Even though I'm considered the "owner" of Ruby in Fedora (note the quotes), I would like to think that such status should not mean that such one individual should be looked at as if the entire package and its future depended on the word or involvement of that one contributor. So, again, I very much appreciate the involvement and effort you have all shown and put in towards including Ruby 1.8.7 in Fedora. Now, I think we all know that I'm working on something different. My target is to make Fedora the ultimate platform for Ruby developers, and Enterprise Linux the ultimate platform to deploy Ruby applications. This includes, in my current plans, parallel stacks. There's insurmountable problems to overcome in the path towards such functionality. In short; it's going to take a while for me to get there. That said; it shouldn't mean the status of Ruby in Fedora (meanwhile) comes to a stand-still. Again, I very much appreciate there's a number of people willing to take care for Ruby in Fedora now and for the foreseeable future. Now, I was asked to look over the Ruby 1.8.7 feature, and the status of the current, latest package[1]. I regret to have to admit I do not have enough time to do so. I also regret that it's mutually exclusive with what I'm working on myself, and to just go ahead and destroy my box just to test the ruby 1.8.7 package, frankly, seems just too inefficient. Hence, I would like you all to continue the good work as you see fit. I have strong confidence in that Ruby 1.8.7 will be a success, despite even the slight probability of breaking some of the packages that depend on Ruby. Furthermore, I would like you to consider the fact that little of all of this has been worked on through some or the other infrastructure that let's us truly collaborate. I regret the fact that the Fedora Project simply won't allow us to use their infrastructure to throw up one or more development repositories to work on various stuff, and so I'm setting up such infrastructure myself. If you're interested in working with me, please let me know ;-) Kind regards, Jeroen van Meeuwen [1] http://mo.morsi.org/files/rpms/ruby-1.8.7.299-3.fc13.src.rpm

2 1

Orphaning my packages for EPEL6
by Mamoru Tasaka 13 Jul '10

13 Jul '10

Hello, all: I have released the ownership on the packages I maintain(ed) on EPEL6 (only): rubygem-activeldap rubygem-hoe rubygem-rubyforge If you are interested, please feel free to take over maintainership on these packages on EPEL6. Also even for other packages and other branches, co-maintainers for my packages are always welcomed. Regards, Mamoru

3 7

gem2rpm rpm acceptable?
by "Guillermo Gómez S." 09 Jul '10

09 Jul '10

Hi there ruby/sig, :) Im looking to produce a fedora pkg for phusion passenger. First i tried from ground cero, then i recalled gem2rpm command. Of ocurse i took the shortcut, now i have an rpm which sources are not "pristine" ¿are they? I produced the gem from the pristine source with rake package:gem Then gem2rpm gem-name > new.spec Is this procedure acceptable for Fedora to produce rpms? krgds Guillermo (btw: im looking for sponsorship to become a fedora packager/maintainer) ------------------------ http://www.neotechgw.com http://gomix.fedora-ve.org

2 3

RPM and GEMS - Unholy marriage
by Bert Meerman 02 Jul '10

02 Jul '10

Hi everyone, I've been following the discussion on RPM and GEMS conflict of interest. I found it quite interesting, and I would like to discuss some packaging options already present within ruby and rails. There are three things I would like to add to Jeroen's page: 1) A valid Rails RPM package *explicit* links to gems required. Strictly speaking, you can lazy load the gems an application needs. This might work, especially if you use gems that are very common (like Rails). Problem is, that a critical dependency is missing. You can add this info in the RPM spec, but I think it is better to make it mandatory more downstream. For RPM packaging, all you need to do is ask for the dependent gems. My question: what are your thoughts on this? 2) A valid Rails RPM package must contain the version when specifying gems and the version must be limited. Example: # require 'aws/s3' config.gem 'aws-s3', :lib => 'aws/s3', :version => '0.4.0', # :source => "http://code.whytheluckystiff.net" (see also http://api.rubyonrails.org/classes/Rails/Configuration.html#M002064) This means that the module will use any version greater than 0.4.0. You can also specify smaller, a range or a specific number. The trick is this: if you do this correctly, you can use multiple gem versions on the same system. In theory, this must work. This is what was causing the issue with Lighthouse. I think you should fix the version or make it a range, never a 'greater than' (as in the example and with Lighthouse). My question: what are your thoughts on this, especially the mandatory 'limit the version number'? 3) Gems can be vendorized. OK, this is the moment where a lot of people are going to be amazed, mouth open and staring at the screen for the next five minutes: you can make a Rails application and include the gems in it, as it where local code. This is called vendorization. A vendorized gem is only available to the application using it: it is part of the source code of that application and located in the /vendor directory of the application root (not in the normal gem directory). In fact, you can vendorize a gem and then even modify the code. On one hand, if you say all gems should be vendorized, you don't have any version conflicts. On the other hand, I heard someone complain about static linking... Personally, I disagree with the vendorization of gems. It obfuscates version management. Question: does Fedore prefer (or mandatorize) a specific approach? Why? Thanks in advance, Bert

3 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

ruby-sig July 2010