Geek on Two Wheels

I present to you, Exhibit A:  Bug #1339—lighttpd doesn’t set empty QUERY_STRING in cgi environment

Now, please direct your attention to Exhibit B: RFC 3875, section 4.1.7. Specifically, the below quoted paragraph:

   The server MUST set this variable; if the Script-URI does not include
   a query component, the QUERY_STRING MUST be defined as an empty
   string ("").

A potential  poit user recently encountered this problem.   While I would like to update the lighttpd bug entry alerting them to this crucial violation of specification, I’m also unwilling to sign up to yet another bug tracker just to fire off a single comment; avoiding such overhead is precisely the reason why I support OpenID.

Update: Mere minutes later, said user has pinged the bug.  Hopefully this leads to a resolution more correct than the first.

The longer it takes to fix a bug, the smaller the fix will be.

When I first read this little gem of wisdom on DadHacker, I literally laughed out loud.  It was the same month that we finally resolved the once-infamous fd.o bug #13405.

#13405 was filed against xf86-video-radeonhd towards the end of November, 2007.  xf86-video-ati has a counterpart as bug #19215, but filed almost a year later.   Despite a handful of very bright core developers and a few dedicated newbies (including yours truly) looking very closely at the problem, the fix was not to be committed until early May of 2009.

That’s over seventeen months.

To be fair, I don’t think there were any serious attempts at actually resolving the bug until I came along a year after its initial filing, eager to prove to the open source world that I have what it takes.  Even accounting for that, however, this was a process that took roughly five months.

In that time, a couple other commits fixing cursor corruption were made, but they turned out to be additional bugs that were only affecting certain hardware.  While both happened under equally peculiar circumstances, the original bug remained unresolved, despite multiple pairs of eyes and man hour investment in the double digits.

Finally, in the first week of May, 2009, the ever-awesome Alex Deucher made commit da58e351 to xf86-video-ati, which I promptly ported to radeonhd, finally closing a year-and-a-half old bug.

So, what was the problem that plagued us for so long?

-	RHDRegWrite(Cursor, Cursor->RegOffset + D1CUR_CONTROL, 0);
+	RHDRegWrite(Cursor, Cursor->RegOffset + D1CUR_CONTROL, 0x00000200);

One bit.

Laugh out loud, indeed.

Just released version 0.1 of poit.

There is documentation on how to set up the server itself, but not on how to set up an OpenID identity to use said server.  I plan to write a more complete HOWTO on the latter in the coming days.

I had originally planned to make the version 0.1 release of poit a couple weeks ago, but good weather has conspired to keep me away from the computer and on my bike. Good times were had.

Due to the need for recovery then injury, I have been home more than usual in the last few days, and have managed to put in some solid work on the project.  The UI is mostly finalized, consumer-specific quirks have been worked out, and, code wise, it is ready for 0.1.

Well, at least according to my original plan.

One thing that is still lacking is per-consumer configuration, which means poit currently authenticates to any and all consumers if there is still a valid session when asked to operate in immediate mode.  Although not particularly dangerous, this is not going to stay the default, and it feels irresponsible to leave it as such until 0.2.

So, a little more waiting until I get this sorted out.

In the meantime, if you’re OK with the above mentioned policy, grab the source from git and give it a go.

Announcing poit, a simple, single-user OpenID authentication server implementation.

This is a reworking of a even simpler server I hacked together for personal use last year.  The UI is currently very bare, and there is no documentation, but it does work, and the code is no longer terrible to work with.

It’s been tested to work on a handful of OpenID consumer sites, with only two known failures so far: Facebook and Stack Overflow.

Unsurprisingly, Facebook’s consumer implementation seems to be broken, and I won’t bother following up on that any time soon.  The failure against Stack Overflow is both unfortunate and ironic as using it was a major motivation for starting the original project.

At the moment, the UI is very crude and it doesn’t protect against all plausible bad inputs, but it is functional, and I do use it for my own needs.  Time permitting, I’m hoping to be able to cross off all the features planned for the first release in two weeks.  Some additional testing would be much appreciated.

Critiques, suggestions, and patches welcome—notification of security issues, especially.

In any sane web development setup, at some point, content must be propagated from the development environment to the production one. scp and sftp are some of the favourites: git is mine.

By using the working directory of a git repository as your live website, you gain several notable advantages over manual uploading:

• The website itself doubles as your primary, authoritative repository.
• It becomes possible to apply all of git’s features on your production website. Things such as emergency roll-backs become trivial, dependencies permitting.
• No need to think about what actually needs to be uploaded and what doesn’t on an update: just git push.

Now, the last point needs some explanation. When blobs are pushed from one repository to another, by default, the working directory of the remote repository is untouched.  The reasons for this should be obvious, but, in this case, modifying the working directory is precisely the desired behaviour.  To have git update the working directory every time it receives an update, we use the post-update hook.  Here is a trivial example:

#!/bin/sh
# Update from repo
cd ..
unset GIT_DIR
exec git reset --hard

1. git runs its hooks from inside the .git directory. Not all git commands work from this location, so first we get out from it.
2. The GIT_DIR environment variable is set to “.” when executing hooks. This will cause issues as we are no longer in .git, and must be unset.
3. Finally, git reset --hard is ran to reset the working directory to match the current branch’s data in the repository.

Of course, there are tons more things you can do using the hook, as you have full shell scripting capabilities.  See git help hooks for information on all the available hooks.

As a departing note, remember to set the permission on the .git directory so that you are not leaking sensitive information.  Unless, of course, you want everybody and anybody to be able to checkout the complete revision history of your website.

Whether you’re just learning git or want to learn a new trick or two, git ready is a pretty good place to go.  The listing of articles by task goal instead of command explanation should be especially helpful to the newbies.

Hackers that know me personally may have noticed my praising of Git. Today, I came across an article talking about what the author calls the Tangled Working Copy Problem, and how git copes with it. The article is a good read, regardless of your source code management taste.

Aside from highlighting some useful features that are afforded by distributed VCSs, the article also exposes how weak Subversion can sometimes be, no matter how magnificent it may seem compared to CVS.

If you haven’t made the leap and embraced the distributed VCS model, I highly recommend at least trying it. Git, Mercurial, Bazaar, whatever: just pick one up, and do some development with it. You may never go back to subversion again.

Update on the Brother MFC-420CN situation:

The Perl CUPS wrapper is done, and seems to be working fairly well, at least for just simple printing using only the default options.

On the SANE side, things are less than ideal. Despite finally being able to cleanly compile the brother and brother2 back-ends against the latest sane-1.0.18 sources, there are problems with required functions not being properly defined, and hence unusable.

For those that care, the Brother binary SANE drivers don’t work because sane-1.0.17 did not have a workaround that allows multiple processes to access the same USB device simultaneously. This is required for multi-function printers, where the usblp will reserve device at boot time, causing SANE to always receive a BUSY status when querying for the scanner.

After upgrading gcc, my server once again began to crap up with libstdc++.so.6 not found errors.

Three recompiles, and much research later, it turns out that my ldconfig is busted. Some poking around later, I finally managed to create a proper ld.so.cache file on my laptop, solving the linking problem on the server.

ldconfig, however, is still busted:

sui ~ # ldconfig -vp
Killed

Fuck…