The Ruby Oniguruma gem pissed me off the other day. I was trying to install the ultraviolet gem, and while building dependencies, compiling was done, that failed. Ultraviolet depended on oniguruma. gem did it’s thing and started installing that, but oniguruma has extensions that must be compiled, and to do so needed some headers from oniguruma itself.
I’m not a debian developer, but I like debs. First, if I was doing this with debs instead of gems, a binary package compiled for my architecture would have been pulled in automatically and life would have moved on. If I really wanted to build this from sources, libonig-dev would have been installed when I ran ‘apt-get build-dep liboniguruma-ruby’.
I’ve built a couple ruby debs in the past by stealing from other debs, but last night in my frustration I went out, read a bunch, chattered some, and started building more. You can find a repo here:
deb http://ubuntu.ninjr.org/ hardy ninjr deb-src http://ubuntu.ninjr.org/ hardy ninjr
And if you so desire grab the key with:
wget http://ubuntu.ninjr.org/btm@loftninjas.org.gpg.key sudo apt-key add btm@loftninjas.org.gpg.key sudo apt-get update
Gunnar Wolf responded to my query about packaging with an awesome tip, libsetup-ruby1.8.
- apt-get install libsetup-ruby1.8 ruby-pkg-tools fakeroot dpkg-dev debhelper cdbs ruby1.8-dev
- Grab a .tgz or .gem
- untar it (or ‘gem unpack foo.gem’).
- cp /usr/lib/ruby/1.8/setup.rb package-1.1.1/
- mkdir package-1.1.1/debian
- cd package-1.1.1
- dch –create -v1.1.1-1
- fix your email, pick a package name (libpackage-ruby is my choice), put in ‘unstable’
- cd debian
- put this in ‘rules’:
#!/usr/bin/make -f # copyright 2006 by Esteban Manchado Vel�zquez include /usr/share/cdbs/1/rules/simple-patchsys.mk include /usr/share/cdbs/1/rules/debhelper.mk # Ruby package with setup.rb include /usr/share/ruby-pkg-tools/1/class/ruby-setup-rb.mk
- Make a ‘control’ file like this:
Source: libtextpow-ruby Section: libs Priority: optional Maintainer: Bryan McLellan Build-Depends: cdbs, debhelper (>> 5.0.0), ruby-pkg-tools, ruby1.8 Standards-Version: 3.8.0 Package: libtextpow-ruby Architecture: all Depends: libtextpow-ruby1.8 Description: a library to parse and process Textmate bundles. . This is a dummy package to install the GD library bindings for the default version of Ruby. Package: libtextpow-ruby1.8 Architecture: all Depends: ruby1.8, libplist-ruby, liboniguruma-ruby Description: a library to parse and process Textmate bundles. Package: libtextpow-ruby-doc Section: doc Architecture: all Description: a library to parse and process Textmate bundles. a library to parse and process Textmate bundles . This is the documentation package, with upstream documentation as well as generated rdoc.
On the package libpackage-ruby1.8 line, change architecture to ‘any’ if the package compiles any extensions so your package output will correctly be architecture specific. If the ruby package has no docs, pull that section out.
- cd ..
- dpkg-buildpackage -rfakeroot
That’s about it. Contributing to debian appears difficult. I think you’ve got to know someone who knows someone to get involved. But at least this way you can start building debs.
You don’t need to know someone to get involved with Debian! A lot of work can be done without any authorization at all- fixing bugs, fixing or adding to docs, helping with the website, and even creating packages (you do need a sponsor to upload packages into Debian).
If you want to get further involved than that, take a look at http://www.debian.org/devel/join/newmaint for information on how you can join Debian in a more official way.
@the paul,
Most work requires getting someone to pay attention. If you fix a bug, even if you do all the work possible and create a dpatch or quilt patch file that just needs to be dropped in, you still need to get someone to do it.
I’ve recently put effort into helping with packaging, but it’s still a matter of needing to know someone. Sending an RFS doesn’t put you in any sort of queue, someone has to be feeling nice and want to look over your packaging for you.
Becoming a maintainer requires you go through a lot of these steps, which are heavily social. In the end, you have to be driven to want to help (or maybe want power of some kind?) to contribute. The challenge of learning to do everything the debian way is hard enough on it’s own.
Yeah, contribution does require some social steps; at the minimum, e-mailing people and asking them to accept work, or posting fixes, links, or information on a wiki or the BTS.
But I don’t know of any other software projects- open source or otherwise- to which it is any easier to contribute in a social vacuum. If you have some good ideas in that arena, I’d be happy to pass them on.
A side note regarding motivation- when I joined Debian, it wasn’t for power or even through a desire to help. I used Debian, and I wanted it to get better, and the best way to make it better was to share my improvements with the rest of the community so my work could be inspected, further improved by others, and so on.
Anyway, as I neglected to mention above, thanks for this post. It came in handy today.
And while there’s a lot of documentation out there for using the smorgasborg of debian tools, it takes a bit of “try, try, try again”. When I posted to DRE offering to help, nobody responded. I took that to mean that I would need to find my own way to help.
When I later posted an RFS for a ruby package, I got a couple suggestions from non-DDs.
So I’ve fiddled with the packaging a bit more, and in the interim found someone I know who is a DD who promised to look at the packages when I was ready again (holidays).
I understand the difficulties with educating a group of users where you can’t tell if it will be worth it or not. However my time is valuable as well and always goes to the projects that I get responses from. From the outside looking in, it’s likely a social problem. It’s too easy to forgot how difficult it can be when you have experience dealing with a problem.
I suppose when someone emails an RFS, it should be tied (cc’d) by policy to the ITP bug. There should be some way to search for ITPs with an associated RFS, a state. If a bug remains in that state without any comment for a certain period of time it should send out a reminder or at least be searchable for that fashion and a group of DDs should regularly watch this result, trying to discover why the process has stalled.
I suppose this is kind of like the volunteers on launchpad who don’t actually resolve bugs, but manage ensuring that all the information is collected that a developer would need to fix the bug.