The mobile phone I travel with is pretty good and I use JabberMixClient to instant message from it. Version 2.1 finally got rid of the avatar-replacement bug, so I only wanted to solve my inability to make an SSL connection to our servers. (The linked email is slightly wrong: it’s signed by our own Certificate Authority, not self-signed.) The answer was to install TTLLP’s Certificate to the phone, as suggested on Sony Ericsson’s developer site. After a few unsuccessful atttempts, I corrected my two mistakes: firstly, I needed to install our CA certificate, not the server certificate; secondly, use PEM format, like on tjworld’s k800i. The exact command was obexftp -b $PHONE -p ca.pem and then the phone prompted me whether I wanted to install it. Now I can jabber from the phone without the phone company eavesdropping and without having to MidpSSH to a server. Can’t I?

I love collecting quotes but I file most of them away in some file on my computer or distribute them in class. I thought I might start sharing some of my favorite passages/quotes. This one, which I read 3 years ago, reminded me of the craft-like spirit in Debian and Free Software in general. I like how the author brings together the themes of labor, time, quality, mistakes, intimacy and tools all in one swoop.

I refuse to be in such a hurry that I squeeze the aesthetic value out of everything just to gain a few minutes of time time which will then just be filled with more rushing and more mass-produced, soulless junk. In the drive to achieve instant gratification, we have spent a century trying to shorten the learning curve and eliminate the chance of error in every human activity. There is much good in this, but something has been lost in the process. The Galoots are the guardians of that which was almost lost: the challenge of trying to master a skill that can never be fully mastered, the creative freedom that comes from intimacy with a medium as complex as wood, the sense of self-sufficiency that comes with knowing that you can make a useful object with tools so simple that you can make the tools too, and the peaceful mediation of trying to bring eye, hand, and wood together into harmony through finesse and understanding rather than brute force.

Quoted from Hohn (2005), The Romance with Rust, a Harper’s article on tool collectors. A Galoot is a person with a deep passion for old hand tools, their ways, workings, and their history.

John Goerzen recently wrote in his blog about the value of a broad, classical education. I wholeheartedly agree, and this gives me the opportunity to plug a gem of a company that makes a product you may not realize you're interested in (I didn't until I heard about it). I love to learn about random parts of the world and random bits of history and culture, even if I have no practical use for the knowledge. I do a lot of that by reading, but reading requires certain conditions and a level of attention, and I can never read as much as I want to. I also often want something more in-depth than a popularization can provide, but not as technical and focused as academic writings in the subject. A college course is just about right, but I don't really want to take courses. Apart from the possible expense (although I could audit classes for free) and hassle of having to be somewhere at a particular time, courses are often also based around more reading and around homework and grades, none of which I'm interested in. I get completely irrational about grades and push myself out of proportion to their significance, which meant I had an excellent GPA in college and I still have nightmares about missing tests. Enter The Teaching Company. What they do is find high-rated college professors, generally those who have won teaching awards, and have them record a course within their field of expertise but without the homework and grades. They then sell those courses on DVD, CD, or MP3 download (some visual-heavy courses are only available on DVD). Some of them are as long as a full college course and some of them are a bit shorter, but they're all meaty enough to really dig into a topic. A typical course is about 18 hours of material; some can be twice that length. And they're exceptional, better than just taking courses at a local college since they draw on the best teachers from all over the United States (I haven't seen any non-US teachers yet, although it wouldn't surprise me if there were some). I listen to these while I'm exercising, on long car trips, while I'm walking back and forth to work, even while I'm grocery shopping — basically, all the places you'd listen to a book on tape. I've listened to several twice, since I wasn't always paying attention the first time. So far, I've gone through a course on Greek mythology, a literature survey covering plays, poetry and novels, a course on modern economics, two history courses (Vikings and China), and I'm currently listening to a course on opera mostly because I knew I didn't know anything about it. The courses are a bit spendy (always buy them on sale — they have a weird pricing structure where courses go on sale on a rolling basis, and the non-sale price is ridiculously higher), but you can get a shorter one for around US$50 and from that get an idea of whether you're interested. (And while that's a lot to spend at once, it's actually a great deal for the length of material you get.) They have a very solid guarantee system, they'll replace lost or worn-out or broken CDs from CD sets for life, they have a reasonable on-line ordering system, and I've had nothing but positive experiences with them as a company. And as soon as you start buying courses, they tend to give you discounts and special deals and so forth. Highly recommended. It's filled a gap I've felt for a long time but never had the time to read enough to fill normally.

I played with an Eee for a bit last time I was in Boston, culminating in a patch to make the eeepc-laptop driver use standard interfaces rather than just having random files in /sys that people need to write custom scripts to use. The world became a better place.

However. Asus implemented the rfkill control on the Eee in a slightly odd way. Disabling the wifi actually causes the entire card to drop off the bus, similar to how Bluetooth is normally handled. The difference is that the Bluetooth dongles are almost exclusively USB, while the Eee's wifi is PCI. Linux supports hotplugging of PCI devices, but nothing seemed to work out of the box on the Eee. Another case of this was the SD reader in the Acer Aspire One. Unless a card was present in the slot during boot, it simply wouldn't appear on the PCI bus. It turned out that Acer have implemented things in such a way that removing the card results in the entire chip being unplugged. This was when I started looking more closely into how this functionality is implemented.

The two common cases of PCI hotplug are native PCIe hotplug and ACPI mediated hotplug. In the former case, the chipset generates an interrupt when a hotplug event occurs and the OS then rescans the bus. This is a mildly complicated operation, requiring enabling the slot, checking whether there's a card there, powering the card and all its functions up, waiting for the PCIe link to settle and then announcing the new PCI device to the rest of the OS. ACPI-mediated hotplugging puts more of the load on the firmware rather than the OS - the hotplug event generates a notify message that is caught by the ACPI interpreter in the OS, allowing the OS to check for device presence by calling another ACPI method. If the device is present it's then a simple matter of telling the PCI layer about it.

Native PCIe hotplug has the advantage that there's much less vendor code involved. ACPI is still involved to an extent - an _OSC method on the PCIe bridge is called to allow the OS to tell the firmware that it supports handling hotplug events. This allows the firmware to stop sending any ACPI notifications. ACPI hotplugging requires more support in the firmware, but can work for PCI as well as PCIe.

The general approach taken to getting the Eee's wifi hotplugging to work has been to load the pciehp driver with the pciehp_force=1 argument. This tells the driver to listen for hotplugging events even when there's no _OSC method to tell the firmware that the OS is handling things now. Since the hardware will generate the event anyway, things work. However, this is non-ideal. Some hardware exists where ACPI hotplugging will work, but due to quirks in the hardware design native PCIe hotplugging control will fail. This has been handled in their firmware by having the _OSC method fail, signalling to the pciehp driver that it shouldn't bind to the port. Using pciehp_force overrides that, leading to a situation where hardware could potentially be removed from a port that's powered up. Unfortunate.

My first approach was to add a new argument to pciehp called pciehp_passive. This would indicate to the pciehp driver that it should only listen for notifications from the hardware. User-triggered events would not be supported, avoiding the situation where anyone could remove the card by accident. This worked on my test machine (an Eee 901 somewhere in Ottawa, since I don't actually have one myself...) but was reported to work less well on a 700. Since the 700 didn't claim to have any support for power control, the code was forced to wait a second on every operation to see whether the link powered up or not. This resulted in long pauses during boot and suspend/resume operations.

The final issue that convinced me that this was the wrong approach was reading a document on Microsoft's site on how PCIe hotplugging is implemented in Windows. It turns out that XP doesn't support native PCIe hotplugging at all - that feature was added in Vista. Both the Eee and the Aspire One are available with XP, but things work there. So PCIe native hotplugging was clearly not the right answer. Time to look further.

Armed with a disassembly of the Aspire One's DSDT, I figured out why the ACPI hotplug driver didn't work on it. The first thing the driver does is walk the list of ACPI devices, looking for any that are removable. That was being implemented by looking for an _EJ0 method. _EJ0 indicates that the device can be ejected under the control of the OS. The Aspire One doesn't have an _EJ0 method on its SD readers. However, it did have an _RMV method. This can be used to indicate that a device is removable but not ejectable - that is, the device can be removed (by physically pulling it out or by the hardware taking it away itself), but there's no standard way to ask the OS to logically disconnect it. A quick patch to acpiphp later and the Aspire One now worked without any forcing or spec contravention. This also has the nice side effect of making expresscard hotplug work on a bunch of machines where it otherwise wouldn't.

But back to the Eee. acpiphp still wasn't binding, and a closer examination revealed why. There's nothing to indicate that the Eee's ports are hotpluggable, and there's no topological data in the ACPI tables that ties the wifi function to the PCIe root bridges. However, the Eee firmware was sending an ACPI notification on wifi hotplug. But it was only sending this to the PCIe root bridges, and there's no way to then tell which device had potentially appeared or vanished.

In the end, I gave up on trying to solve this generically. Instead I've got a patch that implements the hotplugging entirely in eeepc-laptop. In an ideal world nobody else will have implemented this in the same way as Asus and we can all be happy.

One month with Emacs and counting - Part 2 A while ago I've blogged about my switch from Vim to Emacs, promising a blog post series, quite a mouthful nevertheless, it's time to continue the series. The first part was about why I think that nowadays Emacs is ready to be switching to. This second part is about flawed Vim design choices which substantially contributed to my choice. (Of course all this post is under a IMO-/rant-disclaimer, it can't be otherwise, so take it cum grano salis) Flawed Vim design choices Vim started as a wonderful editor, following the path of Vi, which in turn has got right a good deal of design choices. One is the often debated modality. In spite of being a HCI PITA in general, modality is not a problem at all for software you are using every single day (and the editor is the 2nd program I use the most, with the terminal being the 1st), because you learn it as a habit. In the case of Vim, modality is good because it let you use powerful yet simple motions in command mode, which can be easily combined with operator-pending commands. This can be considered yet another incarnation of the UNIX philosophy, casted inside the editor itself. ... which brings us to the good old joke which describes Emacs as a great operating system, lacking only a decent editor. In fact, Vim is no longer the nice Unix philosophy player which it used to be, and Emacs plays much more nicely with external tools than Vim. As arguments, let's consider a few (not so) recent Vim evolutions:

• Spell checking. Starting with version 7, Vim has got support for on-the-fly spell-checking of text buffers. It is a super-nice feature, which I've advertised in the past, because spell checking is needed in many tasks we daily do with editors (mail/doc writing, code commenting), and having a single interface to do it comes handy. Unfortunately, how that is implemented in Vim is definitely not along the lines of the UNIX philosophy. We have countless different FOOspell implementations whereas Vim implemented yet another one, without relying on any pre-existing implementation. Even more so, the file format of spell files is basically ad-hoc, and not sharable with other tools. This is already a PITA for packaging (let's add to Debian another 20 binary packages vim-spellfiles-FOO), but is even worst than that: the spell files must be generated in ad-hoc ways which are seriously prone to failures (guess why in Debian we don't have yet the vim-spellfiles-FOO packages which used to exist in experimental a long time ago?). What would have been the UNIX-friendly way of achieving the same result? Well, obviously spawning FOOspell and interact with its process from the editor. Keep that in mind.
• Internal grep. A feature of Vim I've always loved is :grep (yet another instance of quick-fixing, which is also used for jumping to compile-time errors). In its original incarnation it was as simple as invoking grep and parse its output. KISS. Then, Vim started to have a problem: grep -r can take ages and in the meantime the editor was stuck. Hence, starting with Vim 7, vimgrep has born: an internal re-implementation of grep. OK, it is more portable (but how many of us do care? on how many system you use you are missing grep? damn, I used to install it also on Windoze!), and the editor retain control. Control that is exploited just to show a nice progress bar of what is being scanned ..., while the editor is still stuck. Well, to me it looks like the problem would have been solved much more nicely by adding the ability to interact with an external process (deja vu?). That process can then be grep -r. Full stop.
• Lack of debugging support (on purpose). Long standing missing feature of Vim: you can not "easily" drive a debugger from Vim, because a firm choice in Vim is to ... (OK, I confess, I'm starting to beat a dead horse) ... not have support for interaction with external processes. I found such a choice quite dumb: to me it is evident that it induces a trade-off between being feature-complete wrt programmer needs (as available external tools get available to face those needs) and not "re-implementing the wheel" inside the editor. Going back to the lack of debugging support in Vim, that has spawned projects like GdbVim, Clewn, Bram's Agide, and my own tiny teeny incarnation specific to ocamldebug called WOWcamldebug. Every single project of that list acts as an intermediary between Vim and an external process (a debugger of some sort), whereas that could have been implemented by an editor plugin, provided that the editor offer, guess what, support for interaction with external processes.
• Top-level. Similar to the debugging support issue, there is the interpreter issue, namely how to evaluate "phrases" of your interpreted language of choice directly from the editor. Nowadays a lot of languages have the so called top-levels which evaluate language phrases interactively (Python, Ruby, OCaml, many Lisps, ...) and show evaluation results. That ability can speed up testing considerably, but can become cumbersome to use for large code snippets without editor support (good luck with copy and paste). Yes, Vim has support for that, but the implementation choice is close to be ridicolous: only if you have linked Vim together the interpreted for a given language, then you will be able to interactive evaluate phrases of that language. What if you program in Python, Ruby, and Perl? Well, you need to link all of them. What if you also program in OCaml? Then you're screwed, because Vim currently does not support linking with it. (Yes, I know that there are other reasons for doing that linking, they are discussed below.) Do I need to tell you which feature will be enough to address top-level support? interaction with extern.. OK, I'll drop it, you know that already.

Well, I acknowledge that Emacs got this choice right, and that it's an important one: Emacs supports interaction with external processes, and plugin authors have been happy to exploit it to create really cool stuff (sticking to the UNIX philosophy). Please welcome: Flyspell, M-x grep (shameless smartass plug: same number of keystroke of :grep), Grand Unified Debugger, a sampling of language-specific major modes with top-level support. (But I recommend having a look at least once at the coolness of other stuff built-on top of external process support, like Flymake, mentioned by dancer not a long ago.)

• Its own scripting language. I've bored you enough with the external process topic, hence here is the second one: the saga of Vim and its scripting language, i.e., the programming language using which you can customize the editor. Note that the choice of scripting language impacts on 2 different targets: final users in need of fire and forget automations (when they start to get to complex to be implemented on top of, say, macros), and developer of editor extensions such as addons. The impact of scripting language on extension developer is crucial for the evolution of an editor aiming at being powerful. If the scripting language and the API towards the editor is flexible enough, then a lot of cool extensions and features will be developed by third party authors, otherwise the burden stays on editor upstream author.
  1. In its phase 1 (my term, Vim < 7.0) Vim pretended that it needed only a minimal scripting language (Vim script) and that everything else can be developed using external programming languages, linked in the editor. As a consequence Vim script was just a tiny teeny procedural language with editor interfacing capabilities, most notably lacking any "decent" data structures (no lists, no dictionaries, ...). In that phase, if you were a user it was fair enough. You just had to chose your external programming language (at compile time ...), and you were able to write your quick hacks with it. But if you were willing to develop an extension you were screwed, because you had either to impose your external programming language to the final user (that is what gave born to absurdities like vim-full, look at the deps!) or to enjoy a good deal of masochism to explode your 30 lines of Python extension into 200 lines of Vim script to make your Vim extension more "portable".
  2. In its phase 2 (Vim >= 7.0) it has been realized that something were wrong in the initial choices about Vim script, and data structures (lists, dictionaries, function references!) have been added to it, relieving a bit the pain of programming portable extensions. Nevertheless, and probably due to how it started, Vim script is far from being a programming language one can enjoy programming in. Consider for example the standard library of the language. It started as a random collection of unrelated functions being added on a "as-needed" basis, ... and continued along that path! Now the API reference lists together totally unrelated functions, organized inconsistently, and making really painful finding what you need (assuming it exists).

Even in this respect, I acknowledge that Emacs got this right. It has chosen a single, now full-fledged, programming language (Elisp), which is offered both to the final user (fact: the average Emacs user knows much better how to program her own editor than the average Vim user) and to extensions developer. The standard library of the language is organized with a consistent naming (even though not always intuitive) and documented in an organized manner. You might not like the language, but at least is has been taken seriously and managed as such. Finally, being a Lisp dialect, you might need what you learn with Elisp elsewhere. Vim script is too committing: it is useful only inside Vim. I believe that contributed significantly in its scarce diffusion among Vim users. The fact that Elisp was born together with Emacs and that it is also used internally for the editor implementation is not relevant here: I do care about what is offered to me as an user and as an extension developer. What I see on the Emacs side in this respect is much better that what I see on the Vim side. Moreover, from the point of view of the users, is the difference between what is inside the editor and what is outside (i.e., the extensions) that relevant? I think it is not, and that brings me to the final Vim choice which I consider flawed and which has the potential of seriously limit its future evolutions:

• Editor as a distribution. Emacs is managed as a intermediate software distribution layer, similarly to what happens in other softwares where many third party authors cooperates (e.g., TeXLive). The distribution architecture has advantages and contributes to the longevity and potentialities of a software project. What does this mean concretely in the Vim vs Emacs dispute? For example it means that Emacs get more feature-complete each passing release, still preserving uniformity in documentation and keybindings. On the contrary Vim sports many addons, which are very likely to step on each other feet when enabled simultaneously. Actually, that is one of the reason which brought me to the creation of vim-addons: you cannot enable all the content of vim-scripts together due to various kind of conflicts. As we know well in Debian, distributions have a fundamental role in blending together lightly-coupled software components, that's role is missing in Vim evolutionary path and I find that worrisome.

Where to from here in this blog post series? For sure some tips on how to migrate for hard-core Vim users, then we'll see ... If you did enjoy the read please let me know commenting in the discussion page (as you did in the last post, thanks!).

Hey, Xfce 4.6 Beta 2 Hopper has just been released and, guess what, packages are already available. Still not in unstable (or even experimental), that will wait post-lenny. You can install it from my repository, and, as usual, there's no Debian support on them. The known_issue page is currently quite empty, and this beta looks really quite polished. Packages currently available are i386 and amd64, powerpc will be available when I have time to put the mac at build. This beta features mostly bug fixing, and some features too:

• power management stuff in xfce4-session. Based on a patch included long ago in Ubuntu, it means that when you click the logout button it'll ask you if you want to suspend/hibernate the box. That works through hal and it may need some tuning on the machine. Reports appreciated here or there. 
• soname bump in xfconf. That means package renaming from libxconf-0-0 to libxfconf-0-2. No standard upgrade path (Replaces:) is provided because I don't want to clutter the packages before upload to Debian. This will continue for following changes (libxfconf-0-3 for rc for example). For the final release the library name will be changed to libxfconf-1 and the soname will be reset to 0, which means the package name will be libxfconf-1-0. There again, no upgrade path will be provided for people using my repository. The only upgraded path supported will be 4.4 →4.6. (but you won't be totally alone in the dark, I use 4.6 beta on my laptop so I'll pass through hell before you)
• keyboard shortcut can be configured (both window manager ones and applications) and there is now conflict handling
• session management has been greatly improved, you can now save the session immediately (a long-wanted feature) and it manages stuff like SMRestartImmediately etc.

The official announcement can be found there.
Have fnu!

Well, at least, it was the last official day of my employment in Berlin as I took some free days this week. I'm looking forward for me new job, starting next Monday. For more information you can read my German blog entry.

---

A couple of minutes ago I received an email notification about #479427 being closed:

#479427: epiphany-gecko: please reduce the number of dependencies by avoiding linking to some libs
...
* Pass --as-needed to LDFLAGS. Closes: #479427.
+ Introduce 99_ltmain_as-needed.patch.

Being very interested on the subject I went to incoming.d.o and downloaded the -gecko and -webkit versions of epiphany, which were both listed in my packages with most dependencies top 20.

$ countPkgsDeps.pl epiphany-*_2.24.1-1_amd64/control
epiphany-webkit:27
epiphany-gecko:32

So yes, the number of dependencies dropped from 55 and 58 to 27 and 32, accordingly :)

Should dropping the number of useless dependencies be a RG for squeeze? we'll see.

Note: I'll update the post as soon as the i386 packages are built, because the number of package dependencies of my previous blog post were calculated from i386's Packages, not amd64's.

Oh, and of course many thanks to Josselin Mouette for working on the issue.

My goal is to collect all the import statements in a Python code tree to identify what modules are needed to run that piece of code. So let's start from the lower level: parse one file for its import.

One simple solution could be to grep (or re.compile) something like "import (.*) from (.*) import .*" but what for import statement like:

from  import (
ABC,
DEF,
GHI)

or multiple import on one line?

So, if I had to rewrite the Python interpreter parser, why not use that exact parser?

I started with the parser module, but its output is not so parsable :) even if you can recall the structure (i.e. import statements are at nodes with id = 282, with imported module at id = 287 and so on). It's really powerful, but too low level for this task.

But there is another interesting module: compiler (it's deprecated in 2.6 and removed in 3.0, but I'm working with 2.5, so it's fine). Using parseFile and some objects from compiler.ast, I wrote a simple script that parses a file given in input and prints out the modules imported with "import mod" or with "from mod import xxx".

Suggestions are always welcome :)

UPDATE: please note that conditional imports are included in the list and the calls to __import__ are ignored.

There have been a number of improvements to the Debian installer on Network Attached Storage (NAS) devices in the last few months and they are available to users now that RC1 has been released. We have added support for Marvell's Orion platform. Orion is a system on a chip (SoC) that integrates an ARM CPU, Ethernet, SATA, USB, and other functionality in one chip. The majority of NAS devices that have come out within the last two years are based on Orion chips, so it's exciting to have support for this significant platform in Debian. Specifically, we support the following devices based on Orion: QNAP Turbo Station (TS-109, TS-209, TS-409), HP Media Vault mv2120, and Buffalo Kurobox Pro (with more to come later). Here are some other newsworthy improvements and changes:

• When a static IP address is set in the original system that is the default from the vendor, this address will now be used. In the past, the installer would use DHCP in this case but users found this confusing. This affects the Linksys NSLU2 and Thecus N2100.
• If a static IP configuration is used in the original system but this configuration is incomplete (i.e. IP address or DNS are missing), then the installer will use DHCP (instead of hanging during start). This affects the Linksys NSLU2 and Thecus N2100.
• On the Linksys NSLU2 and Cobalt devices, all required installer modules are automatically installed now and no longer have to be selected manually from a list.
• initramfs will use MODULES=dep rather than MODULES=most. In other words, only modules that are actually needed on your system will be included in the ramdisk.
• /etc/default/rcS will be configured on supported NAS devices to contain FSCKFIX=y, so e2fsck will attempt to repair the filesystem without prompting the user for input. This is useful on NAS devices since they are usually headless.

Finally, the armel port is recommended for new installations now. Debian lenny has two different and incompatible ARM ports: the old ABI port (arm) and the new EABI port (armel). Debian lenny is the last release with support for the arm port and future releases will only support the armel port. It's therefore recommended to use armel for new installations of lenny.

when not being distracted by other uses of the system, i've managed to spend some more time on packaging some more stuff that's useful on a debian ps3. namely:

• ps3-utils: necessary utilities (boot-game-os, ps3-video-mode, etc)
• speutils: threading and message passing library
• spu-medialib: spu-accellerated audio/video library
• xserver-xorg-video-spu: spu-accellerated framebuffer driver for xorg

the last of which i think will be of the most interest to some folks, as it provides an spu-based xvideo extension, which brings back the possibility of playing HD videos etc on the ps3. now if you're interested in checking out these packages, read on, starting with this: !=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!= ZOMG WARNING!!!1!!ONE!! THESE ARE EXPERIMENTAL BLEEDING EDGE PACKAGES. I MAKE NO GUARANTEE WHETHER THESE PACKAGES ARE PROPERLY BUILT, WILL INSTALL, WILL WORK, WILL NOT DESTROY YOUR SYSTEM, WILL NOT CRAWL OUT OF YOUR SYSTEM AND MAKE LONG DISTANCE PHONE CALLS WHILE EATING THAT SNACK YOU WERE SAVING IN THE FRIDGE, ETC. !=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!= okay, so now that we've disposed with that formality, i'm glad if you're interested and still here so... where were we? oh yes. put this in your sources.list:

deb http://people.debian.org/~seanius/ps3-experimental-packages sid main

source packages are also available if you want to poke around or backport the packages to etch or ubuntu or something else wierd like that:

deb-src http://people.debian.org/~seanius/ps3-experimental-packages sid main

now, if you have a properly configured system, you should get a warning:

Reading package lists... Done
W: GPG error: http://people.debian.org sid Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY CA78CB3E6E76D81D
W: You may want to run apt-get update to correct these problems

but i promise this key is valid, and mine. but hey, you don't have to take my word for it

sudo apt-get install debian-keyring
gpg --no-default-keyring --keyring /usr/share/keyrings/debian-keyring.gpg --export --armor CA78CB3E6E76D81D   sudo apt-key add -

then you can install the packages... assuming you want the xorg video driver:

sudo apt-get install xserver-xorg-video-spu

and update the appropriate Device entry in your xorg.conf, so that the normal fbdev is commented out and instead you use the spufbdev driver. example:

Section "Device"
        Identifier      "Generic Video Card"
        Driver          "spufbdev"
        Option "ShadowFB" "false"
EndSection

and then

sudo /etc/init.d/gdm restart

(or the equivalent if you're using something else). that's it! more packages may trickle in here as well, at least until and they find their way into debian proper. i'm also in contact with the upstream authors of this stuff, and they're generally very responsive, so let me know if you have any problems.

Looking at:

http://www.iht.com/articles/ap/2008/11/13/america/Gay-Marriage.php

It looks like Connecticut now has what we had a week or so ago. And isn't staring a proposition in the eyes to get rid of it.

Someone explain to be how gay San Francisco can't have weddings and somewhere-by-DC Connecticut can?

I wouldn't have wanted folks in Connecticut to have to wait any longer, but I admit that I'm having trouble overcoming my sadness at Prop 8 enough to celebrate this the way it should be. It's an awesome ruling, and I wish people many long and happy marriages. I love being married and think that everyone should be able to have the same shot at this.

Long time no post. Anyway, I have some good news. The Gtk code for Aptitude has been merged some time ago into the main development trunk and we now have a release in Experimental. For those that don’t know about it, here’s what it’s all about : “The new frontend is is an effort to bring some of the design principles of the curses frontend to a GUI environment, while also exploiting the unique features a GUI gives us and exploring ways to deal with changes in the environment in the nine years since aptitude was first designed.” I had a very good time this summer working on Aptitude with Daniel Burrows in the Google Summer of Code program and I’m very glad we now have a real release. This version is by no means final or perfect but it’s a good start. Head for the blog post from Daniel for some other informations : [Daniel Burrows]

I've released version 0.5.0 of the aptitude package manager (release notes). Once the mirrors have synced, you should be able to download it from Debian's experimental distribution, or manually from the aptitude package page.

---

[Edit] This release was uploaded to experimental because it is not a final release. aptitude follows the Linux version numbering scheme in which an odd second digit indicates an unstable development version. DO NOT INSTALL THIS VERSION IF YOU WANT STABLE SOFTWARE; IT IS INCOMPLETE, INADEQUATE, AND PROBABLY INCORRECT. To reply to some questions that several people have asked me:

1. The final release of aptitude 0.6.0 will be split into two packages, one containing only the traditional text interface and named aptitude-curses, and one containing the GUI binary named aptitude-gtk, with both of them providing the aptitude binary through Debian's alternatives mechanism. This release wasn't split because the code to drop GTK+ support was buggy and I discovered this fact halfway through assembling the release. It's fixed now.
2. To run the traditional curses interface, pass the --no-gui command-line parameter or set the option Aptitude::Start-Gui to false in /etc/apt/apt.conf. Unless you want to test that the curses frontend isn't broken, though, there won't be much for you in this release: the only change affecting it is Xapian support, and that currently breaks incremental search. (see the note above about this being an unstable release)

Also, another feature that I suspect might be bothersome is the behavior of updating the package lists and downloading changelogs on startup. There's no switch for changelogs yet, but you can disable the package list update by setting Aptitude::Update-On-Startup to false.

---

The main change in this release is the new GTK+ frontend, designed and implemented by Obey Arthur Liu with funding from the 2008 edition of Google's Summer of Code. The new frontend is is an effort to bring some of the design principles of the curses frontend to a GUI environment, while also exploiting the unique features a GUI gives us and exploring ways to deal with changes in the environment in the nine years since aptitude was first designed. For instance, it is no longer reasonable for the user to actually read the entire package list (when I first installed Debian, you could read through the whole package list in a single sitting). So instead of basing the interface around a list of all the packages, we based it around the ability to search for the packages you're interested in. This version of aptitude also introduces Xapian searching:

daniel@emurlahn:~$ aptitude search "apt package manager"
i   apt                                  - Advanced front-end for dpkg
p   apt-dater                            - terminal-based remote package update manager
p   apt-dater-dbg                        - terminal-based remote package update manager (d
i   aptitude                             - terminal-based package manager
i   aptitude-dbg                         - Debug symbols for the aptitude package manager
p   createrepo                           - generates the metadata necessary for a RPM pack
p   gnome-apt                            - graphical package manager
p   smartpm                              - An alternative package manager that works with
p   smartpm-core                         - An alternative package manager that works with
i   synaptic                             - Graphical package manager
i A update-manager-core                  - APT update manager core functionality

You might ask why I didn't search for just package manager. The reason is simple: aptitude doesn't yet sort by relevance, and that second search gave me screenfuls of packages whose description contains both package and manager, including addressmanager.app (a PIM for GNUstep), compiz-gtk (a piece of eye candy), and wterm (an X terminal emulator). However, it is worth noting that Xapian searches are fully integrated into the aptitude search language, so they can be combined with non-Xapian search terms in just the way you would expect:

daniel@emurlahn:~$ aptitude search "?installed apt package manager"
i   apt                                  - Advanced front-end for dpkg
i   aptitude                             - terminal-based package manager
i   aptitude-dbg                         - Debug symbols for the aptitude package manager
i   synaptic                             - Graphical package manager
i A update-manager-core                  - APT update manager core functionality

So, all the basic functionality that the GUI version needs is in place; the next step is to start polishing it and filling in the gaps that are left. And, of course, suggestions and bug reports are welcome, so we know where the rough spots and the gaps are. Please send your comments to aptitude-devel@lists.alioth.debian.org so that they are part of the public record and so that people besides me can read them. Happy package managing!

Finally, Flickrpc 0.3 is released. Some nice features that we all know and love from Postr here:

• Proxy support
• Add more upload arguments: safety, privacy, public/friends/private, search_hidden
• Cache the users full name, username and NSID (jcrosby)
• Fix UTF-8 encoding problems
• Verify our cached token before using it

Grab a tarball here or the Bazaar tree here.

After some hilariously frightening reactions from Dell support to simple problems, and HP becoming aggressively competitive on price, we've been using HP servers for a few years now. The hardware is good, and the support, while reasonable, always... pauses... when I mention that we're running Debian. I try not to let it slip if I don't have to.

We put in some HP blades a couple of years ago, and I was annoyed to discover that they have discontinued that enclosure and all the blades in it. I decided this was a good time to look at their newer options, as well as at other companies.

Back in July, I had noticed a Silicon Mechanics booth at OSCon. I noticed their slogan "experts included." That sounds great; we've got software experts here, but not hardware experts, and I'd enjoy dealing with a company that knows more about their hardware than I do. I went up to their booth and asked what they'd say about us running Debian on their hardware. "That would be just fine." "So you'd fully support it when I'm running Debian?" "Sure." "What about management software - do you have any of that which I'd find annoying to port to Debian?" "Our servers don't need any management software other than what comes with your kernel." Good answers.

So, when it came time for us to decide what to do about getting a new server in here, I figured I'd call up Silicon Mechanics and see what they'd recommend. They put me on a conference call with a sales rep and an IT engineer, and wound up recommending a 1U server for us to start with, and an iSCSI storage device to address some of the storage needs we have (both for that server and others). I had heard of iSCSI only vaguely, and asked how it worked, and what the performance would be like compared to our 2Gb FC SAN. I got back intelligent (and correct) answers.

They probably spent 2 hours with me on the phone before we placed an order. I was incredibly happy with their service, level of expertise, and helpfulness. They even did a webinar to demo the management interface on the storage unit for me.

Today, the 1U server arrived. I unboxed it and set it on my desk to configure. First item: set an IP address for the IPMI card. That's the device that lets me connect to it over a web browser and interact with the console, power cycle it, etc. as if I was there. I set an IP, but somehow couldn't seem to figure out the username and password for the web interface.

So I called Silicon Mechanics support at the number that was included on the fridge magnet (!) that came with the shipment. Phone rang once. Then a live, capable American answered. No menus, no fuss. I asked my question. He apologized, saying, "I should know that, but I'll have to look it up... hold on just a bit." I had my answer about 90 seconds later. He offered to send me the full docs for the IPMI card if I wanted as well.

So I've been very impressed with them so far. From what I've heard, their iSCSI enclosure ought to be quite something as well. They even helped us spec out a switch that supports trunking for use with it.

I'll give them a "highly recommended".

Good news everyone, new Gammu testing version is out. Fixes are there for everybody, starting in AT engine initialization, going through FBUS and Nokia drivers up to OBEX handling in Siemens phones. Full list of changes:

• Script gammu-config can now also work with whiptail.
• Minor fixes in gammu-config script.
• Extra spaces from connection or device name are now stripped.
• Automatically reinitialize FBUS connection if it is dropped.
• Disable OBEX with Motorola Z6c, it is broken (bug #746).
• Refresh manufacturer information on second init of AT (bug #746).
• Always get charset information on AT phone initialization.
• Better handling of OBEX switching for Siemens phones.
• Fix flags for 2630 and 3109c (bug #752).
• Fix handling of caller groups and picture IDs (bug #752).
• Properly set calendar location while adding (bug #747).

You can download from usual place: http://cihar.com/gammu/, Debian users will find packages in experimental soon.