• Plugged the camera through USB, restarted it
• Checked that it was detected with gphoto2 --auto-detect
• Checked the capabilities with gphoto2 -a
• Looked at the config options with gphoto2 --list-options
• Found the /main/status/shuttercounter option
• Ran gphoto2 --get-config=/main/status/shuttercounter
• And here it is : 27781 shutter actuations

That number seems quite reliable, since I can have about 15000 of those pictures on my hard drive disks and I used to drop about 2 pics on 3 in my early days (I’m a lot softer on the shutter now, after experiencing the joys of picture sorting ).

Good to know I’m still far from the 100.000 actuations expected shutter life for 450D’s.

Well, thanks gphoto2 for your simplicity !

You can find the source in BloGit git repo, and see an example at BloGit example. To use the source, you first have to pack it (using the pack script), which will merge the raw_post and raw_produce, producing a single post script (which I also included at the end of this post), which you can simply put in an empty directory and run it. It will unpack the other script (produce), initialize the git repo, and set the hooks. It’ll then prompt you for your post title and then open an editor for you to set your post contents. Save the file, and you’re done with your first post : check the index.html file which has been produced in the same directory. You can write your own stylesheet in the blogit-style.css file. Further posts can be done with the same post script.

Yet, the best way is probably just to use the usual git workflow. To initialize the repo and all, run post --unpack, and to post post --raw or git commit --allow-empty (when using git commit, leave a blank line between the subject line and the rest of the post). You can also amend existing commits (using git commit --amend), use the GIT_AUTHOR_* environment variables to change the author, and so on. Since merge commits are skipped by the html generator, it should work just great for multi author blogging !

PS : I know this is JUST a git log pretty printer, and that the whole thing is pretty much trivial. I also know that using versionned files to store the posts would allow a lot of extra bonuses (such as automatically adding “Updated on …” mentions based on the commit log of each single file). I just thought the idea was fun There are probably a lot of things to improve, or a lot of smart git features to use there that I overlooked. Feel free to leave a line

#!/usr/bin/env python
"""
 bloggit
 Author : Guillaume "iXce" Seguin
 Email  : guillaume@segu.in (or guillaume.seguin@ens.fr)
 Copyright (C) 2010 Guillaume Seguin
 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 2
 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.
 You should have received a copy of the GNU General Public License
 along with this program; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor,
 Boston, MA  02110-1301, USA.
"""
import subprocess, os, sys
import base64, bz2
CONTENTS_FILE = "POST_CONTENTS"
repo = os.path.dirname (os.path.abspath (__file__))
os.chdir (repo)
if not os.path.exists (os.path.join (repo, ".git")):
    subprocess.call (["git", "init"])
produce_path = os.path.join (repo, "produce")
produce_script = bz2.decompress (base64.b64decode ("""
QlpoOTFBWSZTWQf3J2wAAV//gFxQAYB6b/p/f+fe7r///+pQBd42u22yaV13O6AGigNBIy
aIp7Sn6DJiSaeSeo00PykD1M1B+inpA03qQDU0AJk0mhqNPRGgAGjQaAGgADTQDQEajUYp
im2RT9U9RkGTQZAZG1DIAAAcaMmRhGIBhNBgE0GgZMmjJkMIDCRQTQmCaJtI1GjT1GmhqA
0yPUNDQbUNDQepWIWGfa4d31kD+Y5Rb4yaILtfQ2R3ruai19rArmVtHwltw/M/SKgVz+HG
mewWVLlaRGi+TgiYISYkD6/fECu/rM0N4r5GtcYW1QTuePdDZ+sPg4zb9+44SCBIOFkkg0
x55udVuK1GAeJhbulbdkEl+jz2G9vfcAh34ns8FhgJwKe1v5KFIdM2Eyyw0GMr3CL7ZNzK
RBUsFKRqwtgoNy9FHvVS66uV+heJbKHRXDHFf4J1zs3cj8oXsMfU5N+644WGdjzvLX1aap
AI6VwBnkLDzalqgjQuC2soFnZlK5GCZb80ra1gw5fh4rnD8GUmm6eUSa5mYoiFgrwmamRK
zCz9yuRcozq5UKJtbq3sBSN1gjHDQ9z2BK7Dw2KcWMHm491MdO2B62ZoUOzKwCqoREREHo
ZjLn2p0HiWYoMBQRP8YCAzIgZUc2PJZaZrY/lODrob1VQg4U9L1ZRXpNBCelwBoEqUbFCs
BJpOCKGs54vnVO1AQDU6v9X0lEnEHuE1nlsy5pNWawCEYImSZc/AdREPAKBrlp73jcCryL
OAdFJcMZqdVjjE5gIfQY4Qjju9UdOBBmuXjz6uZhpsc3LhrDg1BQGoL4GyiDRmpTkImmc9
YlDd26K11qaiVDQ4wwITIEMyxMiLi274jeFlLrj8BpnXU87qMq6z2VQs6RN74sifuXfw7d
bOOm9bexNvdsxPvZDgG0cmUYClTHvcCFAMAdL+/IndGLRmvh7w/Bni8LAUfWdAcRyR4NDu
d49goYEMqHwDJLLa4vSbQRLptFdWVLzfSggKVzGtJIX1laSjr8I2BUTyiovpeiiyNQZu5Y
xresZCItgNp6ArbjFsCdRdgrgsw9tcrCa1Djq7A7ItXvGBWWs9IP0iIEAqnJ8xcH6Do9+1
UNVwkrSI5yC/J0ACce0NqBmWdEXp0KBIBWawoxJI66zSW55iEHoFRC0m8pYQICMFCcrrbT
Lg5yvtsbQNwVvMipGYYYTGs+czVBOZBcoWGD+l1xRtlbVMDwM0OpEVa3YMa1Ax/SosYOB4
WQVhQejJLSsL7hmrQh6V/tgUDTQ1C5tNdUOZckY4G+CyuDeTOgkEyPE+YjKpYtTRnMzumS
KImpjWQIAaLK2djnoVkRq5F+Sglu77bey0552SggnVQj0jKnFwwvhT3Y6oFpO4b8hmb1t7
A3yKE74eX6aqvJ7fP5wjXYonDYwumjqnrlv3obv7WsTxFpxVYpHCErmRUKGvwPUiSRWYMn
FZIzt0eUPDxJrGAamFrkeX3WwB0CmC/Jls/DLFV7uiPSiVaMNxy1GXfqziuzlXVsk2mQw2
AeNj5+QtDUFuUCZKDGMagNGpxIx/46nKSJsbprNPXGqzJVxVcglKGV5VysJDCqgRinuNbX
ChqDzZ6JXB8Rz0VF8aK+NMxXupulQOr1U6XP19can5uVqG7fs6Sa3Kq51jGOK9jDQ6fZf4
zXLr884Wq67SW+YyPk5OB1G0WmA1s8OiKQRBccciEMujm6A2LMvcIDogVk2GRbzgYrapcB
VDXEsgM9FJCQrvwaVw3C6i0FlYbnwXoJqe3bYlAjrGTVnqOSOpUOWcFXUdVlKmeOahYuhi
mEIgcCiiFMPnz5r1hXukd6HApZVuGq1kxn8DgWUiEMcRm+5FDm1Y7cFNuOVzIkcaRHdWGj
vESnObg+IQwh5zNAYUb6CROYdEATsATAW/EnFc9IJTEQfCce8EymZ4uNSNoi3DgvNBNkxt
jAmszFZUqNLNxxkjqWcA+gkju1U2gyzjAujsieBpM9X37TNq17LCRv6ToL1MIOJeWVwUiB
6MrbOTHwIixlYyW5xO7y/+LuSKcKEgD+5O2A==
""".strip ().replace ("\n", "")))
if not os.path.exists (produce_path):
    open (produce_path, "w").write (produce_script)
    os.chmod (produce_path, 0755)
for hook in ("post-receive", "post-commit"):
    hook_path = os.path.join (repo, ".git", "hooks", hook)
    if not os.path.exists (hook_path) \
     or os.path.realpath (hook_path) != produce_path:
        if os.path.lexists (hook_path): os.remove (hook_path)
        os.symlink (produce_path, hook_path)
if "--unpack" in sys.argv:
    print "Unpack only"
    raise SystemExit
if "--raw" in sys.argv:
    p = subprocess.Popen (["git", "commit", "--allow-empty"])
    p.communicate ()
else:
    title = raw_input ("Post title ? ")
    editor = "vi"
    if "VISUAL" in os.environ:
        editor = os.environ["VISUAL"]
    elif "EDITOR" in os.environ:
        editor = os.environ["EDITOR"]
    contents_path = os.path.join (repo, CONTENTS_FILE)
    if os.path.exists (contents_path):
        os.remove (contents_path)
    ret = subprocess.call ([editor, contents_path])
    if ret == 0 and os.path.exists (contents_path):
        contents = open (contents_path).read ()
        os.remove (contents_path)
    else:
        print "A problem occured while editing the contents file"
        raise SystemExit
    p = subprocess.Popen (["git", "commit", "--allow-empty", "-F", "-"],
                          stdin = subprocess.PIPE)
    p.communicate ("%s\n\n%s" % (title, contents))
if p.returncode == 0: print "New post successfully added"
else:
    print "Couldn't add new post"
    sys.exit (1)

After spending quite a bunch of time trying to tell X to just ignore, I took the easy way and… switched to Ubuntu. But yesterday, I asked drago01 (maintainer of Compiz packages in Fedora) about the issue, and he immediately recognised the problem, calling it the “Ghost TV problem”. According to him and Adam Jackson (ajax), this is a screw up from hardware vendors. The graphics chipset thinks there is that TV plugged while there is definitely none.

Anyway, he also pointed me to the fix. 4 lines in xorg.conf and you’re done (this is actually my whole xorg.conf )

Section "Monitor"
Identifier "TV1"
Option "Ignore" "1"
EndSection

For instance, take this metacity commit : Change default cycle_group keybinding to Alt-grave. This change looks perfectly harmless, right ? Well not quite. It’s most likely based on the assumption that the end users has a qwerty keyboard layout (and it makes perfectly sense there). But let’s take an azerty layout. Grave is on the é/7 key, which is even farther from alt or tab than F6 is (well, not much I agree, but it might be even worse on other layouts). Is it really worth doing such a change then ?

Let’s also note that this also triggers a bad bug which gets alt+7 and alt+shift+7 to trigger the binding as well, while alt+grave is actually alt+altgr+7. This has been keeping me from nicely switching to my window n°7 in irssi for months (great thing that this window holds a really low traffic channel…).

All in all, I guess that the real problem is not that this change was made, but rather than we might need a system to have layout-dependant keybindings, or maybe hardware-location-based keybindings (i.e. that the key above the Tab key would trigger this keybinding independently of the layout).

Initially published on Mar 24, 2010 @ 8:22

Update : this change has been reverted for the GNOME 2.30 release. Even though I’m happy that the problem is “fixed”, it’s sad that the underlying problem (Alt+Shift+7 triggering Alt+`) is still there.

Since the project code was written in Python, all the inheritance relations were already held by the code and could be introspected, so that it was theoretically possible to automatically produce the inheritance diagram. And it actually is, and is implemented by things like the Epydoc (a documentation generator for Python code) parser, as well as the diagram generation, which Epydoc also implements. The only thing is that I wasn’t satisfied by the Epydoc diagrams since they were limited to the inheritance relationships, while I was also willing to include usage relationships and display only the main methods and variables of my objects.

I thus wrote Umlpy, a UML-like class diagram generator for Python code, which depends on Epydoc (for the parser) and python-graphviz (for the graph generation, it produces nicely spaced graphs and can output jpg, png or pdf files, and probably more). It handles the aforementioned requirements through docstrings parsing and introspection. Check the Umlpy README file for more documentation on how to use it. It took me about 10 minutes to get to the result I was expecting (it’s basically about adding a little docstring for usage relationship, and copy-pasting a docstring on methods or variables you want to see on the diagram.

This wouldn’t be complete without the mandatory screenshot, and this example code results into this diagram :

I then discovered libghoto2, which is the library behind the Linux support of this feature. After a little bit of googling, I stumbled upon the gphoto2 website, where they mentionned that it was possible to command shooting from the computer and directly get the resulting image on the computer. Immediately tried and… it works great ! (though I haven’t figured yet how to get the picture on the sdcard instead of directly on the computer).

Not sure what I’m going to do with this, but I’m confident there is a bunch of hacking possibilities here. Maybe should I write a simple GUI on top of it someday to begin with. Or I could try building a motorized base and remote control the whole thing from my n900 (and attempt to do things like Paris 26 Gigapixels). Hmmmmm…

Wondering how it looks? Here is the output of a little test:

ixce@timmy:~$ sudo shutdown -r
W: molly-guard: SSH session detected!
Please type in hostname of the machine to shutdown:
Good thing I asked; I won't shutdown timmy ...

Since it doesn’t correctly handle sudo yet (actually sudo is at fault here, since it drops SSH_CONNECTION environment variable when doing its stuff), you might want to add PRETEND_SSH around the beginning of /usr/sbin/shutdown as specified on Nico “nion” Golde’s blog.

You might also want to grab the molly-guard 0.3.2 etch package I backported from sid (all I changed is downgrade debhelper build-dep version and debhelper compatibility level in debian/compat since etch only has debhelper 5 and the sid package required debhelper 6 ; this shouldn’t break anything since the newer debhelper just seems to be needed to recognize a few fields in debian/control about where the package is maintained). Sources are also available, anyway.

Thanks hr for the tip

Sorry, I look completely tired and I’ve got too much hair these days

Oh, just a little tip, to avoid “Unsafe disk removal”, just add the drive to /etc/fstab (you can reference it by label) and make it readonly and mountable by user.
LABEL=MY-KEY /media/auth vfat ro,defaults,user,noauto 0 0If you want to rename *your key, just head to the RenameUSBDrive article in Ubuntu Documentation

Here are 0.4.2 debs for hardy (which currently only has 0.4.0):

• libpamusb 0.4.2 deb for hardy
• pamusb-tools deb for hardy

And a few handy links:

• Neat howto for debian based distros
• pamusb homepage
• Andrea Luzzardi’s blog (pamusb author)