Paul's Web Pages

Also Giving up on Ruby Packaging

Paul van Tilburg — 2011-01-25T00:00:00+01:00

I have just sent a mail to the Debian/Ruby Extras mailing list stating that I will also give up most of my Ruby packaging efforts and reduce my involvement in the team. I am following Lucas Nussbaum in his decision. Although our reasons are slightly different, I subscribe most of what he says in his blog post. Besides that, I haven’t done much Ruby programming in the past years, making me lose the motivation for the huge load of packages I am responsible for and thus subconsciously perceive that as a burden, as I feel guilty not having/making time to work on them.

So, what does this mean? I will handover (co)maintainership of over 50 libraries. Many of which have dead upstream, unfortunately. Also will I be looking for someone to take over the administrative tasks of heading the team such as mailing list moderation and Alioth repository access. I will keep maintaining some programs that I still use, such as Camping, and am approachable for (mentor) uploads.

Meanwhile I will continue my work on my PhD thesis, which is progressing well and should lead to my defence (hopefully) somewhere around September this year. That said, I will try to keep tinkering with Ruby and other F/OSS projects. Oh, and also to get more motivated and some inspiration…

Post-FOSDEM 2009

Paul van Tilburg — 2009-02-16T00:00:00+01:00

I have attended FOSDEM again this year. Most of all, it was nice to see everyone again, especially the Collabora crew. Besides having fun while hanging out with them again, I must say FOSDEM was quite a motivation boost too!

I feel motivated again to work on Ruby packaging. The whole RubyGem mess and other less-specific Ruby-related messes keep draining my motivation. This feels very conflicting, since I like the language very much. The upcoming transition to Ruby 1.9.1 will be quite a challenge and I hope that we can finally work out a nice, actual Ruby policy for Squeeze.

A few days ago I have also joined the pkg-gstreamer team, mainly to work on Elisa packaging. Elisa is a nice-looking media center application that I am using on my HTPC. Debian’s experimental suite now contains an up-to-date version of Elisa, try it out if you want.

Elisa 0.5.27

So, why is Elisa not in unstable yet. Well, Elisa has a plugin system which also features auto-updates. While this is very nice on platforms such as Windows, it is not really nice for Debian. I have been working to get this updating disabled by default. Once I am sure (hopefully by the time 0.5.28 gets released) that it is in order, I wil upload it to unstable.

Meanwhile I am planning to work on some Elisa plugins to add some features that I feel are missing. First of all I need webradio a la Rhythmbox in there. Then something to watch TV: a MythTV frontend-plugin, via UPnp, or whatever works. Finally it might be nice to have to have a plugin to setup video-conferencing using Telepathy. I’m quite sure some of these things are lying around somewhere, more about that later.

Lenny Released

Paul van Tilburg — 2009-02-15T00:00:00+01:00

The long-awaited, big and stable Debian GNU/Linux “Lenny” 5.0 has been released! Great job everyone and congratulations!

In this release the Debian/Ruby Extra team has an ever greater presence. We were able to increase the number of mainted libraries and applications to over 95 packages. Also quite a lot of issues were resolved and I am proud that we obtained this quality level.

For Squeeze we plan to deal with the transition to Ruby 1.9 and with possible multiple interpreter-support (still Ruby 1.8, JRuby?). We might also deal with the gems, who knows? :)

P.S. Indeed, did I just started posting without explaining why I was away for over 7 months?

Taking and Giving

Paul van Tilburg — 2007-11-04T00:00:00+01:00

From Debian I downloaded, installed and toyed around with Liquidsoap. It took me a few moments to understand the language, but once I did, I got very enthusiastic about it. I always wanted something more than just streaming a set for my friends now and then and this tool allows me to created a quite contrived webradio setup. More about that later…

To Debian unstable I finally uploaded Camping, a small Ruby web framework for MCV type applications. It is in NEW now. I’ve been writing (or at least started writing) quite a few apps based on Camping the past few months. Primarily because it is fun, but also because I like its flexibility and strength very much (see also some examples). Once Camping is in Debian, I’d like to put more Camping apps out in the open.

Ruby D-Bus 0.2.0

Paul van Tilburg — 2007-07-03T00:00:00+02:00

Arnaud and I finally managed to release Ruby D-Bus “Almost live from DebConf 7” 0.2.0. The release was planned for DebConf 7. However, I didn’t manage to get it ready in between all the talks, meetings, and other social stuff. Ruby D-Bus is an implementation of the D-Bus protocol in pure Ruby. After starting the development in February, it soon became apparent that several other projects were out there with about the same goal, such as Pure Ruby DBUS and R-Bus.

Our approach is to have an API that is close to the old Ruby D-Bus bindings. While the other, similar projects seem to have a slightly different goal, we still invite them to come to some sort of merging so that no duplicate effort is put into three or four separate projects with almost the same result.

The 0.2.0 release is our first real public release. We have a large subset of the features working and documented. The main focus of this release was to improve the API documentation and the tutorial. The 0.2.0 release is a release for exploratory purposes. We invite everyone interested to have a look at the API and inner works and provide us with feedback and/or patches. This means that the API can still change a bit over time based on feedback and tweaks performed by ourselves. So don’t built a big application on it just yet if you’re not willing to make some changes later on. For more information, see our project (Trac) page.

Debconf Debian/Ruby Extras Meeting

Paul van Tilburg — 2007-06-19T00:00:00+02:00

The Debian/Ruby Extras team has come to an agreement about a meeting time and date, yay! We’re going to meet today, Tuesday June 19, 2007 and discuss current packaging issues, plans for the future, and the Ruby policy. I’m delighted that half of the members of the team are here and are able to get together.

Invitation If anyone is interested in joining the team or observing what we do, please meet us at 18:00 in front of the cafeteria.

Oh, and could somebody at least bring a computer, because my PowerBook is not as portable anymore as it used to be.

Update: I forgot to mention that most team members usually hide out on IRC in the #debian-ruby channel on OFTC.

DebCamp Update

Paul van Tilburg — 2007-06-15T00:00:00+02:00

It is time for a DebCamp update, since I’ve been here three days now. I have mainly been working on picking up the slack regarding Debian/Ruby Extras. This meant: getting rid of a CDBS rule that substitutes the entire team in the Uploaders field, cleaning up some package, uploading some packages with new upstream, solving and filing bugs.

During all this, the “picture” of the environment outside is actually only missing yellow/brown trees shedding their leaves.

Ruby D-Bus 0.2.0

In between the Debian/Ruby Extras work I have been able to finish the documentation of our Ruby D-Bus protocol implementation. It is due for release this weekend and I think we’ll make it.

Technical Stuff

Paul van Tilburg — 2007-03-21T00:00:00+01:00

Hobix

There were some issues concerning Hobix and the new Ruby (1.8.6) that entered Sid recently. I’ve solved the problem, as you can see, and uploaded a Subversion snapshot package to experimental.

Update: It seems that hobix 0.5~svn20070319-1 accidently was uploaded without share data. This was spotted and fixed by Arnaud, thanks! A new version (0.5~svn20070319-2) is on its way to experimental!

Ruby D-Bus

A few weeks ago I wrote to Arnaud Cornet about the fact that it is quite amazing that there is no up-to-date implementation of D-Bus for Ruby at all after such a long time. This resulted a few days ago in our Ruby D-Bus project. Some stuff is working already, quite low-level still, but really nice. I’m looking forward to designing the high-level API.

I found out that other people had the same thoughts as us and also started to work on an implementations on their own without telling anyone. So, it seems there are three implementions now (as far as I know) that all have specific features working. I hope we can merge everything into one project. We’ll see what happens…

OpenID

I have taken some interest into OpenID, having to register some accounts on arbitrary forums. I ran into the fact that Rails recently got OpenID support and that support for phpBB is coming up, which is nice. Finally it could be over with all the logins and all the password. At the moment I haven’t found a statisfactory identity provider yet, so I started working on my own service. Ruby OpenID has an example server implementation which I am working on to become FLOIDS: the Free Luon OpenID Service.

Koditoj

Recently, I inventoried all the programs I authored or co-authored in the past 8 years. There is some stuff in there that maybe deserves a second life or at least some description. So, in a series of posts that I’ll call ‘Koditoj’ (free translatable from Esperanto to ‘things that have been coded’) I want to go over all these programs and libraries and give them some attention. More to come soon…

Debian Ruby Extras Etch To Do

Paul van Tilburg — 2006-11-01T00:00:00+01:00

During the past weeks I’ve been drawing up a list with things to be done for the Etch release concerning my work for the Debian/Ruby Extras team. I think it is quite complete now. I hope my fellow team members can help me accomplish these goals:

Solve all remaining issues concerning the ruby-pkg-tools.
Make sure that all team-maintained packages are:
- bug-less, that is, no open priority minor or higher bug reports,
- installable,
- up-to-date with respect to the upstream version.
Consider all work-in-progress packages and get them in Etch if they are worthy.
Take over the packages put up for adaption by Damog.
Create the libextras-ruby meta-package and get it into Etch.

I think the first two items are as good as taken care of. However, the last three points need some more attention the next few weeks.

Journal Alive Again

Paul van Tilburg — 2006-07-01T00:00:00+02:00

After replacing the laptop disk of my “server” that was failing yet again, my journal is alive again. I already had to replace the disk in November 2005. Of course, I cannot expect it to run for more than 7 months.

Anyway, holiday is near! I will leave for France (Perret, Bretagne) with friends and will really be gone for two weeks. I will leave July 8 and return on July 22. I am looking forward to this, especially because this is going to be my first real “external” holiday in 3 years.

Study

The study is going smoothly. I have almost finished my exams and the ones I have done so far went quite well. I had to change my planning though, since I was asking too much of myself. A feasible, less ambitious planning will get the job done much better than an overfull, too ambitious plan (4 courses, 4 assignment and 10 hours of work per week). While everybody is probably consciously aware of this, including me, I had to learn it the hard way.

After my holiday I plan to finish the pending thee assignments that I have been postponing for years and then, September 1, start with my 6 month Master project. I hope to finish the project and get my MSc somewhere in April 2007, so near… :)

Debian/Ruby

I noticed that the Debian Python team beat us to it with the rigorous policy changes. The Debian/Ruby Extras team has been planning quite some changes for a few months but actually haven’t gotten around to discussing about it and doing some real proposals. Meanwhile the team grown in numbers of members and packages and everything is running smoothly (except of course for some issues concerning the current policy). I hope to activate that process in or just after the summer holidays.

Ruby Stdlib (3)

Paul van Tilburg — 2005-03-15T00:00:00+01:00

I’ve mailed a few times with Akira Yamada and after some tweaking, his Ruby 1.8 packages have been uploaded with most of Ruby’s standard library packages put in one package: libruby1.8. The libraries still being packages separately are the ones have dependencies unrelated to Ruby’s dependencies. Great work Akira.

This is step 1 and I hope that Fumitoshy Ukai will follow with step 2: adapting the ruby-defaults to follow the setup of the new ruby1.8 package structure. When this is done (hopefully soon), the “main complaint” about Debian from a Ruby users perspective (yes, Andrew, some people are nuts and get involved with another blasted pocket language) will be gone when it’s time to release Sarge¹.

Website

Between studying for exams I’ve finished converting my own small website to use Hobix as well, so that the layout side but also maintaining side works and looks the same. A lean and mean site for my P233-laptop-server, dynamic HTML is overrated anyway.

¹ Nope, I am not going to say anything about that. :)

RubyGems and Debian

Paul van Tilburg — 2005-02-11T00:00:00+01:00

I was surprised to see some activity for packaging RubyGems for Debian two weeks ago; it has been really quiet in that area for a while now. There had been a lot of discussion in the Ruby community some time ago whether RPA or RubyGems should be used to install third party Ruby libraries and applications. Currently the general consensus is that both systems can live together as long as developers are not going to publish their software in Gem form only.

Last week there was some discussion about RPA/RubyGems and Debian on the Debian-Ruby list as a reaction on the packaging of Rails (which is well underway). Marcelo E. Magallon brought up some interesting points and hit the spot with what I had been thinking about the situation too.

In my opinion RPA does and will do a better job for Debian Ruby package maintainers both philosophy and operational wise, because they are very much alike. I’ve posted about RPA earlier and have decided to ITP RPA base. The resulting package will be meant as a tool for Debian Ruby developers so that QA can be done in cooperation with the RPA team but also to work in a CPAN-like manner, provided it can be adapted not to update Debian native installed libs and handle other subtle issues.

Ruby Stdlib (2)

Paul van Tilburg — 2005-01-27T00:00:00+01:00

There has been quite a lot of fuss about the Debian Ruby Stdlib stuff the past days. Adeodato Simó, Andres Salomon and I have drafted a proposal for a possible working solution for the problem. I think the solution given in the proposal is better than what the idea I had in a previous journal entry. It adapts the ruby-defaults package and providing for ways to install ruby using three levels (on a Debian X-like manner):

ruby — installs the full ruby suite (ruby-core and rest of standard libs that depends on non-standard/required libraries).

ruby-core — installs ruby-interpreter and most of the standard libs that are either pure Ruby or depend on standard/required libraries.

ruby-interpreter — installs the Ruby interpreter only, what the ruby package is now.

This way, apt-get install ruby will install what everyone expects, the interpreter and all of standard lib. I have uploaded a modified version of the ruby-defaults packages to try this setup, they are available via:

deb http://people.debian.org/~paulvt/ruby ./

I can now use ruby-core since I don’t feel much for having Tk and stuff. Note that there are still some version depends on ruby. Although ruby-interpreter provides ruby, you’ll still have to install the entire tree when you got some packages installed that have a versioned depend on ruby.

Ruby Stdlib

Paul van Tilburg — 2005-01-25T00:00:00+01:00

OK! I have to write something about this. Warren Brian Noronha on the #ruby-lang IRC (FreeNode) channel pointed me to some nasty blog entries (too-biased and the buckblogs here) about the current state of Ruby’s standard library packages in Debian. Besides the fact that such an issue shouldn’t be a reason at all to switch distro (if it is, one can keep switching forever), there is a point in all this.

A bug report has been open for a while requesting the creation of a ruby-stdlib virtual packaging and I’ve seen it be seconded many times on the debian-ruby mailinglist. Unfortunately I’ve seen no action on nor any comments about this bug/request. I’ve heard many requests for putting everything in one ruby-stdlib package, which is not a really nice solution either, IMO. I can understand the maintainers reluctance; such a package would introduce dependencies on Tk, XML libraries, etc.

A compromise could be to make the ruby package depend on ruby-stdlib-core, which is a real package containing all architecture independent libs without causing dependencies on other Debian packages (ala perl-modules). Both can be installed regardless anything. Next to that, ruby should recommend on the virtual ruby-stdlib-other (or some other name) package, that depends on smaller stdlib packages as libruby-tk, etc (ala gstreamer0.8-plugins).

NB. If someone has other suggestions, please mail them to the debian-ruby list or drop by at the IRC channel (#debian-ruby@FreeNode).

Ruby Tutor cancelled

Paul van Tilburg — 2004-10-02T00:00:00+02:00

The plan to program a Ruby Tutor as I earlier posted last week has been cancelled. It seems that the purpose of the project for the Intelligent Systems course wasn’t clear enough to us.

Since I (we) have no time at all this trimester for such a large project and the major imperative to do implement is now gone, I don’t think it’ll ever happen. Sorry!

Ruby Tutor

Paul van Tilburg — 2004-09-25T00:00:00+02:00

For the Intelligent Systems course, we have to write an intelligent agent as a project. We came up with the idea to write a Ruby Programming Language Tutor. The agent should learn someone without programming or at least OOP knowledge the Ruby language. The agent does this by giving the student interactive lessons consisting of small explanations, examples and exercises on a certain topic. I’ve posted our idea to the Ruby Talk mailinglist, got some reactions so far, but would’ve liked to have more. Well, maybe that will happen when I post more concrete ideas, providing we’ll go with this idea anyway.

RPA proposals

Paul van Tilburg — 2004-09-24T00:00:00+02:00

I had a look at some of RPA’s proposals for a good API design and good practices. I really think RPA is a better influence on Ruby packaging stuff then Gems are. At least from a personal and Debian packager perspective. Also saw that Why had finished Chapter 5 of the Why’s (Poignant) Guide to Ruby. It’s really fun and wacko stuff to read, thanks Why!

Gems

Paul van Tilburg — 2004-09-08T00:00:00+02:00

Has it been 4 days already? So it seems, hmmm… days can be sooo full, last Monday I was occupied from 8:15 till over 18:15, I think the Trimester of Hell remark on August 17 wasn’t an overstatement. I mean, it’s only the beginning!

The Ruby Pickaxe 2nd edition is bound to release very soon. I’ve been looking forward to buying this, since the first edition is based on Ruby 1.6, but I’ve been using Ruby 1.8 for months now. I have to say something about these Ruby Gems. Everyone keeps asking me what it is that I have against Ruby Gems, so I’ll try to answer that here. It was conceived as a way, ala CPAN, but then different. Since each Gems is just one directory, this leads to some unclean side-effects:

You have to install program stubs all over the place, i.e. let $prefix/bin/program link to the binary in the gem’s dir so it’s in the user’s path.
Since libraries are distributed as gems too, you can require them. You can do: require 'some_gem_lib' But for this require is redefined to search efficiently through all gems.
Since the libraries are located in one directory, programmers can abuse this by using more relative paths in the code. For example: require "../../../mylib/a/b/c.rb" This is not at all a best practice and packages packging harder.

Also some stuff learned in other package systems are not used (for now), such as Recommends, Suggests, etc. Also versioned depends are not a required thing, which, I think, shall lead to some chaos. Since the main goal is to create a standard way to distribute code to third party, packager etc. I think they should’ve been more involved. Installing these gems in those directory also violates the FHS, making it all very hard to package for Debian. I’m looking much more at RPA now, which looks very nice and interesting. I hope people aren’t going to distribute their stuff as gems only and also won’t make assumptions based on it if they do.