Yesterday, I finally took closer look at long standing GePeS bug on displaying speed and altitude wrongly (which I've mentioned in very first posts). For some reason I believed it is not my bug, but in QML bindings and let it be there. Receiving complain from Maarten ter Huurne, that this does not work made me look into it more deeply. Of course I found out it was caused by stupid typo and quickly fixed it. New release is now available on GePeS homepage and will be available shortly in Nokia store.

Filed under: English Meego 0 comments Flattr this!

We just released a sample chapter of the Debian Administrator s Handbook. It covers the APT family of tools: apt-get, aptitude, synaptic, update-manager, etc.

Click here to get your free sample chapter I m sure you will enjoy it. There are many interesting things to learn:

• How to customize the sources.list file
• The various APT repositories that Debian offers (Security Updates, Stable Updates, Proposed Updates, Backports, Experimental, etc.)
• How to select the best Debian mirror for you
• How to find old package versions
• How to install the same selection of packages on multiple computers
• How to install and remove a package on a single command-line
• How to reinstall packages and how to install a specific version of a package
• How to pass options to dpkg via APT
• How to configure a proxy for APT
• How to set priorities to various package sources (APT pinning)
• How to safely mix packages from several distributions on a single system
• How to use aptitude s text-mode graphical interface
• How to use the tracking of automatically installed packages to keep a clean system
• How APT checks the authenticity of packages that it downloads
• How to add supplementary GnuPG keys to APT s trusted keyring
• How to upgrade from one stable distribution to the next
• How to handles problems after an upgrade
• How to keep a system up-to-date
• How to automate upgrades
• How to find the package that you re looking for

If you liked this chapter, click here to contribute a few euros towards the liberation of the whole book. That way you ll get a copy of the ebook as soon as it s available. Thank you! I also invite you to share this sample chapter as widely as possible. We re only at 40% of the liberation fund and there s less than 2 weeks left. I hope this book extract will convince enough people that the book is going to be great, and that it really deserves to be liberated and bundled with Debian!

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

Recently my installation of Qt SDK I use for development of applications for Nokia N950 (N9) got broken. It happened by update some postinst script failed what caused almost no part of Harmattan SDK to be installed. I hoped this to be temporary error which will get fixed by later updates, but it turned out to persist even for 1.1.4 which has been released week ago. Yesterday I finally got time to look into it and after some debugging I found out that it was trying to install x86_64 version, which was not downloaded because I was using 32bit installer. I quickly realized this was caused by using 64-bit kernel, while running 32-bit userspace, for which the installer somehow was not prepared. Fortunately there is easy workaround for that:

linux32 ./Qt_SDK_Lin32_online_v1_1_4_en.run

What will run the binary in 32-bit personality and make kernel pretend it is compiled for 32-bit.

Filed under: English Meego 2 comments Flattr this!

Last Friday (11 November 2011), I was at the Cooperatives-SW annual conference at the Cube Cinema in Bristol, titled Growing Your Co-operative and sponsored by the Co-operative Membership South and West. It was another sold-out event, featuring headline talks from Co-op Party member and Labour MP Kerry McCarthy, Eli Sarre of Essential Trading worker co-op (pictured), Carole Theyer of Sparks Inc and Jim Pettipher from Co-operative Futures. There were also some great workshops I went to a finance workshop led by Ian Rothwell from Co-operative and Community Finance and a regulations one with Paul Martin of Kabin (details may appear on their event page) and a brilliant lunch from Runcible Spoon (and those of you who know me will know I have been livid with some co-op event lunches!) with some time to chat and network, although I also went to a fringe meeting about the RISE problems. The event concluded with the formal AGM of Co-operatives SW (electing a new chairperson and approving transfer to a new co-op corporation) as well as a bit more chat afterwards. I felt it was a great event and well worth my time being there. I m glad that some people from outside the co-op movement, from community businesses like the Strawberry Line Cafe and a few people considering joining or forming co-ops, were there and I hope it was good for them too.

After recently reading a number of SSL/TLS-related articles, I decided to experiment and look for the ideal OpenSSL configuration for Apache (using mod_ssl since I haven't tried mod_gnutls yet) and nginx.

By "ideal" I mean that this configuration needs to be compatible with most user agents likely to interact with my website as well as being fast and secure.

Here is what I came up with for Apache:

SSLProtocol TLSv1
SSLHonorCipherOrder On
SSLCipherSuite RC4-SHA:HIGH:!kEDH

and for nginx:

ssl_protocols  TLSv1;
ssl_ciphers  RC4-SHA:HIGH:!kEDH;
ssl_prefer_server_ciphers   on;

Cipher and protocol selectionIn terms of choosing a cipher to use, this configuration does three things:

• disables all weak ciphers and protocols
• disables very slow ciphers that use ephemeral Diffie-Hellman exchanges
• gives priority to the RC4 cipher to minimize CPU usage and defend against the BEAST attack

Testing toolsThe main tool I used while testing various configurations was the SSL labs online tool. The CipherFox extension for Firefox was also quite useful to quickly identify the selected cipher.

Of course, you'll want to make sure that your configuration works in common browsers, but you should also test with tools like wget, curl and httping. Many of the online monitoring services are based on these.

Other considerationsTo increase the performance and security of your connections, you should ensure that the following features are enabled:

• SSL session caching with a session store shared between all of your web servers
• HSTS headers to let browsers know that they should always visit your site over HTTPS

We've had sporadic Altus Metrum customer reports about RF susceptibility issues with their TeleMetrum installations. In almost every case, these problems have been completely resolved by either making sure the system battery has sufficient charge before launch, or through the application of standard engineering techniques such as twisting wire pairs to reduce differential coupling. However, even when every technique we could think of had been applied, once in a while someone still had issues. Around the time of LDRS this year, the incidence of such reports seemed to increase. One customer, in particular, had an installation in which he virtually always saw continuous resets of the board once his 54mm airframe was put on a launch rail, and several customers reported seeing board resets during ejection charge firing. Keith and I saw a board reset during main charge firing happen in person at NCR's Oktoberfest, and with a couple days available to work together after that launch, we decided it was time to figure out what was really going on. Here's what we've learned. In bench testing, it quickly became clear that the problem was the 3.3 volt power supply rail getting pulled down far enough to reset the CPU. This most frequently happened during ejection charge firing, when the input of the LDO regulator is pulled down by the near-short presented by the e-match when a pyro FET is turned on. To keep the 3.3 volt rail voltage up during firing, we include a 100uF bulk capacitor on the regulator's output. In all of our prior bench testing, we never saw the 3.3 volt rail droop significantly. Clearly something had changed... or maybe several things had changed? The first thing I wondered about was whether the new Kalman filtering code, which requires more compute cycles from the processor, might be consuming enough more power to pull the rail down faster during charge firing. After poking around at it, though, we have no data to suggest the new code makes a measurable difference in power consumption. The next thing we pondered was that at least some of the e-matches we and others are using in the hobby now come from the fireworks industry, where it is apparently considered a feature for the match to retain continuity after firing. This means the input of the LDO gets held down for longer than with the e-matches we used to use and Quest Q2G2 igniters that open when fired. But that still didn't make sense as the root cause, as we chose the FET firing time such that even with a dead short across the igniter terminals, the 3.3 volt rail wouldn't be pulled down far enough to cause trouble during firing. One of the big changes between v1.0 and v1.1 on TeleMetrum was that the newer boards incorporate a better reset circuit. This helps ensure the GPS chip always comes up running at power on, which was a problem at temperature extremes with older boards. However, a side-effect of this change is that a v1.1 board will reset any time the 3.3 volt rail drops below 3.15 volts, whereas older boards didn't trip until a much lower voltage. So the recent increase in reports might just be related to more v1.1 boards being placed in service? While experimenting on the bench, we observed that injecting RF energy into the input of the LDO regulator had the effect of pulling down the output voltage, presumably because the internal reference source accumulates charge and is fooled into thinking the output is too high. Since our designs all have the power switch contacts ahead of the LDO, the wires going out to the switch and back are effectively an antenna... as are, to a lesser extent, the wires going to the e-matches. There is some variability from part to part in just how badly the LDO reacts. But by attaching a tuned length of wire as an antenna to the LDO input and playing around, we were finally able to reproduce the problem reliably on a test board at my bench! On further analysis, we realized that the output of the USB battery charger chip and the input of the LDO both expect a 1uF bypass cap to ground. At some point, those looked redundant and we eliminated one of the two. Unfortunately, we weren't internalizing the fact that the switch leads were between the two caps, and the one we left was on the output of the charger and not at the input of the LDO. Placing a suitable bypass cap right at the input of the LDO turns out to have a truly dramatic effect on RF immunity! Once we realized that RF getting into the LDO input was the problem, Keith pointed out that we used to see "noise" in the accelerometer data on earlier boards that was caused by the 3.3 volt rail moving slightly during radio transmit, which we fixed with a hardware change on v1.1. We are now convinced that this was at least partly related to RF coupling to the LDO input, not just the change in power consumption on the LDO output. We didn't realize what was going on in earlier testing because we often didn't have ematches wired up, so RF coupling was minimal. But going back to flights logged with v1.0 boards that included deployment, and studying the magnitude of the "steps" in acceleration data observed when the transmitter was on, Keith was able to compute the amount the 3.3 volt rail must have sagged if the real acceleration wasn't changing... which in some cases was as much as 180mV! We think this proves that RFI could cause the LDO to drop its output voltage below the reset controller set point on v1.1 boards. Based on these observations, I'm making two hardware changes for the next version of TeleMetrum (version 1.2), and Keith is also making a software change. We have tested all of these changes on real boards both on the bench and in test flights, and the net effect is a major improvement in the RF immunity of TeleMetrum. The first hardware change is moving to a slightly lower trip voltage on the reset controller. Instead of 3.15, the new part trips at 3.00 volts nominal. This gives us more "headroom" to tolerate 3.3 volt rail droop during charge firing, and will allow the board to operate longer on a given battery charge. This change is not relevant for v1.0 and prior. The second hardware change is adding an appropriate bypass capacitor right at the LDO input. This requires a PCB update, but it's possible for me to update existing production boards by adding an 0402 cap right across the appropriate pins on the regulator chip. The software change prevents our altimeters from turning on the radio transmitter while an ejection charge is firing. Since the RF transmitter draws substantial additional power, this should help keep the 3.3 volt rail from drooping. This may not really matter, but it feels like the right thing to do. This change will be part of our next stable firmware release. We think most TeleMetrum customers need not worry about these updates. But if you have seen odd resets on the rail or during ejection charge firing in flight with a TeleMetrum v1.1, feel free to contact me about updating your existing board to include these improvements.

Back in the dark ages of the web, before the introduction of CSS 3, browsers could only display fonts available on the client system. Thanks to the introduction of @font-face and its now widespread support, this is over. Now, Web designers have access to a large selection of fonts and most users will be able to appreciate them. Typekit provides a subscription-based library of hosted, high-quality fonts to use on websites. I expose here my own, mostly uneducated¹ on the typographic side, look on this service.

Fonts embedding 101 There are several ways to embed fonts for the Web. Let s have a look at the most common ones.

Self-hosting and @font-face A first possibility is to host fonts yourself and provide a CSS file with the appropriate @font-face declarations. There are five important things to know:

1. There is no common format. You will need to host different versions of the same font to support most browsers.
2. Of course, Internet Explorer comes with its own quirks that you need to work around.
3. Most browsers enforce a same origin policy. You need to serve your fonts from the same domain as the requesting page. You can circumvent such a limitation by enabling cross-origin resource sharing: add an Access-Control-Allow-Origin header when serving fonts.
4. Fonts are unlikely to change. To leverage caching, configure an explicit expiration date far in the future. Something like 30 days.
5. There is no MIME types registered for fonts. Don t bother setting one, even if Google Chrome likes to complain about them in the console.

One great resource is Font Squirrel which provides kits with fonts and the appropriate CSS declarations. You choose your font family (or upload one of your own), the formats that you want to use (check them all) and you will get a ZIP archive with all fonts and a CSS file. You may want to tweak it a bit to enable automatic use of the bold variant when needed and to use a local copy if available. For example, if you choose Crimson, an oldstyle typeface, you may want to declare the bold version with font-weight: bold and add local names:

@font-face  
    font-family: 'Crimson';
    src: url('Crimson-Bold-webfont.eot');
    src: local('Crimson Bold'), local('Crimson Text Bold'),
         url('Crimson-Bold-webfont.eot?#iefix') format('embedded-opentype'),
         url('Crimson-Bold-webfont.woff') format('woff'),
         url('Crimson-Bold-webfont.ttf') format('truetype'),
         url('Crimson-Bold-webfont.svg#CrimsonBold') format('svg');
    font-weight: bold;
    font-style: normal;
 

Google Web Fonts For open-source fonts, you can also use Google Web Fonts instead of hosting the files yourself. Build a collection of fonts and choose the variants that you want to use for each of them. You will then be provided with a code snippet to paste in the <head> element of your page. For example, for Crimson:

<link href='http://fonts.googleapis.com/css?family=Crimson+Text:400,700,400italic'
      rel='stylesheet' type='text/css'>

Why choose this solution over self-hosting?

1. You don t use your own bandwith to serve fonts. This may be important if you pay for it.
2. Google uses its own CDN to serve fonts. If you don t use a CDN yourself, this can be a major performance improvement.
3. Caching is more efficient since many sites will use the same font.
4. It s easier to do it right.

Unless you are concerned about Google tracking your users², I think this is a better solution than self-hosting. Quick delivery of fonts is pretty important since content rendering can be delayed by them.

Paid services If you would like to use commercial fonts, like Adobe Minion Pro or Paratype Futura PT, a convenient option is to rent them. Typekit is service providing such an option. Pricing depends on volume and the number of fonts you want to have access to. There is a free plan and the first paid plan is US$24.99 per year. Other similar services exist. Feel free to compare. Once registered, the workflow is similar to Google Web Fonts. You choose your fonts, assemble them in a kit and publish it. Instead of directly providing a CSS file, Typekit provides some Javascript which will in turn download a CSS file containing all fonts in the appropriate format for the browser (on most browsers, fonts are inlined).

<script type="text/javascript"
        src="//use.typekit.com/tyt0atd.js"></script>
<script type="text/javascript">
  try Typekit.load(); catch(e) 
</script>

Typekit: the good parts So, why choose Typekit? First, there is the very large choice of fonts. The first paid plan comes with more than 500 fonts from about 80 foundries. There are about a hundred serif fonts and a couple hundred sans serif ones. Typekit provides a convenient interface to browse fonts. You can either search fonts by name or by characteristics. In the last case, you can filter on properties like the classification (serif, sans serif, decorative, etc.), weight, width, contrast, x-height, recommended use or language support. Once a font is selected and added to your kit, you can easily choose what variants you want. The kit total size is displayed. If you happen to meet any problem or have some questions, Typekit support is very responsive. I got clear and crisp answers in less than a few hours in the week-end.

and the bad ones Unfortunately, Typekit has also some shortcomings. One of the most commonly cited is that Javascript is mandatory. No Javascript, no fonts. If you want to display the appropriate fonts for users without Javascript, you should just not use Typekit.

Not free, nor free While Typekit offers some open-source fonts, most of them are not. Moreover, only a few of them are available in the free plan. While I would prefer to use open-source fonts, I don t consider this a strong requirement: if you are dissatisfied for some reason, switching back to open-source fonts (or another service) is fast and easy. I like serif fonts a lot and they get less attention from the FLOSS world: it is difficult to find one whose readability on screen is excellent. Droid Serif is a nice font but is a bit too black for me. Maybe Cardo would be a good match. You may disagree and in this case, Google Web Fonts or self-hosting seem the perfect match.

Difficulty to choose and test fonts While browsing fonts is easy and smooth, choosing and testing them is another matter. For example, Typekit is missing some interface to compare font rendering for whole paragraphs at a given size. It also misses a way to check how two fonts render together, one for headings and one for paragraphs. Here, Google Web Fonts is more versatile. Things become really difficult when you want to test your selected fonts for real. Except if you have invested into one of the expensive plans, you can only include a limited number of fonts in your kit. Each time you want to try another set of fonts, you need to modify your kit and wait for it to be distributed across Typekit network. You may have to wait five or ten minutes between each change! Another inconvenient thing is that once you publish your site, any change to the kit will affect the published version. Therefore, you need to use a second kit for development and play back and forth with those two kits. What would be convenient here is a special kit with all fonts from the library with restricted access to some IP to avoid abuse. This is something done by Fontdeck, a competitor.

Poor subset support Because you want to keep the font size small (about 30 kB for each variant), Typekit usually proposes two subsets: the default one contains only latin characters and the complete one with all glyphs. If some glyph is absent from the default subset, you need to use the complete one which is roughly two to four times the size of the default one. This is a bit huge for only one character. What would be nice is to have subsets for each language. In my case, I would take a French subset because I need the glyph which appears in French in words like c ur (heart or core) or il (eye). I don t want to select the complete subset just for this character. When a glyph is absent, the next font in the CSS stack is used. For example, if the selected font is FF Tisa Web Pro and the next font in the stack is Droid Serif, here is how the word c ur may be rendered. On the first line, FF Tisa Web Pro contains the appropriate glyph. On the second line, the glyph is absent and taken from Droid Serif. Since x-height and contrast are a bit different, the replaced glyph seems out of tone. At small sizes, the difference accounts for more than 10%. I have also added a third line where the ligature is built from o and e and the following style is applied to e :

.lf-ligature  
    margin-left: -0.172em;
    zoom: 1; /* Here to trigger hasLayout on IE7 */
 

As you can see, the result seems good. I have a piece of Javascript turning a ligature into the appropriate markup. It can be extended to handle more ligatures and could be adapted to handle other composed characters (like the ones in Anton n Dvo k ).

Defective caching Because a document can only be rendered after the fonts have been loaded³, it is pretty important to deliver fonts as fast as possible. Typekit uses Edgecast as a CDN and DynECT for DNS hosting. Two files are downloaded. Both of them are hosted on use.typekit.com. The first one is a script that will act as a loader. Based on the characteristics of your browser, it will choose how to download the requested fonts for best rendering. The second file is generally a big CSS file containing the fonts. Here are the headers returned for the first file:

HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: max-age=300
Content-Encoding: gzip
Content-Type: text/javascript
Date: Tue, 08 Nov 2011 18:34:16 GMT
ETag: "388467610+gzip"
Expires: Tue, 08 Nov 2011 18:39:16 GMT
Last-Modified: Sat, 05 Nov 2011 09:31:57 GMT
Server: ECS (cdg/D624)
Vary: Accept-Encoding
X-Cache: HIT
Content-Length: 7440

First, notice that the content is served compressed. Good point. The next headers to look at are Cache-Control, Date, ETag and Expires: the server requests the content to be cached for 5 minutes. When the browser notices that its copy is out-of-date, it will issue a new request including a If-None-Match: 388467610+gzip header. Unless the kit has been modified, the server will answer with 304 Not Modified and no content. The copy of the browser will be valid for another 5 minutes. This means that after 5 minutes, at least 3 round-trips are needed to check if our fonts are up-to-date. Worse, sometimes, Typekit servers may be just slow. They can wait one second before answering, just to send a 304. Since the first file is a script embedded in <head>, the whole page is blocked until you get the answer. Here is an illustrative example with Chromium 14 where a page using Typekit is loaded while all static assets are in the navigator cache and things have gone wrong (which is pretty rare): Since fonts are needed, the rendering has been paused for 3.5 seconds until Typekit was fully loaded. If we look more closely, we may also notice we got a status 200 from the server instead of 304. Here is an excerpt of the browser request:

GET /tyt0atd.js HTTP/1.1
Host: use.typekit.com
Connection: keep-alive
Accept-Encoding: gzip,deflate,sdch
If-None-Match: "2200251225+gzip"
If-Modified-Since: Thu, 10 Nov 2011 11:38:11 GMT

And here is an excerpt of the answer headers:

HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: max-age=300
Content-Type: text/javascript
Date: Fri, 11 Nov 2011 17:10:03 GMT
ETag: "2200251225"
Expires: Fri, 11 Nov 2011 17:15:03 GMT
Last-Modified: Thu, 10 Nov 2011 11:38:11 GMT
Server: EOS (lax001/54E5)
Content-Length: 25755

What happened? For some unknown reason, the server denied the access to the compressed version of the resource: there is no Content-Encoding: gzip while the browser did send Accept-Encoding: gzip. The tag provided by the browser (2200251225+gzip) came obviously from the compressed resource and therefore does not match. RFC 2616 requests If-Modified-Since header to be ignored if the tag does not match. Consequently, the server answers with 200 OK and resend the whole file. The same problem happened with the CSS file. Let me stress again how important the problem is: we had to download again the two files but we also downloaded the non-compressed version. Now, let s suppose that we did not run into this problem and the server answered with 304 Not Modified. The result is still not satisfactory: we would have waited 1.3 seconds to get both answers from the server. Keep in mind that most of the time, Typekit is pretty fast. Here is how I think this should have been done: each time you modify your font kit, you get a new URL to use (containing the version of the font kit for example). This resource and the associated fonts (whose URL is also versioned) are requested to be cached for several days. As a sidenote, this also enables to modify a kit for your development environment without modifying the kit for your production site. I suspect that Typekit did not go this way to track kit usage more accurately and enforce the appropriate pricing. Having multiple versions of the same kit would also allow us to use more fonts that we are paying for. UPDATED: Typekit support knows the problem and is working on it:

You ve identified a small bug in our CDN provider that we re working with them to fix. Hopefully I can give an explanation of what s happening. The CDN edge servers have a cache of recently served kits on them. Any request that is served from that cache will be correctly Gzipped and handle ETags. Unfortunately, if the content isn t already in cache and needs to be fetched from the master origin server then the request won t be gzipped correctly which has the side effect of breaking ETags. [ ] We are working to on getting this bug fixed, but any change to a globally distributed CDN will take some time. We re also working on having our content cached longer than 5 minutes whilst still allowing people to quickly update their site.

Conclusion I have mixed feelings about Typekit. While the difficulty to test fonts and the lack of language-related subsets are annoying, I have been able to work around them. However, the caching problem is more annoying. I am still considering going back to Google Web Fonts just because of this.

---

1. While I have a high interest in typography, have my own copy of The Elements of Typographic Style by Robert Bringhurst and have throughly read The Elements of Typographic Style Applied to the Web , I am still fairly novice on this matter.
2. Google serves fonts from a cookie-less domain. Technically, they could still do some kind of tracking but I believe they don t.
3. In fact, browsers have different strategies on how to render before fonts availability. Paul Irish wrote a comprehensive article on FOUT. One common strategy is to render a blank space until downloaded fonts are available. If this takes too much time, fallback fonts may be used.

A few years ago, I ran into my friend Jay in the MIT Infinite Corridor. He was looking for volunteers to have their pictures taken and then added to the library of freely licensed and remixable media that would ship with every version of Scratch -- the graphical programming language built by Mitch Resnick's Lifelong Kindergarten group that is designed to let kids create animations and interactive games. Jay suggested I make some emotive faces and I posed for three images that made the final cut: But although I've spent quite a bit of time studying the Scratch community in the last few years as it is grown to include millions of participants and projects, I forgot about about Jay's photo shoot. A couple months ago, Acetarium resident Andres Lombana Bermudez pointed out that there was a mako tag on the Scratch website and that a whole bunch of users had been publishing projects using the pictures of me which, apparently, shipped in Scratch under my name. For example, in this project in which I dance in front of a enormous "MAKO" banner: That said, given the rather emotive nature of the pictures, I seem to usually end up being blown up shot, shrunk, set on fire by dragons, or meeting other similarly unfortunate ends. There's quite many more entertaining examples under the tag and many more elsewhere on the Scratch website although they are a little trickier to track down. Jonathan Zittrain likes to say that the best technologies are generative in the sense that they encourage their users to make things with them that the designer never forsaw or anticipated. I feel generative.

We have been working on adding build-arch support for about a week now and I figured a little status update would be in order. According to UDD, we had 506 packages to fix when we started and after todays update it has dropped to 485. It is a little less than the 4 packages a day needed to ensure that they are all fixed in Wheezy, but I think it has been a good start. On a related note, I am very pleased to see the progress on the general build-arch fixes. According to the statistics collected by Lintian on lintian.d.o[1], maintainers in Debian has fixed a total of 67 packages since we started. To put that into perspective, we fixed about 36 packages the week before that. [1] Currently only DD-accessible on lintian.debian.org /srv/lintian.debian.org/history/tags/debian-rules-missing-recommended-target.dat

& another mix of various RC bug fixes: applying patches from others, fixing stuff myself, closing obsolete bugs:

• #634650 src:xplanet: "xplanet: Please Build-Depends on libjpeg-dev, not libjpeg62-dev"
  do as the bug report requests, upload to DELAYED/2
• #637936 libtunepimp: "FTBFS: fatal error: curl/types.h: No such file or directory"
  add patch from peter green, upload to DELAYED/2
• #639152 src:csmash: "csmash: Please Build-Depends on libjpeg-dev, not libjpeg62-dev"
  fix build-deps, upload to DELAYED/2
• #639176 src:fdm: "fdm: FTBFS: unsatisfiable build-dependency: tdb-dev (>= 1.1.1~svn26294-1.1) (versioned dep on a virtual pkg?)"
  fix build-deps, upload to DELAYED/2, later sponsor maintainer upload
• #640588 roundup: "roundup: package purge (after dependencies removal) fails"
  apply patch from Ubuntu / Daniel T Chen, upload to DELAYED/2
• #640597 ekeyd: "ekeyd: installation fails"
  fix postinst (check for existence of init script), upload to DELAYED/2
• #640599 anon-proxy: "anon-proxy: installation fails: chown: cannot access /var/run/anon-proxy': No such file or directory"
  apply patch from Ubuntu / Daniel T Chen, upload to DELAYED/2
• #642689 src:mailsync: "mailsync: FTBFS: configure: error: a working c-client installation is required for building mailsync"
  apply patch from Ubuntu / Ilya Barygin, upload to DELAYED/2
• #642721 src:libcaca: "libcaca: FTBFS: make[4]: *** [refman.pdf] Error 1"
  unreproducible with the newest version neither locally nor on Grid'5000, do a versioned close
• #642793 src:tkgate: "tkgate: FTBFS: ERROR: Unable to find library X11"
  apply patch from Ubuntu / Andreas Moog, QA upload
• #647120 src:libgeo-proj4-perl: "libgeo-proj4-perl: FTBFS with perl 5.14: CCFLAGS should include $Config ccflags "
  add patch from Dominic Hargreaves, upload to DELAYED/2

in somehow related news: the perl 5.14 transition has begun. that also means that the severity of some bug reports was raised, & maybe we'll see some new ones. but it also means these bugs are easier to fix now that perl 5.14 is in unstable.

Hi all! My name is Alberto Garcia and this is my first (well, second) post in Planet Debian. So I ll introduce myself. I m a free software developer and enthusiast from Galicia, Spain. I studied computer science at the Corunha University, where I first heard about GNU/Linux and Debian. After leaving university I co-founded Igalia with a group of friends. We ve been working on lots of different things during all these years, but some projects we ve been particularly involved in include GNOME, Maemo/MeeGo and WebKit. Although I ve been using Debian for more than a decade now (my first -and still running!- installation was in 1997) and I m quite familiar with the distribution, it wasn t until a few years ago that I started maintaining packages officially. Apart from software, my other main hobby is music. When I m not using my computer you ll find me at some concert (preferably small bands: I hate long queues, crowded places and being far from the stage). It s no coincidence that my first Debian package was a Last.fm player ;) I don t have much more to add. I d like to thank Ana for adding me to the planet, and I m proud to be part of the Debian community!

During the OpenRheinRuhr I noticed that a friend of mine didn t know about zgrep and friends. So I told him what other grep variations I know and he told me about some grep variations I didn t know about. So here s our collection of grep wrappers, derivatives and variations. First I ll list programs which search for text in different file formats:

grep through what	Fixed Strings	Wildcards / Basic RegExps	Extended RegExps	Debian package
uncompressed text files	fgrep	grep	egrep	grep
gzip-compressed text files	zfgrep	zgrep	zegrep	zutils, gzip
bzip2-compressed text files	bzfgrep	bzgrep	bzegrep	bzip2
xz-compressed text files	xzfgrep	xzgrep	xzegrep	xz-utils
uncompressed text files in installed Debian packages	dfgrep	dgrep	degrep	debian-goodies
gzip-compressed text files in installed Debian packages	-	dzgrep	-	debian-goodies
PDF documents	-	-	pdfgrep	pdfgrep
POD texts	podgrep	-	-	pmtools
E-Mail folder (mbox, MH, Maildir)	-	mboxgrep -G	mboxgrep -E	mboxgrep
Patches	-	grepdiff	grepdiff -E	patchutils
Process list	-	-	pgrep	procps
Gnumeric spreadsheets	ssgrep -F	ssgrep	?	gnumeric
Files in ZIP archives	-	-	zipgrep	unzip
ID3 tags in MP3s	-	-	taggrepper	taggrepper
Network packets	-	-	ngrep	ngrep
Tar archives	-	-	targrep / ptargrep	perl (Experimental only for now)

And then there are also greps for special patterns on more or less normal files:

grep for what	uncompressed files	compressed files	Debian package
PCRE (Perl Compatible Regular Expression)	pcregrep (see also the grep -P option)	zpcregrep	pcregrep
IP Address in a given CIDR range	grepcidr	-	grepcidr
XPath expression	xml_grep	-	xml-twig-tools

One question is though still unanswered for us: Is there some kind of meta-grep which chooses per file the right grep from above by looking at the MIME type of the according files, similar to xdg-open. Other tools which have grep in their name, but are too special to properly fit into the above lists:

• ext3grep: Tool to help recover deleted files on ext3 filesystems
• xautomation: Includes a tool named visgrep to grep for subimages inside other images.

Includes contributions by Frank Hofmann and Faidon Liambotis.

Two days ago, I finally brought my system up-to-date with regard to the GNOME packages that I use. I was very reluctant because I am using a heavily customized gnome-panel and I waited until all the applets that I use have been ported to gtk3 and the libgnome-applet library. I am the Debian maintainer of one of these applets, link-notification-daemon, and I have made the changes and tested them in a chroot before, but now that I am actually using it, I found and fixed more visual glitches. I think by now it is as usable as it was before on GNOME 2. I am still looking for someone to step up as the new upstream maintainer for it! I had some trouble with gnome-session and notification-daemon, thought I found the cause and reported it, but a day later I could not reproduce it anymore. Weird. Other problems, such as the busy cursor not disappearing after the session start, or evolution going into a freeze also have stopped occurring by themselves.
Other problems I found and fixed, for example the battery status applet was not visible until a major state change, or panel applets were not loaded due to a race condition, or tooltips not working (which called for a fix in gtk+ itself). I also added to the xmonad package the files required to allow the user to select GNOME with Xmonad in GDM, and found out how to have Galeon appear in the list of possible default browsers.
I don t really have to say much about GNOME3 itself. I disliked the default font, Cantarell, mostly because of the extra spacing that reduced the number of folders and mail I can see in evolution. (Also see what nekohayo has to say about that.) I also was under the impression that the font is much lighter, and I started to adjust the position of my laptop monitor to increase the contrast. So I switch back to DejaVu Sans.
I also disabled the sleep-on-lid-close feature I often run backups, or download stuff, or compile stuff, or calculate stuff, so I want better control over this. So, I guess, now that everything is almost as it was in GNOME2, I can say I like it...

Flattr this post

Debian's libvirt in unstable finally passes the Technology Compatibility Kit (libvirt-tck) for qemu:///system:

Files=59, Tests=1579, 315 wallclock secs ( 0.77 usr  1.02 sys + 31.40 cusr 10.14 csys = 43.33 CPU)
Result: PASS

We're running libvirt's internal test suite since 0.9.0 but this doesn't launch any real virtual machines to check things like suspend, resume, snapshotting, migration and it doesn't create storage pools and volumes or networks. This means a lot of testing was done manually with each release. libvirt-tck provides a framework to perform these kinds of integration testing between libvirt and it's drivers, comes with hundreds of testcases already and it's easy to set up since it's available in experimental:

apt-get install -t experimental libvirt-tck

Edit /etc/libvirt-tck/default.cfg if you don't want to use the default connection URI. Then just run libvirt-tck:

libvirt-tck

Since this is supposed to stress libvirtd and the hypervisor and since it creates and deletes storage pools, networks and virtual machines it's recommended to run this on a dedicated system to make sure the tests don't blow away any precious config. If a test fails one can debug that single test using:

LIBVIRT_TCK_CONFIG=/etc/libvirt-tck/default.cfg prove --verbose /usr/share/libvirt-tck/tests/hooks/051-daemon-hook.t

This already revealed errors in our package like a missing parted build dependency breaking the creation of disk based storage pools, bugs in libvirt, crashes in QEMU and minor errors in the test suite itself. We're currently cheating a bit since the tests for hooks and nwfilter are currently disabled due to license problems with the used Perl modules. libvirt-tck can easily be integrated into Jenkins since it can now use libtap-formatter-junit-perl to generate JUnit XML. To do so simply configure a free-style software project to execute these commands:

rm -f libvirt-tck.xml
sudo libvirt-tck --timer --format junit --force > libvirt-tck.xml

allow Jenkins to run libvirt-tck as root

jenkins ALL=(ALL) NOPASSWD: /usr/bin/libvirt-tck --timer --format junit --force

and configure it to publish a JUnit test result report. Currently I'm only running the tests for qemu:///system so any help running and debugging this for LXC, VirtualBox or XEN is very welcome. Many thanks go to Salvatore Bonaccorso for packaging the missing Perl modules needed by libvirt-tck.

See also parts 1, 2, 3, and 4. This is the biggest highlight of our trip to Greece for me. I enjoy having the chance to meet people, visit for awhile, and make new friends and that certainly happened in Greece. In one of the shops we happened to step into, I noticed a radio behind the counter. That s not unusual itself; radios often catch my eye these days. But this radio was tuned to 21.070, an amateur radio frequency. So I asked the shop owner if he happened to be a ham. And indeed he was. He was Lakis (SV5KKU), and Terah and I had a great time visiting with him. Terah took some photos of us, and then we made our purchases and headed out. I had brought my HT (handheld radio, weighs a few ounces and is powered by batteries) with me, and Lakis told me about the repeaters in the area. I had known about some of that since I had emailed Panos of the amatuer radio club in Rhodes before leaving home (I found his name via Google). A couple of days later, on Tuesday, we found ourselves back in Lindos. It was mid-afternoon, so the shops were quiet. After a late lunch, I thought it would be nice to drop in on Lakis one more time, since we were scheduled to fly back the following morning. I m not sure how long we stayed it must have been at least an hour and enjoyed the fresh orange juice he prepared. After we got back to our hotel Tuesday, I learned that our flights on Wednesday were canceled due to a nationwide air traffic controller strike in Greece. After 3 hours on the phone with Delta (more on that experience later), we got rescheduled to fly back Friday. On Wednesday morning, I remembered that the Rhodes amateur radio club meets every Wednesday evening, and now I would be able to go! I knew how to contact Lakis by email and on the radio, and he kindly offered to pick me up and take me there. So that evening, I got a tour of his impressive mountaintop installation, and then it was on to the club the Radio Amateur Association of the Dodecanese (SZ5RDS). There I met Panos, whom I had emailed earlier (and I think surprised him a bit). It was a friendly group, and they translated into English for me every so often so I knew what was being discussed. When I was about to leave, they gave me this: The translation, partly from my memory and partly with the help of Google Translate, is:

Radio Amateur Association of the Dodecanese, SZ5RDS Our friend and radio colleague KR0L JOHN GOERZEN, who visited the island, has our recognition as an HONORARY CLUB MEMBER. PRESIDENT KAVALAKIS PANAGIOTIS SV5AZK (Panos) SECRETARY PAPADIMITRIOU CHRISTOS SV5DDT RHODES Oct. 5, 2011

(I hope that any Greeks reading this will send me corrections.) I truly appreciated that gesture and meeting all the people in the club. On the way back to the hotel, Lakis and I stopped by a restaurant, which I believe had the best souvlaki I ve ever tasted thanks! We brought some back for Terah. She had chosen to stay at the hotel that evening and had a small hotel meal earlier, but enjoyed the souvlaki and pita. Terah had explained to the ma tre d that I wasn t along that evening because I had gone to an amateur radio club meeting. Judging by the surprised reaction, this was probably the first time they had heard that particular comment! Experiences like this make travel fun and worthwhile. Thank you very much, Lakis and everyone in the club I hope to have a chance to visit again.

So, like many people, I have received GNOME 3 in the latest upgrade on Debian testing, and switched away to Xfce very soon after. What's amazing (to me) about this whole experience, however, is how easy it is to switch desktop environments in Debian. Two years ago, I fled KDE in very similar circumstances. I have since used Openbox, LXDE, GNOME, Xfce, as well as a few more obscure window managers in short-lived experiments. All of this was easy to do and worked flawlessly. Most of my settings, my preferred programs, and startup applications were preserved, and if I didn't like it, I could switch back without a problem. (Ironically, the upgrades from KDE 3 to KDE 4 and from GNOME 2 to GNOME 3 lost far more settings than changes to other environments.) And of course you can mix and match applications from different environments, and these days this doesn't result in a visual crime. I don't know whom to thank for this, probably a combination of upstream developers, freedesktop.org guys, and Debian maintainers. Keep it up.

No matter whether you're a professional or hobby player, if you play Magic: The Gathering, you certainly visit Wizards of the Coast's homepage from time to time. And while other parts of the WotC's page have been made unusable without ECMAScript enabled, the MTG part can be used without it mostly. The one part, that didn't work (and I needed) was card links. They have some ECMAScript to fetch the image from the Gatherer and overlay that on the current page, if you hover over a card link. If you click, it's again some script, that opens a Gatherer window. I just want all card links to be plain links pointing to the respective entries in the rather lightweight magiccards.info card search, which displays all relevant data in a compact layout. Today I finally got around to throw the ten or so lines of ECMAScript together, Greasemonkey needs to make that happen. If you like to give it a try, you can download it from my Greasemonkey script collection (direct link for the impatient: wotc_with_noscript_and_card_links.user.js). As an additional note: I'd like to point out, that there are other scripts available from userscripts.org which can do the same. But all those scripts did a lot else (like using jQuery to fetch the image on mouse over from magiccards.info).

The Age reports that Adobe has ceased development of Flash for mobile systems [1]. This is described as leading to an improvement in the web experience for iPhone and iPad users, but the more important thing is that it will improve the experience for everyone. The Flash plugin has always been a resource hog and has never been properly supported on all the common platforms. Also most sites that use Flash never needed to as there were other ways of getting equal or better results without it. Now that Flash is officially on the path to obsolescence everyone can move to HTML5. I use the following configuration directives in my Squid configuration to block Flash, I selectively enable Flash for the few web sites which use it for useful things. Blocking flash in this manner means that desktop systems which have the Flash plugin installed probably won t be vulnerable to Flash security flaws as it is unlikely that one of the few sites that I permit to send Flash to my network would end up hosting hostile Flash code. acl swf url_regex swf$ swf\?
acl swftype req_mime_type -i ^application/x-shockwave-flash$
http_access deny swf
http_access deny swftype Wikipedia has a comparison of HTML5 and Flash. One interesting benefit that is claimed for Flash is that it allows DRM and it supports inserting commercials and in other ways giving the user an experience that they don t want. It seems that to put some more nails in the Flash coffin we need tools to suck video from Flash sites regardless of DRM and which skip commercials.

• [1] http://www.theage.com.au/technology/technology-news/adobe-surrenders-to-apple-in-mobile-flash-war-20111110-1n85p.html

If you ever get an error message from the blktrace tool that looks like this:

BLKTRACESETUP(2) /dev/dm-0 failed: 2/No such file or directory
Thread 3 failed open /sys/kernel/debug/block/(null)/trace3: 2/No such file or directory
Thread 2 failed open /sys/kernel/debug/block/(null)/trace2: 2/No such file or directory
Thread 0 failed open /sys/kernel/debug/block/(null)/trace0: 2/No such file or directory
Thread 1 failed open /sys/kernel/debug/block/(null)/trace1: 2/No such file or directory
FAILED to start thread on CPU 0: 1/Operation not permitted
FAILED to start thread on CPU 1: 1/Operation not permitted
FAILED to start thread on CPU 2: 1/Operation not permitted
FAILED to start thread on CPU 3: 1/Operation not permitted

Don t be alarmed your disk hasn t suddenly disappeared out from underneath you. In fact, it means quite the opposite of what No such file or directory might imply. In fact, it means that there is already a blktrace of that particular block device in progress, and you ll need to kill that one off before you can start another one. Thank $DEITY for the kernel source code it was the only hope I had of diagnosing this particular nit before I went completely bananas and smashed my keyboard into small pieces.

The other day, I was asked if it was really possible to get build-arch support in Wheezy (as in, buildds using build-arch) by adding these optional targets. Lets have a look at the data that is available to us:

• At least ~500 packages must be fixed (the reduced set )
• The Wheezy freeze is expected in June (as I recall, I may be off)
• NMUs can take quite a while, so lets reduce it to May.

To simplify my calculation I will assume we can fix packages over a course of 150 days (which is 5 months of ~30 days or every day in Dec to April). So 500/150 = 10/3 =~ 3.3 packages from the reduced set should be fixed every day. Erring on the side of caution, we should make that 4 packages every day. So if we fix 4 packages from the reduced set every day, we will definitely fix all of them before Wheezy. But the reduced set are only the source packages that could possibly benefit from having a build-arch target (it builds both arch:all and non-arch:all packages). There could (and probably will) still be sources building non-arch:all packages without a build-arch target. Furthermore, with the rate of 4 a day we will only have a month to get dpkg and buildd support In short, no. I do not expect us to get archive-wide build-arch support on buildds for Wheezy. But I will do my best to ensure that option #4 flip the switch becomes very attractive early in the Wheezy + 1 development schedule. I hope you will join us in this endeavour. Most of the time it is a trivial 3-4 line fix and often you can even throw in some hardening flags to spice it up a bit. The easiest way to help is to fix your (team s) packages listed in the reduced set . Once you are done with that you can look at the rest of your (team s) packages (see the full dd-list). The most important thing to remember is that Build-Depends-Indep is still broken! That is, you cannot rely on Build-Depends-Indep being installed on a buildd in the build target. So any existing workarounds have to stay for now (i.e. check for certain commands or deferring indep till binary-indep is called). If you are in doubt about how to fix a certain package feel free to ask for help. Note: I pull the data directly from lintian.d.o (full set) and UDD (reduced set). I try to remember to refresh it daily. The full set is basically (z)grep cut uniq on the lintian log, the reduced set is found using the UDD query from this script (based on a query done by Jakub Wilk). Since all data is (in)directly based on lintian.d.o only packages that are in sid are considered.