Activity of our current Chinese translator pushed me to do some work on localized documentation for phpMyAdmin. The biggest change is that I lowered ratio for generating translated documents from 70% to 15%. I know 15% is quite low threshold, but I think showing partially translated documents is better than nothing. Especially for those like Chinese where the translation does cover installation instructions but not rest of document. Also now header of each translated document points users where to improve the translation, so hopefully we will get even more contributors. Anyway if you're interested in it, just go to our translation server.

RCBW - #22 With a mini-rush in the week-end, I'm now back on track to the weekly schedule of RCBW; here are this week's squashes:

• bug #565274 - tex4ht - test and close bug fixed by recent binNMU
• bug #553553 - phpsysinfo - fix dir-or-file-in-var-www, based on a patch by Mats Erik Andersson
• bug #553496 - doc-central - fix dir-or-file-in-var-www, sponsor NMU by Mats Erik Andersson
• bug #559821 - libtunepimp - fix libltdl CVE (bonus fix bug #476378), patches by Yavor Doganov
• bug #568982 - sqldeveloper-package - port from dos2unix to fromdos, patch by Michael Musenbrock
• bug #534721 - libhpricot-ruby1.8 - error in printing tags to stdout (fixed upstream in a version already in Debian)
• bug #564680 - gnugk - rebuild against firebird 2.1, as requested by Damyan Ivanov (important bug blocking RC bug #549062)

About this week highlights:

• In his latest RC-bug statistics, Tolimar has pointed to the RCBW description as inspiring. That's good, I hope more and more people can find it inspiring (in fact, that's why I wrote it). A handful of people doing RCBW is pointless, unless as a side-effect we manage to change the culture of our project in order to be more collaborative on how we reach a release.
• I've been amazed by how many RC bugs are "stuck" just because no one took care of establishing communication among the appropriate people. That of course happens when the maintainer of the bug has been unresponsive, but some investigations of the bug is usually enough to make the appropriate people (upstream, porters, related package maintainers, ...) aware of it ... and then the bug will "mature" all alone.
• Josselin has announced the Debian/GNOME bug weekend for the next weekend (27-28/02/2010): an initiative to collaboratively triage GNOME-related bugs in Debian. For large-enough packages (and GNOME fits that definition for quite some different notions of "large"), such efforts are as badly needed as RC squashing: if you liked RCBW, you can't miss the GNOME bug weekend

Application Indicators: A Case of Canonical Upstream Involvement and its Problems I always thought Canonical could do a bit more to contribute to the GNOME project, so I was happy to see the work on application indicators proposed to GNOME. Application indicators are based on the (originally KDE-driven, I believe) proposed cross-desktop status notifier spec. The idea (as I understand it) is to have a consistent way of interacting with status notifiers and stop the confusing mix of panel applets and systray indicators. This is a very laudable goal as mentioned by Colin Walters:

"First, +5000 that this change is being driven by designers, and +1000 that new useful code is being written. There are definite problems being solved here."

The discussion that followed was very useful, including the comments by Canonical's usability expert Matthew Paul Thomas. Most of the discussion was about the question how this proposal and spec could be best integrated into GTK, the place where most people seemed to agree this belongs (rather than changing all apps to provide this, this should be a service provided by the platform) However, on the same day, Canonical employee Ted Gould proposed libappindicator as an external dependency. The following thread showed a couple of problems, both technical and otherwise:

• It is proposed as an external dependency, not as a part of GTK
• It is unclear how it will integrate with the GNOME3 Shell
• It requires Canonical's notorious copyright assignment
• It is licensed under the LGPLv2.1 or 3 specifically, not any later one

What I personally disliked is the way the Cody Russel and Ted Gould are papering over the above issues in the thread that followed. For examples, about point one, Ted Gould writes in the proposal:

Q: Shouldn't this be in GTK+?
A: Apparently not.

while he himself said on the same day, on the same mailing list: "Yes, I think GTK/glib is a good place" and nobody was against it (and in fact most people seemed to favor including this in GTK). To the question about why libappindicator is not licensed as usual under the LGPL, version 2.1 or later, Canonical employee Cody Russell even replied:

"Because seriously, everything should be this way. None of us should be saying "LGPL 2.1 or later". Ask a lawyer, even one from the FSF, how much sense it makes to license your software that way."

Not everybody has to love the FSF, but proposing code under mandated copyright assignments which a lot of people have opposed and at the same time insinuating that the FSF was not to be trusted on their next revision of the LGPL license seems rather bold to me. Finally, on the topic of copyright assignments, Ted said:

"Like Clutter for example ;) Seriously though, GNOME already is dependent on projects that require contributor agreements."

It is true that there are (or at least were) GNOME applications which require copyright assignments for contributions (evolution used to be an example, but the requirement was lifted), however, none of the platform modules require this to my knowledge (clutter is an external dependency as well). It seems most people in the GNOME community have the opinion that application indicators should be in GTK at least eventually, so having libappindicator as an external dependency with copyright assignments might work for now but will not be future proof. In summary, Most of the issues could be dealt with by reimplementing it for GTK when the time comes for this spec to be included, but this would mean (i) duplication of effort, (ii) possibly porting all applications twice and (iii) probably no upstream contribution by Canonical. Furthermore, I am amazed at how the Canonical people approach the community for something this delicate (their first major code drop, as far as I am aware). To be fair, neither Ted nor Cody posted the above using their company email addresses, but nevertheless the work is sponsored by Canonical, so their posts to desktop-devel-list could be seen as writing with their Canonical hat on. Canonical does not have an outstanding track record on contributing code to GNOME, and at least to me it seems this case is not doing much to improve things, either.

In ancient Rome, the Imperial cult was the worship of the Roman emperor as a god. It came to be at roughly the same time as Christianity. In the cult of the emperor, Caesar was revered as a deity. According to Harvey Cox, This was what we might today call a civil religion it had its holidays, processions, and holy sites throughout the empire. Adherence to it was required of all of the emperor s subjects, wherever they lived and whatever other deities they also worshiped. It was the religious and ideological mucilage that held the far-flung empire together. Perhaps you see where this is going. There was a certain group that found the imperial cult, well, repugnant. They felt their own goals bringing their god s peace and justice to the world were incompatible with this sort of devotion to a human institution, and the very institution that had killed their leader at that. Their reaction went like this:

Regarding worship of the emperor, Christians responded with an unequivocal no. They claimed that Jesus Christ was God s kyrios ( anointed one in Greek), but since kyrios was one of the titles attributed to Caesar, they refused to participate in the imperial cult. They were willing to pray for the emperor and for his health, but they stubbornly refused to pray to him or offer ritual tribute. They recognized that one could not be a follower of Jesus while also honoring a rival to the loyalty their faith in him and his Kingdom required; therefore, not even one pinch of incense on the imperial altar. This defiance of the political religion of the empire, which led their critics to brand them subversive, landed many of them in arenas with salivating lions. Harvey Cox in The Future of Faith

Now, you may be wondering, why am I asking if anyone still worships the emperor of a long-extinct empire? I maintain that this practice is still alive and well, just under a different name. I have been interested in some of the debates about American institutions that choose to perform neither the national anthem nor the pledge of allegiance. Many of these institutions are Mennonite, and their reason for not participating in these two particular acts mirrors that of the early Christians refusing to worship Caesar: namely, their goal is to bring about God s peaceful and just kingdom on earth, and no country, no human institution at all, can ever command greater loyalty than that cause. Moreover, the American national anthem is a particularly violent one, celebrating the taking of life right there at the beginning. Not completely compatible with the ethics of a church trying to bring about a more peaceful world, right? It is from that basis that many Mennonites, and our institutions, do not perform the national anthem or say the pledge of allegiance. For myself, when the national anthem is being performed, I will stand out of respect for those around me for whom the moment is important, but I do not sing. I am deeply appreciative that the United States, like many other countries, makes it legal to do this. I am heartened by the fact that I do not risk a confrontation with the lions over my religious stance today. Goshen College, a Mennonite institution, recently decided to go back on a century of history (which goes back farther than the anthem itself, which was only adopted in 1931) and will now be performing the anthem, followed by a prayer, before select sporting events. And by so doing, they fail both to act in accordance with the way of Christ, and to be a patriot. They fail to act for peace and justice by playing an anthem that supports and glorifies war and violence. And they fail to be patriotic. Patriotism and nationalism are different things. It s easy to be nationalistic to get up there and sing a song that everyone wants you to sing. It is far more difficult to be patriotic. Being patriotic in the United States means using the freedoms we have to improve our country. Goshen ought to use its freedom to not observe the national anthem as a way to try to draw a line in the sand against violence, to suggest that our anthem fails to adequately recognize the character of the American people and who we want to be, and to suggest a better alternative. After all, those people who are venerated today as patriots anyone from Martin Luther to Thomas Jefferson to Martin Luther King stood up to their fallible human governments to seek positive change. Instead of a route both religious and patriotic, Goshen College has chosen one that is neither. I am deeply disappointed that 300 phone calls have apparently cowed their leadership. What have we come to when our ancestors braved the lions, and we give up our principles over the fear of bad publicity? Ah, Goshen, perhaps you are thinking that you could spare a few pinches of incense for Caesar after all?

As the release of version 0.15 of Merkaartor (a map editor for OpenStreetMap.org) is planned for the end of February, I've uploaded a svn snapshot based on revision 19956 to Debian experimental. Please test it and report bugs to the BTS as soon as possible, so I can triage and forward them to upstream.

RCBW - #21 I've accumulated one more day of delay, but here is a full RCBW issue. Still, I've a nice good excuse for the extra delay: I've changed house in Paris, the new one is very small (a chambre de bonne), but also very comfortable. Without any further ado, here are this week's squashes:

• bug #555325 - gq - requested removal from testing
• bug #567265 - tinyproxy - clarify ambiguous debian/copyright
• bug #569391 - gmetadom - fix CDBS include order, to ensure proper generation of $ ocaml:Depends
• bug #559814 - hamlib - libltdl privilage escalation (sponsor upload for Kamal Mostafa)
• bug #567192 - ircd-hybrid - apply patch from DSA-1980-1 (thanks Steffen Joeris)
• bug #563883 - python-dmidecode - avoid shipping /usr/local/ stuff (sponsor upload for Nima Talebi)
• bug #561904 - python-dmidecode - fix file clash w/ -dbg package (ditto for the sponsoring)

And here are the usual highlights:

• a quote from #debian-devel, on 10/02/2010:

    (11:41:49) Zhenech: zack, damn you, now you infected me with the nmu virus :P
    (11:42:08) zack: Zhenech: yay, another one \o/
    (11:42:30) zack: Zhenech: can I quote you? ;-)
    (11:42:45) Zhenech: zack, only if you don't sell it to elsevier ;)
    (11:43:12) zack: deal!
  
  

• in some particular cases RC bugs can be "fixed" by requesting the removal of a package from testing (when it is not appropriate to remove the involved packages completely from the archive, which is often the case). As I didn't that much often in the past, I forgot how to do that: just file a bug against release.debian.org respecting the usual removal conventions
• gregor hermann is my hero
• bernd zeimez posted on planet an impressive summary of Moenchengladbach's BSP

As can be already visible from our SourceForge.net devel page or from repository listing, there are already some Git repositories for phpMyAdmin. They are not yet being used for development, they are there just for developers to get used to new workflow. The only exception are scripts and localized_docs repositories, which were made master as of today and will not receive updates from SVN anymore. Anyway the repository should have same content as SVN (as of yesterday) so if you find any problems with that please let me know so that I can fix migration magic.

Dear lazyweb: I am in search of a mailing list for discussion on matters related to digital identity and privacy in the information age. Unfortunately, my (limited) searching has not unveiled results, mostly because many mailing lists have privacy agreements or somesuch, polluting the results with pointers to those. If you know such a list, or you don t but you are interested in the topic, don t hesitate to drop me a line. I will then either let you know when my search was successful, or subscribe you when I have created a list to fill the void. NP: Sola Rosa: Solarized

Sorry! I cannot tell you when KDE 4.4 will be uploaded to unstable. I am not working on that. My initial plan was writing about other tasks I am planning to work on and asking for your help. But I realized people would be more interested in knowing about KDE 4.4 packages. Once you know about this, I might trick you into helping in others areas ;) Debian packages for KDE 4.4 are being worked on, just slowly and of course, keeping on with the quality you are used to. There will be also some changes that have been in some people s TODO for long time. The goal is having them in very good shape for Squeeze, that will ship with some point release of 4.4. The doubt is which point release will be: 4.4.2? 4.4.3 ? The schedule for the point releases has not been made yet, so it makes a bit harder trying to predict it. In the same lines, I can not tell you when Squeeze will be released neither, it needs to be frozen first! If you want to know about the reasons of this delay, it is simple math: KDE has been growing a lot of more than the number of people working in Debian packages of KDE. I am not talking about size in lines of code in KDE, it is more the number of new dependencies that the KDE team have to take care now too: soprano, libutempter, Have you wondered why some are under the name of Debian Krap maintainers? :) And there are releases much more often than in the KDE 3 times. You might have notice not only 4.3.5 have been skipped, it also was the case with 4.2.3 or 4.1.4. This is not good or bad, it is just the same number of maintainers (or less) with more work. And what is worse with more bugs open in the Debian BTS! I think reiterated calls for not to file upstream bugs in the Debian BTS and directly in KDE bugzilla (see my blog post about this here) have helped but still we have a large amount of bugs piled through the years. This graph could give you an estimate how we tried in the past fighting against without too much success:
Olivier Vitrat, we miss you :) One of the most heavy (and boring) talks that needs to be done for the KDE 4.4 packages is the copyright checking. I am not sure a total newbie can help with this, but if you have knowledge about licenses and you want to try helping, we are waiting for you. About other areas of the packaging maintenance, if you are interested in start learning and helping with future releases, you are welcome to start lurking in the #debian-qt-kde channel in OFTC and in the mailing lists. Update February 21th: 4.4.0 is for sure not being uploaded into the archive. Probably KDE SC 4.4.1 to be released 2nd March will be uploaded to unstable or experimental.

I ve been looking at instant messaging and chat software lately. Briefly stated, I connect to Jabber and IRC networks from at least three different computers. I don t like having to sign in and out on different machines. One of the nice features about Jabber (XMPP) is that I can have clients signing in from all over the place and it will automatically route messages to the active one. If the clients are smart enough, that is. Gajim I have been using Gajim as my primary chat client for some time now. It has a good feature set, but has had a history of being a bit buggy for me. It used to have issues when starting up: sometimes it would try to fire up two copies of itself. It still has a bug when being fired up from a terminal: if you run gajim & exit, it will simply die. You have to wait a few seconds to close the terminal you launched it from. It has also had issues with failing to reconnect properly after a dropped network connection and generating spurious resource already in use errors. Upgrades sometimes fix bugs, and sometimes introduce them. The latest one I ve been dealing with is its auto-idle support. Sometimes it will fail to recognize that I am back at the machine. Even weirder, sometimes it will set one of my accounts to available status, but not the other. So much for my complaints about Gajim; it also has some good sides. It has excellent multi-account support. You can have it present your multiple accounts as separate sections in the roster, or you can have them merged. Then, say, all your contacts in a group called Friends will be listed together, regardless of which account you use to contact them. The Jabber protocol (XMPP) permits you to connect from multiple clients. Each client specifies a numeric priority for its connection. When someone sends you a message, it will be sent to the connection with the highest priority. The obvious feature, then, is to lower your priority when you are away (or auto-away due to being idle), so that you always get IMs at the device you are actively using. Gajim supports this via letting you specify timeouts that get you into different away states, and using the advanced configuration editor, you can also set the priority that each state goes to. So, if Gajim actually recognized your idleness correctly, this would be great. I do also have AIM and MSN accounts which I use rarely. I run Jabber gateways to each of these on my server, so there is no need for me to use a multiprotocol client. That also is nice because then I can use a simple Jabber client on my phone, laptop, whatever and see all my contacts. Gajim does not support voice or video calls. Due to an apparent bug in Facebook, the latest Gajim release won t connect to Facebook servers, but there is a patch that claims to fix it. Psi Psi is another single-protocol Jabber client, and like Gajim, it runs on Linux, Windows, and MacOS. Psi has a nicer GUI than Gajim, and is more stable. It is not quite as featureful, and one huge omission is that it doesn t support dropping priority on auto-away (though it, weirdly, does support a dropped priority when you manually set yourself away). Psi doesn t support account merging, so it always shows my contacts from one account separately from those from another. I like having the option in Gajim. There is a fork of Psi known variously as psi-dev or psi-plus or Psi+. It adds that missing priority feature and some others. Unfortunately, I ve had it crash on me several times. Not only that, but the documentation, wiki, bug tracker, everything is available only in Russian. That is not very helpful to me, unfortunately. Psi+ still doesn t support account merging. Both branches of Psi support media calling. Kopete Kopete is a KDE multiprotocol instant messenger client. I gave it only about 10 minutes of time because it is far from meeting my needs. It doesn t support adjustable priorities that I can tell. It also doesn t support XMPP service discovery, which is used to do things like establish links to other chat networks using a Jabber gateway. It also has no way to access ejabberd s send message to all online users feature (which can be accessed via service discovery), which I need in emergencies at work. It does offer multimedia calls, but that s about it. Update: A comment pointed out that Kopete can do service discovery, though it is in a very non-obvious place. However, it still can t adjust priority when auto-away, so I still can t use it. Pidgin Pidgin is a multiprotocol chat client. I have been avoiding it for years, with the legitimate fear that it was jack of all trades, master of none. Last I looked at it, it had the same limitations that Kopete does. But these days, it is more capable. It supports all those XMPP features. It supports priority dropping by default, and with a plugin, you can even configure all the priority levels just like with Gajim. It also has decent, though not excellent, IRC protocol support. Pidgin supports account merging and in fact, it doesn t support any other mode. You can, for instance, tell it that a given person on IRC is the same as a given Jabber ID. That works, but it s annoying because you have to manually do it on every machine you re running Pidgin on. Worse, they used to support a view without merged accounts, but don t anymore, and they think that s a feature. Pidgin does still miss some nifty features that Gajim and Psi both have. Both of those clients will not only tell you that someone is away, but if you hover over their name, tell you how long someone has been away. (Gajim says away since , while Pidgin shows last status at . Same data either way.) Pidgin has the data to show this, but doesn t. You can manually find it in the system log if you like, but unhelpfully, it s not on the log for an individual person. Also, the Jabber protocol supports notifications while in a chat: The contact is typing , paying attention to a conversation, or closed the chat window. Psi and Gajim have configurable support for these; you can send whatever notifications your privacy preferences say. Pidgin, alas, removed that option, and again they see this as a feature. Pidgin, as a result, makes me rather nervous. They keep removing useful features. What will they remove next? It is difficult to change colors in Pidgin. It follows the Gtk theme, and there is a special plugin that will override some, but not all, Gtk options. Empathy Empathy supports neither priority dropping when away nor service discovery, so it s not usable for me. Its feature set appears sparse in general, although it has a unique desktop sharing option. Update: this section added in response to a comment. On IRC I also use IRC, and have been using Xchat for that for quite some time now. I tried IRC in Pidgin. It has OK IRC support, but not great. It can automatically identify to nickserv, but it is under-documented and doesn t support multiple IRC servers for a given network. I ve started using xchat with the bip IRC proxy, which makes connecting from multiple machines easier.

Want a healthy diet, but difficulty determining diet have much less heart disease and diabetes, now do not need to be confused. The problem currently existing software can determine which food or menu with us. This tool was created Muhammad Burhanuddin SI students majoring in the College information systems Information Management and Computer Engineering (STIKOM). Pemuda Surabaya original was inspired by his desire to want to get the ideal body weight. He then sought a reference from a variety of books on diet and sehata the ideal body shape. From the book, he then designed a program for determining menu diet with computerized systems. Yes at first it was because I found it difficult to lose weight and see the number of experts in determining the diet for patients with certain diseases, he said on the red building STIKOM Surabaya, Jalan Kedung Baruk, Thursday (15/10/2009). During the decisive finishing diet program, she had difficulty in the verification phase of the rule which took one month of a total of four months of completion of the program is the final project. This 21 year young man said this program can ciptaanya to help digunakanahli nutrition diet suitable for the patient. At first nutritionist to determine the menu of resus a patient s blood type that has gone through laboratory tests. Then determine the disease
patients suffered until finally obtained the results of a diet, he said.

On Saturday, I joined The Albuquerque Rocket Society monthly launch in Rio Rancho, NM. A friend, Mike, who lives in the area joined me for the launch. While the morning started off clear and calm, if a bit cold... the wind came up hard and we had to call it quits before lunch. But before the wind "blew us away", I managed to get one flight in. And it was an absolutely perfect test of one of my brand-new TeleMetrum v0.2 boards! My cut-down Hawk Mountain "Raptor" kit, renamed "G-Spot" last October during my quest to exceed 50 g acceleration, was loaded with TeleMetrum serial number 51... and launched on a Cesaroni 229H255WT-14A motor. The ascent was beautiful! I've put a few photos of the rocket leaving the launch rail up on flickr. However, despite a clear sky, we quickly lost sight of it! I managed to spot a bit of the smoke trail from the delay grain as the rocket approached apogee, but that was it! None of us at the launch saw anything after apogee! After losing sight of the rocket, I turned my attention to my computer, where we were receiving a solid telemetry stream. It quickly became apparent that the rocket was descending normally under chute. As it got closer to the ground, I started calling out elevation, azimuth, and distance numbers, but still nobody could spot the rocket. As expected, we lost the RF link once the rocket reached the ground. As various folks on the flight line wished me luck finding my rocket, I put the last reported GPS position into my hand-held receiver. Staring at the map display, Mike and I realized the rocket was far down range, near one of the roads into the site. We jumped into my vehicle and drove down the road to the point closest to the rocket's reported position. We then walked to where the GPS receiver said the rocket should be... And found the rocket within about 20 feet! That was well within the window of position uncertainty my hand-held GPS was reporting at the time. Things just don't get much better than that! We picked up the rocket, and returned to the flight line only a few minutes after leaving it. After dumping the data from the board's on-board memory, I quickly generated the usual plots, along with a kml file that can be viewed in Google Earth. The rocket reached 1881 meters apogee, or around 6173 feet, and the maximum acceleration was 19.5 g. It touched down nearly 1.3 miles down range from the launch rail, in sage-brush desert. I honestly don't think I would have found the rocket without at least the radio beacon. It was hugely gratifying that the GPS worked and let me walk right up to the rocket! I could not have asked for a better test of the new electronics! Later in the day, Keith flew a successful test of serial number 52 at a launch in Wilsonville, Oregon. We're very happy with these results! Weather permitting, I hope to get more test flights in next weekend at Hudson Ranch. Stay tuned!

This spring I'm taking a class that does all its programming assignments in MIT Scheme. The last time I had to write Scheme for class, we used PLT Scheme, and thus the DrScheme editor. This time, with that option out, I've decided to do the assignments in Emacs. It is, after all, an editor built out of lisp. I've used vim for the last five years or so. Some people ask me why this is so I do go to MIT after all, where Emacs was originally written. The answer to that is simply that Debian got to me first, and at the time at least, the people I knew there used vim. I've heard Emacs is good, but up until this point every time I've tried it I've thrown it down in frustration and then couldn't figure out how to exit the damn thing. This time I was more determined, and made it through the initial hump of being completely useless at the editor. Here are a few of my observations so far, after mucking around for a couple days over a period of about two weeks:

• The movement commands seem much more awkward to me. Since I'm using the Colemak keyboard layout, I have backspace bound to Caps-Lock, and it is not available to be a Control key. It may be that I just need some more time to get used to emacs not being modal.
• It's awkward to switch between split windows using C-x o when I have 4-6 open at a time. I'd like to be able to jump between specific ones directly.
• C-x 3 will always split the window containing the current buffer evenly in two, which makes it difficult to, for example, create three equally sized vertical windows, side-by-side. Vim defaults to creating evenly sized windows even when you invoke a split twice in a row.
• The paradigm of being able to have e.g. a scheme buffer or a shell as one of my split windows is nice, though I haven't yet gotten used to having to use emacs special bindings to interact with those buffers rather than what I'd use if I'd just invoked the command from a terminal.
• I noticed that emacs automatically detects the VCS in my directory. It seems incredibly bizarre to me to interact with my VCS from my editor. Do people actually do this?
• Emacs's use of the tab character to perform code indentation is interesting. It does solve the problem of code being auto-indented when you don't want it to, which sometimes happens to me in vim, but I wonder if it actually ends up saving keystrokes in the end, since I think not auto-indenting is the exception rather than the rule for me.
• There seem to be two different methods for completion: "dynamic abbrev" expansion, which I believe is analagous to what I'm used to in vim, and M-TAB (what a horrible keybinding, as most window managers will grab this for window-switching), which seems to be some sort of language-specific completion. I haven't yet seen how this can be harnessed since the symbolic completion seems to be irrelevant for scheme.
• Emacs's syntax highlighting gets at least one thing right about scheme that vim doesn't: extended comments between # # patterns.
• Bookmarks seem waaay more verbose/awkward than vim's marks. C-x r m NAME huh? I like being able to have a very short pattern to mark and jump back to points in a file, like vim's m/ syntax for marks. Maybe I'll need to bind the bookmark functions to something else.

I'm pretty sure at this point that I'm still trying to bend emacs into being vim with different keybindings instead of figuring out how emacs wants to be used. It's also difficult to compare and contrast between the two editors in that my .vimrc contains years of tweaks and customizations whereas my .emacs started out as a clean slate. There are two things I'm doing to try to mentally separate emacs from vim, to avoid my fingers' muscle memory from becoming confused:

1. I'm always using emacs in an X window with dark-on-light text, whereas I always use vim in a terminal with light-on-dark text.
2. I'm only writing scheme in emacs. No other languages so far.

I'm planning to keep working on these programming assignments in emacs, despite it being annoying slower than I would be in vim. Tips and pointers for improving my experience are welcome.

Some of the participants of the BSP here in M nchengladbach asked me to put the blog post from blog.credativ.com on planet Debian. I think thats a great idea as the BSP was not only successfull, but also a lot of fun and it was very nice to meet a lot of Debian Developers and package maintainers. We were glad that so many people followed the invitation! So here we go - please leave your comments at the original blog post.

---

The 2010 Debian Bug Squashing Party turned out to be a great success: around 200 bugs were fixed, ready for the forthcoming version of Debian. The weekend of 22-24 January saw this year s Bug Squashing Party hosted yet again by credativ. The aim of the weekend was to find and fix bugs in the next Debian release. The results were as follows: Altogether that gives a grand total of 200 bugs. In addition, information was gathered on a further 100 bugs, which will help when they come to be fixed. A lot of time was also spent on quality assurance, an under appreciated but very important job. More gossip: it is rumoured that backports.org is not far off becoming an official Debian project and in the meantime it will be launching a brand new website running on ikiwiki. Our guests from far and wide were more than happy with the BSP party: Steve McIntyre: (Debian project leader)

Thanks to the folks at credativ for hosting and participating in the BSP - we got a huge amount of work done towards the next release and had a great time doing it!

Stefano Zacchiroli:

My 1st M nchengladbach BSP, won t be the last! Lots of cool people and hacking, and I ve enjoyed my 1st traditional Formorer s chilli too :).

credativ would like to thank all those who came and got involved - now you can lean back, relax and enjoy the photos of the event.

Yesterday I stumbled upon an interesting and broken behaviour of Django: Running two instances with the same memcached as cache backend might result in displaying the wrong template from the cache in case we have template files with the same name but a different content. This behaviour is also visible in all django applications which use the cache backend without taking care of settings.CACHE_MIDDLEWARE_KEY_PREFIX. As mentioned in the bug report a design decision is necessary here, as the setting was only supposed to be used in middlewares. On the other side not honouring the setting everywhere makes it impossible to use different (unrelated) Django instances with one memcached. While this is not such a big issue for template data, it should be - for example - possible to insert faked django CMS user permissions into memcached as they are cached there, too. One possible solution is to ensure that settings.CACHE_MIDDLEWARE_KEY_PREFIX (or a similar setting with a better name) is used for every access. Using the following snippet as custom cache backend ensures this. Additionally it is much harder to insert faked cache content by using a md5 hexdigest as key. Although you should never store sensitive data in memcached - if you need to cache such data, use locmem, file or db as cache backend, as they allow to limit access to the data properly.

from django.conf import settings
from django.core.cache.backends.memcached import CacheClass as DjangoMemcachedCacheClass
from django.utils.hashcompat import md5_constructor
class CacheClass(DjangoMemcachedCacheClass):
    def __init__(self, server, params):
        self.key_prefix = settings.CACHE_MIDDLEWARE_KEY_PREFIX
        super(CacheClass, self).__init__(server, params)
    def _genkey(self, origkey):
        return md5_constructor("%s:%s" %(self.key_prefix, origkey)).hexdigest()
    def add(self, key, value, timeout=0):
        return super(CacheClass, self).add(self._genkey(key), value, timeout)
    def get(self, key, default=None):
        return super(CacheClass, self).get(self._genkey(key), default)
    def set(self, key, value, timeout=0):
        return super(CacheClass, self).set(self._genkey(key), value, timeout)
    def delete(self, key):
        return super(CacheClass, self).delete(self._genkey(key))
    def get_many(self, keys):
        return super(CacheClass, self).get_many(self._genkey(key))
    def incr(self, key, delta=1):
        return super(CacheClass, self).incr(self._genkey(key), delta)
    def decr(self, key, delta=1):
        return super(CacheClass, self).decr(self._genkey(key), delta)

If I told you that you suffer from MEAD you might think (if you are an anthropologist like me) that you suffer from an obsession with a plump anthropologist of said name who popularized the discipline bringing home tales of Samoan teenagers who did not seem to suffer from the angst and anxiety of their American counterpart. Or you might think MASSIVE EMAIL ANXIETY DISORDER, which is a DSM diagnosis I invented last week and thus have minimized the work that the American Psychiatric Association will have to put into updating their DSM (you re welcome). So I have penned down its major characteristics and effects so that you too can identify with some other inner pathology that might mark your daily life and being (you re welcome)

The Diagnostic and Statistical Manual of the American Psychiatric Association currently defines Massive Email Anxiety Disorder (MEAD) disorder in the following way. Please note that while this definition of MEAD is the most definitive and clearly produced to date, there are several potential problems with this definition that will hopefully be addressed by the task forces, editors, and research coordinators of the association as time progresses. The Current DSM-IV Definition (Abridged): A. A persistent fear of one or more emails situations in which an author of an email worries about the status of a sent email. The individual fears that the tone or content of a message was misinterpreted or that an email never arrived to its correct destination. Alternatively, they worry excessively about why they have not received a response. B. Exposure to the feared situation almost invariably provokes anxiety, which may take the form of a situationally bound or situationally pre-disposed Panic Attack. C. The person recognizes that this fear is unreasonable or excessive. D. The feared situations are avoided or else are endured with intense anxiety and distress. Alternatively the person suffering from MEAD shuffles over to their partner or office-mate to talk (obsessively) about the nature and possible effect of the email, sometimes for hours, sometimes even for days. E. The avoidance, anxious anticipation, or distress in writing email, which interferes significantly with the person s normal routine, occupational (academic) functioning, or social activities or relationships, or there is marked distress about having the phobia. F. In individuals under age 18 years, the duration is at least 6 months. G. The fear or avoidance is not due to direct physiological effects of a substance (e.g., drugs, medications) or a general medical condition not better accounted for by another mental disorder. Problems with the DSM Definition of Massive Email Anxiety Disorder While this definition is clearly the most definitive and precise official definition produced so far, Massive Email Anxiety Disorder has only been officially recognized since 2020, and the problem did not become adequately explained until the 2015 version of the DSM. Thus, the definition of MEAD disorder is becoming clearer and more precise with each edition.

Written in honor of current revisions for the DSM, expected to be published in 2013

If I told you that you suffer from MEAD you might think (if you are an anthropologist like me) that you suffer from an obsession with a plump anthropologist of said name who popularized the discipline bringing home tales of Samoan teenagers who did not seem to suffer from the angst and anxiety of their American counterpart. Or you might think MASSIVE EMAIL ANXIETY DISORDER, which is a DSM diagnosis I invented last week and thus have minimized the work that the American Psychiatric Association will have to put into updating their DSM (you re welcome). So I have penned down its major characteristics and effects so that you too can identify with some other inner pathology that might mark your daily life and being (you re welcome)

The Diagnostic and Statistical Manual of the American Psychiatric Association currently defines Massive Email Anxiety Disorder (MEAD) disorder in the following way. Please note that while this definition of MEAD is the most definitive and clearly produced to date, there are several potential problems with this definition that will hopefully be addressed by the task forces, editors, and research coordinators of the association as time progresses. The Current DSM-IV Definition (Abridged): A. A persistent fear of one or more emails situations in which an author of an email worries about the status of a sent email. The individual fears that the tone or content of a message was misinterpreted or that an email never arrived to its correct destination. Alternatively, they worry excessively about why they have not received a response. B. Exposure to the feared situation almost invariably provokes anxiety, which may take the form of a situationally bound or situationally pre-disposed Panic Attack. C. The person recognizes that this fear is unreasonable or excessive. D. The feared situations are avoided or else are endured with intense anxiety and distress. Alternatively the person suffering from MEAD shuffles over to their partner or office-mate to talk (obsessively) about the nature and possible effect of the email, sometimes for hours, sometimes even for days. E. The avoidance, anxious anticipation, or distress in writing email, which interferes significantly with the person s normal routine, occupational (academic) functioning, or social activities or relationships, or there is marked distress about having the phobia. F. In individuals under age 18 years, the duration is at least 6 months. G. The fear or avoidance is not due to direct physiological effects of a substance (e.g., drugs, medications) or a general medical condition not better accounted for by another mental disorder. Problems with the DSM Definition of Massive Email Anxiety Disorder While this definition is clearly the most definitive and precise official definition produced so far, Massive Email Anxiety Disorder has only been officially recognized since 2020, and the problem did not become adequately explained until the 2015 version of the DSM. Thus, the definition of MEAD disorder is becoming clearer and more precise with each edition.

Written in honor of current revisions for the DSM, expected to be published in 2013

When users upgrade Firefox, they are shown a special web page after restart. As this was obviously very Firefox oriented, this was disabled in Iceweasel. Until a week ago. A week ago, I created a (quite raw) web page that users of Iceweasel 3.5.6-2 would see after they install or upgrade. The idea behind this page was suggested by Moritz Muehlenhoff during my BoF at DebConf 9, and consisted of displaying a call for help message in a splash screen. What most looked like this in Iceweasel is the Firefox feature mentioned above. I unfortunately wasn t able to implement it until now. So, a week after these pages were put online and Iceweasel 3.5.6-2 was uploaded, even though I can t say it s a huge success, it at least led to some movement: More than 12000 users (still growing) saw the pages, out of which almost 1800 (roughly 15%) followed the link for a new logo. While there was no contribution for a new logo yet, there has already been several translations contributions for the web pages, in german, spanish and italian. Next iceweasel upload will consequently send users to a localized version of the web page when it exists. The server logs also allow to have some figures on the usage of localized versions of Iceweasel, but as this is based on user agent strings, it is not totally accurate, though somehow interesting:

1. english: 58.3%
2. german: 15.2%
3. french: 7.9%
4. spanish: 3.8%
5. italian: 2.7%
6. polish: 2.5%
7. japanese: 2.2%
8. russian: 2.1%
9. portuguese: 1%
10. czech: 0.6%

Another interesting figure is that apparently 2.4% of users haven t upgraded xulrunner-1.9.1 and are not using version 1.9.1.6 with their Iceweasel 3.5.6. I m afraid of what this can mean for stable security updates, although, as being security updates, they may be followed better. Somewhere around 7% of users have, at some point, changed their user agent string to include Firefox in it, because web sites suck. This is a very interesting figure because despite that being quite significant, we haven t got that many complaints (I m not saying there weren t, but I would have expected more, considering the amount of users involved). Fortunately, this was changed recently, so all these users could reset their user agent string. And last but not least, except amd64 and x86 users, we saw 14 powerpc users and 7 arm users.

A new release of our Rcpp R / C++ interface classes is now out, the version number is 0.7.5. It comes on the heels of the release 0.7.4 and keeps with our semi-frantic schedule of releases every ten or so days going. The package is now on CRAN and Debian, and mirrors start to get the new versions. As before, my local page provides more details and Romain's blog is always worth watching too. The changes are summarised below in the NEWS file snippet, more details are in the ChangeLog as well.

0.7.5	2010-02-08
    o 	wrap has been much improved. wrappable types now are :
    	- primitive types : int, double, Rbyte, Rcomplex, float, bool
    	- std::string
    	- STL containers which have iterators over wrappable types:
    	  (e.g. std::vector<t>, std::deque<t>, std::list<t>, etc ...). 
    	- STL maps keyed by std::string, e.g std::map<std::string>
    	- classes that have implicit conversion to SEXP
    	- classes for which the wrap template if fully or partly specialized
    	This allows composition, so for example this class is wrappable: 
    	std::vector< std::map<std::string> > (if T is wrappable)
    	
    o 	The range based version of wrap is now exposed at the Rcpp::
    	level with the following interface : 
    	Rcpp::wrap( InputIterator first, InputIterator last )
    	This is dispatched internally to the most appropriate implementation
    	using traits
    o	a new namespace Rcpp::traits has been added to host the various
    	type traits used by wrap
    o 	The doxygen documentation now shows the examples
    o 	A new file inst/THANKS acknowledges the kind help we got from others
    o	The RcppSexp has been removed from the library.
    
    o 	The methods RObject::asFoo are deprecated and will be removed
    	in the next version. The alternative is to use as<foo>.
    o	The method RObject::slot can now be used to get or set the 
    	associated slot. This is one more example of the proxy pattern
    	
    o	Rcpp::VectorBase gains a names() method that allows getting/setting
    	the names of a vector. This is yet another example of the 
    	proxy pattern.
    	
    o	Rcpp::DottedPair gains templated operator<< and operator>> that 
    	allow wrap and push_back or wrap and push_front of an object
    	
    o	Rcpp::DottedPair, Rcpp::Language, Rcpp::Pairlist are less
    	dependent on C++0x features. They gain constructors with up
    	to 5 templated arguments. 5 was choosed arbitrarily and might 
    	be updated upon request.
    	
    o	function calls by the Rcpp::Function class is less dependent
    	on C++0x. It is now possible to call a function with up to 
    	5 templated arguments (candidate for implicit wrap)
    	
    o	added support for 64-bit Windows (thanks to Brian Ripley and Uwe Ligges)

As always, even fuller details are in the ChangeLog on the Rcpp page which also leads to the downloads, the browseable doxygen docs and zip files of doxygen output for the standard formats. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page

... or why I mutilated your java package in Debian This post is especially addressed to what we Debian Developers refer to as upstream maintainers, that is the people who write/maintain the software that we package for Debian. It is meant to explain why, in some cases, Debian Developers prefer to mutilate your work rather than upload it to Debian Archives in a state that gives it proper credit. And to apologize. These opinions are my own, but I have a faint feeling that I'm not the only Debian Developer working like that, and that this few words could help soothe the relation betwenn Debian Developers and Upstream Maintainers, which can be quite tense some times... It happens unfortunately quite often (too often!) that I disable (or don't enable) features in programs I package. Exact reasons vary, but they essentially fall into two categories:

• A feature requires code that does not comply to Debian Free Software Guidelines, which Debian cannot distribute. This is a no-go.
• A relatively minor feature depends on other software that are not packaged yet, and in which I don't have specific interest, which means I would not be able to maintain them properly (or it would require too much packaging work and so on...).

When a program has features which falls in one of these categories, I have two choices: either I give up packaging the software or I give up some of the features... For packages for which I care, obviously the second option looks better from my point of view as a Debian Developer. Java packages are especially affected by this problem, for a very simple reason. Java is one of the few (I don't say only because I'll probably be flamed to death) programming languages which allows very easy distribution of binary platform-independent libraries, in the form of JAR files. Many projects simply reuse and embed JAR files published for other projects in their own JAR files, often without precise references to where the source code can be found. Packaging a moderately-sized Java application often rely on dozens of embedded JARs, which we need to remove from the packages we build (as Debian does not distribute binaries without sources for many reasons), and for which we need to hunt down the original source code and often packaging the original project, which might pull in yet other dependencies and so on... A true nightmare ! That's why it is so tempting some times to simply drop some of the code, possibly write patches to disable references to removed libraries, and be done with it. Therefore, I would wish to publicly apologize to any upstream developer I've offended by stripping down apparently carelessly their beautiful software before uploading to the Debian Archives; I hope they now understand why I've done that. Note to users: it is not because one of the features of your favorite software has been disabled by its (Debian) maintainer that you need to turn away from Debian ! Rather, file a bug report against the package. You'll get the reasons why the feature was disabled, and you have a chance to convince the maintainer to switch it back on.