Search Results: "Bdale Garbee"

3 December 2020

Bdale Garbee: Shifting Emphasis

I joined the Debian project in late 1994, well before the first stable release was issued, and have been involved in various ways continuously ever since. Over the years, I adopted a number of packages that are, or at least were at one time, fundamental to the distribution. But, not surprisingly, my interests have shifted over time. In the more than quarter century I've contributed to Debian, I've adopted existing packages that needed attention, packaged new software I wanted to use that wasn't yet in Debian, offered packages up for others to adopt, and even sometimes requested the removal of packages that became obsolete or replaced by something better. That all felt completely healthy. But over the last couple weeks, I realized I'm still "responsible" for some packages I'd had for a very long time, that generally work well but over time have accumulated bugs in functionality I just don't use, and frankly haven't been able to find the motivation to chase down. As one example, I just noticed that I first uploaded the gzip package 25 years ago today, on 2 December 1995. And while the package works fine for me and most other folks, there are 30 outstanding bugs and 3 forwarded bugs that I just can't muster up any energy to address. So, I just added gzip to a short list of packages I've offered up for adoption recently. I'm pleased that tar already has a new maintainer, and hope that both sudo and gzip will get more attention soon. It's not that I'm less interested in Debian. I've just been busy recently packaging up more software I use or want to use in designing high power model rockets and the solid propellant motors I fly in them, and would rather spend the time I have available for Debian maintaining those packages and all their various build dependencies than continuing to be responsible for core packages in the distribution that "work fine for me" but could use attention. I'm writing about this partly to mark the passing of more than a quarter century as a package maintainer for Debian, partly to encourage other Debian package maintainers with the right skills and motivation to consider adopting some of the packages I'm giving up, and finally to encourage other long-time participants in Debian to spend a little time evaluating their own package lists in a similar way.

2 August 2020

Holger Levsen: 20200802-debconf4

DebConf4 This tshirt is 16 years old and from DebConf4. Again, I should probably wash it at 60 celcius for once... DebConf4 was my 2nd DebConf and took place in Porto Alegre, Brasil. Like many DebConfs, it was a great opportunity to meet people: I remember sitting in the lobby of the venue and some guy asked me what I did in Debian and I told him about my little involvements and then asked him what he was doing, and he told me he wanted to become involved in Debian again, after getting distracted away. His name was Ian Murdock... DebConf4 also had a very cool history session in the hallway track (IIRC, but see below) with Bdale Garbee, Ian Jackson and Ian Murdock and with a young student named Biella Coleman busy writing notes. That same hallway also saw the kickoff meeting of the Debian Women project, though sadly today ("there's no cabal") only shows an apache placeholder page and not a picture of that meeting. DebCon4 was also the first time I got a bit involved in preparing DebConf, together with Jonas Smedegaard I've set up some computers there, using FAI. I had no idea that this was the start of me contributing to DebConfs for text ten years. And of course I also saw some talks, including one which I really liked, which then in turn made me notice there were no people doing video recordings, which then lead to something... I missed the group picture of this one. I guess it's important to me to mention it because I've met very wonderful people at this DebConf... (some mentioned in this post, some not. You know who you are!) Afterwards some people stayed in Porto Alegre for FISL, where we saw Lawrence Lessing present Creative Commons to the world for the first time. On the flight back I sat next to a very friendly guy from Poland and we talked almost the whole flight and then we never saw each other again, until 15 years later in Asia... Oh, and then, after DebConf4, I used IRC for the first time. And stayed in the #debconf4 IRC channel for quite some years :) Finally, DebConf4 and more importantly FISL, which was really big (5000 people?) and after that, the wizard of OS conference in Berlin (which had a very nice talk about Linux in different places in the world, illustrating the different states of 'first they ignore you, then they laugh at you, then they fight you, then you win'), made me quit my job at a company supporting Windows- and Linux-setups as I realized I'd better start freelancing with Linux-only jobs. So, once again, my life would have been different if I would not have attended these events! Note: yesterdays post about DebConf3 was thankfully corrected twice. This might well happen to this post too! :)

1 March 2017

Petter Reinholdtsen: Unlimited randomness with the ChaosKey?

A few days ago I ordered a small batch of the ChaosKey, a small USB dongle for generating entropy created by Bdale Garbee and Keith Packard. Yesterday it arrived, and I am very happy to report that it work great! According to its designers, to get it to work out of the box, you need the Linux kernel version 4.1 or later. I tested on a Debian Stretch machine (kernel version 4.9), and there it worked just fine, increasing the available entropy very quickly. I wrote a small test oneliner to test. It first print the current entropy level, drain /dev/random, and then print the entropy level for five seconds. Here is the situation without the ChaosKey inserted:
% cat /proc/sys/kernel/random/entropy_avail; \
  dd bs=1M if=/dev/random of=/dev/null count=1; \
  for n in $(seq 1 5); do \
     cat /proc/sys/kernel/random/entropy_avail; \
     sleep 1; \
0+1 oppf ringer inn
0+1 oppf ringer ut
28 byte kopiert, 0,000264565 s, 106 kB/s
The entropy level increases by 3-4 every second. In such case any application requiring random bits (like a HTTPS enabled web server) will halt and wait for more entrpy. And here is the situation with the ChaosKey inserted:
% cat /proc/sys/kernel/random/entropy_avail; \
  dd bs=1M if=/dev/random of=/dev/null count=1; \
  for n in $(seq 1 5); do \
     cat /proc/sys/kernel/random/entropy_avail; \
     sleep 1; \
0+1 oppf ringer inn
0+1 oppf ringer ut
104 byte kopiert, 0,000487647 s, 213 kB/s
Quite the difference. :) I bought a few more than I need, in case someone want to buy one here in Norway. :) Update: The dongle was presented at Debconf last year. You might find the talk recording illuminating. It explains exactly what the source of randomness is, if you are unable to spot it from the schema drawing available from the ChaosKey web site linked at the start of this blog post.

31 January 2017

Bdale Garbee: ACLU

When I was younger, and worked in an "old HP" test and measurement division, I sometimes sat at lunch in the cafeteria with a group of older co-workers who I grew to have immense respect for. They told great stories. I learned a lot of practical electronics from them... and other things too. Each carried on their person a copy of the US Constitution and Bill of Rights, and most also had a "concealed carry" permit, which they would refer to as their "redneck license". I quickly learned that they weren't all gun fanatics... at that time, the vetting process for such a permit was a bit daunting, and having one was their way of "proving" that they were honest, law-abiding citizens. Citizens who knew their rights. Who enjoyed debating boundary conditions in those rights inspired by current events at the lunch table. I miss those guys and those conversations. I mention this because it's one of those things that I realize now had a significant formative impact on my adult values and world view. Freedom matters. That's why, despite my long-standing appreciation for and support of the organization's activities, I'm embarrassed to admit that it wasn't until this week that I personally joined the American Civil Liberties Union and sent them a donation.

30 September 2016

Bdale Garbee: Second Retirement

At the end of August 2012, I announced my Early Retirement from HP. Two years later, my friend and former boss Martin Fink successfully recruited me to return to what later became Hewlett Packard Enterprise, as an HPE Fellow working on open source strategy in his Office of the CTO. I'm proud of what I was was able to accomplish in the 25 months since then, but recent efforts to "simplify" HPE actually made things complicated for me. Between the announcement in late June that Martin intended to retire himself, and the two major spin-merger announcements involving Enterprise Services and Software... well... The bottom line is that today, 30 September 2016, is my last day at HPE. My plan is to "return to retirement" and work on some fun projects with my wife now that we are "empty nesters". I do intend to remain involved in the Free Software and open hardware worlds, but whether that might eventually involve further employment is something I'm going to try and avoid thinking about for a while... There is a rocket launch scheduled nearby this weekend, after all!

23 August 2016

Reproducible builds folks: Reproducible Builds: week 69 in Stretch cycle

What happened in the Reproducible Builds effort between Sunday August 14 and Saturday August 20 2016: Fasten your seatbelts Important note: we enabled build path variation for unstable now, so your package(s) might become unreproducible, while previously it was said to be reproducible given a specific build path it probably still is reproducible but read on for the details below in the section! As said many times: this is still research and we are working to make it reality. Media coverage Daniel Stender blogged about python packaging and explained some caveats regarding reproducible builds. Toolchain developments Thomas Schmitt uploaded xorriso which now obeys SOURCE_DATE_EPOCH. As stated in its man pages:
SOURCE_DATE_EPOCH  belongs to the specs of  It
is supposed to be either undefined or to contain a decimal number which
tells the seconds since january 1st 1970. If it contains a number, then
it is used as time value to set the  default  of  --modification-date=,
--gpt_disk_guid,  and  --set_all_file_dates.  Startup files and program
options can override the effect of SOURCE_DATE_EPOCH.
Packages reviewed and fixed, and bugs filed The following packages have become reproducible after being fixed: The following updated packages appear to be reproducible now, for reasons we were not able to figure out. (Relevant changelogs did not mention reproducible builds.) The following 2 packages were not changed, but have become reproducible due to changes in their build-dependencies: tagsoup tclx8.4. Some uploads have addressed some reproducibility issues, but not all of them: Patches submitted that have not made their way to the archive yet: Bug tracker house keeping: Reviews of unreproducible packages 55 package reviews have been added, 161 have been updated and 136 have been removed in this week, adding to our knowledge about identified issues. 2 issue types have been updated: Weekly QA work FTBFS bugs have been reported by: diffoscope development Chris Lamb, Holger Levsen and Mattia Rizzolo worked on diffoscope this week. Improvements were made to SquashFS and JSON comparison, the web service, documentation, packaging, and general code quality. diffoscope 57, 58, and 59 were uploaded to unstable by Chris Lamb. Versions 57 and 58 were both broken, so Holger set up a job on to test diffoscope on each git commit. He also wrote a CONTRIBUTING document to help prevent this from happening in future. From these efforts, we were also able to learn that diffoscope is now reproducible even when built across multiple architectures:
< h01ger> shows these packages were built on amd64:
< h01ger>    bd21db708fe91c01ba1c9cb35b9d41a7c9b0db2b 62288 diffoscope_59_all.deb
< h01ger>    366200bf2841136a4c8f8c30bdc87057d59a4cdd 20146 trydiffoscope_59_all.deb
< h01ger>   and on i386:
< h01ger>    bd21db708fe91c01ba1c9cb35b9d41a7c9b0db2b 62288 diffoscope_59_all.deb
< h01ger>    366200bf2841136a4c8f8c30bdc87057d59a4cdd 20146 trydiffoscope_59_all.deb
< h01ger>   and on armhf:
< h01ger>    bd21db708fe91c01ba1c9cb35b9d41a7c9b0db2b 62288 diffoscope_59_all.deb
< h01ger>    366200bf2841136a4c8f8c30bdc87057d59a4cdd 20146 trydiffoscope_59_all.deb
And those also match the binaries uploaded by Chris in his diffoscope 59 binary upload to, yay! Eating our own dogfood and enjoying it! Debian related: The last change probably will have an impact you will see: your package might become unreproducible in unstable and this will be shown on, while it will still be reproducible in testing. We've done this, because we think reproducible builds are possible with arbitrary build paths. But: we don't think those are a realistic goal for stretch, where we still recommend to use .buildinfo to record the build patch and then do rebuilds using that path. We are doing this, because besides doing theoretical groundwork we also have a practical goal: enable users to independently verify builds. And if they only can do this with a fixed path, so be it. For now :) To be clear: for Stretch we recommend that reproducible builds are done in the same build path as the "original" build. Finally, and just for our future references, when we enabled build path variation on Saturday, August 20th 2016, the numbers for unstable were:
suite all reproducible unreproducible ftbfs depwait not for this arch blacklisted
unstable/amd64 24693 21794 (88.2%) 1753 (7.1%) 972 (3.9%) 65 (0.2%) 95 (0.3%) 10 (0.0%)
unstable/i386 24693 21182 (85.7%) 2349 (9.5%) 972 (3.9%) 76 (0.3%) 103 (0.4%) 10 (0.0%)
unstable/armhf 24693 20889 (84.6%) 2050 (8.3%) 1126 (4.5%) 199 (0.8%) 296 (1.1%) 129 (0.5%)
Misc. Ximin Luo updated our git setup scripts to make it easier for people to write proper descriptions for our repositories. This week's edition was written by Ximin Luo and Holger Levsen and reviewed by a bunch of Reproducible Builds folks on IRC.

3 August 2016

Bdale Garbee: ChaosKey

I'm pleased to announce that, at long last, the ChaosKey hardware random number generator described in talks at Debconf 14 in Portland and Debconf 16 in Cape Town is now available for purchase from Garbee and Garbee.

21 March 2016

Lunar: Reproducible builds: week 47 in Stretch cycle

What happened in the reproducible builds effort between March 13th and March 19th 2016:

Toolchain fixes
  • Petter Reinholdtsen uploaded naturaldocs/1.51-1.1 which makes the output reproducible. Original patch by Chris Lamb.
  • Damyan Ivanov uploaded libpdf-api2-perl/2.025-2 which will make internal font ID reproducible.
  • Christian Hofstaedtler uploaded ruby2.3/2.3.0-5 which sets gzip embedded mtime field to fixed value for rdoc-generated compressed javascript data.

Packages fixed The following packages have become reproducible due to changes in their build dependencies: diction, doublecmd, ruby-hiredis, vdr-plugin-epgsearch. The following packages became reproducible after getting fixed: Some uploads fixed some reproducibility issues, but not all of them: Patches submitted which have not made their way to the archive yet:
  • #818128 on nethack by Reiner Herrmann: implement support for SOURCE_DATE_EPOCH, set LC_ALL to C, and ensure deterministic build order when running parallel builds.
  • #818111 on debian-keyring by Satyam Zode: fix the order of files in md5sums.
  • #818067 on ncurses by Niels Thykier: strip trailing whitespaces introduced when using dash as system shell.
  • #818230 on aircrack-ng by Reiner Herrmann: build assembly code as a separate .o file.
  • #818419 on mutt by Daniel Shahaf: use C locale when listing files to be put in README.Patches.
  • #818430 on ruby-coveralls by Dhole: ensure UTC is used as the timezone when generating the documentation.
  • #818686 on littlewizard by Reiner Herrmann: use the C locale in the script for iterating over the files.
  • #818704 on strigi by Reiner Herrmann: sort keys when traversing hashes in

Package reviews 44 reviews have been removed, 40 added and 5 updated in the previous week. Chris Lamb has reported 16 FTBFS.

1 January 2016

Bdale Garbee: Term Limited

I woke up this morning and realized that for the first time since 17 April 2001, I am no longer a member of the Debian Technical Committee. My departure from the committee is a consequence of the Debian General Resolution "limiting the term of the technical committee members" that was passed amending the Debian Constitution nearly a year ago. As the two longest-serving members, both over the term limit, Steve Langasek and I completed our service yesterday. In early March 2015, I stepped down from the role of chairman after serving in that role for the better part of a decade, to help ensure a smooth transition. Don Armstrong is now serving admirably in that role, I have the utmost respect for the remaining members of the TC, and the process of nominating replacements for the two now-vacant seats is already well underway. So, for the Debian project as a whole, today is really a non-event... which is exactly as it should be! Debian has been a part of my life since 1994, and I sincerely hope to be able to remain involved for many years to come!

23 November 2015

Thomas Goirand: OpenStack Liberty and Debian

Long over due post It s been a long time I haven t written here. And lots of things happened in the OpenStack planet. As a full time employee with the mission to package OpenStack in Debian, it feels like it is kind of my duty to tell everyone about what s going on. Liberty is out, uploaded to Debian Since my last post, OpenStack Liberty, the 12th release of OpenStack, was released. In late August, Debian was the first platform which included Liberty, as I proudly outran both RDO and Canonical. So I was the first to make the announcement that Liberty passed most of the Tempest tests with the beta 3 release of Liberty (the Beta 3 is always kind of the first pre-release, as this is when feature freeze happens). Though I never made the announcement that Liberty final was uploaded to Debian, it was done just a single day after the official release. Before the release, all of Liberty was living in Debian Experimental. Following the upload of the final packages in Experimental, I uploaded all of it to Sid. This represented 102 packages, so it took me about 3 days to do it all. Tokyo summit I had the pleasure to be in Tokyo for the Mitaka summit. I was very pleased with the cross-project sessions during the first day. Lots of these sessions were very interesting for me. In fact, I wish I could have attended them all, but of course, I can t split myself in 3 to follow all of the 3 tracks. Then there was the 2 sessions about Debian packaging on upstream OpenStack infra. The goal is to setup the OpenStack upstream infrastructure to allow packaging using Gerrit, and gating each git commit using the usual tools: building the package and checking there s no FTBFS, running checks like lintian, piuparts and such. I knew already the overview of what was needed to make it happen. What I didn t know was the implementation details, which I hoped we could figure out during the 1:30 slot. Unfortunately, this didn t happen as I expected, and we discussed more general things than I wished. I was told that just reading the docs from the infra team was enough, but in reality, it was not. What currently needs to happen is building a Debian based image, using disk-image-builder, which would include the usual tools to build packages: git-buildpackage, sbuild, and so on. I m still stuck at this stage, which would be trivial if I knew a bit more about how upstream infra works, since I already know how to setup all of that on a local machine. I ve been told by Monty Tailor that he would help. Though he s always a very busy man, and to date, he still didn t find enough time to give me a hand. Nobody replied to my request for help in the openstack-dev list either. Hopefully, with a bit of insistence, someone will help. Keystone migration to Testing (aka: Debian Stretch) blocked by python-repoze.who Absolutely all of OpenStack Liberty, as of today, has migrated to Stretch. All? No. Keystone is blocked by a chain of dependency. Keystone depends on python-pysaml2, itself blocked by python-repoze.who. The later, I upgraded it to version 2.2. Though python-repoze.what depends on version <= 1.9, which is blocking the migration. Since python-repoze.who-plugins, python-repoze.what and python-repoze.what-plugins aren t used by any package anymore, I asked for them to be removed from Debian (see #805407). Until this request is processed by the FTP masters, Keystone, which is the most important piece of OpenStack (it does the authentication) will be blocked for migration to Stretch. New OpenStack server packages available On my presentation at Debconf 15, I quickly introduced new services which were released upstream. I have since packaged them all: Congress, unfortunately, was not accepted to Sid yet, because of some licensing issues, especially with the doc of python-pulp. I will correct this (remove the non-free files) and reattempt an upload. I hope to make them all available in jessie-backports (see below). For the previous release of OpenStack (ie: Kilo), I skipped the uploads of services which I thought were not really critical (like Ironic, Designate and more). But from the feedback of users, they would really like to have them all available. So this time, I will upload them all to the official jessie-backports repository. Keystone v3 support For those who don t know about it, Keystone API v3 means that, on top of the users and tenant, there s a new entity called a domain . All of the Liberty is now coming with Keystone v3 support. This includes the automated Keystone catalog registration done using debconf for all *-api packages. As much as I could tell by running tempest on my CI, everything still works pretty well. In fact, Liberty is, to my experience, the first release of OpenStack to support Keystone API v3. Uploading Liberty to jessie-backports I have rebuilt all of Liberty for jessie-backports on my laptop using sbuild. This is more than 150 packages (166 packages currently). It took me about 3 days to rebuild them all, including unit tests run at build time. As soon as #805407 is closed by the FTP masters, all what s remaining will be available in Stretch (mostly Keystone), and the upload will be possible. As there will be a lot of NEW packages (from the point of view of backports), I do expect that the approval will take some time. Also, I have to warn the original maintainers of the packages that I don t maintain (for example, those maintained within the DPMT), that because of the big number of packages, I will not be able to process the usual communication to tell that I m uploading to backports. However, here s the list of package. If you see one that you maintain, and that you wish to upload the backport by yourself, please let me know. Here s the list of packages, hopefully, exhaustive, that I will upload to jessie-backports, and that I don t maintain myself: alabaster contextlib2 kazoo python-cachetools python-cffi python-cliff python-crank python-ddt python-docker python-eventlet python-git python-gitdb python-hypothesis python-ldap3 python-mock python-mysqldb python-pathlib python-repoze.who python-setuptools python-smmap python-unicodecsv python-urllib3 requests routes ryu sphinx sqlalchemy turbogears2 unittest2 zzzeeksphinx. More than ever, I wish I could just upload these to a PPA^W Bikeshed, to minimize the disruption for both the backports FTP masters, other maintainers, and our OpenStack users. Hopefully, Bikesheds will be available soon. I am sorry to give that much approval work to the backports FTP masters, however, using the latest stable system with the latest release, is what most OpenStack users really want to do. All other major distributions have specific repositories too (ie: RDO for CentOS / Red Hat, and cloud archive for Ubuntu), and stable-backports is currently the only place where I can upload support for the Stable release. Debian listed as supported distribution on Good news! If you go at you will see a list of supported distributions. I am proud to be able to tell that, after 6 months of lobbying from my side, Debian is also listed there. The process of having Debian there included talking with folks from the OpenStack foundation, and having Bdale to sign an agreement so that the Debian logo could be reproduced on Thanks to Bdale Garbee, Neil McGovern, Jonathan Brice, and Danny Carreno, without who this wouldn t have happen.

1 September 2015

Lunar: Reproducible builds: week 18 in Stretch cycle

What happened in the reproducible builds effort this week: Toolchain fixes Aur lien Jarno uploaded glibc/2.21-0experimental1 which will fix the issue were locales-all did not behave exactly like locales despite having it in the Provides field. Lunar rebased the pu/reproducible_builds branch for dpkg on top of the released 1.18.2. This made visible an issue with udebs and automatically generated debug packages. The summary from the meeting at DebConf15 between ftpmasters, dpkg mainatainers and reproducible builds folks has been posted to the revelant mailing lists. Packages fixed The following 70 packages became reproducible due to changes in their build dependencies: activemq-activeio, async-http-client, classworlds, clirr, compress-lzf, dbus-c++, felix-bundlerepository, felix-framework, felix-gogo-command, felix-gogo-runtime, felix-gogo-shell, felix-main, felix-shell-tui, felix-shell, findbugs-bcel, gco, gdebi, gecode, geronimo-ejb-3.2-spec, git-repair, gmetric4j, gs-collections, hawtbuf, hawtdispatch, jack-tools, jackson-dataformat-cbor, jackson-dataformat-yaml, jackson-module-jaxb-annotations, jmxetric, json-simple, kryo-serializers, lhapdf, libccrtp, libclaw, libcommoncpp2, libftdi1, libjboss-marshalling-java, libmimic, libphysfs, libxstream-java, limereg, maven-debian-helper, maven-filtering, maven-invoker, mochiweb, mongo-java-driver, mqtt-client, netty-3.9, openhft-chronicle-queue, openhft-compiler, openhft-lang, pavucontrol, plexus-ant-factory, plexus-archiver, plexus-bsh-factory, plexus-cdc, plexus-classworlds2, plexus-component-metadata, plexus-container-default, plexus-io, pytone, scolasync, sisu-ioc, snappy-java, spatial4j-0.4, tika, treeline, wss4j, xtalk, zshdb. The following packages became reproducible after getting fixed: Some uploads fixed some reproducibility issues but not all of them: Patches submitted which have not made their way to the archive yet: Chris Lamb also noticed that binaries shipped with libsilo-bin did not work. Documentation update Chris Lamb and Ximin Luo assembled a proper specification for SOURCE_DATE_EPOCH in the hope to convince more upstreams to adopt it. Thanks to Holger it is published under a non-Debian domain name. Lunar documented easiest way to solve issues with file ordering and timestamps in tarballs that came with tar/1.28-1. Some examples on how to use SOURCE_DATE_EPOCH have been improved to support systems without GNU date. armhf is finally being tested, which also means the remote building of Debian packages finally works! This paves the way to perform the tests on even more architectures and doing variations on CPU and date. Some packages even produce the same binary Arch:all packages on different architectures (1, 2). (h01ger) Tests for FreeBSD are finally running. (h01ger) As it seems the gcc5 transition has cooled off, we schedule sid more often than testing again on amd64. (h01ger) disorderfs has been built and installed on all build nodes (amd64 and armhf). One issue related to permissions for root and unpriviliged users needs to be solved before disorderfs can be used on (h01ger) strip-nondeterminism Version 0.011-1 has been released on August 29th. The new version updates dh_strip_nondeterminism to match recent changes in debhelper. (Andrew Ayer) disorderfs disorderfs, the new FUSE filesystem to ease testing of filesystem-related variations, is now almost ready to be used. Version 0.2.0 adds support for extended attributes. Since then Andrew Ayer also added support to reverse directory entries instead of shuffling them, and arbitrary padding to the number of blocks used by files. Package reviews 142 reviews have been removed, 48 added and 259 updated this week. Santiago Vila renamed the not_using_dh_builddeb issue into varying_mtimes_in_data_tar_gz_or_control_tar_gz to align better with other tag names. New issue identified this week: random_order_in_python_doit_completion. 37 FTBFS issues have been reported by Chris West (Faux) and Chris Lamb. Misc. h01ger gave a talk at FrOSCon on August 23rd. Recordings are already online. These reports are being reviewed and enhanced every week by many people hanging out on #debian-reproducible. Huge thanks!

10 June 2015

DebConf team: DebConf15 Invited speakers (Posted by DebConf Team)

This year, on top of the many excellent contributed talks, BoFs, and other events always part of DebConf (some of which have already been announced) we are excited to have confirmed the following keynote speakers. During the Open Weekend (Saturday, August 15th and Sunday, August 16th), we will have keynotes delivered by: On the last day of DebConf, we look forward to the closing keynote by: For more information about our invited speakers, please see Citizenfour Screening Additionally, there will be a screening of the Citizenfour movie, winner of the Best Documentary Feature Academy Award on the evening of Friday, August 21st. You still have time to submit your talk There are only a few days left before the end of the Call for Proposals on June 15th. Events submitted after that date might not be part of the official DebConf schedule. So, please, hurry, check out the proposal submission guide and submit your event. Regards from the DebConf Team

18 January 2014

James Bromberger: 2014: LCA TV

The radio silence here on my blog has been not from lack of activity, but the inverse. chewed up the few remaining spare cycles I have had recently (after family and work), but not from organising the conference (been there, got the T-Shirt and the bag). So, let s do a run through of what has happened LCA2014 Perth has come and gone in pretty smooth fashion. A remarkable effort from the likes of the Perth crew of Luke, Paul, Euan, Leon, Jason, Michael, and a slew of volunteers who stepped up not to mention our interstate firends of Steve and Erin, Matthew, James I, Tim the Streaming guy and others, and our pro organisers at Manhattan Events. It was a reasonably smooth ride: the UWA campus was beautiful, the leacture theatres were workable, and the Octogon Theatre was at its best when filled with just shy of 500 like minded people and an accomplished person gracing the stage. What was impressive (to me, at least) was the effort of the AV team (which I was on the extreme edges of); videos of keynotes hit the Linux Australia mirror within hours of the event. Recording and live streaming of all keynotes and sessions happend almost flawlessly. Leon had built a reasonably robust video capture management system (eventstreamer on github) to ensure that people fresh to DVswitch had nothing break so bad it didn t automatically fix itself and all of this was monitored from the Operations Room (called the TAVNOC, which would have been the AV NOC, but somehow a loose reference to the UWA Tavern the Tav crept in there). Some 167 videos were made and uploaded most of this was also mirrored on campus before th end of the conference so attendees could load up their laptops with plenty of content for the return trip home. Euan s quick Blender work meant there was a nice intro and outro graphic, and Leon s scripting ensured that Zookeepr, the LCA conference manegment software, was the source of truth in getting all videos processed and tagged correctly. I was scheduled (and did give) a presentation at LCA 2014 about Debian on Amazon Web Services (on Thursday), and attended as many of the sessions as possible, but my good friend Michael Davies (LCA 2004 chair, and chair of the LCA Papers Committee for a good many years) had another role for this year. We wanted to capture some of the hallway track of that is missed in all the videos of presentations. And thus was born LCA TV. LCA TV consisted of the video equipment for an additional stream mixer host, cameras, cables and switches, hooking into the same streaming framework as the rest of the sessions. We took over a corner of the registration room (UWA Undercroft), brought in a few stage lights, a couch, coffee table, seat, some extra mics, and aimed to fill the session gaps with informal chats with some of the people at speakers, attendees, volunteers alike. And come they did. One or two interviews didn t succeed (this was an experiment), but in the end, we ve got over 20 interviews with some interesting people. These streamed out live to the people watching LCA from afar; those unable to make it to Perth in early January; but they were recorded too and we can start to watch them (see below) I was also lucky enough to mix the video for the three keynotes as well as the opening and closing, with very capable crew around the Octogon Theatre. As the curtain came down, and the 2014 crew took to the stage to be congratulated by the attendees, I couldn t help but feel a little bit proud and a touch nostalgic memories from 11 years earlier when LCA 2003 came to a close in the very same venue. So, before we head into the viewing season for LCA TV, let me thank all the volunteers who organised, the AV volunteers, the Registration volunteers, the UWA team who helped with Octogon, Networking, awesome CB Radios hooked up to the UWA repeated that worked all the way to the airport. Thanks to the Speakers who submitted proposals. The Speakers who were accepted, made the journey and took to the stage. The people who attended. The sponsors who help make this happen. All of the above helps share the knowledge, and ultimately, move the community forward. But my thanks to Luke and Paul for agreeing to stand there in the middle of all this madness and hive of semi structured activity that just worked. Please remember this was experimental; the noise was the buzz of the conference going on around us. There was pretty much only one person on the AV kit my thanks to Andrew Cooks who I ll dub as our sound editor, vision director, floor manager, and anything else. So who did we interview? One or two talks did not work, so appologies to those that are missing. Here s the playlist to start you off! Enjoy.

19 November 2013

Rapha&#235;l Hertzog: Will Debian s technical committee coopt Keith Packard or Philipp Kern?

The process has been ongoing for more than a year but the Debian technical committee is about to select a candidate to recommend for its vacant seat. The Debian Project Leader will then (likely) appoint him (looks like it won t be a women). According to recent discussions on, it seems that either Keith Packard or Philipp Kern will join the committee. If you look at the current membership of the committee, you will see: That s very Anglo-Saxon centric (6 out of 7 members). While I trust the current members and while I know that they are open-minded people, it still bothers me to see this important body with so few diversity. Coming back to the choice at hand, Keith Packard is American and Philipp Kern is German. No new country in the mix. I can only hope that Philipp will be picked to bring some more balance in the body.

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

27 September 2013

Petter Reinholdtsen: Videos about the Freedombox project - for inspiration and learning

The Freedombox project have been going on for a while, and have presented the vision, ideas and solution several places. Here is a little collection of videos of talks and presentation of the project. A larger list is available from the Freedombox Wiki. On other news, I am happy to report that Freedombox based on Debian Jessie is coming along quite well, and soon both Owncloud and using Tor should be available for testers of the Freedombox solution. :) In a few weeks I hope everything needed to test it is included in Debian. The withsqlite package is already in Debian, and the plinth package is pending in NEW. The third and vital part of that puzzle is the metapackage/setup framework, which is still pending an upload. Join us on IRC (#freedombox on and the mailing list if you want to help make this vision come true.

21 May 2013

Bdale Garbee: Introducing TeleBT

Keith and I are pleased to announce the immediate availability of TeleBT, a new Altus Metrum ground station product providing the equivalent of TeleDongle plus Bluetooth. TeleBT working with AltosDroid on an Android device provides everything needed to monitor a rocket in flight, record telemetry, and know how to walk right to the airframe after it's back on the ground. The Bluetooth capability of TeleBT is also supported by AltosUI on Linux, and with a micro USB cable TeleBT works just like TeleDongle on Windows, Mac, and Linux systems running AltOS version 1.2.1 or later.

29 April 2013

Bdale Garbee: Removing LiPo Protection Boards

In my post about Batteries and Pyro Circuits, one of my suggestions was to remove the protection circuit board from LiPo cells used with Altus Metrum flight computers. To help out folks who want to do this themselves, I put together and posted a how-to with photos in the Documents section of our web site.

11 April 2013

Bdale Garbee: Batteries and Pyro Circuits

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. Background 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.

18 February 2013

Enrico Zini: Thanks for the group hug!

Thanks for the group hug! Francesca started a DPL game and I've been mentioned a few times, by people I like deeply. Thank you! However I don't intend to run, and I hope I won't disappoint those who nominated me by saying so. But I don't think of it in terms of letting people down: I can't let anyone down since I never mentioned I'd like to run in the first place. Rather, I like to think that I've just received a wonderful group hug, and hey, wow, come here and let me hug you back! <3 And let me hug some more: I cannot think of a fourth DPL candidate right now and I don't want to postpone this post indefinitely. Think about it this way: you three are so good I can't think of a fourth one right now :) There are actually lots of people I admire in Debian. I tried to name a few without thinking, but I wasn't thinking so I lost count as soon as I ran out of fingers. I know however that many enjoy to stay out of the spotlight and keep their fun focused on a few specific things. I am one of those myself. Oh dear, FOSDEM was too short, can I have DebConf soon? In the meantime, let's have some fun with the DPL campaign.

22 November 2012

Bdale Garbee: Shiny Black Friday

Altus Metrum is pleased to announce our first-ever "Shiny Black Friday" event! We're combining a special, one-time discount on TeleMini products with a price reduction on TeleMetrum boards ... and a new product introduction! For one day only, Friday, 23 November 2012, we are offering a special $50 discount on TeleMini Starter Kits (regular $225, now only $175!) and TeleMini boards (regular $125, now only $75!). This discount is available only for direct orders from our web site, see below. TeleMini is a baro-only recording dual deployment altimeter with radio telemetry and direction finding features. Learn more about TeleMini at We are also pleased to announce that TeleMetrum is back in stock after a brief production delay. To celebrate, we are dropping the price of extra TeleMetrum boards from $350 to $325. Starter kits will continue to sell for $400. TeleMetrum is a dual-deploy altimeter with accel and baro sensors, GPS, and radio telemetry and direction finding features all on one board! Learn more about TeleMetrum at Last, but certainly not least (unless we're talking size or mass!), we are proud to introduce a new product... MicroPeak! MicroPeak is a tiny board that provides highly accurate peak barometric altitude recording. About the size and weight of a US dime with battery ready to fly (18x14mm, 1.9 grams), this is the ideal altimeter for model rocket contests. MicroPeak is so easy to use that it's also the ideal altimeter for young people working on rocket related science fair projects, etc! MicroPeak sells for $50, learn more at Find more information on all Altus Metrum products at The special Black Friday discount on TeleMini products is available only on orders placed through Bdale's web store at Thank you for making 2012 such a great year for Altus Metrum, LLC. We're having fun, and look forward to introducing several exciting new products in the weeks and months ahead!