More 1.9.3 fun
by Michael Stahnke
When installing a gem natively using ruby 1.9.3 package built from the
github ruby.spec, I'm having trouble using them, specifically with
bundler.
When I install sqlite3, I get a shared object in
[root@centos6-32 gems]# locate sqlite3_native.so
/usr/local/lib/gems/exts/sqlite3-1.3.5/lib/sqlite3/sqlite3_native.so
/usr/local/share/gems/gems/sqlite3-1.3.5/ext/sqlite3/sqlite3_native.so
It seems odd that the lib dir and the gems dir are not the same. That
may not be the issue though.
When I install via bundler (forgive my ignorance here, I normally
avoid bundler, but for this application it was required).
bundle install --without development test
[root@centos6-32 gitlabhq]# bundle show sqlite3
/usr/local/share/gems/gems/sqlite3-1.3.4
[root@centos6-32 gitlabhq]# bundle exec rake -T
rake aborted!
cannot load such file -- sqlite3/sqlite3_native
(See full trace by running task with --trace)
[root@centos6-32 gitlabhq]# bundle exec rake -T --trace
rake aborted!
cannot load such file -- sqlite3/sqlite3_native
/usr/local/share/gems/gems/sqlite3-1.3.4/lib/sqlite3.rb:6:in `require'
/usr/local/share/gems/gems/sqlite3-1.3.4/lib/sqlite3.rb:6:in `rescue
in <top (required)>'
/usr/local/share/gems/gems/sqlite3-1.3.4/lib/sqlite3.rb:2:in `<top (required)>'
/usr/local/share/gems/gems/bundler-1.0.21/lib/bundler/runtime.rb:68:in `require'
/usr/local/share/gems/gems/bundler-1.0.21/lib/bundler/runtime.rb:68:in
`block (2 levels) in require'
/usr/local/share/gems/gems/bundler-1.0.21/lib/bundler/runtime.rb:66:in `each'
/usr/local/share/gems/gems/bundler-1.0.21/lib/bundler/runtime.rb:66:in
`block in require'
/usr/local/share/gems/gems/bundler-1.0.21/lib/bundler/runtime.rb:55:in `each'
/usr/local/share/gems/gems/bundler-1.0.21/lib/bundler/runtime.rb:55:in `require'
/usr/local/share/gems/gems/bundler-1.0.21/lib/bundler.rb:122:in `require'
/srv/gitlabhq/config/application.rb:7:in `<top (required)>'
/srv/gitlabhq/Rakefile:5:in `require'
/srv/gitlabhq/Rakefile:5:in `<top (required)>'
/usr/share/gems/gems/rake-0.9.2.2/lib/rake/rake_module.rb:25:in `load'
/usr/share/gems/gems/rake-0.9.2.2/lib/rake/rake_module.rb:25:in `load_rakefile'
/usr/share/gems/gems/rake-0.9.2.2/lib/rake/application.rb:501:in
`raw_load_rakefile'
/usr/share/gems/gems/rake-0.9.2.2/lib/rake/application.rb:82:in `block
in load_rakefile'
/usr/share/gems/gems/rake-0.9.2.2/lib/rake/application.rb:133:in
`standard_exception_handling'
/usr/share/gems/gems/rake-0.9.2.2/lib/rake/application.rb:81:in `load_rakefile'
/usr/share/gems/gems/rake-0.9.2.2/lib/rake/application.rb:65:in `block in run'
/usr/share/gems/gems/rake-0.9.2.2/lib/rake/application.rb:133:in
`standard_exception_handling'
/usr/share/gems/gems/rake-0.9.2.2/lib/rake/application.rb:63:in `run'
/usr/bin/rake:32:in `<main>'
[root@centos6-32 gitlabhq]# bundle console
/usr/local/share/gems/gems/sqlite3-1.3.4/lib/sqlite3.rb:6:in
`require': cannot load such file -- sqlite3/sqlite3_native (LoadError)
from /usr/local/share/gems/gems/sqlite3-1.3.4/lib/sqlite3.rb:6:in
`rescue in <top (required)>'
from /usr/local/share/gems/gems/sqlite3-1.3.4/lib/sqlite3.rb:2:in
`<top (required)>'
from /usr/local/share/gems/gems/bundler-1.0.21/lib/bundler/runtime.rb:68:in
`require'
from /usr/local/share/gems/gems/bundler-1.0.21/lib/bundler/runtime.rb:68:in
`block (2 levels) in require'
from /usr/local/share/gems/gems/bundler-1.0.21/lib/bundler/runtime.rb:66:in
`each'
from /usr/local/share/gems/gems/bundler-1.0.21/lib/bundler/runtime.rb:66:in
`block in require'
from /usr/local/share/gems/gems/bundler-1.0.21/lib/bundler/runtime.rb:55:in
`each'
from /usr/local/share/gems/gems/bundler-1.0.21/lib/bundler/runtime.rb:55:in
`require'
from /usr/local/share/gems/gems/bundler-1.0.21/lib/bundler.rb:122:in `require'
from /usr/local/share/gems/gems/bundler-1.0.21/lib/bundler/cli.rb:430:in
`console'
from /usr/local/share/gems/gems/bundler-1.0.21/lib/bundler/vendor/thor/task.rb:22:in
`run'
from /usr/local/share/gems/gems/bundler-1.0.21/lib/bundler/vendor/thor/invocation.rb:118:in
`invoke_task'
from /usr/local/share/gems/gems/bundler-1.0.21/lib/bundler/vendor/thor.rb:263:in
`dispatch'
from /usr/local/share/gems/gems/bundler-1.0.21/lib/bundler/vendor/thor/base.rb:386:in
`start'
from /usr/local/share/gems/gems/bundler-1.0.21/bin/bundle:13:in `<top
(required)>'
from /usr/local/bin/bundle:19:in `load'
from /usr/local/bin/bundle:19:in `<main>'
So, obviously the bundle can't find the C extension. According to
some research, I see this on rubygems.org
"This works because rubygems copies the shared object from ext to lib
when the gem is installed."
I'm not sure that's happening.
I may be completely wrong with that I am doing here as well. The new
layout of gems in the 1.9 paradigm is still a bit confusing to me, so
that's why I am suspecting it is the issue. It potentially could be
the application (http://gitlabhq.com) as well.
Any help would be welcome.
11 years, 8 months
Retire rubygem-mongrel
by Vít Ondruch
Hi,
If nobody objects, I am going to retire *rubygem-mongrel* and its
associated gems rubygem-gem_plugin, rubygem-fastthread and
rubygem-mongrel_cluster.
Mongrel is not maintained anymore [1]. It dos not support Ruby on Rails
3 available in Fedora, the last supported Ruby on Rails version was
2.3.7. There are available more viable Ruby web servers such as
rubygem-thin. I believe nobody will regret this loss.
Vit
[1]
https://github.com/evan/mongrel/commit/12a06f658a5645e8ad0fa41c488a6f4a65...
11 years, 8 months
Package review request (ruby 1.9 attempt too)
by Michael Stahnke
I'm working on building out Puppet on Ruby 1.9 for my day job at
Puppet Labs. I also recently took over ruby-shadow since it was
orphaned. Upstream has moved to github and they now only distribute
as a gem. So, the package will be renamed to rubygem-ruby-shadow.
I *think* I've follwed the new proposed ruby 1.9 guidelines, but I am
sure I've missed a couple things. I'm also curious if there is a way
I could use the same spec for packages still on Ruby 1.8 (Fedora < 17
and EL)
Anyway, I'd appreciate Feedback. If it's too early to be attempting
Ruby 1.9 reviews, that's fine too. :)
https://bugzilla.redhat.com/show_bug.cgi?id=782560
stahnma
11 years, 8 months
Ruby 1.9.3 testing repository
by Vít Ondruch
Hello,
I have prepared testing repository with Ruby 1.9.3 rev 33347 (i.e. bit
newer version then RC1). You can enable it by downloading repo file [1]
into your /etc/yum.repos.d directory. You can later install the Ruby
package by issuing:
# sudo yum install ruby rubygems-1.8.10-rc1.1.fc17
Please note that installation of fully versioned rubygems is *mandatory*
ATM and you have to *uninstall rubygems* package prior installing this
test release to avoid version conflicts. This will be fixes as soon as
final release of Ruby will be available.
Vit
[1] http://vondruch.fedorapeople.org/ruby_1.9.3.repo
11 years, 8 months
Updated Guidelines Draft
by Bohuslav Kabrda
Hi guys,
thank you all for your comments. I updated the guidelines draft to reflect them:
- BR: ruby is now replaced with BR: ruby-devel for Ruby packages.
- The Gem versioned dependencies for R: and BR: were reformulated.
- Examples for packaging Gems with C extensions (did some rewriting in that section, too) and packaging Ruby applications (also fixed the header from h3 to h2 here :)) were added.
- Creation of non-Gem subpackages is no longer allowed.
It would be great if you could comment on the changes.
Regards,
Bohuslav.
11 years, 8 months
Ruby 1.9.3 rebuild
by Bohuslav Kabrda
Hi guys,
as the rebuild for Ruby 1.9.3 is nearing, I have prepared something that should ease our cooperation when rebuilding the packages with complicated dependencies.
As I was doing the rebuild myself (and locating the problematic packages as mentioned in [1]), I created the dependency trees and used an online tool to visualize them. Here are my results:
- The repo with textual representation of dependency trees is located on Github [2].
- The packages are divided into groups (G1 - G19). The syntax of the files is taken from the tool that I used for visualization [3]. The "urls" file in the repository contains links to graphs corresponding with each group.
- The dependencies are only shown inside the groups, but each package _may_ also be dependent on another package from a group with a lower number (you will have to check that in the specfile).
- The numbers in graphs represent the actual order in which the packages need to be built.
- If the package name ends with an underscore, it is one of the problematic packages mentioned in [1], so have a look there to see my suggestion what to do with it.
Here is what you can do with the Git repo (once we get the Koji tag):
- Checkout the repo, use grep to find the group that contains your package (if it is "rubygem-gemname", search only for "gemname", otherwise search for the whole package name).
- Look at "urls" and go to url that contains the graph with your package - there you can see what is needed before you can build your package.
- If necessary, communicate with the people that own the packages that you need.
- Build your package as soon as its dependencies are met.
- If your package is the last one of groups 1-9, please write an email to this list as soon as you build it. These groups contain packages that have lots of dependencies even between the groups, so it would be nice if everybody knew when each group is finished.
Please note, that you can use the packages from the rebuild I did - I wrote about that in one of my previous mails [4].
Regards,
Bohuslav.
[1] http://lists.fedoraproject.org/pipermail/ruby-sig/2011-December/000729.html
[2] https://github.com/bkabrda/ruby-rebuild-dependencies
[3] http://yuml.me/
[4] http://lists.fedoraproject.org/pipermail/ruby-sig/2011-December/000735.html
11 years, 8 months
ruby-ldap
by Michael Stahnke
It looks like the upstream of ruby-ldap has moved to distribution as a
gem only. I can get a tarball from github based upon a tag, but that
seems like a less good solution.
Does this mean that the package ruby-ldap should be retired, and a new
package rubygem-ruby-ldap should be added? This seems like quite a
bit of work for nothing more than a distribution methodology change,
but may be the best course.
Thoughts?
stahnma
11 years, 8 months
Ruby 1.9.3 update schedule
by Vít Ondruch
Hi rubyists,
Just to let you know about the schedule.
1) The Fedora feature page [1] was marked as "FeatureReadyForWrangler".
So hopefully, Ruby 1.9.3 will be approved by next FESCo meeting which
should be held at Monday 9th of January, if I am not mistaken.
2) We have already requested dedicated tag in Koji [2] to prevent longer
disruption of Rawhide and to provide us fallback if something goes
really wrong. However ...
3) Unfortunately, due to update of GCC, mass rebuild will start next
Thursday 12th of January and will be finished hopefully around 20th of
January. After that, we will get our tag.
4) This leaves us 2.5 weeks to rebuild all Ruby packages, because we
should merge the tag back to master before F17 cutoff (7th of February).
5) If we will not be able to rebuild all the packages in time, we will
need later to submit updates by Bodhi and use build overrides if needed.
I would appreciate if you, as a Ruby package maintainers, could provide
support during that period and take care of your packages. Hopefully we
will convince some proven packager to help us to speed the process of
updates and rebuilds.
Vit
[1] https://fedoraproject.org/wiki/Features/Ruby_1.9.3
[2] https://fedorahosted.org/rel-eng/ticket/5016
11 years, 8 months
