PEAR and Debian/Ubuntu

There seems to be something inherently wrong with how PEAR is packaged in Debian/Ubuntu (hence referred to as Debian, since Ubuntu doesn't modify the php5 source package with regards to PEAR). A bit of background: I'm currently trying to update the PHPUnit package to the current version (the Debian version seems to be stuck at 3.2.x — 3.3.9 was released the day this was written). I'm (re-)running dh-make-php to accomplish this, mostly because there doesn't appear to be a very obvious way of upgrading PEAR packaging for Debian (given package.xml, etc.). The problem is that PEAR is bundled with PHP on Debian, courtesy of the php-pear package. The one on Ubuntu's Hardy Heron is stuck at 1.6.1, whereas the current version (again, as of the day this was written) is 1.7.2. I can't use dh-make-pear to package the latest PHPUnit because the package.xml file requires PEAR 1.7.1 to parse it.

Now, Ubuntu's community documentation for PEAR recommends upgrading PEAR via the pear command. That seems counterproductive to me. Given that pear, by default, installs to the same location as the package, I presume that PEAR and any other "pre-installed" package that was pear-upgraded would be reverted, in particular if there's a security release. This makes the sysadmin's job harder, obviously. I can't seem to find any rationale for this packaging behavior (admittedly, I didn't look very hard). But other distros get it right - Gentoo definitely packages the non-bundled PEAR versions, and from a cursory search, it appears that Fedora does as well.

So, what's my solution (for now)? Backport the latest stable PEAR into the php5 source package.

HOWTO Run an OpenID-authenticated WSGI Application (with AuthKit)

According to Blogger, this is going to be post #100. I have no idea if that counts the various dead drafts in my queue or not.

Anyway, if you've been following my Twitter stream, you'll know that I've been playing with Pylons, and by extension, WSGI. One of the things that I'm interested in is OpenID-only authentication, mostly because I hate having to create new account names/passwords everywhere, and I'm too lazy/paranoid to use one of those password management extensions. After several attempts, here is a short Python script which runs a sample web app that requires OpenID authentication for the /private path (via the AuthKit middleware). The OpenID URL that was used to sign in is stored in the environ['REMOTE_USER'] variable. It was tested with AuthKit 0.4.2, Beaker 1.0.3, and Paste 1.7.2.

#!/usr/bin/env python
#
# Copyright (C) 2008  Mark Lee
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# For a copy of the GNU General Public License, see
# <http://www.gnu.org/licenses/>.

import os
from beaker.middleware import SessionMiddleware
from paste.auth.auth_tkt import AuthTKTMiddleware
from authkit.authenticate import middleware, sample_app
from paste.httpserver import serve

app = middleware(sample_app,
                 enable=True,
                 setup_method='openid',
                 openid_store_type='file',
                 openid_store_config=os.getcwd(),
                 openid_path_signedin='/private')

app = AuthTKTMiddleware(SessionMiddleware(app),
                        'some auth ticket secret');
serve(app) # opens a socket at localhost:8080

On Feeds and Backwards Compatibility

Zach Hale notes:

Should I choose RSS or Atom?

Who cares? I don’t. I bet if I asked everyone I had contact info for, only a few would prefer one or the other (though hopefully one in particular).

I've got a preference — Atom. This is mostly because of the fact that's it's one de jure standard, as opposed to the at least five de facto RSS standards.

More to the point, I agree with the underlying argument:

And that being so, it makes no sense to put both standards (if not different versions of each) in the auto-discovery tags, especially for big sites like Flickr and consumer blogging software like WordPress. [...] For the rest of us, our feed readers could care less. So please stop confusing us.

Sadly, I also know the history behind this. Back in the "bad old days", feed readers did not follow the robustness principle. So, websites had to deploy a sort of "inverse robustness principle", to make sure that as many feed consumers as possible could read the content. The good news is that today, any decent feed reader can read most feed formats. The bad news is that no one (or not enough people) have bugged the feed producers (e.g., Flickr) into fixing it. The solution? File a bug and remind them of Postel's law. Of course, only file said bug if no one else has already done so — we don't need to annoy the developers.

On Version Control "best practices"

Source code management, or version/revision control, is one of the most useful tools that a developer has, especially if this person works with others on a shared code base. However, I've recently realized that some people don't understand what a good "commit"^[1] entails. (I'm not naming them, or whether they come from my professional or hobby "spheres of influence".) It doesn't matter whether you're using Subversion, Bazaar, or even CVS. There are a few principles that you should consider when you make a "public" commit (as opposed to a "local" commit, which is supported by distributed version control systems):

• Limit your commit to one discrete idea. This can be fixing a bug or adding a new feature. Obviously, there is an exception when you happen to fix a bug by creating a new feature, but these instances tend to be rare. The big reason for this principle is that developers are (generally speaking) not infallible. If it turns out that the commit introduced bugs and/or regressions, it is easier to revert an entire revision (through whatever means your SCM provides), than to comb through the differences between the revisions in question for the "tainted" code.
• Good commit messages are key. Due to the way that most source code repository viewers work, it is considered good practice to summarize the commit in the first line, and then give a more detailed explanation in subsequent lines. This is actually similar to how writing is taught (at least in the US): provide a topic sentence in which you summarize what you're going to write about, and then write your content. In this case, though, you don't need a summary/closing statement at the end.
• If your project management and/or your SCM software supports it, annotate your commit as much as possible. I'll give two examples as to what I mean:
  1. Bazaar lets you annotate your commit with a couple of metadata flags when you invoke bzr commit: --fixes=[BUG] and --author=[AUTHOR]. The flag --fixes lets you annotate which bug this revision is supposed to fix, and --author lets you specify the author of the code, e.g., if you are just committing a patch for someone else who doesn't have the proper permissions to do it themselves.
  2. There is a post-commit hook for Subversion, distributed with the Trac project management system, that allows tickets to be changed based on the existence of certain key phrases in a commit message. For example, the message Add foo. Addresses #12345 adds a comment to ticket 12345 with that commit message and a link to the revision, whereas the message Add bar (fixes #12345). performs the same task as the "addresses" phrase, plus it sets the ticket status to "closed". In my opinion, putting the "fixes" or "addresses" phrases at the end of the first line is preferable to putting them in the detailed explanation.

Hopefully, this is helpful to those who are new to using version control systems, and those people who are the "gatekeepers" of the repositories. Comments and criticisms are welcome.

¹: The difference between a "commit" and a "revision", in my view, is that a revision is a patch that has been committed to a repository, whereas a commit is the process.

Awn PSA

This is in response to something that I read on an Ubuntu Brainstorm page.

Attention people who think that you need an expensive video card in order to run Avant Window Navigator, AKA Awn: I have a computer that I maintain with a Diamond Monster Fusion video card (tdfx Xorg driver) that runs Metacity + Awn 0.3.1 (on Ubuntu Hardy) just fine, with applets, on an everyday basis.

This has been a public service announcement by your somewhat friendly Awn/Awn Extras developer. You may now continue to go about your Interneting.

Donate to LGM! (and other conference-related items)

For the 1% of Open Source software enthusiasts who haven't yet seen this yet: Donate to support the development of free/libre/open source graphics software by helping developers meet in real time, in person, (etc.) at the Libre Graphics Meeting 2008! I'm a big fan of Inkscape, because it lets me, as someone who is not very artistic (nor has very good (precise) hand-eye coordination) to create and manipulate logos and icons with ease. My graphics programming skills are essentially non-existent, so I figured that I could be more useful by donating some cash to help a developer of one of the participating projects travel to the meeting.

And here's the shiny (but not flash-shiny) information-rich button that they're using to show how much more money they need to reach their goal: (I should note for the American-income-tax-minded that this is a tax-deductable donation.)

On a somewhat related note, I'm planning on going to LinuxFest Northwest 2008. Fortunately for me, both the conference and the transportation is free. People who have either followed me for at least a year or have read through the archives know that I went last year. I plan on going on Saturday again (this year, April 26), and I'm bringing my XO laptop with me. If things work out right (i.e., my stupid printer decides to work), I'll have a nice, big Awn icon (again, thank you Inkscape!) taped to my bag. It'll be an interesting experiment to see who recognizes it.

Awn News & Commentary (ANC), 2008/03/21

Obviously, I haven't done one of these in a while. There are a few reasons for this. For one, my workload has gotten a bit larger. Additionally, Super Smash Bros. Brawl came out recently...it's ridiculous how much time that game eats up, and I'm only halfway through "adventure mode".

But seriously...both the forums and the bug tracker have been relatively quiet. It's difficult to figure out exactly why that is. However, there have been a few things that have happened in the past month or so.

Moonbeam has a summary of what happened in the week following my last post. Additionally, he has been working on the framework for an applet that can use either the Gecko engine (used, most notably, in Firefox) or the WebKit engine (used in Safari) to render HTML. Hopefully, this will alleviate some of the problems that people have had trying to get some of the HTML-based applets to run properly. Unfortunately for us, moonbeam has become rather busy in real life lately, and so there may or may not be very much progress on the features/applets that he's been working on.

Andrewsomething, a longtime bug/answer triager for both Awn and Awn Extras, has finally taken the plunge (so to speak) and joined the Awn Extras developer team. His first contribution is the "Remember the Milk" applet, and for his next undertaking, he is seeing if there's any interest in a simple note applet.

It is interesting to note that two new, experimental branches have appeared for Awn recently. One, created by moonbeam, focuses on refactoring the launcher/task/applet effects framework so that it's easier to add new effects, and uses cairo's surfaces instead of Gtk+'s "pixel buffers" to manipulate the images. This allows for more complex effects to be used, while keeping the overall effect smooth (and potentially hardware-accelerated).

The other branch was created by longtime Awn contributor haytjes. He's working on fixing the "custom icon" feature. Currently, there are several bugs which prevent that feature from being very usable.

And finally, I'd like to give a quick Planet Awn roundup. Moonbeam has a very good post on the architecture of Awn and why it's not possible (currently) to have features such as parabolic zoom. Our fearless leader, Neil, has (finally) written a post about the recent Awn/Awn Extras release, and our upcoming plans for the projects. Hopefully, his presence on Planet Gnome will continue to give Awn more publicity :).

Awn News & Commentary (ANC), 2008/02/15

I'm taking a break from both trying to make a <tbody/> scroll vertically without a horizontal scrollbar present and playing "Link's Crossbow Training" to write up what's transpired in the past several days in Awn-land.

The Awn Curves branch was partially merged into awn-core-testing. I say "partially merged" because meek is merging it in parts, due to the complexity.

The big event was when Neil finished reviewing the awn-core-testing and awn-extras-testing branches and merged them into their respective trunks. Among the benefits is that users of reacocard's Ubuntu Gutsy repository can now use the shiny new features that those of us on the (very) bleeding edge have been using for a while now.

I should also point out that Neil has added both moonbeam and myself to awn-core, in recognition of our work on both the testing branches and our respective personal branches. This means we have commit access to Awn's trunk branch and more bug/blueprint triaging privileges.

As a result of the big merge, we now have a new roadmap. What used to be Neil's big rewrite for 0.3 (code-named fandabbydosy) has been spread out over several releases. See the roadmap link for details. One important item to mention is that we plan to release version 0.2.4 of both Awn and Awn Extras on Monday (02/18).

In Awn Extras, most of the changes have been bugfixes. A patch was added to the media-control applet for Quod Libet support.

Finally, I'm holding a contest for Awn users/enthusiasts. In the near future, I'd like to have a post with screenshots and videos showing off all of the new features and applets in Awn/Awn Extras. Unfortunately, I suck at doing that sort of thing myself. :) So, I'm giving the Awn community the chance to show off their customized docks.

The only restriction on the screenshots and videos is that you license them under a Creative Commons license. I will, of course, attribute all media to their proper creators :) Ideally, the screenshots should be as hi-res as possible, but any resolution is welcome. The same goes for videos.

The deadline is Feb. 21, because I'd like to write the post by the end of next week. I'll choose a set of media that looks the nicest (with the help of the people in #awn) and use that as the basis of my next Awn post.

So if you wish to participate, please post the URL to the media, the attribution information you wish to use (your name or nick), and which feature/applet you're highlighting on the forum thread or as a comment here.

Avant Window Navigator News and Commentary, 2008/02/09

Given the lack of releases of Awn, I figure that there needs to be some record of what's happening in Awn-land ever since we got version 0.2.1 of Awn and awn-extras out the door, other than the mish-mash of posts on the forums.

Awn

Here's a (most likely incomplete) list of the new features in awn-core-testing, mostly taken from the branch whiteboards:

• A simple mouse wheel task scrolling implementation
• Sort applets in alphabetical order in awn-manager
• Xfce support (build flag: --with-desktop=xfce4)
• desktop-environment-agnostic support (build flag: --with-desktop=agnostic): this requires GLib 2.15.x and above, because it uses the new GIO library to replace the GnomeVFS code.
• GKeyFile configuration backend support (build flag: --without-gconf): this adds a compile-time option to build a .ini-style configuration backend, instead of GConf.
• Freedesktop.org Desktop Entry wrapper API: Desktop entry files are used all over the place in both Awn and awn-extras, so I wrote an API that wraps both the GnomeDesktopItem and EggDesktopFile APIs, depending on your desktop preference. Note that the Xfce backend also uses EggDesktopFile, because I found out that libxfce4util's desktop entry implementation was read-only, and read-write-support was needed.
• File/directory monitoring wrapper API: The Gnome implementation uses GnomeVFS, the Xfce implementation uses ThunarVFS, and the agnostic implementation uses GIO.
• Python bindings for all of the new APIs
• Vala bindings (auto-detected at build time)
• remove the gnome-panel dependency by writing a launcher/desktop entry editor in Python (including custom/stock icon chooser)
• changed awn-manager applet interface

Note that everything except the first two items are also in my desktop-agnostic branch.

awn-extras

Since the 0.2.1 release, a number of new applets and other changes have occurred in the awn-extras tree.

New applets

• Affinity (yes, that Affinity)
• Arss (Applet to view feeds)
• Awn Terminal
• Cairo Menu
• Clock/Calendar
• Comic
• Digg
• Digital Clock
• File Browser Launcher
• Last.FM
• MiMenu
• Mount
• Pandora
• Places
• PyClock
• Shiny Switcher
• Standalone Launcher, Taskmand, Taskmand-applet: an alternative to the built-in launchers and task manager.
• Terminal Services

Other changes

• Rewritten build system
• Shared libraries for applets to use: libawn-extras (with python bindings) and AWNLib (for Python only)
• The GMail applet has been renamed to the Mail applet and has been completely rewritten. As a consequence, it no longer uses libgmail.
• Stacks: experimental GUI
• BlingSwitcher: Due to the lack of both a maintainer and a license, this applet will most likely be removed from the tree. However, an archived copy will be linked on the forum and the wiki.

Distribution support

Our resident Debian/Ubuntu packager, gilir, successfully got Awn (the dock) into the official Hardy repositories, specifically universe/gnome, as avant-window-navigator. Unfortunately, there are some QA problems with the awn-extras applets package, awn-core-applets, but gilir is working very hard to get that resolved before the package freeze. He is also working on getting said packages into Debian sid.

Meanwhile, in Gentoo-land, there are official ebuilds for both Awn and awn-extras, named gnome-extra/avant-window-navigator and gnome-extra/avant-window-navigator-extras, respectively. Since the xeffects overlay is defunct, I'm working with the team behind the desktop-effects overlay to get the awn-core-testing and awn-extras-testing branches in as working "live" ebuilds. Of course, this comes after I was alerted via an awn-extras bug that one of the desktop-effects developers described the build system as piss-poor. Being the author of the new build system, I was a bit offended. Luckily, the lead developer for that overlay was more level-headed than the stereotypical Gentoo developer whose comment started it all. I'm still waiting for an apology from said developer, but I'm not holding my breath.

Wiki

A community member has contributed a wiki for our project. We've been using it for both end-user documentation (Installation, FAQ) and internal processes. In particular, the applet developers have been collaborating on some applet development guidelines which should be followed if a person would like their applet to be included in the awn-extras tree.

Other

In non-Awn/Awn Extras news, there have been reports that the Gimmie project has added Awn applet support, in addition to its current support for the gnome-panel.

---

The changes I've listed for Awn and AWN Extras are currently being reviewed so that they'll be merged into trunk in the near future. In the meantime, you can grab the test packages from the Awn Testing Team's PPA (for Ubuntu users), install Awn and Awn Extras from the desktop-effects overlay (for Gentoo users), or simply install from source (making sure that you uninstall any previous version of Awn/Awn Extras first!).

The Result of Boredom

(@flickr. Created at O'Reilly Maker [Via Ajaxian]. Under a CC-BY-SA license.)

OpenWrt + dnsmasq

Note to self: the OpenWrt wiki, particularly the dnsmasq page, is a very useful resource for understanding why my XMPP server won't talk to the GMail or LiveJournal XMPP servers. (Hint: filterwin2k is a very bad configuration option for XMPP servers. Stupid default option.)

This'll be interesting...

I switched my DNS host from zoneedit.com to editdns.net, because ZoneEdit doesn't support DNS SRV records. They're needed for XMPP server-to-server federation support. My XMPP address is <${my_second_level_domain} at ${my_second_level_domain} dot com>. Note that this is different from my email address.

If I haven't seen it, It's new to me!

I learned something new today: it seems that <button>s have a type attribute, and default to type="submit". Obviously, this doesn't apply to IE, which defaults to type="button". Makes my life just a bit more annoying. On the other hand, I don't have to use <input type="[submit|reset]"/>, which apparently makes it a bit easier to style.