Bdale is a long-time Free Software believer, he has been contributing even before Debian existed in the prehistoric era of free software. Anyone who went to a big Free Software conference has seen one of his colorful t-shirts. Or maybe you have heard the story where he got his beard shaved by Linus Torvalds to raise funds to protect the Tasmanian Devil. More seriously Bdale has played and continue to play a number of important roles in the Debian community. He also represents one of the biggest corporate sponsors (both for DebConf and for the servers that Debian owns): Hewlett Packard. My questions are in bold, the rest is by Bdale. Who are you? I made my first personal contribution of source code to what we now call Free Software in 1979. I started with HP in 1986 and for nearly a decade have served the company as Chief Technologist for Open Source & Linux. I am president of Software in the Public Interest, which is the umbrella organization providing legal and financial existence for Debian in the USA. I also represent users, developers, and Debian interests on a number of boards including at the Linux Foundation and the Freedombox Foundation. I m happily married with two children. Many people in Debian have met some or all of my family. They all joined me for Debconf in Edinburgh, and my daughter Elizabeth also attended in Caceres and New York. I joined Debian in 1994. I ve been responsible for a number of packages essential to our base system continuously since that time. But I ve also contributed to the project in many other ways over the years. I ran the first server that was fully dedicated to Debian. Ideas of mine influenced the development of project infrastructure, from the early design of our mirror network to structuring the archive around a package pool . I started or made significant early contributions to 5 ports of Debian to non-i386 architectures. I served as Debian Project Leader (DPL) in 2002-2003, was acting Secretary for a while, and have served on the Technical Committee for a number of years. Over the years, I ve also had some interesting hobbies. I helped design, build, and program pieces of various amateur radio satellites. I enjoy making physical things, and have many tools for working in wood and metals. My son and I are very active in the world of high power model rockets. And with my partner (and fellow Debian developer!) Keith Packard I m now running a small business making and selling open hardware and open source avionics for hobby rockets. You can read more about that at http://altusmetrum.org. You re the chair of the Debian technical committee. Can you quickly explain the role of this committee? I think many people assume the Technical Committee has a larger role in Debian than it really does. Section 6 of Debian s constitution defines the official role of the Technical Committee. Most importantly, the committee exists as a last resort place to resolve technical conflicts between Debian developers that they are unable to resolve by themselves. Most of the power in Debian is left in the hands of individual developers, who are usually able to collaborate with each other to make good technical decisions. So the Technical Committee s resolution process has only rarely been needed, which I think is a very good thing. From my point of view, the technical committee is not working. In many cases, the committee does not take any (timely) decision and just waits until the underlying situation has evolved to a point where the intervention of the committee is no longer needed. Do you agree with this and how can you explain it? I think it s very important for all of us to remember that everyone working on Debian does so voluntarily, and people who volunteer their time generally deserve a measure of respect and appreciation for their efforts. No issue is brought to the Technical Committee unless resolving it is expected to be really difficult, or at least contentious. And often, the issues brought to the committee have been as much or more about personality than technology. That makes some of them really hard to solve. So I do not agree that the technical committee is not working. It seems to me that the decisions that bog down and take a long time are the ones where arguments start out or become emotional instead of technical. In this context, if committee members can help lead public and private discussions in a way that causes a situation to evolve to the point where a decision is no longer needed, that may be healthier for the project in the long term than a quick vote that satisfies some contributors at the expense of others. The last important change that was made to try to revive the committee was the addition of two new members (Don Armstrong and Russ Allbery). Is there anything else that could be tried? The biggest improvement I could personally wish for is something people sending issues to the committee can help with. As the ultimate technical decision making body for a project whose output is mostly software, the more a request can be put in terms of a decision about source code, the easier it will be for us to make a decision. That won t always be possible, but when we re forced to try and dream up alternatives and then figure out whether anyone would actually be willing to write the code to implement those alternatives, the process takes a lot longer than choosing between competing patch sets or deciding whether a patch should be included. Besides your role in the technical committee, you have held the role of mediator/facilitator/advisor on numerous occasions. Because you re an old wise bearded guy who travels a lot and knows many Debian contributors I would like to thank you for all this work that few people notice. Are there been times where this has been a real burden for you? Thank you for mentioning this. I ve put a lot of my heart into Debian over the years, largely because it s a project and a community that continues to amaze and inspire me. I feel fortunate to have been able to meet and work on Debian with so many outstanding people from around the world. Many are now my friends, with all the silly and serious things being a friend implies. I ve been asked for and have given advice many times. I ve helped celebrate birthdays, marriages, new jobs, and the arrival of children. Sadly, I have also found myself having to try and find the right words to mark the loss of some of these friends The only time any of this feels like a burden is when there s some important problem that many people care about, that I m working behind the scenes to help fix, but can t really talk about publicly without causing more harm than good. It s distressing to have people think you don t care or aren t helping, when really you re doing everything you possibly can just not in a publicly visible way. Of course I understand that this is an impossible situation. If you can t see what s happening, there s no way to know if something is happening or not. That s why I advocate doing as much as possible in Debian, and SPI, and everywhere else I contribute in as open a way as possible. You have been Debian Project Leader and you promoted the vision of Debian as the Universal Operating System. What does universal mean for you? The biggest thing to me at the time was the idea that Debian could be anything. Those who chose to work on Debian would ultimately determine what Debian became. I also wanted to make sure we thought about as broad a set of potential users and collaborators as possible. But this vision provided a framework for pursuing a whole range of worthwhile increases in Debian s scope of utility, some of which I articulated in my DPL platforms, some others put forward. Internationalization, porting to more supported architectures, our inclusive and evolving approaches to accepting new developers and new packages, and so forth. I think this vision has served us well, and it pleases me that it has stayed a part of our collective thinking for so long. We re again in Debian s electoral period, what do you think of the work done by the current DPL? I m very happy with what I ve observed of Stefano s activities during his first year as DPL. He has an obvious enthusiasm for Debian, communicates well both in one to one interactions and in front of a crowd, and I think represents Debian very well. It is interesting that he s running unopposed for re-election this year. I choose to interpret that as evidence he s doing a good job, the project is running well, and nobody feels the need to try and take the job away From him. I m glad he s willing to continue in this role for another year. What s the most important thing that Debian should achieve in the wheezy timeframe? I don t yet have a very crisp personal wish-list for wheezy. But I would certainly like to see multiarch support finally completed! I m also very interested to see what comes from the CUT work. You have been an early supporter of multiarch , a project to allow easy installation of foreign architecture packages. It s on good track for Wheezy. Do you think it s an important milestone? My original motivation for requesting multiarch support was to enable support for 32-bit x86 binaries on ia64 Itanium systems, in the time leading up to the sarge release. I ended up creating the ia32-libs package, which I m not proud of. The emergence of 64-bit extensions to x86 (the amd64 architecture) made this a much broader issue. Today, I run a 64 bit kernel and a 32 bit user space on my notebook. There are problems with just moving entirely to 64 bit but I would like to be able to run some applications that work with large data sets in full 64 bit mode!

---

Thank you to Bdale Garbee for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

4 comments Liked this article? Click here. My blog is Flattr-enabled.

For many months I ve wondered what would happen if one completed half a census return online and half on paper. Tonight, finally, I get to find out. (for international readers: it s the night of the U.K. census, which with a little imagination has the potential for all sorts of fun.)

---

A little civil disobedience is a post from: jwiltshire.org.uk Flattr

Well, three months in and still going. It's getting harder to find things around the house to photograph when I don't get the chance to get outside with my camera. This image was shot in my makeshift home studio ( bedroom ) using only the light from the large window. If anyone is interested I may post some behind the scenes shots next time.

I have uploaded GnuTLS 2.12.0 to experimental. Please test.

• Ben Hutchings reported that older Lenny CDs do not actually install anymore. As we are still telling people that they don't need to throw away old CDs this was a tad disappointing to me. Got myself a 5.0.0 disc through jigdo and cdimage's fine snapshot service for packages that aren't actually in (old)stable anymore. Using a network mirror during installation is apparently the default (although you can decline it). Doing so will try to go to the security mirror and try to upgrade the base installation it just expanded from the debs on the CD. As the archive signing key changed recently, this leads to apt moaning about untrusted packages, which isn't actually exported to the debian-installer UI. The installation just hangs in "Select and install software" with a prompt being displayed on tty4. Mark Hymers agreed that it makes sense to switch the Release signature for lenny-security back to the old key for the time being and called for objections on debian-devel. Doing so should fix installation for oldstable users with old CDs again. In the future d-i should upgrade debian-archive-keyring first before the security archive's contacted and I've filed a bug report about that (#619751).
• Closed some old crufty bug reports on the pseudo package buildd.debian.org that were either already solved or easy to solve. (#607619, #602841, #586882, #520479, #507153, #605285)
• Scripted the generation of keys to get the initial batch of them done. 27 machine keys have been generated so far, with the exception of some machines that are currently down or lack entropy (like the kfreebsd-* ones which aren't fed by the keys). The keys are already activated on the archive side. s390, half of powerpc and some amd64 already run with autosigning turned on. armel will follow tomorrow thanks to Riku Voipio. We'll get more coverage soon, I bet.
• Fixed up retry as an answer to the build log. There are two possible actions that a buildd admin can do when he received a log: retry and give-back. The former will cause a build retry on the same buildd it was tried before. The latter will give it back to wanna-build to reschedule it. Due to the way retry is implemented you cannot retry binNMUs, though. There's #524547 filed against buildd about that. (There's still no support to schedule a build on a specific set of buildds neither.)
• Fixed up a typo in the wanna-build trigger for the main archive that caused double builds when we manual re-run it instead of being pushed by the archive.
• Thought about how to use Packages-arch-specific properly from WB::QD (our Perl-ish quinn-diff replacement). Currently the handling of annotations like "!linux-any" is broken because the logic does not account for architecture wildcards (besides of "any" which is special ). Luckily there's some sort of test suite, which I already adapted locally, but the code isn't really the best to read at the moment. So that's still on my to-do list to solve #603762.
• There's a post on arch:all autobuilding not happening just yet pending in the queue. I hope to get it out tomorrow or the day after.

I m online again. (In case you didn t notice, duh ) Seems as if we (the Telco/ISP guy and me) just needed to look at it hard enough for it to go away first he could dial in, using my account data, which I probably should change now, then herc with ppp(8) and pppoe(8) was working (although at about 50 KiB/s down, he showed me 508 KiB/s a rate I had never achieved with his WiXP), then I took my notebook, which worked with pppoe(4). Now herc s working again. (Maybe altq(9) can explain the slowdown? Hm, from debian.netcologne.de I get 500 so it looks okay.)
But eurynome isn t, oh the joy. Luckily, gecko2 who administers its host system just woke up. Things we do want to see: the Telco/ISP guy accepting that I run MirBSD on a P-233MMX box with Hercules graphics card and a 9 monitor with no comment other than considering its age (and that it usually runs 24/7) as partial cause for the bug. Thanks, Netcologne! Things we don t want to see:
Mar 26 10:40:02 blau /bsd: signal 11 received by (screen:16857) UID(2999) EUID(2999), parent (screen:19111) UID(2999) EUID(2999)
Suddenly the Dungeon collapses!! - You die... (luckily, I get it about once a year only) ObCoffeeSpices: Marrakech (Cumin, Allspice, Cumin Aroma) though, due to its relative strength compared to the others, the only coffee spice I have left. And another hint: pre-warming the coffee cup with hot water, so it doesn t cool down too fast with the amounts of milk I put in, rocks. I just wore the Squeeze Release (FOSDEM, Spacefun) T-Shirt to the bakery and got asked by a neighbour: Oh, a Debian fan? Developer, even now imagine the typical informed interested guy talk for a conference booth of your OS of choice here. How proud he was to get his wife and himself Windows -free at home; how he likes to tinker a bit (if he s got any time left), which has become harder with Windows; how his time constraints have him at OpenSuSE currently but asked how squeeze is; and the usual complaints at places like $ork where they have to use Windows and MSIE (apparently you can t centrally manage Firefox, eh, good someone tells me, because that s what we do ). Wow. Anyway, it s spring, so people, wear your shirts. (Hrm, what do I make of the fact that this is my only Debian shirt although I m thinking how to get Tartan Trousers if money were no issue and nobody had ever commented on my various BSD, FOSDEM, FrOSCon, etc. wear )

And here we are again. And we still have energy for one more day (and a half). Barely, but still. And it is actually looking good, we do think we will have a working archive when we are leaving here tomorrow at noon. And compared to last year we won t even need a session until 3AM to make this work (and still have half of the tools not working). Yay. Yesterday had Ansgar fixing up various issues until we set him onto Generate Packages/Sources files out of the database . Which got us some funny quotes later on, like are 3.6 seconds to write a Sources file ok or too slow? (compared to the roughly 90 seconds it takes today). Torsten had various bugfixes (as we all, somehow there is never an end of them) and is currently looking at DSUS , which is the result we got out of a GSOC project. Mark tried to continue the multi-archive stuff but got distracted a lot, we regularly asked him to look at other items and then we also made him restart all the thoughts on it by slightly redefining the parameters for the multiple archives. I myself continued with shell scripting around the buildd autosigning and today I take to check up on all our cronjobs (besides unchecked/dinstall which we know do work) to ensure we can turn them back on starting this afternoon.

A meme that keeps going around is that Asperger Syndrome (AS) is somehow universally good. The DSM doesn t list things that are beneficial, so any diagnostic criteria has to be for something that has some serious down-sides even if there are positive aspects to it. Of course on the Internet the debate won t just end there.Positive Aspects of ASThe main positive aspect of AS is intense concentration on topics of Special Interest, if a Special Interest is something that is related to a high paying job (such as computer programming) then that s a really good thing. Of course a Special Interest that isn t related to well paid employment or for which most people get paid little and only a lucky few get paid really well (such as music) isn t going to be a good thing by objective criteria.It seems that most people on the Autism Spectrum have sensory advantages over Neuro-Typical people (NTs). Better vision and hearing are quite common. It s good to be able to notice small and quiet things that most people miss, but that s not a benefit that most people seem to particularly desire. The down-side is that loud sounds and bright lights are more unpleasant and it s easy to be distracted by things that other people won t notice.The desire to give lectures has obvious benefits for any profession where giving lectures is a large part of the work, this is one reason why so many Aspies end up in academic careers. The down-side is that this is usually combined with a lack of ability to recognise when people aren t interested in receiving a lecture.Things can work out quite well for people on the Autism Spectrum who have a special interest that relates to a well paying career, who don t have any problems that prevent them from getting and keeping a job.Neutral Aspects of ASOn forums some Aspies report that they don t want to have friends, presumably their needs for friendship are met by the interaction with other forum members. As far as I can determine they are happy like that. I m sure that such people are a lot happier than people who want friends and don t have any.The incidence of asexuality among Aspies is apparently a lot higher than among the general population (something like 30% vs 1%). This isn t a bad thing for those people (I am not aware of any evidence to suggest that asexuals are less happy than people with average sexual desire), but it is evidence to suggest that Aspies are not the next stage in human evolution.Negative Aspects of ASThe DSM-IV diagnostic criteria for AS has as section C The disturbance causes clinically significant impairment in social, occupational, or other important areas of functioning , in the proposed changes for DSM-V it s merged into Autistic Disorder with section D being Symptoms together limit and impair everyday functioning [1]. These seem like clear disadvantages, it doesn t seem possible to be diagnosed as being on the Autism Spectrum without having some real disadvantage.Autism Spectrum Disorders (ASDs) seem to usually be correlated with Sensory Processing Disorder. Symptoms of SPD can include a lack of tolerance for noise, lights, certain types of clothing, dirt, and lots of other things as well as being physically clumsy. SPD is not in the diagnostic criteria for any ASD but it seems that most people on the Spectrum experience it to some degree and many regard it as the worst down-side of Autism.Spiritual Aspects of ASI ve seen a claim that AS gives them some advantage over NTs in terms of spiritual development. When someone manages to prove that their God exists or whatever other supernatural belief they have is based on fact then I ll consider this possibility.I think it s worth noting however that most religions seem to place some emphasis on humility, that seems to go against claiming that one s neuro-type is genetically predisposed to being successful at religion.ConclusionThere are many positive, neutral, and negative aspects of AS that I didn t list, I only mentioned some of the more common ones. How the positive and negative aspects compare differs on an individual basis, some people seem to be better off by objective criteria. But it seems that the best outcome is to have a different life experience that isn t objectively worse, which usually seems to involve a career in computers, science, engineering, or academia.Really if we were better then the Neuro-Typical people (NTs) would envy us, and I haven t seen much evidence of that. The NTs who do think that AS is a good thing seem to have little knowledge of AS.

• [1] http://www.dsm5.org/ProposedRevisions/Pages/proposedrevision.aspx?rid=97

Proposals for autosigning were floating around for quite some time. The most controversial parts were how we secure the machines that do the building (and in turn: how do we secure the key) and who's going to manage the keyring (because there are multiple teams involved; such discussions can indeed take quite a bit time).

What we've agreed upon now is as follows:

• All buildds with autosigned must be debian.org machines, which means that they are administrated by the Debian Sysadmins. This involves regular upgrades of the machine, firewalling and monitoring. They are all doing this already (kudos!), so there was no change needed.
• The machines must be restricted so that only a limited set of people may access it. That's done, it's just the buildd admins for the specific buildd and the global group builddadm (plus the admins and the local admin, of course).
• Every host has its own GPG key. Key generation locally on the buildds is eased by having the fine Entropy Key hooked up to provide entropy centrally and distributed to the debian.org machines. Private keys don't need to and must not leave the host. The keys are rotated every 120 days, expiry dates will be used to ensure that and to remind us when rotation is due. Sadly there is no HSM involved. Given the geographic dispersiveness of the Debian infrastructure that's not done easily. Some machines (like s390 racks) would also be unable to connect local hardware.
• The keys are restricted to specific architectures. They are not able to upload any source to the archive. However every binary on the specific architecture can be uploaded using the key, there are no further restrictions on package priorities or the like. They are maintained by the wanna-build admins on ftp-master by signing the armored public keys with their personal GPG keys (instructions available on the list). Thus a trust chain is established: who added or removed which key and when.
• We plan to suppress networking in the chroot soon. This will possibly be done with unshare(1) in util-linux, as soon as we sort out proper localhost networking. This was not deemed a blocker at this point.

The RInside package makes it pretty simple and straightforward to embed R, the wonderful statistical programming environment and language, inside of a C++ application. This uses both the robust embedding API provided by R itself, and the higher-level abstractions from our Rcpp package. A number of examples are shown on this blog both here and here as well as on the RInside page; and the source package actually contains well over a dozen complete examples which cover anything from simple examples to parallel use via MPI for parallel computing. Beginning users sometimes ask about how to use RInside inside larger projects. And as I had meant to experiment with embedding inside of the powerful Qt framework anyway, I started to dabble a little. A first result is now in the SVN sources of RInside. My starting point was the classic tkdensity demo that comes with R itself. It is a good point of departure as Tcl/Tk makes it very portable---in fact it should run on every platform that runs R---and quite expressive. And having followed some of the GUI experiments around R over the years, I have also seen various re-implementations using different GUI frameworks. And so I am adding mine to this body of work: The problem I addressed first was actual buildability. For the RInside examples, Romain and I provide a Makefile that just works by making calls to R itself to learn about flags for R, Rcpp and RInside such that all required headers and libraries are found. That is actually relatively straightforward (and documented in our vignettes) but a little intimidating at first---which is why a ready-made Makefile is a good thing. Qt of course uses qmake and the .pro files to encode / resolve dependencies. So task one was to map what our Makefile does into its variables. Turns out that wasn't all that hard:

## -*- mode: Makefile; c-indent-level: 4; c-basic-offset: 4;  tab-width: 8; -*-
##
## Qt usage example for RInside, inspired by the standard 'density
## sliders' example for other GUI toolkits
##
## Copyright (C) 2011  Dirk Eddelbuettel and Romain Francois
TEMPLATE =              app
HEADERS =               qtdensity.h 
SOURCES =               qtdensity.cpp main.cpp
QT +=                   svg
## comment this out if you need a different version of R, 
## and set set R_HOME accordingly as an environment variable
R_HOME =                $$system(R RHOME)
## include headers and libraries for R 
RCPPFLAGS =             $$system($$R_HOME/bin/R CMD config --cppflags)
RLDFLAGS =              $$system($$R_HOME/bin/R CMD config --ldflags)
RBLAS =                 $$system($$R_HOME/bin/R CMD config BLAS_LIBS)
RLAPACK =               $$system($$R_HOME/bin/R CMD config LAPACK_LIBS)
## if you need to set an rpath to R itself, also uncomment
#RRPATH =               -Wl,-rpath,$$R_HOME/lib
## include headers and libraries for Rcpp interface classes
RCPPINCL =              $$system($$R_HOME/bin/Rscript -e \'Rcpp:::CxxFlags\(\)\')
RCPPLIBS =              $$system($$R_HOME/bin/Rscript -e \'Rcpp:::LdFlags\(\)\')
## for some reason when building with Qt we get this each time
## so we turn unused parameter warnings off
RCPPWARNING =           -Wno-unused-parameter 
## include headers and libraries for RInside embedding classes
RINSIDEINCL =           $$system($$R_HOME/bin/Rscript -e \'RInside:::CxxFlags\(\)\')
RINSIDELIBS =           $$system($$R_HOME/bin/Rscript -e \'RInside:::LdFlags\(\)\')
## compiler etc settings used in default make rules
QMAKE_CXXFLAGS +=       $$RCPPWARNING $$RCPPFLAGS $$RCPPINCL $$RINSIDEINCL
QMAKE_LFLAGS +=         $$RLDFLAGS $$RBLAS $$RLAPACK $$RCPPLIBS $$RINSIDELIBS
## addition clean targets
QMAKE_CLEAN +=          qtdensity Makefile

The double dollar signs and escaping of parentheses are a little tedious, but hey it works and expands the compiler and linker flags such that everything <emjust works="Works">. The code itself is pretty straightforward too. We instantiate the RInside object as well as the main Qt application object. We then instantiate a new object of class QtDensity that will launch the main widget; it is given a reference to the RInside object.

// -*- mode: C++; c-indent-level: 4; c-basic-offset: 4;  tab-width: 8; -*-
//
// Qt usage example for RInside, inspired by the standard 'density
// sliders' example for other GUI toolkits
//
// Copyright (C) 2011  Dirk Eddelbuettel and Romain Francois
#include <QApplication>
#include "qtdensity.h"
int main(int argc, char *argv[])
 
    RInside R(argc, argv);  		// create an embedded R instance
    QApplication app(argc, argv);
    QtDensity qtdensity(R);
    return app.exec();
 

The definition of the main object is pretty simple: a few private variables, and a few functions to interact with the GUI and get values from the radio buttons, slider or input field---as well as functions to update the chart or re-draw the random variables.

// -*- mode: C++; c-indent-level: 4; c-basic-offset: 4;  tab-width: 8; -*-
//
// Qt usage example for RInside, inspired by the standard 'density
// sliders' example for other GUI toolkits
//
// Copyright (C) 2011  Dirk Eddelbuettel and Romain Francois
#ifndef QTDENSITY_H
#define QTDENSITY_H
#include <RInside.h>
#include <QMainWindow>
#include <QHBoxLayout>
#include <QSlider>
#include <QSpinBox>
#include <QLabel>
#include <QTemporaryFile>
#include <QSvgWidget>
class QtDensity : public QMainWindow
 
    Q_OBJECT
public:
    QtDensity(RInside & R);
private slots:
    void getBandwidth(int bw);
    void getKernel(int kernel);
    void getRandomDataCmd(QString txt);
    void runRandomDataCmd(void);
private:
    void setupDisplay(void);    // standard GUI boilderplate of arranging things
    void plot(void);            // run a density plot in R and update the
    void filterFile(void);      // modify the richer SVG produced by R
    QSvgWidget *m_svg;          // the SVG device
    RInside & m_R;              // reference to the R instance passed to constructor
    QString m_tempfile;         // name of file used by R for plots
    QString m_svgfile;          // another temp file, this time from Qt
    int m_bw, m_kernel;         // parameters used to estimate the density
    QString m_cmd;              // random draw command string
 ;
#endif

Lastly, no big magic in the code either (apart from the standard magic provided by RInside). A bit of standard GUI layouting, and then some functions to pick values from the inputs as well as to compute / update the output. One issue is worth mentioning. The screenshot and code show the second version of this little application. I built a first one using a standard portable network graphics (png) file. That was fine, but not crisp as png is a pixel format so I went back and experimented with scalable vector graphics (svg) instead. One can create svg output with R in a number of ways, one of which is the cairoDevice package by Michael Lawrence (who also wrote RGtk2 and good chunks of Ggobi). Now, it turns out that Qt displays the so-called SVG tiny standard whereas R creates a fuller SVG format. Some discussion with Michael reveals that one can modify the svg file suitably (which is what the function filterFile below does) and it all works. Well: almost. There is a bug (and Michael thinks it is the SVG rendering) in which the density estimate does not get clipped to the plotting region.

// -*- mode: C++; c-indent-level: 4; c-basic-offset: 4;  tab-width: 8; -*-
//
// Qt usage example for RInside, inspired by the standard 'density
// sliders' example for other GUI toolkits -- this time with SVG
//
// Copyright (C) 2011  Dirk Eddelbuettel and Romain Francois
#include <QtGui>
#include "qtdensity.h"
QtDensity::QtDensity(RInside & R) : m_R(R)
 
    m_bw = 100;                 // initial bandwidth, will be scaled by 100 so 1.0
    m_kernel = 0;               // initial kernel: gaussian
    m_cmd = "c(rnorm(100,0,1), rnorm(50,5,1))"; // simple mixture
    m_R["bw"] = m_bw;           // pass bandwidth to R, and have R compute a temp.file name
    m_tempfile = QString::fromStdString(Rcpp::as<std::string>(m_R.parseEval("tfile <- tempfile()")));
    m_svgfile = QString::fromStdString(Rcpp::as<std::string>(m_R.parseEval("sfile <- tempfile()")));
    m_R.parseEvalQ("library(cairoDevice)");
    setupDisplay();
 
void QtDensity::setupDisplay(void)   
    QWidget *window = new QWidget;
    window->setWindowTitle("Qt and RInside demo: density estimation");
    QSpinBox *spinBox = new QSpinBox;
    QSlider *slider = new QSlider(Qt::Horizontal);
    spinBox->setRange(5, 200);
    slider->setRange(5, 200);
    QObject::connect(spinBox, SIGNAL(valueChanged(int)), slider, SLOT(setValue(int)));
    QObject::connect(slider, SIGNAL(valueChanged(int)), spinBox, SLOT(setValue(int)));
    spinBox->setValue(m_bw);
    QObject::connect(spinBox, SIGNAL(valueChanged(int)), this, SLOT(getBandwidth(int)));
    QLabel *cmdLabel = new QLabel("R command for random data creation");
    QLineEdit *cmdEntry = new QLineEdit(m_cmd);
    QObject::connect(cmdEntry,  SIGNAL(textEdited(QString)), this, SLOT(getRandomDataCmd(QString)));
    QObject::connect(cmdEntry,  SIGNAL(editingFinished()), this, SLOT(runRandomDataCmd()));
    QGroupBox *kernelRadioBox = new QGroupBox("Density Estimation kernel");
    QRadioButton *radio1 = new QRadioButton("&Gaussian");
    QRadioButton *radio2 = new QRadioButton("&Epanechnikov");
    QRadioButton *radio3 = new QRadioButton("&Rectangular");
    QRadioButton *radio4 = new QRadioButton("&Triangular");
    QRadioButton *radio5 = new QRadioButton("&Cosine");
    radio1->setChecked(true);
    QVBoxLayout *vbox = new QVBoxLayout;
    vbox->addWidget(radio1);
    vbox->addWidget(radio2);
    vbox->addWidget(radio3);
    vbox->addWidget(radio4);
    vbox->addWidget(radio5);
    kernelRadioBox->setMinimumSize(260,140);
    kernelRadioBox->setMaximumSize(260,140);
    kernelRadioBox->setSizePolicy(QSizePolicy::Fixed, QSizePolicy::Fixed);
    kernelRadioBox->setLayout(vbox);
    QButtonGroup *kernelGroup = new QButtonGroup;
    kernelGroup->addButton(radio1, 0);
    kernelGroup->addButton(radio2, 1);
    kernelGroup->addButton(radio3, 2);
    kernelGroup->addButton(radio4, 3);
    kernelGroup->addButton(radio5, 4);
    QObject::connect(kernelGroup, SIGNAL(buttonClicked(int)), this, SLOT(getKernel(int)));
    m_svg = new QSvgWidget();
    runRandomDataCmd();         // also calls plot()
    QGroupBox *estimationBox = new QGroupBox("Density estimation bandwidth (scaled by 100)");
    QHBoxLayout *spinners = new QHBoxLayout;
    spinners->addWidget(spinBox);
    spinners->addWidget(slider);
    QVBoxLayout *topright = new QVBoxLayout;
    topright->addLayout(spinners);
    topright->addWidget(cmdLabel);
    topright->addWidget(cmdEntry);
    estimationBox->setMinimumSize(360,140);
    estimationBox->setMaximumSize(360,140);
    estimationBox->setSizePolicy(QSizePolicy::Fixed, QSizePolicy::Fixed);
    estimationBox->setLayout(topright);
    QHBoxLayout *upperlayout = new QHBoxLayout;
    upperlayout->addWidget(kernelRadioBox);
    upperlayout->addWidget(estimationBox);
    QHBoxLayout *svglayout = new QHBoxLayout;
    svglayout->addWidget(m_svg);
    QVBoxLayout *outer = new QVBoxLayout;
    outer->addLayout(upperlayout);
    outer->addLayout(svglayout);
    window->setLayout(outer);
    window->show();
 
void QtDensity::plot(void)  
    const char *kernelstrings[] =   "gaussian", "epanechnikov", "rectangular", "triangular", "cosine"  ;
    m_R["bw"] = m_bw;
    m_R["kernel"] = kernelstrings[m_kernel]; // that passes the string to R
    std::string cmd1 = "Cairo(width=6,height=6,pointsize=10,surface='svg',filename=tfile); "
                       "plot(density(y, bw=bw/100, kernel=kernel), xlim=range(y)+c(-2,2), main=\"Kernel: ";
    std::string cmd2 = "\"); points(y, rep(0, length(y)), pch=16, col=rgb(0,0,0,1/4));  dev.off()";
    std::string cmd = cmd1 + kernelstrings[m_kernel] + cmd2; // stick the selected kernel in the middle
    m_R.parseEvalQ(cmd);
    filterFile();               // we need to simplify the svg file for display by Qt 
    m_svg->load(m_svgfile);
 
void QtDensity::getBandwidth(int bw)  
    if (bw != m_bw)  
        m_bw = bw;
        plot();
     
 
void QtDensity::getKernel(int kernel)  
    if (kernel != m_kernel)  
        m_kernel = kernel;
        plot();
     
 
void QtDensity::getRandomDataCmd(QString txt)  
    m_cmd = txt;
 
void QtDensity::runRandomDataCmd(void)  
    std::string cmd = "y <- " + m_cmd.toStdString();
    m_R.parseEvalQ(cmd);
    plot();                     // after each random draw, update plot with estimate
 
void QtDensity::filterFile()  
    // cairoDevice creates richer SVG than Qt can display
    // but per Michaele Lawrence, a simple trick is to s/symbol/g/ which we do here
    QFile infile(m_tempfile);
    infile.open(QFile::ReadOnly);
    QFile outfile(m_svgfile);
    outfile.open(QFile::WriteOnly   QFile::Truncate);
    
    QTextStream in(&infile);
    QTextStream out(&outfile);
    QRegExp rx1("<symbol"); 
    QRegExp rx2("</symbol");    
    while (!in.atEnd())  
        QString line = in.readLine();
        line.replace(rx1, "<g"); // so '<symbol' becomes '<g ...'
        line.replace(rx2, "</g");// and '</symbol becomes '</g'
        out << line << "\n";
     
    infile.close();
    outfile.close();
 

What the little application does is actually somewhat neat for the few lines. One key features is that the generated data can be specified directly by an R expression which allows for mixtures (as shown, and as is the default). With that it easy to see how many points are needed in the second hump to make the estimate multi-modal, and how much of a distance between both centers is needed and so on. Obviously, the effect of the chosen kernel and bandwidth can also be visualized. And with the chart the being a support vector graphics display, we can resize and scale at will and it still looks crisp. The code (for both the simpler png variant and the svg version shown here) is in the SVN repository for RInside and will be in the next release. Special thanks to Michael Lawrence for patiently working through some svg woes with me over a few emails.

Update: Some typos fixed.

Update 2: Two URLs corrected.

forked-daapd v0.14 is available. This release includes a number of improvements to the sort headers/sort fields handling by Kai that got entangled into a larger database revamp at the end of last year. That will be the subject of the next release. Also in this release:

• better handling of tags for TV shows
• better handling of DRM-afflicted files
• configurable IPv6 support
• fixes to the URL file scanner
• misc fixes

This release performs a heavy database upgrade process that dumps and reloads the files table; this can take some time on big libraries, so please be patient while this process takes place. You should backup your database file before upgrading, just in case. See you in about two weeks for 0.15 with some database speedups that will finally see the light :-) Tarballs available at http://alioth.debian.org/~jblache/forked-daapd/ ; GPG signatures made with my Debian key F5D65169.

Should you have thought we are gone, let me assure you - we are not. I just blog a bit later than I did the last days. Anyways, we did have a good day yesterday. Turns out that, when Ansgar said I don t know much Python so might not be able to do much he actually meant Just point me at problems, no matter how complicated, and I come up with the python code to fix them . And so we did point him at various problems and got lots of code. And we intend to continue this until Sunday. Yesterday Mark got his Packages/Sources tool so far that we are about ready to ditch the old things, even though he took time to finalize my generate-release changes too. Not to speak about that database changes I wrote about in my last entry, which he now seems to have finally wrapped his brain around in a way to get those done. Short cite: good god, this will overhaul about all our code and database handling . And thats where he is currently working on too. He did draw a plenty complicated thats how it works onto the flip chart, and now seems to dump his brain into some form of python code. I m curious about the result, lets see. Torsten fixed up the code that generated the Maintainers and Uploaders files. The old code was just plain silly and took about 15 minutes just for the Uploaders file. It is now doing both of them in less than two. Of course there had been lots of bugfixes and code enhances too, not really good to list in a blog like this. My work, besides getting a bit sick in the evening, consisted of writing shell scripts to enable us and wanna-build admins to handle the keys needed for the automated signing of packages build on DSA maintained buildds. I have those ready now, so we are able to start doing the autosign stuff today/tomorrow. Phil - well, did whatever buildd related stuff he has to. Different place, I dont see much of it, but he has a blog himself, look over there.

Having Synology diskstation, notebook with XBMC and smart phone with Symbian, it should be possible to make all these talk together being able to play music stored on the diskstation using XBMC and controlled by phone, right? I tried to set it up some time ago, but I used samba export on the diskstatio and all I found for controlling was XBMC Symbian S60 Remote v2, which is indeed useful, but choosing what to play remotely is quite limited. Luckily yesterday I've discovered world of DLNA aka uPNP and was surprised that this works pretty well. I've configured diskstation to behave as a uPHP media server, XBMC is able to act as media renderer and my Nokia E52 has ability to act as a controller. If you are lost in these terms, good overview is available here. Well the control interface of Nokia E52 is far from perfect, but still provides good way to control all the stuff. Maybe I will look for some other solution in future, I'm sure it will exist as well.

Filed under: English 2 comments Flattr this!

If you are wondering, how we will manage to have the DebCamp preceding DebConf 11 in 2009, it's quite easy: Each attendee will find a time machine in his conference back. By the way: To make that happen, the DebConf orga team is looking for help in fund raising. Please consider helping us, or we will have to cancel the time machines and fall back to the boring DebCamp directly preceding DebConf solution.

Exactly a year after I switched from pre to droid, I broke another cell phone contract. So there seem to be three fool-proof ways to get out of a cell phone contract in the US, despite all the hype about them involving signing away your firstborn.

1. Switch to a different US cell phone company, and do it by going into a store and finding a hungry salesman in person, and making his sale contingent on him finding a way to break your old contract. What I did last year.
2. Simply move to a part of the map that doesn't have cell phone coverage. (You will have seen these parts of the map from a plane.) It probably helps to have your cell phone drop off the edge of their map repeatedly for some months, presumably they can look this stuff up. Call up technical support, go thru some mild rigamarole as they try to configure your phone to magically see cell towers that have several mountains and/or the curvature of the Earth blocking line of site to you. Magic words: "please note on account: no cell service"
3. Sell your contract on one of the existing cell contract exchanges, to someone who wants cell service with a shorter than usual contract. (Means giving up your number.) I haven't tried this one, maybe next time?

Unlike my Palm Pre which didn't survive being cut off the cell net, my Android phone is still fairly happy. While I'd really like to turn it into a proper Debian box, with X etc, I may just use it as a camera, web browsing (on wifi) and emergency 911 system. Pity though about the GPS stuff needing an internet connection when the phone has many gigabytes of free space that could hold a useful map. (If you want to phone me now, the number is 1-423-IKIWIKI. I only receive voice mail, and your call data and transcript will be absorbed by the Google Borg.)

I wrote this code today to verify setup branch pushes on Branchable. When I was writing it I was just down in the trenches coding until it worked, but it's rather surprising that what it does to git does work. The following code runs in git's update hook. The fast path of the hook (written in C) notices that the user is committing a change to the setup branch, and hands the incoming git ref off to the setup verifier.

                # doing a shared clone makes the setupref, which has
                # not landed on any branch, be available for checkout
                shell("git", "clone", "--quiet", "--shared",
                        "--no-checkout", repository($hostname), $tmpcheckout);
                chdir($tmpcheckout)   error "chdir $tmpcheckout: $!";
                shell("git", "checkout", "--quiet", $setupref, "-b", "setup");

I got lucky here, since I initially passed --shared only to avoid the overhead of a clone of the site's entire git repository (which can be quite large, since Branchable doesn't have any real limits on site size). Without the --shared, the clone wouldn't see the incoming ref at all. In the setup branch is an ikiwiki.setup file, and we only want to allow safe changes to be committed to it. Ikiwiki has metadata about which configurations are safe. Checking that and various other amusing scenarios (what if someone makes ikiwiki.setup a symlink etc) takes a hundred lines of fairly hairy code, but that doesn't matter here. Eventually it decides the setup file is ok as-is, or it's already died with an error message.

                # Check out setup file in toplevel. This is slightly tricky
                # as the commit has not landed in the bare git repo yet --
                # but it is available in the tmpcheckout.
                shell("git", "pull", "-q", $tmpcheckout, "setup");
                # Refresh or rebuild site to reflect setup changes.
                print STDERR "Updating site to reflect setup changes...\n";
                shell("ikiwiki", "-setup", "ikiwiki.setup", "-v",
                        ($rebuild_needed ? ("-rebuild") : ("-refresh", "-wrappers"))
                );

When this code runs there are three repositories, each with a different view of the setup branch. The main bare repository is waiting for the hook to succeed before it updates the ref to point to what was pushed. The temporary clone has what was pushed already checked out. And the site's home directory still has the old version of the setup branch checked out. Possibly even a version that has diverged from what's in the bare repository. It's rather odd that the update hook goes and causes that latter repository to be updated, before the change has finished landing in the bare repository. But it does work; it ensures that if there is some kind of bizzare merge problem the user doing the push sees it, and I probably won't regret it. The result certianly is nice -- edit ikiwiki.setup file locally, commit and push it, and ikiwiki automatically reconfigures itself and even rebuilds your whole site if you've changed something significant.

I know this is almost a cliche, but here goes. Just to show you that it still exists. Today my car needed some work. This morning I dropped it off at the mechanic, who lives right off a well-traveled state highway. They don t have a dropbox for keys because, well, they don t need one. I left the keys in the car. They called to say that they d have to close early this afternoon, but not to worry the keys were in the car along with the bill, which I could drop by and pay or put in the family s box at church. And sure enough, the car sat there the rest of the afternoon, and until about 9:45PM, with the keys in the ignition, bill tucked in under my ham radio speaker, ready to pick up. And it wasn t at risk for being stolen. Things just sort of happen that way out here sometimes. I remember one time we were taking a train out of Newton, KS, which departs at about 3:30AM. The only other train through there departs at 3:00AM. And back then, there was sometimes no station agent on some days. We got there our usual 15 minutes before the train departed, and struck up a conversation with a couple from California. They were almost beside themselves with shock. First off, they had arrived an hour and a half early, being used to doing that for getting on planes and, apparently, trains. But what really stunned them was the fact that the station was simply left unlocked all night. There weren t any cops there, and in fact there was nobody there at all for most of the night. And yet it had no signs of graffiti, no vandalism, and no apparent concern from anybody that it was unlocked. I think they also felt unsafe, having no guards or officials present. And they were literally the only people in the station for an hour, I m sure. And sure enough, along came the train. We all heard the whistle and had our things ready to go by the time the conductor got off the train, walked into the station, announced it, and led us all out to it. 3 minutes later, we were all on our way to California and the land of, apparently, locked doors. Back in 2002, when we bought a house in Kansas, the inspector commented that none of the outside locks worked. At closing, the sellers gave us a key, commenting We never use it and it took forever to find it. I guess that s why they didn t know the locks were broken. There s something good about a setting like this. I know that my car is safe at the mechanic with the keys in it. He knows that I ll pay his bill. We all take pride in our community institutions. And besides, if anybody did try to spray some graffiti in the train station, they ll be living with people that will remember it for the next 40 years. Accountability is implicit here.

I finally found some time to convert my backport script to support squeeze (mostly because I finally did my first backport to squeeze). The script now treats squeeze as the default target and knows that it's the current stable, treats lenny as oldstable, and knows the correct version suffix to use for squeeze backports. It also now uses regular expressions to try to determine what code name a backport is targetted at, which should work better for more non-Debian internal distribution cases. You can get the latest version from my scripts distribution page.

I'm experimenting with building Qt Embedded for armel using Emdebian toolchains and Debian packaging/patches. Initially, I've just "got it to build" with a few too many things nobbled and disabled - the results (using the package from Squeeze) are in Emdebian SVN - and the next task is to enable the missing bits and get closer to the standard Qt4-X11 binaries. Certain packages will simply not exist, even when finished, but it's been fun working out how to create a qmake.conf to map the Emdebian toolchain to what Qt expects from toolchains like CodeSourcery.

If it continues to work, it may be worth pushing upstream - but it may be better to wait until Multi-Arch supports cross-building, I'd only have to submit a different qmake.conf with updated paths otherwise.

I've also got a basic qmake.conf to help Qt applications cross-build using the Emdebian toolchains. This also needs updating once we finally get Multi-Arch-Cross.

The way I see this working is that the Qt Embedded packages would have to kept entirely separate from the Debian Qt4-X11 binaries from the KDE/Qt team because they use the same package names. That's relatively simple if the embedded packages are kept for cross-building only, either as -armel-cross packages generated by dpkg-cross or (eventually) as Multi-Arch packages. What won't work is having Qt-X11 and Qt-Embedded installed on the same architecture, without using a chroot or similar.

Initially, I hoped to keep the changes small enough that the Debian package could include the tweaks in a conditional part of debian/rules via a DEB_BUILD_OPTION. The current diff is a little too awkward (mainly in the .install files) but that's still worth keeping as a goal.

No warranty, created in the hope it's useful etc. etc., nothing to say it'll build on your system, no support for anything except the Debian armel port and only tested with the Emdebian toolchains from Lenny, not coming to a distribution near you anytime soon, don't blame me if it messes up your entire Qt-X11 installation on your desktop.... yada, yada.

It's just a bit of tinkering really, although it would be more fun if Qt didn't take quite so many hours to build each time I want to test a change....