Planet Debian

Over two years ago, the FSF started its BadVista campaign with the goal of educating the public on problems related to software freedom, DRM, and more, with Microsoft's latest operating system. Today, the FSF is declaring victory; the name "Vista" is synonymous in the public eye with failure.

The real credit, I suppose, should go to Microsoft. Vista's design put the desires of big media companies, software companies, and Microsoft itself ahead of the desires of users. Vista defeated itself.

But the FSF's campaign drew a huge amount attention to the problems with Vista --- especially early on --- and provided a central location aggregating and amplifying criticism of Vista. In doing so, the FSF played an important role in helping the whole process along and in balancing this criticism with a more positive message about free software alternatives.

Gratitude is due to the FSF staff, members, and supports who made BadVista a success. Please read the announcement, Digg the article, support the FSF, and follow its other work in its other campaigns so that all the FSF's work can be as successful as BadVista.

Yesterday evening I received a quite nice mail - the people behind Linux New Media and the LNM Award asked me if I want to participate in the Jury for the 2009 edition of it. Sure I want. :) The process seems to be a very simple one (good), the Jury members make nominations for the various categories and then later on vote on them.

Now, while I already thought about it and know candidates I will nominate, what about you? I list the categories for this years edition below. Do you think something/someone/whatever should be nominated in those categories? Why? Note that only products/projects/people/organizations/whatever that have been very significant in 2008 should be nominated.

This editions categories are - Outstanding Contribution to Open Source / Linux / Free Software

• Most Linux / Open Source-Friendly Hardware Vendor

• Most Innovative Open Source Project

• Best Open Source Contribution for Mobile Devices

• Best Open Source Programming Language

• Most Significant Contribution for Security in Open Source

If you want, feel free to tell me what you think should go in those categories. Leave a comment here or send me email. If you also add a little reasoning why, even better.

After lot of development, I finally decided to release new testing release of Gammu.

The biggest changes are in SMS daemon, which got lot of improvements and is now in separate binary gammu-smsd. It can log better (support for syslog and Windows Event Log has been added), it can work as a proper daemon or Windows Service, it can be debugged easier (Gammu logs go to same log as other messages, SQL queries can be logged), can reload configuration on the fly.

In libGammu, debugging has also improved (you can now use callback to process messages), some memory leaks were fixed and some minor bugs has been fixed.

Command line interface now supports text for text messages to be entered through parameter and not only using standard input, it has a new command chekfirmware which obsoletes UsePhoneDB configuration option and other bug fixes has happened, for example messages sending is now again working on Windows.

And last but not least, SMS daemon, all related things and gammu configuration files now have man pages, which boosts documentation level from none to almost perfect ;-).

As a special bonus for Czech users, Gammu translation is now more complete and all new man pages are translated to Czech.

Full list of changes:

• Fix some memory leaks found by cppcheck.
• Fix unsafe sprintf usage in some modules.
• Improve debugging facilities to use state machine debug configuration when possible.
• Separate SMS daemon out of gammu binary.
• SMSD now requires [gammu] section in config file.
• UsePhoneDB option replaced by chekfirmware command.
• Added pkgconfig support for gsmsd (SMSD library).
• Debug logging can be handled by custom function in application.
• SMSD log now includes gammu log messages.
• SMSD now can log to syslog.
• SMSD can now deamonize itself.
• All callbacks can now pass user data along.
• SMSD can now write PID file.
• Added man pages for gammu-smsd(1), gammu-smsdrc(5) and gammurc(5).
• SMSD can now natively run as a Windows service (bug #451).
• SMSD debugging can be now enabled by DebugLevel directive.
• Proper reconnecting support for MySQL.
• Better error logging of PostgtreSQL SMSD service.
• SMSD now properly frees allocated memory.
• SMSD now handles SIGHUP for rereading configuration.
• Added LSB init script for SMSD.
• SMSD can now log to stderr/stdout.
• RunOnReceive now can get IDs of received messages.
• Avoid duplicating of same code in command line and tests for messages displaying.
• New binary gammu-smsd-inject to inject messages to SMSD.
• Gammu binary now does not support any SMSD operations.
• Sending TEXT message now accepts text using -text parameter.
• Improved logging differentiation of SMSD log messages.
• Properly remove messages from queue when sending fails (bug #778).
• Use own test handler instead of asserts.
• Separate gammu and libgammu messages, libgammu no longer sets textdomain.
• Use po4a for translating man pages.
• Dump more information in dct3trac, thanks to Duncan Salerno.
• SMSD cal log to Windows Event Log.
• Added man pages for SMSD backend services.
• Dropped static configuration files for MSVC, they were broken anyway and CMake now works good with MSVC.
• Script gammu-config supports also cdialog.
• Reduce stack usage on message composing (fixes crash on Windows).
• Fixed returned saved location on AT engine.
• Added support for dropping privileges in SMSD.

You can download from usual place: http://cihar.com/gammu/,

Debian users will find packages in experimental as soon as they will go through NEW queue.

Upgrading a laptop that has not been updated for ca. 2 months. Now it requests me to restart the system after every 5 minutes of downloading and installing packages. Repeatedly: I had to restart the upgrade process about 10 times already. In addition, I'm sure I've seen it updating some of the packages at least three times. But I'm sure by the end of today I'll be there.

OpenSUSE. For when Windows was not annoying enough.

Today I got my Acer One AOA150, is a really nice device, Unfortunately this model did not come with GNU/Linux, so I sadly have to still pay the microsoft tax

But the good point is that the Debian installation was a breeze, really simple, almost all hardware just works out of the box, BTW thanks to the guys who wrote http://wiki.debian.org/DebianAcerOne

my goal is to get used to this laptop and made it my main work laptop, I’ve always be a big fan of smalls laptops so this is a kind of a really nice device for me I guess.

I also always note that a lot of people complain about the small keyboards on the ‘mini-laptops`, but I did not find such a pain, there is still a need to get used to it, but with a couple of hours using it, seeings comfortable enough for me.

…of Nova Scotia.

My past and future colleague Trevor Smedley just lost his appeal to the Supreme Court of Nova Scotia of his criminal conviction for having pet chickens.  As the Supreme Court noted in Trevor J. Smedley and Her Majesty the Queen:

They are not just any chickens - they are special chickens. They are heritage chickens that are brought to this province from Quebec.

Indeed, the court agreed with Mr. Smedley that there was nothing wrong with the chickens:

The trial judge found that they are in every way inoffensive. There is no excessive or even noticeable noise, no odour. The way in which they are kept is not unsightly. The chickens remain on their property seemingly doing no harm to either the aesthetic qualities or the quiet enjoyment of the property of the immediate neighbours. So finds the trial judge.

As I haven’t seen much news about this case in the mainstream media, I’m posting a copy of the complete opinion here to shed public light on the matter. I know very little about Canadian chicken law, so I’m not sure whether further appeals are possible, but I hope Mr. Smedley can keep up the fight.

I just moved my blog from blosxom to ikiwiki. Slowly, but surely, my web-related infrastructure for gag.com and related sites is all moving to ikiwiki+git...

I shoved in a rewrite rule to map the old top-level URL to the new one, and ensured that my rss feed will only contain new posts. However, all the "permanent" article paths changed. Oh well. I'm much happier now!

Some weeks ago I bought myself an e-book reader, Sony Reader PRS 505. It is a really cool gadget, and as I usually read a lot of stuff in my computer, it is somehow an investment in my eyes. I decided on this one because the support for Linux is quite well, through the unofficial Free Software project Calibre.

Calibre is primarily an e-book cataloging program: it manages your e-book collection for you, and it is designed around the concept of the logical book (i.e. a single entry in the database that may correspond to ebooks in several formats). It also upports conversion from a dozen different ebook formats to LRF and EPUB. A graphical interface to the conversion software can be accessed easily by just clicking the “Convert E-books” button. A lot of input formats are supported: MOBI, LIT, PRC, EPUB, ODT, HTML, CBR, CBZ, RTF, TXT, PDF and LRS.

After some weeks of work, Martin Pitt and I have finished the packages for Debian and Ubuntu, which are right now waiting in the Debian NEW Queue. You can temporarily get them from here, compiled for Debian SID AMD64, but of course you can build them for your platform, or wait until they enter Debian.

I recently converted most of the Debian packaging for Telepathy and related projects from bzr to git, while changing the repository contents from just the debian/ directory to the whole source tree. Here's the recipe, using the latest one to be converted (pymsn) as an example.

Create a repository

mkdir pymsn
cd pymsn
git init

Mass tarball import

• download all the tarballs into ../tarballs

• rename all the tarballs to *.orig.tar.gz:

  rename 's/^pymsn-/pymsn_/' *.tar.gz
  rename 's/\.tar\.gz$/.orig.tar.gz/' *.tar.gz
  

• use git-import-orig to import them:

  cd ../pymsn
  ls ../tarballs/pymsn_*.orig.tar.gz
  for v in 0.2 0.2.1 0.2.2 0.3.0 0.3.1 0.3.2 0.3.3; do \
  git-import-orig --no-merge --no-dch --pristine-tar \
      -u $v ../tarballs/pymsn_$v.orig.tar.gz; done
  

• throw away the resulting master branch in favour of using one we convert from bzr later:

  git checkout upstream
  git branch -D master
  

Converting the Debian packaging

This has the slight complication that in some (but not all) of the bzr commits, the repository contained only the contents of the debian directory, in the root of the repository. So, I needed to rewrite history, with this script:

#!/bin/sh
# index-filter.sh
if git ls-files -s | grep debian; then
    :
else
    git ls-files -s |
        sed -e "s-\t-&debian/-" |
        GIT_INDEX_FILE=$GIT_INDEX_FILE.new git update-index --index-info &&
    mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE
fi

• Download unstable and experimental packaging into ../pymsn-experimental and ../pymsn-unstable

• Use bzr-fast-export and git-fast-import to import the two branches:

  ~/.bazaar/plugins/fastimport/exporters/bzr-fast-export.py \
      ../pymsn-unstable | git fast-import
  
  
  git branch -m master debian-lenny
  
  
  ~/.bazaar/plugins/fastimport/exporters/bzr-fast-export.py \
      ../pymsn-experimental | git fast-import
  
  
  git branch -m master debian
  
  
  git branch -D tmp
  

• Rewrite history so changelog, control etc. are consistently inside a debian directory, with the script shown above:

  git filter-branch --index-filter $(pwd)/../index-filter.sh debian-lenny
  rm -r .git/refs/original
  
  
  git filter-branch --index-filter $(pwd)/../index-filter.sh debian
  rm -r .git/refs/original
  

• Merge the appropriate upstream versions into each branch:

  git checkout debian
  git merge upstream/0.3.3
  vim debian/control        # and change Vcs-Bzr to Vcs-Git
  dch "Move packaging to git"
  debcommit -a
  
  
  git checkout debian-lenny
  git merge upstream/0.3.1
  vim debian/control        # and change Vcs-Bzr to Vcs-Git
  dch "Move packaging to git"
  debcommit -a
  

• Rescue Debian patches and put them on a debian-patches branch, which is rebased with each upstream release. For pymsn, there aren't any patches in the debian branch at the moment:

  git branch debian-patches upstream/0.3.3
  

  but there is one in the debian-lenny branch:

  git branch debian-lenny-patches upstream/0.3.1
  git checkout debian-lenny
  cp debian/patches/00-fix-dns-resolution.diff ..
  git checkout debian-lenny-patches
  patch -p1 < ../00-fix-dns-resolution.diff
  git commit -a
  

• Make a repository on alioth:

  cd /git/pkg-telepathy
  GIT_DIR=pymsn.git git init --bare --shared
  GIT_DIR=pymsn.git git config hooks.mailinglist ...
  vim pymsn.git/description
  

• Push to the repository:

  git gc --aggressive
  git remote add origin git+ssh://git.debian.org/git/pkg-telepathy/pymsn.git
  git push --all
  

• On alioth, do some more setup after the initial push:

  cat > pymsn.git/hooks/post-receive <<EOF
  #!/bin/sh
  exec /usr/local/bin/git-commit-notice
  EOF
  chmod +x pymsn.git/hooks/post-receive
  GIT_DIR=pymsn.git git symbolic-ref HEAD refs/heads/debian
  

• Mark the old repositories as no longer used:

  cd ../pymsn-unstable
  dch $'This repository is no longer used, instead please use git:\n'\
  "git://git.debian.org/git/pkg-telepathy/pymsn.git" -c changelog
  debcommit -c changelog
  bzr push
  cd ../pymsn-experimental
  dch $'This repository is no longer used, instead please use git:\n'\
  "git://git.debian.org/git/pkg-telepathy/pymsn.git" -c changelog
  debcommit -c changelog
  bzr push
  cd ../pymsn
  

Romain and Zack have a couple graphs of Vcs-* fields that show that Git usage is growing, but that Subversion’s is still way higher.

Here’s another take on the matter:

• as of today, there are 3348 packages with Vcs-Svn in unstable, and 1145 with Vcs-Git.

• if we group those packages by maintainer and we keep the top 20 for each VCS, 6 of them are teams for Git, versus 16 for Subversion.

• if we count Vcs-* fields without looking at packages maintained by teams, there are 935 packages with Vcs-Svn, and 724 with Vcs-Git.

Conclusion: s/A better CVS/Your lowest common VCS of choice/. (It’ll be interesting to see what KDE and GNOME do about this.)

Sami Haahtinen wrote a nice post about usability. I do mostly agree with him, except for one little thing:

A few years back, I noticed that I often started as a kind of “Joe User” with new applications, and often even stayed that way, often wishing that the UI of that application was simpler or at least made it more obvious which options are important and which I could most likely keep at their defaults.
Yet I am a system administrator and programmer/developer, so most people would probably consider me as an advanced user by default (wether that is correct in any given context or not, for example I still don’t really grok GIMP).
Also I did have quite a lot of contact with users that have very little experience, knowledge and interest in computers and software and only use them to achive certain goals.

Anyway, I’m quite sure most readers of this blog are aware that Linus Torvalds once complained about the Gnome printing dialog being simplified way too much. And at that time, I had to agree (note that I didn’t check out Gnome again since those days, at least 2 years ago).

What I really wonder (especially since I realized this in some of my own applications) is why it is so hard for developers to add some additional checkbox or button that enables/disables advanced options. For example, let’s take an applications printing dialog. By default, it would only allow the selection of a printer, orientation (if sensible) and (if the selected printer supports more than one) the paper size. Now advanced options might include duplex printing (automatic or manual), printing mutliple pages on a single sheet of paper, printing in grey on color printers,…

These options might be of use to anyone, but would most likely confuse beginners. So what I did in most of my little application was to just show the basic options and add an “advanced options” button which provided access to additional functionality which was not normally needed.

As for the issue with firefox updates mentioned by Sami: I don’t think it is a problem that firefox asks what to do with extensions. For one, it only lists extensions which are installed but claim not to support the new version of firefox. Second, practically everyone I know of who uses any extension can be considered to be an advanced user. And third: The dialog is pretty straightforward about what it is asking and when I once hit it while a (”dumb user”) friend was sitting with me, he understood what it was about quite easily (I didn’t explain the dialog, just what extensions were).

So my idea of a good UI is:
As simple as possible for beginning users, but allow advanced users to get to the details (”Details” or “Advanced options” buttons/checkboxes/dialogs).

Wouter, I find your thinking on DebGem a bit overreacted. I think you are taking the product and commercial efforts that a company make as the proposed solution we’ve all been expecting for a similar problem, which is not. You are considering DebGem to be an outcome provided by the Ruby community, which is not, to this issue.

Phusion is obviously not the Ruby community, but part of it. How I see it, it’s great: I applaud that more companies take a look at nice technologies and try to provide their own products. Since I do most of my work with both technologies (and others), Debian and Ruby, I find DebGem worth giving it a try, and if it solves the installation problems of some gems on different systems for me, my employer and the systems I maintain, why not pay for it. However that’s all you can expect it to do, solve your gem installation problems and that’s it, they are not proposing to change how gems are done or how Ruby libraries are implemented as packages in Debian, they are just a bridge, a shortcut, nothing else, nothing more. And if that bridge works and is well built and maintained, hurrah!

I feel I should comment on the whole DebGem thing.

About a week ago, the guys from that project mailed me, stating that they were about to go public, and if I would please have a look at it before they would do so and perhaps give some constructive criticism.

So I did. I must say I wasn't very impressed, initially. What you get there is what the name suggests: a Ruby Gem, but then just repackaged as a Debian package. As in, files laid out exactly the same way. As in, still not FHS compliant. As in, many other problems.

I came up with a list of problems that was quite long, and they've fixed most of them; but the fundamental problem—that RubyGems are peculiar beasts, making it hard, if not impossible, for Debian people to package them so that they adhere to Debian's strict quality requirements—remains, and this service does not (or cannot) solve that.

To be sure, it's a step in the right direction, which will ease the maintenance of Ruby software on many a Debian system, and for that they deserve praise. However, it is not a solution; much more work needs to be done—and it needs to be done within the Ruby community.