Rails/Rack version issue
by jason.guiditta
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
14 years
Examples of the new native gem standards
by Bryan Kearney
Does anyone have example spec files for the new standrds for doing
native gems? I am trying to follow the guidelines about not installing
in the %build section, but most spec files I see still do that.
Thanks in advance.
-- bk
BTW.. Spec files are like JCL.. no one writes them from scatch :)
14 years, 2 months
The Ruby World Domination Plan
by Jeroen van Meeuwen
Hi guys,
after FUDCon, and then some more thoughts in private email and between
my ears, I think I might have the bare bones for a plan to attack the
Ruby challenge;
First of all, let me emphasize that the complete plan is based on the
fact we want different Ruby stacks to be available, namely those Ruby
stacks that someone might target (in development). That said, I think
the list of Ruby stacks one can target right now are:
- ruby-1.8.5 as shipped in EL-5
- ruby-1.8.6 as shipped in Fedora currently, and most likely also EL-6
- ruby-1.9.1 as targeted for Fedora 13
The goal of this thread is to figure out what we should do in terms of
packaging, but having given it a little thought here's how I think I
would prefer to attack the problem. Please bear with me when I start of
rambling 'cause I don't know how to put this in an overview that
everyone understands (but we'll get there);
- Ruby packages themselves are to be named ruby-<major>.<minor>.<teeny>,
as to not have to rename packages to compat-ruby every time a newer
M.M.T is released.
- A base 'ruby' (e.g., the package's %{name} == "ruby") package will
pull in the default stack (targeted to be ruby-1.9.1 in Fedora 13).
- The ruby-<m>.<m>.<t> packages are going to provide:
1) ruby(ABI) = <major>.<minor>
2) ruby(ABI) = <major>.<minor>.<teeny>
3) ruby(API) = <major>.<minor>
4) ruby(API) = <major>.<minor>.<teeny>
The Ruby ABI is pretty stable in between teeny versions, but much less
so for the Ruby API.
- The base directory for Ruby modules is going to be %{ruby_vendorlib}
and %{ruby_vendorarch}, provided through /etc/rpm/macros.ruby, resulting
in /usr/share/ruby/ and %{_libdir}/ruby/.
This is where packaged gems and library extensions to Ruby should end up
initially. If gems turn out to be compatible with one specific Ruby
version only, one can use %{ruby_vendorlib_186} (again provided through
/etc/rpm/macros.ruby), or if a gem is compatible with 1.8.x,
%{ruby_vendorlib_18} should be used.
gems and library extensions installed manually should end up in the
appropriate /usr/local/ directories, which will also appear first in
each of ruby's search paths.
- Search paths are going to look similar to:
/usr/local/lib{,64}/ruby/<major>.<minor>.<teeny>/
/usr/local/lib{,64}/ruby/<major>.<minor>/
/usr/local/lib{,64}/ruby/
/usr/local/share/ruby/<major>.<minor>.<teeny>/
/usr/local/share/ruby/<major>.<minor>/
/usr/local/share/ruby/
/usr/lib{,64}/ruby/<major>.<minor>.<teeny>/
/usr/lib{,64}/ruby/<major>.<minor>/
/usr/lib{,64}/ruby/
/usr/share/ruby/<major>.<minor>.<teeny>/
/usr/share/ruby/<major>.<minor>/
/usr/share/ruby/
as to make sure that rubygem-foo can be packaged for all ruby versions
easily, while making the exception (ruby version specific patch?) is
also perfectly feasible (by putting another copy in the more specific
search path).
To illustrate my packaging points, I would appreciate if you look at the
following git repository, where I keep a couple of .spec files as well
as the macros.ruby file I intend to use:
git://fedorapeople.org/home/fedora/kanarip/public_git/ruby-specs.git
Along with that comes a git repository for Ruby itself, to be found at:
git://fedorapeople.org/home/fedora/kanarip/public_git/ruby.git
Preliminary packages can be found on:
For Fedora 12:
- http://www.kanarip.com/custom/f12-ruby/ and
- http://mirror.nl.kanarip.com/custom/f12-ruby/
For Fedora Rawhide:
- http://www.kanarip.com/custom/rawhide-ruby/ and
- http://mirror.nl.kanarip.com/custom/rawhide-ruby/
That said, these packages could ruin your current Ruby stack (different
search paths and all that).
Please be so kind as to test these versions and provide me with the
necessary feedback, so we can move things along.
Thanks in advance,
Kind regards,
Jeroen van Meeuwen
-kanarip
14 years, 2 months
gem package status
by jason.guiditta
Hello, I was wondering what the update plan (if any) was for the gem
rpm. I have the latest, but it is still pointing at rubyforge.
Changing my .gemrc will work, but is that the only plan, or will the
default source in the gem rpm be updated at some point?
-j
14 years, 2 months
Ruby 1.9.1 for Fedora
by Jeroen van Meeuwen
Hi there,
I'm still struggling with ruby-1.9.1, and there's a couple of
showstoppers and hurdles I wanted to talk about.
First of all, let's forget about the targetted Fedora 13 milestone; it's
just not going to happen.
Second; ruby-shadow doesn't compile with ruby-1.9.1
Third; The multiple ruby parallel stacks thing is throwing up a bunch of
problems beyond what I'm capable of solving myself. I would like to
propose that either we remove the desired feature of being able to have
parallel stacks in the first place, or start working on it together
(keyword: together!). If nothing else, we can always set up the ruby
stack to allow us to add back other versions of ruby should we need to
(and once we're able to).
What do you think?
-- Jeroen
14 years, 2 months
Rails 2.3.5 for rawhide
by David Lutterkort
Mamoru has built packages for Rails 2.3.5 for rawhide, and is going to
push them tomorrow unless somebody finds a serious flaw with them.
If you want to try them before they hit a mirror near you, see bz 559340
for details.
David
14 years, 2 months
