Now that it s much more convenient for me to do NMUs, and simultaneously there a handful of bugs that I can actually deal with, I guess it s about time I got stuck into some RC bugs. Here s my (rather modest) list of fixes for Squeeze the past few days:

• #606298 (deal.ii): can t be reproduced by two of us; closed
• #606657 (wordpress): new upstream release is a targetted fix, so applied and uploaded to DELAYED/5
  (maintainer made a proper upload shortly after)
• #606386 (cakephp): applied patch from upstream and uploaded to DELAYED/2
• #606293 (hol88): reverted the build-dependency bump on gcl and uploaded to DELAYED/5

More than two years ago, I got the most proper free mobile phone ever created, the Openmoko FreeRunner. Unfortunately, things did not go very well. At first, the device was affected by the infamous buzzing hardware issue, making it unusable as a phone. This could be fixed, but even then the device was not reliable: At times, it lost, without any indication, the GSM connection and I d start missing calls; and the audio quality was still an imposition for people trying to talk to me by telephone. I tried to stick to it for almost one year now, using it as my daily phone and hoping that things would get better, but my patience (and the patience of the people around me) have come to an end. So I m finally reviving my old and trusty Siemens S35 phone. I am eying the Nokia N900 phone, which is the most interesting phone for Free Software supporters at the time and, from what I hear, does not suffer from any of technical issues the FreeRunner had. But for now I ll be content if people can reach and hear me reliably, and for that I don t need a new, expensive phone.

platex. It's been 6th year in Tokyo Debian Meeting, 12th time to publish 'Undocumented Debian'. I'm using platex as publishing platform for that. It was like the only real choice 6 years ago. I wonder if the situation has changed.

Debian 6.0 Squeeze to be released with completely free Kernel(s) Today we have announced that, starting with the upcoming release of Squeeze, Debian will be even Free-er. Exceptions to the DFSG for non-free Linux firmware blobs, which have been granted in the past, will no longer be granted. Starting from Squeeze, Debian will be Free the bottom up, no matter where your own definition of software ends. The news has been known for a while within the Debian development community, but we had the pleasure of sharing that with our users only today. According to the reaction on identi.ca, where the news quickly made into the most popular notices, people are enthusiastic about the news and that in turn is very rewarding. If you are as happy and proud about this achievement as I am, please direct your kudos to all the teams who made this possible:

• the Debian kernel team who worked for the past 2 release cycles, together with Linux upstream, to split free-vs-non-free firmware bits and monitor new releases to avoid freedom regressions;
• the Debian CD team who basically "forked" different media production lines, for different user needs wrt firmware;
• the d-i team who added, long ago, support for loading user-provided firmware at installation time;
• whoever else I might have forgotten who contributed to this result (feel free to leave a comment to refresh my memory!).

Having been trol^W asked several times in the past about the "real freeness" of Debian at events, talks, and the like, I consider this episode to be a very nice story to tell. While we have granted exceptions for Linux firmware at the time of Etch and Lenny releases, during this time Debian people have worked, together with upstream, to make this final result possible. All this work has improved the situation not only for Debian users, but also for users of those derivatives which rely upon Debian kernels. Nonetheless, don't expect us to live under a rock. We know that there are users out there who need nasty non-free firmware bits to boot their machines or to access the Internet. That is why separate images with firmware included are being provided, although they are not part of Debian and are properly "discriminated": they should be looked for explicitly by users and can't be supported to the same extent of Free firmware, simply because we (as anybody else other than the hardware manufacturer) do not have access to the corresponding source code. This separation is a perfect example of the pragmatism embodied by the Debian Social contract: Debian consists of 100% Free software; at the same time, Debian enables its users to make their own choices in terms of Freedom, being explicit about what users risk if they cross the boundaries of DFSG. Awareness is the key here and I find it to be a very honest yet effective way of explaining to the world why Free Software is better. This is not the end of the story though, as we need to document this change properly to both increase awareness and avoid leaving users in the dark. A couple of bugs filed today might benefit from the help of some kind doc-writers: Debian bug #607191 (documenting the firmware change in the Squeeze release notes) and Debian bug #607193 (documenting the firmware change on the website).

It's them, I promise. My camera may have been drinking Maker's Manhattans when I wasn't looking. It was an awesome show -- they played all material from their new album, Never Stop. I agree with the Guardian comment about them -- "If the Coen Brothers put together a jazz trio, perhaps it would be like this..." On Saturday I also saw Bela Fleck and the Flecktones there. I don't have a crappy picture to show for it, but it was a great performance -- which included the 12 Days of Christmas performed in 12 keys and 12 time signatures (or so they claimed, I am in no position to verify that) and the surprise (to me) appearance of Alash, the Siberian throat singers.

Sorry for the triple-language post Today, Dec. 15, it's Zamenhof Day. Let's everybody celebrate Esperanto! Oggi, 15 Dicembre, lo Zamenhof Day. Festeggiamo tutti l'Esperanto! Hodia , 15-a de decembro, estas la Zamenhofa Tago. Festu iuj la Esperanton!

Being able to rebuild an existing Debian package is a very useful skill. It s a prerequisite for many tasks that an admin might want to perform at some point: enable a feature that is disabled in the official Debian package, rebuild a source package for another suite (for example build a Debian Testing package for use on Debian Stable, we call that backporting), include a bug fix that upstream developers prepared, etc. Discover the 4 steps to rebuild a Debian package. 1. Download the source package The preferred way to download source packages is to use APT. It can download them from the source repositories that you have configured in /etc/apt/sources.list, for example:

deb-src http://ftp.debian.org/debian unstable main contrib non-free
deb-src http://ftp.debian.org/debian testing main contrib non-free
deb-src http://ftp.debian.org/debian stable main contrib non-free

Note that the lines start with deb-src instead of the usual deb . This tells APT that we are interested in the source packages and not in the binary packages. After an apt-get update you can use apt-get source publican to retrieve the latest version of the source package publican . You can also indicate the distribution where the source package must be fetched with the syntax package/distribution . apt-get source publican/testing will grab the source package publican in the testing distribution and extract it in the current directory (with dpkg-source -x, thus you need to have installed the dpkg-dev package).

$ apt-get source publican/testing
Reading package lists... Done
Building dependency tree
Reading state information... Done
NOTICE: 'publican' packaging is maintained in the 'Git' version control system at:
git://git.debian.org/collab-maint/publican.git
Need to get 727 kB of source archives.
Get:1 http://nas/debian/ squeeze/main publican 2.1-2 (dsc) [2253 B]
Get:2 http://nas/debian/ squeeze/main publican 2.1-2 (tar) [720 kB]
Get:3 http://nas/debian/ squeeze/main publican 2.1-2 (diff) [4728 B]
Fetched 727 kB in 0s (2970 kB/s)
dpkg-source: info: extracting publican in publican-2.1
dpkg-source: info: unpacking publican_2.1.orig.tar.gz
dpkg-source: info: unpacking publican_2.1-2.debian.tar.gz
$ ls -dF publican*
publican-2.1/                 publican_2.1-2.dsc
publican_2.1-2.debian.tar.gz  publican_2.1.orig.tar.gz

If you don t want to use APT, or if the source package is not hosted in an APT source repository, you can download a complete source package with dget -u dsc-url where dsc-url is the URL of the .dsc file representing the source package. dget is provided by the devscripts package. Note that the -u option means that the origin of the source package is not verified before extraction. 2. Install the build-dependencies Again APT can do the grunt work for you, you just have to use apt-get build-dep foo to install the build-dependencies for the last version of the source package foo. It supports the same syntactic sugar than apt-get source so that you can run apt-get build-dep publican/testing to install the build-dependencies required to build the testing version of the publican source package. If you can t use APT for this, enter the directory where the source package has been unpacked and run dpkg-checkbuilddeps. It will spit out a list of unmet build dependencies (if there are any, otherwise it will print nothing and you can go ahead safely). With a bit of copy and paste and a apt-get install invocation, you ll install the required packages in a few seconds. 3. Do whatever changes you need I won t detail this step since it depends on your specific goal with the rebuild. You might have to edit debian/rules, or to apply a patch. But one thing is sure, if you have made any change or have recompiled the package in a different environment, you should really change its version number. You can do this with dch --local foo (again from the devscripts package), replace foo by a short name identifying you as the supplier of the updated version. It will update debian/changelog and invite you to write a small entry documenting your change. 4. Build the package The last step is also the simplest one now that everything is in place. You must be in the directory of the unpacked source package.
Now run either debuild -us -uc (recommended, requires the devscripts package) or directly dpkg-buildpackage -us -uc . The -us -uc options avoid the signature step in the build process that would generate a (harmless) failure at the end if you have no GPG key matching the name entered in the top entry of the Debian changelog.

$ cd publican-2.1
$ debuild -us -uc
 dpkg-buildpackage -rfakeroot -D -us -uc
dpkg-buildpackage: export CFLAGS from dpkg-buildflags (origin: vendor): -g -O2
dpkg-buildpackage: export CPPFLAGS from dpkg-buildflags (origin: vendor):
dpkg-buildpackage: export CXXFLAGS from dpkg-buildflags (origin: vendor): -g -O2
dpkg-buildpackage: export FFLAGS from dpkg-buildflags (origin: vendor): -g -O2
dpkg-buildpackage: export LDFLAGS from dpkg-buildflags (origin: vendor):
dpkg-buildpackage: source package publican
dpkg-buildpackage: source version 2.1-2rh1
dpkg-buildpackage: source changed by Rapha l Hertzog <hertzog>
 dpkg-source --before-build publican-2.1
dpkg-buildpackage: host architecture i386
[...]
dpkg-deb: building package  publican' in  ../publican_2.1-2rh1_all.deb'.
 dpkg-genchanges  >../publican_2.1-2rh1_i386.changes
dpkg-genchanges: not including original source code in upload
 dpkg-source --after-build publican-2.1
dpkg-buildpackage: binary and diff upload (original source NOT included)
Now running lintian...
Finished running lintian.

The build is over, the updated source and binary packages have been generated in the parent directory.

$ cd ..
$ ls -dF publican*
publican-2.1/                    publican_2.1-2rh1.dsc
publican_2.1-2.debian.tar.gz     publican_2.1-2rh1_i386.changes
publican_2.1-2.dsc               publican_2.1-2rh1_source.changes
publican_2.1-2rh1_all.deb        publican_2.1.orig.tar.gz
publican_2.1-2rh1.debian.tar.gz

Do you want to read more tutorials like this one? Click here to subscribe to my free newsletter, you can opt to receive future articles by email.

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

We've just posted a news item about the removal of non-free firmware from Debian's Linux kernel packages. Kudos to the kernel team and others for the work involved to make this happen! While we would be much happier if these binary blobs were not necessary at all, it's clear that some of our users may depend on them to support the hardware they are using. So, as mentioned in that news item, we've started making some unofficial CD images available that include the non-free firmware packages that we can redistribute. If you need one of these CDs, daily builds are to be found at http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/ . Starting with the next debian-installer release (hopefully RC1, coming soon!), we'll be generating fixed versions of these images to match each release too. Be aware that these are only netinstall images, equivalent to the normal free netinst images that we normally produce but with the firmware files added. If you want to do an installation entirely from a set of CDs/DVDs/BDs then you will need to burn one of these in addition to that set, then feed the rest of the set when prompted to by the installer.

As I'm not currently working on any suitable paper, I'll just post this to my blog so it does not completely slip off my radar ;-) Also, it might be interesting to my reader. Readers? Oh, there are two of you now? Good! Yesterday, I learnt thanks to Beatriz Busaniche that a group of South American Free Culture activists launched number zero of a magazine that promises to be very interesting: Cultura RWX, cultura en modo lectura, escritura y acci n (culture in reading, writing and action mode). Guys, best luck with this new project! Anyway, reading it, I found this asseveration I want to keep at hand:

( )cuando surge la industria musical aparecen los derechos de autor como forma de defensa de los productores musicales, espec ficamente los m sicos. No tanto frente a los usuarios, porque hasta el cassette no existi posibilidad de copiar una obra musical. Era una defensa frente a las discogr ficas, que buscaban cerrar contratos muchas veces abusivos con los artistas. M sica en Libertad: La industria musical frente al cambio de paradigma; Mat as Lennie, adaptaci n: Sebasti n Vazquez

Yes, yes, translating to English:

( )when the musical industry was born, copyright appeared as a means of defense of the musical producers, specifically of the musicians. Not so much against the users, because up until the invention of the cassette there was no possibility to copy a musical creation. It was a defense against the discographic companies, which tried to close often abusive contracts with the artists. Music in Freedom: Musical industry and the paradigm shift; Mat as Lennie, adaptation: Sebasti n V zquez

I have argued (i.e. in here) in this same line regarding the birth of copyright itself It was an arrangement that had to be made between writers and printers, back in the XVI/XVII centuries. Simple individuals were just unable to get anything of value out of the copying technology they had at hand. Copyright was born in a time where reproduction required specialized equipment. Today, massive reproduction technology is a given for a good portion of the planet's population. Copyright now only defends big corporations And will inevitably fade away as anachronic. Of course, it refuses to go without a fight... But it cannot win long-term. We cannot afford to allow it!

There s been a lot of discussion regarding whether or not Nokia is Doomed or not. The people who say Nokia are doomed basically point out that Nokia doesn t have any attractive products at the high end, and at the low end the margins are extremely thin. The high end products suffer from the Symbian being essentially dead (even Nokia is recommending that developers not develop native applications for Symbian, but to use Qt instead), and Nokia doesn t have much of a development community following it, and it certainly does have much in the way of 3rd party applications, either targetting Symbian or Qt at the moment. So what do I think of the whole debate between Tomi and Scoble? First of all, I think there is a huge difference in American and European assumptions and perspectives, and a big question is whether the rest of the world will end up looking more like Europe or America vis-a-vis two key areas: cost of data plans, and whether phones become much more application centric. Tomi took Apple to task in the comments section of his 2nd article for not having an SD card slot (how else would people share photos with their friends?) and for not supporting MMS in its earlier phones. My first reaction to that was: Um, isn t that what photo-sharing sites are for? Is it really that hard to attach a photo to an e-mail? And then it hit me. In Europe, data is still like MMS a few years ago a place for rapacious carriers to make way too much money. Many European telco s don t have unlimited data plans, and charge by the megabyte and even if you re lucky enough to live in a country which does have an American-like data plan, the cost of data roaming is still incredibly expensive. In contrast, in the US, I can pay $30/month for an unlimited data plan, and I can travel 2000 miles south or west and it will still be valid. Try doing that in Europe! The US had consumer-friendly data plans much earlier than Europe did, and so perhaps it s not surprising that Nokia has engineered phones that were far more optimized for the limitations caused by the Europe s Wireless carriers. The second area of debate where I think Scoble and Tomi are far apart is whether phones of the future are fundamentally about applications or well, making phone calls. Here I don t have proof that this is a fundamentally European vs. US difference, but I have my suspicions that it might be. Tomi spent a lot of time dwelling on how Nokia was much better at making phone calls (i.e., better microphones, better radios, etc). And my reaction to that was, Who cares? I rarely use my phone for making phone calls these days! And that was certainly one of the reasons why I gave up on Nokia after the E70 its contacts database was garbage! It was OK as a phone directory, but as a place for storing multiple addresses and e-mail addresses, it didn t hold a candle to the Palm PDA. And that s perhaps the key question how much is a smart phone and about being a phone , versus being a PDA (and these days I want a cloud-synchronized PDA, for my calendar, contacts, and todo lists), and how much is it about applications? This is getting long, so I think I ll save my comments about whether I think Meego will be an adequate savior for Nokia for another post. But it s worthwhile to talk here about Tomi s comments about most smartphones being much cheaper than the luxury iPhone, and so it doesn t matter that Nokia s attempt in the higher end smart phones has been a continuous history of fail. First of all, it s worth noting that there are much cheaper Android phones available on the market today, which are price-competitive with Nokia s low-end smartphones (i.e., available for free from T-Mobile in the States with a two year commitment). Secondly, the history in the computer market over the last twenty years is that features inevitably waterfall into the cheaper models, and prices will tend to drop over time as well. Apple started only with the iPod, but over time they added the iPod Nano and the iPod Shuffle. And it would not surprise me if they introduce a lower-end iPhone as well in time as well. It would shock me if they aren t experimenting with such models even as we speak, and have simply chosen not to push one out to the market yet. So even if you buy Tomi s argument that the high-end smartphones don t matter, and you only care about volume, and not about profit margins (talk to the people at Nokia that will need to be laid off to make their expenses match with their lowered revenue run rates; I bet they will care), the question is really about whether Nokia has time to execute on the Meego vision before it s too late and the current application-centric smartphone ecosystems (Android and iPhone) start eating into the lower-end smartphone segment. More on that in my next post. No related posts.

There s been a lot of discussion regarding whether or not Nokia is Doomed or not. The people who say Nokia are doomed basically point out that Nokia doesn t have any attractive products at the high end, and at the low end the margins are extremely thin. The high end products suffer from the Symbian being essentially dead (even Nokia is recommending that developers not develop native applications for Symbian, but to use Qt instead), and Nokia doesn t have much of a development community following it, and it certainly does have much in the way of 3rd party applications, either targetting Symbian or Qt at the moment. So what do I think of the whole debate between Tomi and Scoble? First of all, I think there is a huge difference in American and European assumptions and perspectives, and a big question is whether the rest of the world will end up looking more like Europe or America vis-a-vis two key areas: cost of data plans, and whether phones become much more application centric. Tomi took Apple to task in the comments section of his 2nd article for not having an SD card slot (how else would people share photos with their friends?) and for not supporting MMS in its earlier phones. My first reaction to that was: Um, isn t that what photo-sharing sites are for? Is it really that hard to attach a photo to an e-mail? And then it hit me. In Europe, data is still like MMS a few years ago a place for rapacious carriers to make way too much money. Many European telco s don t have unlimited data plans, and charge by the megabyte and even if you re lucky enough to live in a country which does have an American-like data plan, the cost of data roaming is still incredibly expensive. In contrast, in the US, I can pay $30/month for an unlimited data plan, and I can travel 2000 miles south or west and it will still be valid. Try doing that in Europe! The US had consumer-friendly data plans much earlier than Europe did, and so perhaps it s not surprising that Nokia has engineered phones that were far more optimized for the limitations caused by the Europe s Wireless carriers. The second area of debate where I think Scoble and Tomi are far apart is whether phones of the future are fundamentally about applications or well, making phone calls. Here I don t have proof that this is a fundamentally European vs. US difference, but I have my suspicions that it might be. Tomi spent a lot of time dwelling on how Nokia was much better at making phone calls (i.e., better microphones, better radios, etc). And my reaction to that was, Who cares? I rarely use my phone for making phone calls these days! And that was certainly one of the reasons why I gave up on Nokia after the E70 its contacts database was garbage! It was OK as a phone directory, but as a place for storing multiple addresses and e-mail addresses, it didn t hold a candle to the Palm PDA. And that s perhaps the key question how much is a smart phone and about being a phone , versus being a PDA (and these days I want a cloud-synchronized PDA, for my calendar, contacts, and todo lists), and how much is it about applications? This is getting long, so I think I ll save my comments about whether I think Meego will be an adequate savior for Nokia for another post. But it s worthwhile to talk here about Tomi s comments about most smartphones being much cheaper than the luxury iPhone, and so it doesn t matter that Nokia s attempt in the higher end smart phones has been a continuous history of fail. First of all, it s worth noting that there are much cheaper Android phones available on the market today, which are price-competitive with Nokia s low-end smartphones (i.e., available for free from T-Mobile in the States with a two year commitment). Secondly, the history in the computer market over the last twenty years is that features inevitably waterfall into the cheaper models, and prices will tend to drop over time as well. Apple started only with the iPod, but over time they added the iPod Nano and the iPod Shuffle. And it would not surprise me if they introduce a lower-end iPhone as well in time as well. It would shock me if they aren t experimenting with such models even as we speak, and have simply chosen not to push one out to the market yet. So even if you buy Tomi s argument that the high-end smartphones don t matter, and you only care about volume, and not about profit margins (talk to the people at Nokia that will need to be laid off to make their expenses match with their lowered revenue run rates; I bet they will care), the question is really about whether Nokia has time to execute on the Meego vision before it s too late and the current application-centric smartphone ecosystems (Android and iPhone) start eating into the lower-end smartphone segment. More on that in my next post. No related posts.

Today, Oracle have uploaded version 1.0.4 of its PDF Import Extension to the OpenOffice.org extension repository. The repository have had version 1.0.1 for the last year under Sun s branding. The extension is the 3rd most popular in the extension repository with just over 3,000,000 downloads in 2010. An improvised changelog would be issues #90800, #106853, #109406 and #110871. The major change for me is the addition of Hebrew support (and probably other RTL languages). With the new version, Hebrew is imported correctly and not in a reversed order. The Hebrew support was done by Tk Open Systems which sent the original patch, later to be improved by Philipp Lohmann from Oracle (see #90800 for more info). More work is still needed (see #115184), but this version is a big step forward. After doing some QA and checks for Philipp s code fixes back in October, it s nice to see the results released and to have others enjoy them.
Filed under: Openoffice.org Tagged: openoffice

A new package RcppDE has been uploaded in a first version 0.1.0 to CRAN. It provides differential evolution optimisation---a variant of stochastic optimisation that is similar to genetic algorithms but particularly suitable for the floating-point representations common in numerical optimisation. It builds of on the nice DEoptim package by Ardia et al, but reimplements the algorithm in C++ (rather than C) using a large serving of Rcpp and RcppArmadillo. I worked on this on for a few evenings and weekends in October and November and then spent a few more evenings writing a paper / vignette (which is finished as a very first draft now) about it. This was an interesting and captivating problem as I had worked on genetic algorithms going back quite some time to the beginning and then again the end of graduate school (and traces of that early work are near the bottom of my presentations page). So what got me started? DEoptim is a really nice package, but it is implemented in old-school C. There is nothing wrong with that per se, but at the same time that I was wrestling with GAs, I also taught myself C++ which, to put it simply, offers a few more choices to the programmer. I like having those choices. And with all the work that Romain and I have put into Rcpp, I was curious how far I could push this cart if I were to move it along. I made a bet with myself starting from the old saw shorter, easier, faster: pick any two. Would it be possible to achieve all three of these goals? DEoptim, and I take version 2.0-7 as my reference point here, is pretty efficiently yet verbosely coded. Copying a vector takes a loop with an assignment for each element, copying a matrix does the same using two loops. Replacing that with a single statement in C++ is pretty easy. We also have a few little optimisations behind the scenes here and there in Rcpp: would all that be enough to move the needle in terms of performance? And the same time, DEoptim is also full of the uses of the old R API which we often point to in the Rcpp documentation so fixing readibility should be a relatively low-hanging fruit. To cut a long story short, I was able to reduce code size quite easily by using a combination of C++ and Rcpp idioms. I was also able to get to faster: the paper / vignette demostrates consistent speed improvements on all setups that I tested (three standard functions on three small and three larger parameter vectors). More important speed gains were achieved by allowing use of objective functions that are written in C++ which again is both possible and easy thanks to Rcpp. That leaves easier to prove: adding compiled objective functions is one indication; further proof could be provided by, say, moving the inner loop to parallel execution thanks to Open MP which I may attempt over the next few months. So far I'd like to give myself about half a point here. So not quite yet shorter, easier, faster: pick any three, but working on it. Over the next few days I may try to follow up with a blog post or two contrasting some code examples and maybe showing a chart from the vignette.

Anna visited the Hollow a month ago and blogged a "tour of an underground solar house". She was quietly taking pictures the whole time, and I'm atonished how well they capture the place. I was honored to be the first in Rapha l Hertzog's series of Debian developer interviews. My interview -- the others he's done since seemed better to me. I was pleasantly surprised to open Linux Weekly News this week and see an in-depth article about git-annex. LWN's well-researched content continually impresses. Finally, I was indirectly mentioned in November's Science magazine. I'll leave you to guess which of the articles is the one I influenced.

It's been an intense couple of days out at the Hollow. Did it only start to snow yesterday? It feels like a long time in winter. Yesterday was the first day that the solar panels produced no power, it was too cloudy and snowing most of the time. I cleaned an inch of slushy snow off the panels to no avail, and wondered if the power would last. But the wood stove has kept it nice and warm, so yesterday was spent cosily in the living room enjoying the snowfall, nethack, and podcasts. Also, I'm very much enjoying cooking on the wood stove. I've never been in a position to cook on one before; when I lived at Wortroot the stove was in the cabin, and the cold kitchen in a different building. So cooking on the stove, or even keeping a kettle on, was mostly only done in emergencies. Here, I am constantly using it, and the propane stove is still on its first 20 pound tank. Long slow cooked beany or roastish stuff does especially well. Yesterday I did a great pork loin roast with homemade quick sauerkraut. Today, after cleaning another 3 inches of snow off the solar panels, and scraping off a layer of ice, I am getting a decent amount of power for a cloudy day with some snow still falling. Turns out it was good I cleaned them yesterday after all, since a part I missed has a inch+ layer of hard ice, which I don't dare chip away at for fear of damaging the panels. I'd not want to live someplace where it snowed a lot with solar panels that didn't have some kind of a heating system. I wish I had a camera to show the long walk down the driveway, through the winter woods, and past the field where the wind blows gusts of snow into the air. But my cell phone is on a Caribbean cruise. I have been recording data ever since the fall equinox, and it's almost to the winter solstice now. Time to geek out with some graphs! Solar production has surely been falling off with the waning days, but it seems like it will get through the shortest day with enough, and from then on, no worries.

Highest watt production seen each day I've been here.
Zero all day yesterday.

Power system voltages.
Charge controller limits it to a maximum of 15 volts during the day.
Originally, it was limiting it to 13 volts.

Last week I attended the WebKitGTK+ 2010 hackfest. It was a great opportunity to meet up with the other developers, discuss some plans for the future, hack away at WebKitGTK+. But, most importantly, play Street Figher 2 =). Thanks to Collabora and Igalia for sponsoring the hackfest, Igalia for hosting and organizing it (well done!), and the GNOME foundation for having sponsored my trip to Coru a! Unlike last year we didn t find any big design issues hurting our work (page cache, I m looking at you!) on new futures. I also didn t have any huge plans for new API, although we did manage to get some new stuff in there, like the plugins management API Xan created, and the further work done by Dan in soup. This meant, from my point of view the hackfest has been a great oportunity to look at refactorings that we could do to further simplify understanding the code, changing it, and even sharing it =). Besides pushing the debian packaging of the 1.3.x series a bit further. Coru a was great as always, and I enjoyed going around, eating and hacking there, although I got a cold on the last days which kinda hindered my ability to stare at the screen for too long, some times. Now that I m at the hot brazilian summer again I ll hopefully get better soon =) Cheers \o/

So, last week I bricked a device and I think I can fix it over a RS-232 cable from a borrowed Windows computer. However, I don t have the right cable in my office and the Windows computers I can borrow no longer have old-style serial ports. So I had two choices:

1. Order a USB-serial converter and the right cable from an online supplier and pay a premium for next-day delivery (so it doesn t arrive when I m on the trip);
2. Make a half-hour detour on a trip two days later to visit a high street electronics store and pay fairly high prices (like three times the online price).

Of course, I ordered online. And that s where the trouble started. My order was sent by Initial Citylink, who make Parcelfarce look good. Next day came and went with no delivery. About 2pm, the parcel s web page changed to say There was no one to receive the goods at the delivery point so a card was left and that it would be delivered today, Monday. Of course, there had been someone here all day and no card was left. Phoning Citylink gets a recorded message saying they re too busy to take calls. No offer to call me back. Just suggests trying the useless website. Over the weekend, the page changed again. Now it says Thank you for your rescheduling request. Your parcel(s) will be delivered on Tuesday 14th December between 07:30 and 17:30 . I didn t request that, I don t know who did and there s no way to tell from the web page. There s no way to undo that request and ask for it to be delivered on Monday instead. I wanted the device fixed by today if possible. Now I m going to have to bodge something together from spares (for once I m glad I have a cupboard of old kit here ). Still no answer from Citylink s phones and the supplier doesn t seem to know what s going on either. I m not paying for next-day delivery from anyone who uses Citylink again.

Back in April, I wrote about Jacob and I building his first computer together and how it s running just the Linux command-line interface no graphics at all. And he loves it. Well, as is often the case with him, his interest in various things waxes and wanes over time. He hadn t spent much time with his computer lately, until I suggested he try it one day. He did, and rediscovered sl (a simple program that draws an animated steam locomotive using ASCII characters) again. I showed him how to string sl commands together with the semicolon to get lots of trains, and he loved that. Since then, he s discovered that the up arrow accesses bash history and saves him typing. But more impressive, the other day while I was at work, he was playing with his computer and it looked to him like it had locked up. (I believe he had hit Scroll Lock from talking with Terah.) He was fussy and bothered by that, but then decided he could fix it. He pushed to power button to turn it off, waited for it to shut down, then turned it back on. And logged himself back in. And got right back to his steam locomotives. I run Linux, so he had never been exposed to a power cycle as a troubleshooting mechanism. You re looking at one very impressed dad. And perhaps another future Debian developer?

Someone recently pointed me to some economic/statistical models that were designed for eviews (a proprietary tool). They were looking for help converting the model into a format that could work with gretl (the Gnu Regression, Econometrics and Time-series Library). I'm afraid i'm an economics dunce, and i have no experience with this stuff. Any pointers?Tags: conversion, economics, gretl

as pointed out by Tolimar the number of RC bugs is decreasing. here's the list of my small contributions (which includes also one bug I've caused *cough*).

• #603036 lvm2: "lvm2: fails to install due to incorrect dependencies in init.d LSB header"
  update bug information, test solutions
• #603407 gearman-server: "gearman-server: Server hangs when job is submitted"
  investigate, tag unreproducible, lower severity (pkg-perl)
• #603429 hylafax-server: "hylafax-server: prompting due to modified conffiles which where not modified by the user"
  send new patches, later upload to DELAYED/2
• #604221 hylafax-server: "hylafax-server: installation fails"
  send another patch, later upload to DELAYED/2
• #604225 mailscanner: "mailscanner: installation fails"
  test for existence of /dev/tty in maintainer scripts, upload to DELAYED/2
• #604975 fractxtra,xfractint: "xfractint and fractxtra: error when trying to install together"
  update bug information, later fixed by maintainer
• #605136 python-apt-common: "python-apt-common: fails to install, trying to overwrite other packages files"
  add Replaces in debian/control. upload to DELAYED/2. later overridden by maintainer upload
• #605565 gnustep-base-runtime: "gnustep-base-runtime: unremovable if the daemon is not running"
  sponsor maintainer upload
• #606000 libmail-spf-query-perl: "libmail-spf-query-perl: Incorrect query results with IPv6 addresses; should warn about missing IPv6 support and/or fail graciously"
  investigate (pkg-perl)
• #606802 bacula-director-pgsql: "bacula-director-pgsql: make_catalog_backup is broken"
  investigate and make a proposal

squeeze is getting closer :)