Planet Debian

Subscribe to Planet Debian feed
Planet Debian -
Updated: 11 months 2 weeks ago

Bdale Garbee: Batteries and Pyro Circuits

11 April, 2013 - 11:25

Keith and I have discovered a change in the behavior of the protection circuits integrated in the LiPo batteries we sell for use with Altus Metrum products that poses a risk for our customers. This post is meant to document what we now know, communicate changes we're planning as a result, and explain what we think flyers of our existing electronics and batteries may want to do to maximize their chances of successful flights.


Choosing batteries and designing pyro circuits for high power rocketry avionics involves a variety of trade-offs. Reliability is the highest concern, both because nobody wants to lose an airframe due to a failed pyro event, and also because airframes recovering anomalously have safety implications. But we also care about other factors including cost and weight, and usually want to minimize the complexity of both the electronics and the overall installation.

The objective of a pyro circuit is to dump enough energy rapidly into an electric match to cause it to catch fire. We need batteries both to power the electronics that decide when to fire the charge, and to provide the energy that actually ignites the match.

The two most common battery types seen in the rocketry hobby are alkaline cells, often the nominal 9V rectangular variety, and rechargeable batteries based on Lithium Polymer (LiPo) chemistry. LiPo cells are 3.7 volts per cell nominal voltage, are very light, and have a high energy density.

LiPo capacity is measured in units of current times time, so an 850mAh cell should be able to deliver 850 milliamps for an hour. The battery industry also uses something called a "C rate" to describe how fast the battery can be usefully discharged, wich is a multiplier relative to the battery capacity. So a battery with 850mAh capacity and a "2C" rating can deliver current at a sustained rate of 1700mA until discharged, while the same capacity at a "5C" rating can deliver 4250mA.

By comparison, most 9V alkaline batteries are actually composed of 6 individual 1.5V cells enclosed in a wrapper. It's hard to get hard numbers for capacity and discharge rate, since in an alkaline cell the two are not independent, and the discharge rate is related to the volume of each individual cell. The data sheet for an Energizer 522 shows just over 600mAh at a 25mA discharge rate, dropping to about 300mAh at a 500mA discharge rate.

Importantly for use in pyro circuits, LiPo cells have a very low source impedance, which means they can source immense amounts of current. It's not unusual for cells in the 1000mAh range to have ratings in excess of 30C! Because this rapid discharge ability can pose a risk of fire, it's common for LiPo cells to come with a "protection board" integrated into the battery assembly that is designed to limit the current to some rate such as 2C continuous duty.

In large airframes, or projects that involve staging, air-starts, or other complex pyro event sequences, the most reliable approach will always be to use separate batteries for the control electronics and the source of pyro firing power. In the limit, having separate pyro batteries for each pyro charge with the control electronics only providing the switching to connect the batteries to the charges could even make sense. But for most airframes, this is overkill, and the increases in mass, volume, and wiring complexity just don't make sense.

The challenge, then, is how to design electronics that will robustly initiate pyro events without negatively affecting the rest of the electronics when operating from a single shared battery.

Altus Metrum Pyro Circuits

The very first prototypes of TeleMetrum were designed to use a single-cell LiPo battery, and had an on-board 100mA charging circuit. Because we needed 5 volts to power the accelerometer, we had a small switching regulator that up-converted the LiPo voltage, and we used some of that regulator's output to charge a 1000uF capacitor. The pyro circuit used Fairchild FDN335N N-channel MOSFET switches in a low-side switching configuration to dump the energy stored in the capacitor through an attached ematch. Those FETs had an on resistance of under a tenth of an ohm in our operating conditions. The circuit worked very reliably, but the 1000uF electrolytic cap was huge and we struggled with the mechanics of such a large part hanging off the board...

It turns out that 3.7 volts is way more than enough to fire a typical low-current e-match or equivalents like the Quest Q2G2 igniters. In fact, bench testing with a good digital oscilloscope showed that a typical e-match with resistance of 1.3-1.8 ohms will fire in approximately 13 microseconds when hit with the nominal 3.7 volts from a LiPo.

So, starting with our v0.2 boards, we switched to using the LiPo battery voltage directly to fire the pyro charges, eliminating the clunky electrolytic capacitor entirely. We also switched to the Fairchild FDS9926A dual N-channel MOSFET whose specs are better in all regards for our application. The on resistance is down around 40 milli-ohms in our circuit, such that the current ratings are much higher (FET current limits are primarily driven by how much heat is generated due to current flowing through the channel's on resistance).

Because using the LiPo voltage directly means we're effectively temporarily putting a very low resistance across the battery during the pyro events, the input voltage to the voltage regulator gets pulled down. To ensure the processor could "ride through" these events, we added a 100uF surface mount bulk capacitor on the 3.3 volt regulated voltage rail, which bench testing demonstrated was more than sufficient to maintain processor operation through pyro events. And that is essentially the same pyro circuit on all the boards, both TeleMetrum and TeleMini, that we have shipped to date.

What's Changed

The LiPo batteries we source and sell with our electronics come with a protection board and cable terminated in a 2-pin, 2mm "JST" connector. The specs on the protection board have always been "2C continuous", but we observed the ability to source much higher currents for short periods such as the 13 micro-seconds or so required to fire an e-match. Thus these protection circuits seemed just fine .. we could fire e-matches with a burst of current but were protected against short circuits in the wiring or our boards by the 2C continuous limit.

Unfortunately, the most recent batch of batteries we sourced seem to have a much "twitchier" protection circuit. We can draw more than 2C for short bursts, but not as much as with prior boards, and not for as long an interval. With a 1 ohm power resistor on the pyro terminals of one of our boards, we get about 9 milliseconds of power before the protection circuit cuts in and shuts the battery down. The power stays down until all load is removed, which at least means the board is turned off and back on again, and in some cases could even mean the battery is unplugged and re-plugged since we draw trace current to keep the GPS memory alive even when the power is turned off, and at least some of the new batteries see that as enough to keep the power turned off after an over-current event.

For many e-matches, this isn't an issue, since 9 milliseconds is way longer than the 13 microseconds needed to fire the charge. Unfortunately, we've discovered that many of the e-matches bought and used in the rocketry hobby are actually made for use in the fireworks industry, where it is desireable to retain continuity after firing so that series connections of e-matches all can fire even if some fire faster than others! This means that while the resistance goes up some after firing, sometimes the drain on the battery remains sufficient to cause the protection circuit to kick in even after the pyro charge has fired.

What We're Doing About It

If we remove the protection circuit from the LiPo (or jumper around it), all existing Altus Metrum products will operate successfully with pyro charges thave have an effective resistance of as low as 1 ohm. That's lower than any e-match or Q2G2 we've ever seen, so in effect what this means is that if you have an existing Altus Metrum flight computer, and you remove the LiPo protection circuit, you're good to go. This does not really make things any more "dangerous", since our battery chargers are all current limited and our discharge patterns will never cause heating of the battery. Frankly, in a rocket, the most likely way to cause a problem with a LiPo is by smashing or puncturing the actual battery during bench work or during a crash... and those cause the same problems with or without a protection board present.

In the future, we will ship batteries that have either a much higher C rating on the protection circuit, or have no protection circuit at all.

The number of problems reported by actual customers that we think should be attributed to LiPo protection circuit boards is very low, and we suspect most of our customers who are happily flying their boards can continue to do so. Ground testing where you fire pyro charges (or at least e-matches) using RF to issue the commands (not USB, since the LiPo charger is running any time USB is connected!) will confirm whether there's a problem. If the board resets (does startup beeps) after a pyro event, or shuts down completely (no LED activity), then you have a problem. If the matches light and the board keeps running, you're good to go.

However, any Altus Metrum customer with LiPo batteries sourced from us or our distributors who is worried about this problem (even if you haven't seen problems in ground testing or previous flights), and who doesn't want to try soldering on the battery circuit board yourself, is welcome to contact us about removing the protection circuit for you. We won't charge anything other than shipping.

To take advantage of this offer, just send email to telling us how many of which capacity batteries you have that you'd like updated, and we'll respond with an RMA number and shipping details.

Going Even Further

As previously indicated, with the LiPo protection circuits removed, all of our current products will work reliably with at least 1 ohm across the pyro terminals. That should cover all real-world flying conditions just fine, but we're not satisfied yet.

We've designed a new pyro control circuit that transfers the maximum possible energy to the load regardless of battery voltage without ever allowing the voltage to the processor to droop at all. We're testing this new circuit in various prototypes now, and if it pans out it will probably show up first in MegaMetrum and then trickle down to TeleMetrum and TeleMini as those products are updated later this year. The new pyro circuit tolerates 0 ohms (dead shorts) on the pyro terminals for as long as the battery can provide current, which is as good as it gets. We think the circuit is clever enough that we'll probably write more about it once we're finished validating it.

Julian Andres Klode: apt-show-versions rewrite in C++ (more than 10 times faster)

11 April, 2013 - 02:21

The script apt-show-versions is developed by another Debian Developer called Christoph Martin in Perl. Recently, it turned out that apt-show-versions is too slow for some users; so I decided to rewrite his program using APT’s C++ API. I expect this to be part of a future APT release, rendering the original apt-show-versions obsolete.

The rewrite is sadly not 100% backwards compatible to the original version; as some option names had to be renamed due to our command-line parser not supporting option names like -nh, and some other options were dropped because they are hard to support (like –status-file and –lists-dir) with our command-line parsing. I also decided not to keep the the -p and -r options, but use the standard APT command-line conventions insteads.

For now, it also cannot show you the distribution names you have specified in your sources.list file, but will always display codenames instead; if available. I hope to fix this in Jessie by extending APT’s cache format a bit.

On the performance side, this program now takes about 0.09s compared to the 1.40 seconds needed by apt-show-versions. The times are taken with all data in caches.

The current version can be found in a git repository, a link to gitweb is:

Please also note that support for –allversions is not 100% implemented yet, but it should work for most uses.

Now, go testing and report back!

Filed under: Debian

Lars Wirzenius: Machine-parseable embedded license summary information

11 April, 2013 - 01:47

There is no common way to express license information in each source file at the moment. Some people embed license information in each file, others keep it in README or another file at the top of the source tree.

Worse, there is no common syntax to express the license information in a machine-parseable way. If we had this, we could have tools that, for example, tell you if you're trying to merge code that has an incompatible license.

Obviously, this kind of thing can never work perfectly. People keep inventing new licenses, and it is not possible for a computer program to fully understand any license. It is not clear humans can do that, either. However, it would be possible to do it to a number of well-known licenses, which would help most of the time. A classic 20/80 situation.

I would like to suggest a syntax, similar to Emacs's "Hey Emacs" modelines, for embedding a summary of the license, or licenses, for a source file, in such a way that it can be programmatically extracted and parsed and analysed. With this syntax, one could then write a tool to ensure that all files in a project have the same license, or that all licenses are compatible with the project's overall license.

Such a tool will, of course, rely on heuristics and assumptions. For example, it needs to assume the machine-parseable license summary is correct, and rely on a ruleset on what licenses are compatible with what licenses. Things can go wrong. That's life. Remember, this is aiming at doing the 20% of the work that will work 80% of the time, not perfection.

I don't have a tool written, but I have a suggestion for the syntax.

 * Copyright 2013 Lars Wirzenius
 * tl;dr =*= Licenses: GPL-3+ or Expat, and Artistic =*=
 * Blah. Blah. Blah. Imagine long, boring license texts 
 * here.

The important part is this:

=*= Licenses: GPL-3+ or Expat, and Artistic =*=

The =*= prefix and suffix and the word Licenses are there to make grepping reasonably reliable without too many false positives, and to allow comment characters and other text on the same line.

The actual license summary follows the syntax and semantics of the Debian copyright-format 1.0 specification, which I chose because it exists and has had a fair bit of review so far, and is reasonably expressive.

The license summaries can be extracted with the following GNU sed invocation:

sed -n '/.*=\*= [Ll]icen[cs]es\?: \(.*\)=\*=.*/s//\1/p'

I allowed various forms of the word license, since it's a word that a lot of people will get wrong, and it's easy to catch all four common forms.

So, does anyone else think this might be useful? Would you use it in your own projects?

Peter Makholm: Reviewing my own regular expressions

10 April, 2013 - 20:59

Regular expressions are a wonderful tool, but as many other powerful tools they tend to be misused. If I had a penny for everytime I recommended against using regular expressions for parsing HTML fragments …. yeah you know what I mean.

This time made me think a bit about my own use of regular expressions. Do I ever fall in the trap of misusing regular expressions myself? Looking at my current code base I couldn’t find any glaring misuses, if I could only get a list of all the regular expressions in my current project.

Regular expressions to the rescue? No, that would probably be quite an horrible adventure. Luckily I have tools to parse Perl: PPI to the rescue:

<script src=""></script>

A few hundred regular expressions. Most of them just matching simple substrings (in some cases case insensitive) or just short hand for testing a handful of equalities in one go. The only zero-width assertions we are using are the word boundary and quantifiers are mostly used on simple character classes like \d, \s, [0-9a-f] and a few “anything but this one or two characters” ([^>]).

Lessons learned: 1) PPI is cool. 2) I really do use regular expressions as I preach.

Paul Wise: Inadequate software

10 April, 2013 - 16:17

Just 168 of the 4961 packages (3%) I have installed are inadequate. Unfortunately those packages collectively have 3440 inadequacies. How much of the software on your system has these inadequacies?

  • broken symlinks
  • missing copyright files
  • obsolete conffiles
  • Python modules not byte-compiled
  • /bin and /sbin binaries requiring /usr/lib libraries
  • undefined symbols.

You can find out today by installing Jakub Wilk's software, which is appropriately named adequate. It is now available in Debian unstable. I recommend enabling the apt hook which notifies you when software you are installing is inadequate. Other ways of being notified when you are installing inadequate software include apt-listbugs and debsecan.

If you are interested in software quality, Debian's QA activities wiki page provides a good overview of the quality assurance activities that are being worked on within the context of Debian. If you want to provide better quality software for Debian, please keep an eye on the PTS pages for software you maintain. You can also run various automated checks on your software before you make new releases or upload them to the Debian archive.

More people are needed to improve and expand upon Debian's existing quality assurance activities and infrastructure. Come join us today!

Andrew Pollock: [life/repatexpat] Day #10 of repatriation -- got wheels

10 April, 2013 - 12:22

Finally, finally, I've got a car. I had this grand plan of using a friend of a friend who was a car buyer to source me a car and have it ready for me at the airport when I arrived. That didn't work out so well, so I resorted to and found something very quickly. I could have bought it last Friday, if I'd wanted to forego the RACQ inspection, but I hate used cars at the best of times, and so I want to do what I can do avoid buying a lemon, so I had to wait until Monday for the inspection.

I got the report in the early afternoon on Monday, and the only thing it highlighted was a bit of oil on the front differential housing. I contacted the dealer and he said he'd get it looked at. I got an SMS from him on Tuesday morning saying the car would be ready after 3pm, but by the time I could arrange with Kristy for a ride, we just missed the bank, so I couldn't get the bank cheque to pay for it, so we rescheduled for this morning.

The shipping container was delivered to Sarah's place on Monday, and there's been a steady stream of boxes arriving at my place. It was good to be able to transport some of those myself today, and there'll be more to move tomorrow. I need to sort out storage options, because one thing I don't want is for there to be too much clutter in my home. I think there'll be another trip to IKEA in my near future. At least I can do that all on my own now.

It's so great to have independent mobility again.

Bits from Debian: Call for participants in Debian for the Google Summer of Code

10 April, 2013 - 03:30

The Google Summer of Code is a program that allows post-secondary students aged 18 and older to earn a stipend writing code for Free and Open Source Software projects during the summer.

For the eighth time, Debian has just been accepted as a mentoring organization for this year's program. If you're an eligible student, now is the time to take a look at our project ideas list, engage with the mentors for the projects you find interesting, and start working on your application!
Please read the FAQ and the Program Timeline on Google's website.

If you are interested, we encourage you to come and chat with us on irc (#debian-soc on, or to send an email to the SoC coordination mailing-list. Most of the GSoC related information in Debian can be found on our wiki pages, but feel free to ask us directly on irc or via email.

We're looking forward to work with amazing students again this summer!

Sylvestre Ledru: A New feed: Debian uploads

10 April, 2013 - 02:17

After the Debian new packages, removal and bugs feeds (see the previous blog posts), I also plugged a feed with the last uploads in the archive:
Debian uploads on
Debian uploads on Twitter

As a reminder, here is the list.
Debian uploads
Debian NEW queue
Debian bugs
Debian removed packages

For Twitter:
Debian uploads
Debian NEW queue
Debian bugs
Debian removed packages

Wouter Verhelst: Dear HP,

9 April, 2013 - 23:37

I bought a ScanJet N6350 a few years back, in the belief that it would work. After all, you write free Linux drivers for all your printers, and when those printers are multifunctional printers with scanners, you do make sure the scanner bits of those printers work too. So it shouldn't be too hard to write a Linux driver for that scanner too, right?

Apparently it is. For some reason that I can't imagine, you decided that my money is worth more than my stress levels.

  • The HP ScanJet N6350 is a combination USB/network scanner. That's great; I don't need it to be right next to my laptop all the time. Having the ability to get it sent to me by email (as your product page claims it can do) reduces my workload. Unfortunately, what you didn't mention on the product page is that the scanner is pretty dumb; it does network, yes, but the only way in which it can send emails is by using some application running on a system on the other end of the network connection. That's pretty silly. It wouldn't be so bad, however, except...
  • ... the system on the other end of the network connection has to be running Windows. That's right, you didn't write a Linux driver for some reason. You also didn't publish the network protocol, and even the USB connection seems undocumented. So I can't use Linux to scan my documents. It wouldn't be so bad, however, since I already have a Windows XP virtual machine lying around somewhere, mainly because there's this satellite navigation system builtin to my car that also requires it; I just installed your scanners oftware on that machine, and I can scan. Except...
  • ... whenever an error occurs in the scanning process, the UI locks up completely. I can't retry the last page that I was trying to scan, and often I can't even save the document anymore, either; I have to rescan the whole document. That wouldn't be so bad, except...
  • ... the ADF is total crap. If I put more than a few pages on the feeder, and they've got some horizontal folds in them (as is likely with snail mail that came out of an envelope), I'm very likely to end up with a paper jam, or with multiple pages sucked into the feeder at once, causing an error and a loss of my scanned document. That wouldn't be so bad, except...
  • ... the process for finishing one scan and starting the next involves stopping and starting your whole scanning software, which takes a rather long time. As such, I'd prefer to just scan a whole stack of incoming snail mail in one go, and then use pdfsam to split up the PDF file. But then I have to babysit the scanning process so that I don't get any errors; but I fail at that about as often as I succeed, meaning, it usually takes a long time to get through the stack.

Dear HP, you suck. I fail to understand how the basic loss of functionality after a failed scan managed to get through your testing. I fail to understand why you think Linux users should be able to print, but not scan. And I especially fail to understand why I should waste my time with such an expensive device that can't even perform its basic functionality with more than 10% success rate.

Michal &#268;iha&#345;: phpMyAdmin at GSoC 2013

9 April, 2013 - 16:18

phpMyAdmin has been accepted for Google Summer of Code 2013. So if you are a student and thinking about how to spend this summer, you might want to join us.

This year we will have fresh mentor blood and we have prepared dozen of ideas, so in case you are interested, it's really the time to start to work on your application. We require you to contribute before GSoC, so that we can see you can handle the code and our tools. All details you might need are available in our applicant guide.

Our requirements might sound strict, but without them, we would drown in hundredths of applications with no clue how to decide, so do your homework and prepare perfect application. If you have any questions, get in touch with us on mailing list and get ready for April 22th, when you can submit the application.

Filed under: English Phpmyadmin | 0 comments | Flattr this!

Russ Allbery: Review: Judge Sn Goes Golfing

9 April, 2013 - 11:34

Review: Judge Sn Goes Golfing, by John Scalzi

Artist: Gahan Wilson Publisher: Subterranean Copyright: 2009 Printing: 2012 ISBN: 1-59606-479-X Format: Kindle Pages: 32

As you may have guessed, this is yet another short story by Scalzi that was rolled into the Subterranean Scalzi Super Bundle. This one is a bit longer than the ones I've previously reviewed, and is also illustrationed. Unlike some of the others, it's not available on-line for free... as a written work at least. There's an abridged audio version available for free from Subterranean Press's web site, though. Like the other stories I've reviewed so far, it's humor, but I think it's a bit more successful and substantial than the previous short stories.

Judge Bufan Nigun Sn is an extremely foul-tempered alien judge who loves to golf, despite being terrible at it. He's a sort of circuit court judge for a larger galactic civilization, of which Earth is now part. (There's a smattering of background world-building, but it's not the core of the story.) Golf is his passion, in several senses of the word: his habit of getting into nasty fights with his fellow players and otherwise making public and occasionally injurious scenes has gotten him banned from every course in the Washington DC area, both public and private. Except, that is, for Dulles Woods, a dire, badly-maintained course designed via nepotism and theft whose business model is primarily based on letting the people banned from every other course golf there. And charging them extra to let caddies accompany them.

The plot of this story is about a particular game of golf, dramatically foreshadowed by the opening sentence. But the story is really about Judge Sn's relationship to golfing and to the notorious Dulles Woods. It's one of the better jobs I've seen of writing a thoroughly unlikable person into a gloriously foul-tempered charm. It's also a story about a golf course and golfer who thoroughly deserve each other, and about how it feels to suddenly have something go right after grinding out hours and hours of work on a hobby that is supposed to be fun but manages to fall into some horribly compelling middle ground between enjoyment and rage-inducing frustration.

Speaking as someone who is known to grind out video game completions while swearing at the television, I can sympathize.

I got thoroughly hooked by Scalzi's descriptions of Judge Sn's mental state and enjoyed this story far more than I expected to. Sadly, when the plot does finally arrive, I thought it was a letdown. Scalzi throws in a highly improbable coincidence to create action, and while that's a legitimate plot technique (particularly in humor), it works best when the author goes back afterwards and fills in the back story of the coincidence. Pratchett does this extremely well. Scalzi, alas, doesn't really bother, and while suspension of disbelief isn't as relevant for this sort of story, I thought it was a missed opportunity. The ending seemed to be missing some sort of punch or background twist.

That said, I really liked the character study and I think the story is well worth the 99 cents it's still selling for on the Kindle (and quite possibly other platforms; I haven't checked). If buying short stories on the Kindle is something you want to do, I recommend this one to your attention.

Rating: 7 out of 10

Soeren Sonnenburg: Shogun got accepted at Google Summer of Code 2013

9 April, 2013 - 04:17

We are happy to announce that the shogun machine learning toolbox will participate in this years google summer of code :-)

SHOGUN is designed for unified large-scale learning for a broad range of feature types and learning settings, like classification, regression, or exploratory data analysis.

In case you are a talented student interested in implementing and learning about machine learning algorithms - we are looking for you!

We have collected a number of ideas [1] that we consider worthwhile implementing. And don't forget to apply [2]!



Daniel Pocock: Google Summer of Code, tips for students

8 April, 2013 - 17:12

I've had quite a few queries about the project ideas for Google Summer of Code on the Lumicall and Debian project pages and I'm publishing some notes here to help people get the best chance of participating, while also helping people's expectations.

Firstly, Google is responsible for administering the program and payments, they have the last word on which projects and students participate and free software developers like myself have no direct control over this. In other words, while I would encourage students to make contributions to free software projects to familiarize themselves with the way we work, I can not promise that this will automatically lead to selection. If you are a student, do go ahead and feel free to comment on or make contributions to projects, this helps mentors to see your capabilities very quickly, but don't do any more than you would have done if the GSoC program didn't exist. In any case, building up a portfolio of work that is visible on sites like github does help your employment prospects in the long run. If a development manager is looking at 100 CVs for a job vacancy, and one of them has a strong portfolio on github or Debian, there is a good chance that one person will get an interview - although it doesn't guarantee they get the job.

Where to start?

If you are a student and you are already heavily involved in some free software project then you probably don't need to read the rest of this. The reality is that GSoC is meant to help bring more people into the free software community and this means we need to help people get their foot in the door. That is what I am addressing here, with examples from my own possible projects.

When I went through university in the 90s, there was a very strong UNIX culture in our computer science department and the wider engineering faculty. There were also winds of change, for example, a new dean who wanted to change everything to Windows and a central IT management agenda to abolish campus computers and force students to carry and maintain their own laptops. Around the world, every campus has a different approach. I was fortunate to have UNIX topics like the vi text editor, shell programming and even LaTeX taught as a formal part of the course, students coming after me may have missed those opportunities. I understand that some students have not encountered these concepts at all today. That said, most mentors have a fairly wide tolerance for these things: it is not expected that students know these things, rather, it is an opportunity for you to start learning them whether it is part of your course or not.

The key concept here is to be a self-starter: it is not what you know, but your enthusiasm to go and try the things you don't know. That is the very thing you can start doing now, even before the program commences. Doing this will definitely help you identity the areas of free software and Debian that you are most likely to get excited about, and that will lead to a successful project.

Some general ideas to get started
  • If your campus hasn't taught UNIX in a formal sense, please familiarise yourself with the basics. While some companies do have more jobs working with other platforms, and some campuses have sadly tried to adapt their courses to prepare students for that limited subset of companies, all the best jobs I've had involve UNIX or Linux. I've never worked for a hedge fund that didn't use Linux. Hollywood uses Linux, NASA does too, but learning Linux is not rocket science. Basic things to understand include the vi text editor, shell scripts and using a command line tool for version control, preferably git. As you will be the system administrator of your own desktop or laptop, it's essential to understand some basic concepts like volume management too.
  • If you need to run some Windows software (some courses do require that), use VirtualBox or a similar solution to run both Windows and Linux on your computer or laptop. The VirtualBox documentation is very good and will help you start quickly. My own laptop runs Debian 7 (wheezy) as the main operating system, and I have Windows and Solaris in VirtualBox for some business applications.
  • My own course included a project that involved downloading the open source GNU make program, writing a patch and testing it. If you've never done something like that, please try. Instead of downloading a project tarball, these days you will typically clone the project's git repository. Even if you only make some trivial change that you will never share, it is good to prove that you can compile and successfully execute something like this.
Some specific ideas for my own projects
  • For Lumicall or Android development, just work your way through the build instructions that are published for all contributors. Trying the f-droid build instructions is also a good way to start.
  • For any of the Debian projects, please make sure you have installed Debian 7 (wheezy) on a desktop, laptop or virtual machine. Just follow the installation guide
  • Once you have installed Debian, try installing whichever one of my packages interests you. Try to configure and use it. Prove that the package works in a normal installation. Look at the log files. Run the test cases.
  • Next, try obtaining the source code and building the package. Debian makes it very easy. Here is an example for reSIProcate, the same works for any other package. As root:

    # apt-get update
    # apt-get build-dep resiprocate

    will obtain all the necessary build tools. Then, as a normal user:

    $ mkdir ~/src/resiprocate
    $ cd ~/src/resiprocate
    $ apt-get source resiprocate
    $ cd resiprocate
    $ dpkg-buildpackage -rfakeroot -j12

    In a few minutes, you should find the packages (*.deb files) are created.

  • Now, you could try making some small change to the package and compiling it again. Verify that your change works.

If you've successfully got to this point, then there is every chance you will be able to successfully complete a GSoC project. If you struggled along the way, that is OK too, the important thing to do is to engage with the community and learn how to ask for help. The Debian GSoC wiki provides some excellent ideas about engaging with the project using IRC chat and mailing lists. It is also very worthwhile trying to find a local group or a free software event that Debian is attending near you and spending a few hours with people who can look at any problems you have and give you quick solutions.

Matthias Klumpp: Tanglu status report

8 April, 2013 - 16:24

Hello everyone! I am very excited to report about the awesome progress we made with Tanglu, the new Debian-based Linux-Distribution.

First of all, some off-topic info: I don’t feel comfortable with posting too much Tanglu stuff to Planet-KDE, as this is often not KDE-related. So, in future Planet-KDE won’t get Tanglu information, unless it is KDE-related You might want to take a look at Planet-Tanglu for (much) more information.

So, what happened during the last weeks? Because I haven’t had lectures, I nearly worked full-time on Tanglu, setting up most of the infrastructure we need. (this will change with the next week, where I have lectures again, and I also have work to do on other projects, not just Tanglu ^^) Also, we already have an awesome community of translators, designers and developers. Thanks to them, the Tanglu-Website is now translated to 6 languages, more are in the pipeline and will be merged later. Also, a new website based on the Django framework is in progress.

The Logo-Contest

We’ve run a logo-contest, to find a new and official Tanglu logo, as the previous logo draft was too close to the Debian logo (I asked the trademark people at Debian). More than 30 valid votes (you had to be subscribed to a Tanglu Mailinglist) were received for 7 logo proposals, and we now have a final logo:

I like it very much

Fun with dak

I decided to use dak, the Debian Archive Kit, to handle the Tanglu archive. Choosing dak over smaller and easy-to-use solutions had multiple reasons, the main reason is that dak is way more flexible than the smaller solution (like reprepro or min-dak) and able to handle the large archive of Tanglu. Also, dak is lightning fast. And I would have been involved with dak sooner or later anyway, because I will implement the DEP-11 extension to the Debian Archive later (making the archive application-friendly).

Working with dak is not exactly fun. The documentation is not that awesome, and dak contains many hardcoded stuff for Debian, e.g. it often expects the “unstable” suite to be present. Also, running dak on Debian Wheezy turned out to be a problem, as the Python module apt_pkg changed the API and dak naturally had problems with that. But with the great help of some Debian ftpmasters (many thanks to that!), dak is now working for Tanglu, managing the whole archive. There are still some quirks which need to be fixed, but the archive is in an usable state, accepting and integrating packages.

The work on dak is also great for Debian: I resolved many issues with non-Debian dak installations, and made many parts of dak Wheezy-proof. Also, I added a few functions which might also be useful for Debian itself. All patches have of course been submitted to upstream-dak.

Wanna-build and buildds

This is also nearly finished Wanna-build, the software which manages all buildds for an archive, is a bit complicated to use. I still have some issues with it, but it does it’s job so far. (need to talk to the Debian wanna-build admins for help, e.g. wanna-build seems to be unable to handle arch:all-only packages, also, build logs are only submitted in parts)

The status of Tanglu builds can be viewed at the provisoric Buildd-Status pages.

Setting up a working buildd is also a tricky thing, it involves patching sbuild to escape bug #696841 and applying various workarounds to make the buildd work and upload packages correctly. I will write instructions how to set-up and maintain a buildd soon. At time, we have only one i386 buildd up and running, but more servers (in numbers: 3) are prepared and need to be turned into buildds.

After working on Wanna-build and dak, I fully understand why Canonical developed Launchpad and it’s Soyuz module for Ubuntu. But I think we might be able to achieve something similar, using just the tools Debian already uses (maybe a little less confortable than LP, but setting up an own LP instance would have been much more trouble).

Debian archive import

The import of packages from the Debian archive has finished. Importing the archive resulted in many issues and some odd findings (I didn’t know that there are packages in the archive which didn’t receive an upload since 2004!), but it has finally finished, and the archive is in a consistent state at time. To have a continuous package import from Debian while a distribution is in development, we need some changes to wanna-build, which will hopefully be possible.

Online package search

The Online-Package-Search is (after resolving many issues, who expected that? ) up and running. You can search for any package there. Some issues are remaining, e.g. the file-contents-listing doesn’t work, and changelog support is broken, but the basic functionality is there.

Tanglu Bugtracker

We now also have a bugtracker which is based on the Trac software. The Tanglu-Bugtracker is automatically synced with the Tanglu archive, meaning that you find all packages in Trac to report bugs against them. The dak will automatically update new packages every day. Trac still needs a few confort-adjustments, e.g. submitting replies via email or tracking package versions.

Tanglu base system

The Tanglu metapackages have been published in a first alpha version. We will support GNOME-3 and KDE4, as long as this is possible (= enough people working on the packaging). The Tanglu packages will also depend on systemd, which we will need in GNOME anyway, and which also allows some great new features in KDE.

Side-effect of using systemd is – at least for the start – that Tanglu boots a bit slow, because we haven’t done any systemd adjustments, and because systemd is very old. We will have to wait for the systemd and udev maintainers to merge the packages and release a new version first, before this will improve. (I don’t want to do this downstream in Tanglu, because I don’t know the plans for that at Debian (I only know the information Tollef Fog Heen & Co. provided at FOSDEM))

The community

The community really surprised me! We got an incredible amount of great feedback on Tanglu, and most of the people liked the idea of Tanglu. I think we are one of the less-flamed new distributions ever started . Also, without the very active community, kickstarting Tanglu would not have been possible. My guess was that we might be able to have something running next year. Now, with the community help, I see a chance for a release in October

The only thing people complained about was the name of the distribution. And to be really honest, I am not too happy with the name. But finding a name was an incredibe difficult process (finding something all parties liked), and Tanglu was a good compromise. “Tanglu” has absolutely no meaning, it was taken because it sounded interesting. The name was created by combining the Brazilian “Tangerine” (Clementine) and the German “Iglu” (igloo). I also dont think the name matters that much, and I am more interested in the system itself than the name of it. Also, companies produce a lot of incredibly weird names, Tanglu is relatively harmless compared to that .

In general, thanks to everyone participating in Tanglu! You are driving the project forward!

The first (planned) release

I hereby announce the name of the first Tanglu release, 1.1 “Aequorea Victoria“. It is Daniel’s fault that Tanglu releases will be named after jellyfishes, you can ask him why if you want I picked Aequorea, because this kind of jellyfish was particularly important for research in molecular biology. The GFP protein, a green fluorescent protein (=GFP), caused a small revolution in science and resulted in a Nobel Prize in 2008 for the researchers involved in GFP research (for the interested people: You can tag proteins with GFP and determine their position using light microscopy. GFP also made many other fancy new lab methods possible).

Because Tanglu itself is more or less experimental at time, I found the connection to research just right for the very first release. We don’t have a time yet when this version will be officially released, but I expect it to be in October, if the development speed increases a little and more developers get interested and work on it.

Project Policy

We will need to formalize the Tanglu project policy soon, both the technical and the social policies. In general, regarding free software and technical aspects, we strictly adhere to the Dbian Free Software Guidelines, the Debian Social Contract and the Debian Policy. Some extra stuff will be written later, please be patient!

Tanglu OIN membership

I was approached by the Open Invention Network, to join it as member. In general, I don’t have objections to do that, because it will benefit Tanglu. However, the OIN has a very tolerant public stance on software patents, which I don’t like that much. Debian did not join the OIN for this reason. For Tanglu, I think we could still join the OIN without someone thinking that we support the stance on software patents. Joining would simply be pragmatic: We support the OIN as a way to protect the Linux ecosystem from software patents, even if we don’t like the stance on software patents and see it differently.

Because this affects the whole Tanglu project, I don’t want to decide this alone, but get some feedback from the Tanglu community before making a decision.

Can I install Tanglu now?

Yes and no. We don’t provide installation images yet, so trying Tanglu is a difficult task (you need to install Debian and then upgrade it to Tanglu) – if you want to experiment with it, I recomment trying Tanglu in a VM.

I want to help!

Great, then please catch one of us on IRC or subscribe to the mailinglists. The best thing is not to ask for work, but suggest something you want to do, others will then tell you if that is possible and maybe help with the task.

Packages can for now only be uploaded by Debian Developers, Ubuntu Developers or Debian Maintainers who contacted me directly and whose keys have been verified. This will be changed later, but at the current state of the Tanglu archive (= less safety checks for packages), I only want people to upload stuff who definitely have the knowledge to create sane packages (you can also proove that otherwise, of course). We will later establish a new-member process.

If you want to provide a Tanglu archive mirror, we would be very happy, so that the main server doesn’t have to carry all the load.

If you have experience in creating Linux Live-CDs or have worked with the Ubiquity installer, helping with these parts would be awesome!

Unfortunately, we cannot reuse parts of Linux Mint Debian, because many of their packages don’t build from source and are repackaged binaries, which is a no-go for the Tanglu main archive.

Sneak peek

And here is a screenshot of the very first Tanglu installation (currently more Debian than Tanglu):

Something else…

I am involved in Debian for a very long time now, first as Debian Maintainer and then as Debian Developer – and I never thought much about the work the Debian system administrators do. I didn’t know how dak worked or how Wanna-build handles the buildds and what exactly the ftpmasters have to do. By not knowing, I mean I knew the very basic theory and what these people do. But this is something different than experiencing how much work setting up and maintaining the infrastructure is and what an awesome job the people do for Debian, keeping it all up and running and secure! Kudos for that, to all people maintaining Debian infrastructure! You rock! (And I will never ever complain about slow buildds or packages which stay in NEW for too long )

Raphael Geissert: How the world ended up in Costa Rica

8 April, 2013 - 15:30
Even though I haven't had much time to dedicate to lately, it has been up and running, or should I say serving?

Part of its job is to detect mirrors that have temporary issues or are entirely gone, down, unavailable. It does so, and many other things, by monitoring the so-called "trace files". A very important one being the "master" (or "origin") trace file.

With the recent integration of backports into the main archive, the master trace file of the backports mirrors also changed. Long story short, this change caused backports mirrors to no longer be considered by the mirror redirector as candidates. As long as they were up to date.

After the usual mirror synchronisation delay, more and more mirrors were disabled and subsets of "up to date" candidates re-calculated. This reached a critical point when only one mirror was left in the database. The mirror had not been synchronised for a couple of weeks.

This mirror is located in Costa Rica, and as the only candidate left in the database it was the only one used to serve requests for the backports archive. No matter where the client was located in the world.

The issue was later noticed and the necessary updates to the mirrors master list made. Mirrors started to be re-considered as they were re-checked (with some delay due to the rate limiter) and the subsets re-calculated. In a few hours everything was back to normality.

Correctness and fault-tolerance don't always get together very well...

Bits from Debian: Debian joins Free & Open Source Software Outreach Program for Women

8 April, 2013 - 14:01

The GNOME Foundation started the Free & Open Source Software Outreach Program for Women, OPW, in 2010. In the January-April 2013 round, many other FOSS organizations joined the program. We are happy to announce that Debian will also join in the next round from June-September and we'll offer one internship.

You can find more details about Debian's participation in the program at Debian OPW page.

Call for mentors and projects

OPW allows applicants to work on any kind of project, including coding, design, marketing, web development... The Debian Google Summer of Code projects will be offered also as possible projects for OPW, but GSoC only allows coding projects. If you have any idea of a non-coding project and you want to mentor it, please contact us in the soc-coordination mailing list adding [OPW] in subject.

OPW works in the same way as GSoC except Google doesn't play a part here. The same advice that is provided for GSoC mentors works for OPW mentors.

Call for participants

The main goal of this program is to increase the number of women in FOSS, so all women who are not yet a Debian Developer or a Debian Maintainer are encouraged to apply. There are no age restrictions and applicants don't need to be a student.

If you want to apply, you must follow three steps:

  1. Choose a project from this list. There are two lists, one for GSoC and another with non-coding tasks that can be only offered by the OPW. Those lists may change and add or remove more projects in the next few weeks.

  2. Make a small contribution to Debian. Projects will add a task the applicant must complete as part of the pre-selection process. If no task is provided, you are welcome to ask the mentors of the project. You can also make a different extra task of the one listed to show your skills and interest.

  3. Create a page in the Debian wiki with your application. You can do so under pseudonym, but in that case, please give us information about yourself privately by email to the coordinators listed in the Debian OPW page!

Bits from Debian: DebConf14 to be held in Portland, Oregon, USA

8 April, 2013 - 06:01

We are pleased to announce the 15th annual Debian Conference (DebConf14) is to be held in Portland, Oregon, USA in August 2014, with specific dates yet to be announced.

Portland is an open source hotspot in the Pacific Northwest of the US. It is a technologically savvy community, home to Intel and the adopted home of Linus Torvalds. The city plays host to many Free Software conferences including OSCON, and is where Linux Plumbers originated.

The local team has been involved in mulitple DebConfs in the past, and is excited to bring their experience and ideas to fruition in a city well-positioned to host such a prestigious event.

Rapha&#235;l Hertzog: My Free Software Activities in March 2013

8 April, 2013 - 00:29

This is my monthly summary of my free software related activities. If you’re among the people who made a donation to support my work (114.19 €, thanks everybody!), then you can learn how I spent your money. Otherwise it’s just an interesting status update on my various projects.

Simple-CDD and debian-cd

I tried to use wheezy’s version of debian-cd and simple-cdd to generate an automatic installer. In this process, I filed a couple of bugs on simple-cdd (#701963: type-handling package is gone and should not be listed in default.downloads, and #701998: the --keyboard parameter is not working with wheezy’s debian-installer) and I commited fixes for a few issues in debian-cd:

  • r2518: adjust Makefile for new xorriso requirement
  • r2520: add missing depends on dosfstools
  • r2521: use --no-check-gpg when querying debootstrap
  • r2522: make debian-cd work with a mirror without sources)
Debian France

I completed the new website for Debian France and I put it online. Later I merged some supplementary enhancements prepared by Tanguy Ortolo (and I gave him commits rights at the same time).

I tried to update our Galette installation to the latest upstream version but I reverted to the former version after having encountered two problems (filed here and here). In the process, I created a Debian package for galette (you can grab it on

I also suggested an idea of improvement for Galette’s paypal plugin and it has been quickly implemented. Thus I updated the plugin installed on

Kali related work

It’s been a few months that I have been helping the Kali team to prepare this new Debian derivative. Now that the derivative has gone public, I can attribute some of my Debian work to my collaboration with the Kali team.

This month I contributed a few features and fixes to debian-installer and live-build:

After the launch, we registered Kali in the derivative census. Paul Wise quickly reported some misfiled bugs from early Kali users and I discovered that reportbug was not behaving properly even though we correctly updated base-files (see #703678 on reportbug and #703677 on lsb-release).

Misc packaging work
  • I sponsored a new upstream version of dnsjava because it’s required by Jitsi.
  • I prepared rebuild and uploaded it to testing-proposed-updates for a RC bug fix.
  • I uploaded Publican 3.1.5 to experimental and filed #703514 to request a new upstream version of docbook-xsl that is needed by Publican.
  • I filed #703995 to fix apt-setup’s handling of the apt-setup/multiarch preseed option.
DPL election

I also spent quite some time to read and participate to the discussions on debian-vote since it was campaigning time for the DPL candidates


This was a rather active month if you take into account the fact that I got a second son — Lucas — on March 6th.

See you next month for a new summary of my activities.

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

Olivier Berger: Migrating picture tags from KPhotoAlbum to digiKam (or others) through IPTC

7 April, 2013 - 20:54

I've occasionally used KPhotoAlbum for a few years and eventually added many tags to the pictures.

But I've decided I wanted to try other tools, and digiKam seems to be the best option from the many reviews I've read.

Still, there's apparently no automatic feature to import into digiKam the tags set in KPhotoAlbum.

Fortunately, some smart people have implemented Perl tools allowing to overcome this issue.

The process involves modifying the pictures to save the tags inside the files, using the IPTC standard. Then, digiKam will be able to load the tags from the modified files.

Here's a copy of the (translated) script (the original as in french) I copied from this blog post (in french too).

I've been able to generate .deb packages for the required 2 perl libs dependencies using the method described in the referenced post , with : dh-make-perl  --build --cpan Image::Kimdaba and dh-make-perl  --build --cpan Image::IPTCInfo

Thanks to Pierre Doucet and Bruno Adele for sharing this. Hope this helps.

Andrew Pollock: [life/repatexpat] Getting online

7 April, 2013 - 12:22

I'd decided ahead of time that I wanted to use Internode as my ISP, and had ordered a Naked DSL service from them and also decided to bundle my mobile phone with them as well. For reasons that only made sense to me 7 years ago, I've been paying Telstra to keep my mobile number going, but I've long since lost the SIM. My current phone has a micro-SIM anyway, so I needed a replacement SIM.

My grand plan had been to order the SIM, order the number port from Telstra to Internode, and then, well, profit from the moment I stuck the SIM in my phone. Unfortunately the port didn't go through as planned, and I was left incommunicado for the better part of two and a half days. I felt like I had my hands tied behind my back not having a mobile data service. It was also mildly annoying not being able to call people or be contactable, given the amount of running around I was doing. But it got resolved and is fast becoming a distant memory.

The DSL service required a Telstra technician to come out (I'm not actually sure why) and that was scheduled for Thursday. I happened to catch him while he was at my building's MDF, and had a bit of a chat with him. He was a Scotsman, and I didn't get all the details, but he was going on about how he was only there to operate on the exchange side of the MDF, and I'd have to get someone else to jumper it up to my apartment.

This wasn't what I expected from an installation service, but sure enough when I finally got around to plugging the ADSL modem in on Saturday morning, there was no line sync to be had. A call to Internode confirmed that he'd only jumpered it up to exchange side of the MDF.

What was even more annoying was I'm pretty sure I saw him yanking out jumper wires from the MDF when he was working on it. Jumper wires that connected the exchange side of the MDF to my apartment.

I was not thrilled with the idea of waiting (and paying) for a cabling contractor to come out and hook up a couple of bits of jumper wire, so I put out a call on Facebook for a Krone tool and a tone generator, and Brent was able to come through for me. He dropped the gear around while I was out shopping with Kristy, and when we got back, I located the pair for my unit, and rejumpered the existing jumper wire that I'm pretty sure the Telstra technician had disconnected. Lo and behold, my ADSL started working. I felt pretty proud of myself. It's fun operating at Layer 1 every now and then.

The FRITZ!Box Fon WLAN 7270 is quite the beast of a box. Not only is it an ADSL modem, it's a wireless router, DECT base station, VoIP thingy and an answering machine! I've managed to connect my Engin account up to it, so once I get a DECT handset, I'll be able to make VoIP calls through it. I don't need to run Asterisk any more.


Creative Commons License ลิขสิทธิ์ของบทความเป็นของเจ้าของบทความแต่ละชิ้น
ผลงานนี้ ใช้สัญญาอนุญาตของครีเอทีฟคอมมอนส์แบบ แสดงที่มา-อนุญาตแบบเดียวกัน 3.0 ที่ยังไม่ได้ปรับแก้