A new release of Backup Manager has been published. This release closes a bunch of bugs reported in Debian and in the official Bugzilla. The release notes are available here. Here is the announcement made on the user mailing list. I ve also uploaded a new Debian package to sid, in order to provide 0.7.8 for the unstable distribution of Debian. Reports are welcome (but bug-related ones are prefered, if possible in the official Bugzilla rather than in the Debian BTS).

Hey planet, it s been a very long time since I took my e-pen to write something down here, my work is taking pretty much all my time nowdays. Anyway, it seems that there is sort of a polemic rising here and there about RubyGems and its packaging philosophy. I d like to take that opportunity to contribute to the debate with the experience I had at Yoolink. Yes, we provide Ruby on Rails applications and are defacto dealing (or trying to) with Ruby and its gems. Wouter enlightened the main reason why it s such a mess to put into production a Rails app and to maintain it : the Ruby on Rails ecosystem is unstable. If you start writing your app, there are very big chances that when it gets mature for production mode, one or more of the Ruby libs you depend on will have a new version. And sadly, chances are there too that one of those libs will provide an API change. This can happen in a lot of places in a Rails app, because of its modular structure: plugins, gems or even Rails core upgrades (try to upgrade a real-working Rails app from 1.x to 2.x if you like tricky games). I agree with Joss when he said that Debian packages and Ruby gems are not designed for the same purpose, the latter are for a developer ecosystem and the first suitable for long-working production ecosystems. That s why setting up a complex Rails app in production is a nightmare : no Debian packages for all your Ruby needs on the first hand and API-unstable and hard-to-upgrade gems on the other hand. At Yoolink, the only working way we ve found to maintain in production our Rails apps is to freeze pretty much every Ruby-thing we can. Our production servers are then Rails/Ruby free (nothing installed system-wide) and the apps provides all their Ruby dependencies in their vendor/ directory. You can t do that for native gems but that works for 90% of a random Rails app s dependencies. To conclude, I d say that most of these issues come from the philosophy of the Ruby/Rails people : they don t fear to change anything they want from one release to another, just take a look at the gettext support in Rails 2.2 and you ll understand what I mean . It s like they don t even take in mind that people are now using their stuff, in real world, with customers relying on their apps. It s not a pet project anymore guys, if Rails want to remain the killer app it is, it will have to be someting stable and maintainable.

It’s been a looong time since I blogged here. Perhaps I should write more frequently so you won’t start thinking I died silently ;). I’m not dead. It’s just that I’ve started a company a couple of months ago and that does take a lot of my time. It’s pretty exciting, - as you can imagine - we’re using Debian everywhere and the team is great. I’ll write another blog-entry about that later. In the meanwhile, I’m on holydays for a week, and I plan to squash my TODO list:

• Backup Manager (a couple of bugs have to be fixed)
• Electricsheep (a new upstream release is available)
• My Perl modules deserve a couple of maintenance too, like Coat::Persistent

I’ve uploaded a new major release of TinyMCE into sid, the package jumps from the 2.x branch to the new 3.x one. For the record, packages that use TinyMCE should rather depend on that packge instead of shipping the sources itself.

Yes I know, it’s like a year since the last development release of Backup Manager has been published, I should be ashamed of such a huge idleness. But actually, If you ask me, I’m not. Instead of writing long lines of haiku to apologize for being so late at releasing, here is an illustrated reason why it was so loooong.

Yes I know, it’s like a year since the last development release of Backup Manager has been published, I should be ashamed of such a huge idleness. But actually, If you ask me, I’m not. Instead of writing long lines of haiku to apologize for being so late at releasing, here is an illustrated reason why it was so loooong.

Dear lazyweb, this sunday afternoon, I opened BackupManager’s Bugzilla and started squashing bugs. There was 54 bugs opened that requested a review. 15 of them are now tagged “pending” (meaning they’re closed in SVN and will be shiped with the next release). All of the patches submited - that made sense - were applied, thanks to all the reporters for their help, by the way. So, fear a new release soon…

If you’re like me and want to build the ieee80211 driver for your debian box with the last kernel available in sid (2.6.24), you’ll have to apply that patch to the sources. As you can see, a couple of changes occured in the Kernel API and that blocks the build. Hope that can help.

Sam suggested in his lat blog entry to create a team whose role would be to handle the promotional stuff. I find that idea pretty good, having a central point where to take decisions regarding how Debian should communicate with the outside world makes sense. I totally support that idea.

At work, I was voluntold to deal with an old AIX server, and today, part of my job was to get OpenSSH up and running… Erf. How the hell could someone work with the tool “smitty”? Do they call that a package maintenance system? Do people really pay for that ? This makes me sick, why didn’t they choose Debian? I have the strange feeling of being 10 years back in time, dealing with an old interface, user-unfriendly, terminal intolerant and anti-productive. Sometimes, life is crual.

Top posters in a few Debian-related Planets:

$ planet-scores.sh 
Planet Debian-FR :
     19 Rapha l Hertzog
      4 Roland Mas
      3 Jean-Christophe Dubacq
      2 Gr gory Colpart
      2 Alexis Sukrieh

Sometimes I think this should be renamed Planet Buxy.

Planet Debian-FR (utilisateurs) :
     10 Julien Candelier
      8 Emilien Macchi
      4 Guilhem Bonnefille
      3 Shams Fantar
      1 Rapha l Hertzog
      1 Olivier Berger (perso)
      1 Jean-Christophe Dubacq
      1 Jean-Baptiste H tier (djib)
      1 Eric Veiras Galisson

Newly added contributors to that planet have all their recent articles aggregated, not only the ones they wrote since they were added.

Planet Debian :
     40 Christian Perrier
      2 Russell Coker
      2 Raphael Geissert
      1 Wouter Verhelst
      1 Steve Kemp
      1 Romain Francoise
      1 NOKUBI Takatsugu
      1 Michal  iha 
      1 John Goerzen
      1 Joey Schulze
      1 Gerfried Fuchs
      1 Fathi Boudra
      1 Enrico Zini
      1 Emanuele Rocca
      1 Dirk Eddelbuettel
      1 David Welton
      1 Christine Spang
      1 Antti-Juhani Kaijanaho
      1 Adam Rosi-Kessel

Planet "Christian loves rugby".

debian-community.org :
      4 Holger Levsen
      3 Andrew Donnellan
      2 Evgeni Golov
      1 Wolfgang Lonien
      1 Rapha l Hertzog
      1 Martin Albisetti
      1 Marcos Marado
      1 Jean-Christophe Dubacq
      1 Cord Beermann
      1 Benjamin A'Lee
      1 Andreas Putzo
$

I know I have an encoding problem on some planets, but that script is a very basic curl+shell+sed+grep+recode+sort+uniq pipeline, and I only use it for the amusement value. Maybe I'll recode it with a proper RSS parser some day if I feel utterly bored.

There is going to be a Perl event in Lyon, France during November : The French Perl Workshop 2007 . I’ve submitted two talks, that have been approved today:

• Perl Console - Votre compagnon pour d velopper en Perl (Fr)
• Red couvrir le Perl Objet avec Moose (Fr)

I was thinking of a talk about the Debian packaging of Perl modules. That could be interesting to enlight how Perl libraries are packaged, how one can build his own package for a random module and so on.
This would be a talk designed for Perl developers under Debian. Would be great to do that with a member of the Debian Perl Group. If you’re interested, feel free to contact me so we can coordinate our efforts. Other talks are listed on that page.

A new version of PerlConsole is available. As you can see in the changelog, lots of goodness with this release comes to you (~/.perlconsolerc rules, thanks to S. Zachariah Sprackett for his patch). After reading the source code of Devel::REPL and learning from it (this is really a great library, congrats to mst) I decided not to orphan Perl Console. Yes, that was a possibility as Devel::REPL provides anything you need to build a console (and comes with “re.pl” which actually is a console itself). I decided not to give it up for one reason: Devel::REPL is great, and better written than Perl Console (it supports plugins and profiles and is Moose-based) but, it’s slow. When you launch it, you have to wait a couple of seconds before the console prompts you. This is because of Moose I suppose. I know that’s not blocker as a console is a development tool, but I feel like some of PerlConsole’s users would like to have the choice between a full featured, extensible and Moose-base console that’s slow, and a light one that is basic in design and implementation. I backported one of the most interesting plugin of Devel::REPL to PerlConsole, being the console’s lexical environement. Devel::REPL did a great thing there, using Lexical::Persistence to simulate a namespace in the console. Feel free to give your feedback about this, I wonder if there’s still an audience for PerlConsole when Devel::REPL is in the town. I think so, maybe I’m wrong, then tell me.

A good read eval print loop for perl has been on my Wanted list for a long time. Matt S Trout’s Devel::REPL has been looking promissing but I didn’t want to fiddle with installing the dependencies. Thanks to Alexis Sukrieh and the Debian Perl Group Devel::REPL will enter unstable. Yeahhh… Another thing on my wanted list was Debian packages of Perl::Critic. Couldn’t find a ITP, but looking around at the Debian Perl Group’s website to find out how to package it I discovered that Joey Hess allready did the work. I’ve been using the morning installing the above from the subversion repository on pkg-perl.alioth.debian.org. Only problem was that I needed a newer package of libppi-perl which wasn’t maintained in subversion. What’s next? Looking at my ~/.perl Perl::Tidy seems to be a candidate.

Thanks to Florian Ragwitz, who packaged libpadwalker-perl 1.5-1, there is no blocker anymore that prevents libdevel-repl-perl from entering sid: By the way, the author of Devel::REPL, Matt S Trout, looks pretty happy to see his module entering Debian. I’ve just uploaded libdevel-repl-perl, this upload closes the exciting work session we did during all the weekend with Damyan Ivanov, in order to get the module into debian. All its dependencies are now in the Perl group’s hands. That was fun. Team maintenance rocks!

I decided to play with Devel::REPL which looks to be exactly what I need to enhance my Perl Console. That module is not packaged in Debian, then I started packaging it with the help of the Debian Perl Group (big thanks go to Damyan Ivanov for his help). The day was pretty productive and we’re almost done now, as you can see in this tomboy note: PS MadCoder: I’m sorry dude, I’m still speaking about Perl

The first version of the debian package of Perl Console has been uploaded to the NEW queue. For those who are waiting for it, I’ve also uploaded the package here. Thanks to the patch sent by Antonio Terceiro, the version 0.3 will be properly packaged ala Perl (namely with the famous Makefile.PL, MANIFEST and friends). I plan to adress the multi-line issue for 0.3 (mainly handling code with loops or conditional structures), as Florian Ragwitz underlined, it could be worth using Devel::REPL instead of rewriting the wheel.

Hey, version 0.2 of the Perl Console is out. I found Gunnar’s comment in my first blog entry pretty relevant: providing only a scalar output isn’t user friendly; but freezing the console with either YAML or Data::Dumper would at best satisfy half of the user base. Hence comes the “preferences” idea. The console allows the user to choose either a value or another for a given preference. No big deal there, but it’s clearly the best thing to do for the output issue. In version 0.2, the user can enter something like that to change the output mode:

:set output = yaml

If the user wants to know what are the possible values for the preference “output” he can enter the following command:

:help output

Of course, the help engine reads dynamically the preferences definition, in order not to display outdated information (code changes, you know that!). So, in short, what’s new in 0.2:

• Complete rewrite of the program in object-oriented Perl
• support for preferences (user can set preferences)
• preference “output” added, with 3 values possible: scalar (default), yaml, dumper
• help engine added

The tarball is there, next step is the debian package (ITP already sent).

My Perl Console now uses Term::Readline for grabbing the user input, provides completion and keybindings. Moreover it can also load dynamically a module. Well, actually the pet program is getting older, and I could not resist to give it its own webpage. Check it out Perl developers! Note to myself (and to other members of the Debian Perl Group) : could be very useful for debugging the modules we maintain.

tm suggested:

"delete the feeds you find yourself reading less and less frequently"

In general, maybe, but there are always exceptions, like feeds which rarely update but carry important information when they do. I guess I should scan my subscriptions to see if there are any extremely unupdated feeds. Update: tm clarified:

"I meant those feeds you've subscribed to, but find out you don't read so often, regardless of how often they're updated. for me, one of those is/was: http://feeds.howstuffworks.com/DailyStuff"

That's not so easy for me to tell. I read my subscriptions through a planet-like page, so they appear in the page flow whether or not I expand them or not. Matt Palmer replied:

"I've got to say that I've never had a problem commenting on Limes & Lycopene. I suspect that the problem you had with Alexis Sukrieh's blog was likely unrelated to SpamKarma2 (or if it was SK2, it was a dodgy deployment -- you don't sound too sure what the cause of his breakage was). On the other hand, if there is anything broken on a blog, the polite thing to do is to tell the owner about it -- it might not necessarily be a problem for everyone (although with SQL errors and things like that, it should be possible for the site owner to get error reports via e-mail, but how often do you reckon that gets done?). And yes, Captchas give me the faeces too. For L&L, at least, I know for a fact that any problems will get looked at and fixed up damn quick. Contact e-mail is on Kathryn's site."

I sent a pingback. No response yet. I'll try email if there's no response later.

"Oh, and a comment on your comment system -- the text entry box is tiny (6 lines by maybe 35 characters just isn't enough for a literate comment)."

My preference is for 40x20 but if I make it that big, I get feedback that it's too big. It's always a compromise. It's meant to be about 22x8 now, but what size should it be?