Review for rubygem-rack1
by Michael Stahnke
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
13 years, 10 months
More passenger
by David Lutterkort
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...
13 years, 10 months
Ruby 1.8.7 RPM RC1
by Mo Morsi
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
13 years, 10 months
Ruby 1.8.7
by Jeroen van Meeuwen
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
13 years, 10 months
Orphaning my packages for EPEL6
by Mamoru Tasaka
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
13 years, 10 months
gem2rpm rpm acceptable?
by "Guillermo Gómez S."
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
13 years, 10 months
RPM and GEMS - Unholy marriage
by Bert Meerman
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
13 years, 10 months
