During Jacob Applebaum's talk at DebConf15, he noted that Debian should TLS-enable all services, especially the mirrors. His reasoning was that when a high-value target downloads a security update for package foo, an adversary knows that they are still using a vulnerable version of foo and try to attack before the security update has been installed. In this specific case, TLS is not of much use though. If the target downloads 4.7 MiB right after a security update with 4.7 MiB has been released, or downloads from security.debian.org, it's still obvious what's happening. Even padding won't help much as the 5 MiB download will also be suspicious. The mere act of downloading anything from the mirrors after an update has been released is reason enough to try an attack. The solution, is, of course, Tor. weasel was nice enough to set up a hidden service on Debian's infrastructure; initally we agreed that he would just give me a VM and I would do the actual work, but he went the full way on his own. Thanks :) This service is not redundant, it uses a key which is stored on the local drive, the .onion will change, and things are expected to break. But at least this service exists now and can be used, tested, and put under some load:

http://vwakviie2ienjx6t.onion/

I couldn't get apt-get to be content with a .onion in /etc/apt/sources.list and Acquire::socks::proxy "socks://127.0.0.1:9050"; in /etc/apt/apt.conf, but the torify wrapper worked like a charm. What follows is, to the best of my knowledge, the first ever download from Debian's "official" Tor-enabled mirror:

~ # apt-get install torsocks
~ # mv /etc/apt/sources.list /etc/apt/sources.list.backup
~ # echo 'deb http://vwakviie2ienjx6t.onion/debian/ unstable main non-free contrib' > /etc/apt/sources.list
~ # torify apt-get update
Get:1 http://vwakviie2ienjx6t.onion unstable InRelease [215 kB]
Get:2 http://vwakviie2ienjx6t.onion unstable/main amd64 Packages [7548 kB]
Get:3 http://vwakviie2ienjx6t.onion unstable/non-free amd64 Packages [91.9 kB]
Get:4 http://vwakviie2ienjx6t.onion unstable/contrib amd64 Packages [58.5 kB]
Get:5 http://vwakviie2ienjx6t.onion unstable/main i386 Packages [7541 kB]
Get:6 http://vwakviie2ienjx6t.onion unstable/non-free i386 Packages [85.4 kB]
Get:7 http://vwakviie2ienjx6t.onion unstable/contrib i386 Packages [58.1 kB]
Get:8 http://vwakviie2ienjx6t.onion unstable/contrib Translation-en [45.7 kB]
Get:9 http://vwakviie2ienjx6t.onion unstable/main Translation-en [5060 kB]
Get:10 http://vwakviie2ienjx6t.onion unstable/non-free Translation-en [80.8 kB]
Fetched 20.8 MB in 2min 0s (172 kB/s)
Reading package lists... Done
~ # torify apt-get install vim
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following extra packages will be installed:
  vim-common vim-nox vim-runtime vim-tiny
Suggested packages:
  ctags vim-doc vim-scripts cscope indent
The following packages will be upgraded:
  vim vim-common vim-nox vim-runtime vim-tiny
5 upgraded, 0 newly installed, 0 to remove and 661 not upgraded.
Need to get 0 B/7719 kB of archives.
After this operation, 2048 B disk space will be freed.
Do you want to continue? [Y/n] 
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Reading changelogs... Done
(Reading database ... 316427 files and directories currently installed.)
Preparing to unpack .../vim-nox_2%3a7.4.826-1_amd64.deb ...
Unpacking vim-nox (2:7.4.826-1) over (2:7.4.712-3) ...
Preparing to unpack .../vim_2%3a7.4.826-1_amd64.deb ...
Unpacking vim (2:7.4.826-1) over (2:7.4.712-3) ...
Preparing to unpack .../vim-tiny_2%3a7.4.826-1_amd64.deb ...
Unpacking vim-tiny (2:7.4.826-1) over (2:7.4.712-3) ...
Preparing to unpack .../vim-runtime_2%3a7.4.826-1_all.deb ...
Unpacking vim-runtime (2:7.4.826-1) over (2:7.4.712-3) ...
Preparing to unpack .../vim-common_2%3a7.4.826-1_amd64.deb ...
Unpacking vim-common (2:7.4.826-1) over (2:7.4.712-3) ...
Processing triggers for man-db (2.7.0.2-5) ...
Processing triggers for mime-support (3.58) ...
Processing triggers for desktop-file-utils (0.22-1) ...
Processing triggers for hicolor-icon-theme (0.13-1) ...
Setting up vim-common (2:7.4.826-1) ...
Setting up vim-runtime (2:7.4.826-1) ...
Processing /usr/share/vim/addons/doc
Setting up vim-nox (2:7.4.826-1) ...
Setting up vim (2:7.4.826-1) ...
Setting up vim-tiny (2:7.4.826-1) ...
~ # 

More services will follow. noodles, weasel, and me agreed that the project as a whole should aim to Tor-enable the complete package lifecycle, package information, and the website. Maybe a more secure install option on the official images which, amongst others, sets up apt, apt-listbugs, dput, reportbug, et al up to use Tor without further configuration could even be a realistic stretch goal.

Even though the week of DebCamp took its toll and the stress level will not go down any time soon... ...DebConf15 has finally started! :)

There are a bunch of things I mean to blog about, but as I have just got fully home from Heidelberg and DebConf15 this afternoon that seems most appropriate to start with. It s a bit of a set of disjoint thoughts, but I figure I should write them down while they re in my head. DebConf is an interesting conference. It s the best opportunity the Debian project has every year to come together and actually spend a decent amount of time with each other. As a result it s a fairly full on experience, with lots of planned talks as a basis and a wide range of technical discussions and general social interaction filling in whatever gaps are available. I always find it a thoroughly enjoyable experience, but equally I m glad to be home and doing delightfully dull things like washing my clothes and buying fresh milk. I have always been of the opinion that the key aspect of DebConf is the face time. It was thus great to see so many people there - we were told several times that this was the largest DebConf so far (~ 570 people IIRC). That s good in the sense that it meant I got to speak to a lot of people (both old friends and new), but does mean that there are various people I know I didn t spend enough, or in some cases any, time with. My apologies, but I think many of us were in the same situation. I don t feel it made the conference any less productive for me - I managed to get a bunch of hacking done, discuss a number of open questions in person with various people and get pulled into various interesting discussions I hadn t expected. In short, a typical DebConf. Also I d like to say that the venue worked out really well. I ll admit I was dubious when I heard it was in a hostel, but it was well located (about a 30 minute walk into town, and a reasonable bus service available from just outside the door), self-contained with decent facilities (I m a big believer in having DebConf talks + accommodation be as close as possible to each other) and the room was much better than expected (well, aside from the snoring but I can t blame the DebConf organisers for that). One of the surprising and interesting things for me that was different from previous DebConfs was the opportunity to have more conversations with a legal leaning. I expect to go to DebConf and do OpenPGP/general crypto related bits. I wasn t expecting affirmation about the things I have learnt on my course over the past year, in terms of feeling that I could use that knowledge in the process of helping Debian. It provided me with some hope that I ll be able to tie my technology and law skills together in a way that I will find suitably entertaining (as did various conversations where people expressed significant interest in the crossover). Next year is in Cape Town, South Africa. It s a long way (though I suppose no worse than Portland and I get to stay in the same time zone), and a quick look at flights indicates they re quite expensive at the moment. The bid presentation did look pretty good though so as soon as the dates are confirmed (I believe this will happen as soon as there are signed contracts in place) I ll take another look at flights. In short, excellent DebConf, thanks to the organisers, lovely to see everyone I managed to speak to, apologies to those of you I didn t manage to speak to. Hopefully see you in Cape Town next year.

Triggered by all the bugs around font problems I spent my weekend instead of mountaineering with crawling through the TeX Live history for changes and fixes to dvipdfm-x. Thanks to for his hints, I have pulled out the changes necessary to fix Type1 support in dvipdfm-x and have reincluded them into the Debian texlive-bin package. The uploaded binaries (version 2015.20150524.37493-6) are already compiled against the new C++ ABI, see the Debian transition, so most systems will still need to wait for the update to be installable. At the same time I did an update to the whole set of arch: all packages (texlive-base, texlive-lang, texlive-extra (version 2015.20150823-1). This was triggered by bug that seems to be caused by bad interplay between fontspec and l3 packages. Furthermore, I needed to remove the activation for fontconfig of the URW++ Base35 fonts, to ensure that fontconfig returns always the ones from the gsfonts package, instead of a mixture between TeX Live and gsfonts. Unrelated bug fix: libpaper intergration has been fixed and should work again. So for now all the bugs are now hopefully settled and we are back to normal. What remains is trying to fix jessie which is also broken in some respects. Updated packages acro, animate, babel-bosnian, babel-french, babel-latin, beamer-FUBerlin, beebe, breqn, chemformula, chet, cnltx, crossrefware, dantelogo, datetime2-it-fulltext, disser, drm, dvipdfmx-def, ecclesiastic, eledform, gradstudentresume, idxcmds, l3build, mcf2graph, media9, pageslts, pdfpages, reledmac, siunitx, tcolorbox, tex4ht, texlive-docindex, texlive-scripts, udesoftec, upmethodology, xindy. New packages blochsphere, e-french, fitbox, nar Enjoy.

Hello dear readers, Next week, I'll be running the "Echappee Belle" race : 144km and 10.000 meters positive climb, in French Alps (Belledonne range, this time). That will be, by far, my longest race ever and indeed a great challenge for me with very difficult tracks (when there are tracks). I expect to run for about 48 hours, or even up to 55, two nights out.....or maybe less as I'm in very good shape. You can follow me on the live tracking site. The race starts on Friday August 28th, 06:00 CET DST.

Having had personal contact with Amazon employees, and having read the NYT article Inside Amazon: Wrestling Big Ideas in a Bruising Workplace, I have only a few things to say:

• Most Japanese companies have different methods, but work hours are similar, and exploitation even worse (voluntary service etc)
• I loved one comment in the MobileRead thread on the article, link to the post:
  

  All you need to do is make one assumption: dishonest people will outperform honest people over the short term. Then every year Amazon s culling will get rid of the honest people and keep the dishonest ones. Rinse and repeat. Soon only the sociopaths are left. Best supporting quote from the article: You learn how to diplomatically throw people under the bus.

What remains I guess I would be a horrible performer at Amazon, and I am proud of it.

I tried to start to write this blog entry like I usually do: Type along what goes through my mind and see where I'm heading. This won't work out right now for various reasons, mostly because there is so much going on that I don't have the time to finish that in a reasonable time and I want to publish this today still. So please excuse me for being way more brief than I usually am, and hopefully I'll find the time to expand some things when asked or come back to that later. Part of the reason of me being short on time is different stuff going on in my private life which requires additional attention. A small part of this is also something that I hinted in a former blog entry: I switched my job in June. I really was looking forward to this. I made them aware of what the name Rhonda means to me and it's definitely extremely nice to be addressed with female pronouns at work. And also I'm back in a system administration job which means there is an interest overlap with my work on Debian, so a win-win situation on sooo many levels! I'm at DebConf15 since almost two weeks now. On my way here I was complimented on my outfit by a security guard at the Vienna airport which surprised me but definitely made my day. I was wearing one of these baggy hippie pants (which was sent to me by a fine lady I met at MiniDebConf Bucharest) but pulled up the leg parts to the knees so it could be perceived as a skirt instead. Since I came here I was pretty busy with taking care of DCschedule bot adjustments (like, changing topic and twittering from @DebConf at the start of the talks), helping out with the video team when I noticed there was a lack of people (which is a hint for that you might want to help with the video team in the future too, it's important for remote people but also for yourself because you can't attend multiple sessions at the same time). And I have to repeat myself, this is the place I feel home amongst my extended family, even though I it still is sometimes for me to get to speak up in certain groups. I though believe it's more an issue of certain individuals taking up a lot of space in discussions without giving (more shy) people in the round the space to also join in. I guess it might be the time that we need a session on dominant talking patterns for next year and how to work against them. I absolutely enjoyed such a session during last year's FemCamp in Vienna which set the tone for the rest of the conference, and it was simply great. And then there was the DebConf Poetry Night. I'm kinda disappointed with the outcome this year. It wasn't able to attract as much people anticipated, which I to some degree account to me not making people aware of it well enough, overlapping with a really great band playing at the same time in competition, and even though the place where we did it sounded like a good idea at first, it didn't had enough light for someone to read something from a book (but that was solved through smartphone lights). I know that most people did enjoy it, so it was good to do it, but I'm still a fair bit disappointed with the outcome and will try to work on improving on that grounds for next year. :) With all this going on there unfortunately wasn't as much time as I would have liked to spend with people I haven't seen for a long time, or new people I haven't met yet. Given that this year's DebConf had an height in attendees (526 being here at certain times during the two weeks, and just today someone new arrived too, so that doesn't even have to be the final number) it makes it a bit painful to have picked up so many tasks and thus lost some chances to socialize as much as I would have liked to. So, if you are still here and have the feeling we should have talked more, please look for me. As Bdale pointed out correctly in the New to DebConf BoF (paraphrased): When you see us DebConf old timers speaking to someone else and you feel like you don't want to disturb, please do disturb and speak to us. I always enjoyed to get to know new people. This for me always is one of the important aspects of DebConf. Also, I am very very happy to have received feedback from different people about both my tweets and my blog, thank you a lot of that. It is really motivating to keep going. So, lets enjoy the last few hours of DebConf! Another last side notice: While my old name in the Debian LDAP did manage to find some wrongly displayed names in the DebConf website, like for speakers, or volunteers, it was clear to me that having it exposed through SSO.debian.org isn't really something I appreciate. So I took the chance and spoke to Luca from the DSA team right here today, and ... got it fixed. I love it! Next step is getting my gpg key exchanged, RT ticket is coming up. :)

/debian permanent link Comments: 1 Flattr this

Thursday was our big day: After more than 2.5 years of working in the hidden, ups and downs, Frank Hofmann and myself were able to announce the availability of our book project Debian Package Management under a free license (Creative Commons Attribution ShareAlike 4.0 International License, short CC BY-SA 4.0 ) during a Lightning Talk at DebConf15 in Heidelberg. This became possible because we found Onyx Neon, a publishing company which is specialised on books with contents under free licenses. Its founder does not only have a faible for Perl but also for Debian. (Since the question already came up: We also thought about self-publishing, e.g. via Lulu or Epubli and it would have been our fallback solution , but we prefer the professionalism and services of a real publisher. I m though happy to share what I found out about self-publishing in the past few months.) The source code of the book is written in the AsciiDoc format and available on GitHub. The book is still work in progress. But if you want, you can already build an e-book out of the publically available source code:

sudo apt-get install asciidoc dblatex git
git clone git://github.com/dpmb/dpmb.git
cd dpmb
make

(Works fine on Debian 7 Wheezy, Debian 8 Jessie and Ubuntu 14.04 LTS Trusty. Does not work on Ubuntu 12.04 LTS Precise.) If you find an error in the book, please file an issue on GitHub. If you also know how to fix the error, please for the Git repository on GitHub, fix the error in your Git repository and file a pull request. (The first pull request already happenend and has been applied.) Initially there will be only a German written issue as e-book (at least in HTML, PDF and EPUB formats, maybe also KF8/MOBI and EPUB3) and at some point in the future also as printed book at Onyx Neon. But we re also planning a translation to English as well as a Debian package. If your want to get informed when we publish a printed book, a translation or an official e-book release, please subscribe to one of our mailing lists: There s one in German and one in English.

Today, finally, my first printed draft edition of the Norwegian translation of Free Culture I have been working on for the last few years arrived in the mail. I had to fake a cover to get the interior printed, and the exterior of the book look awful, but that is irrelevant at this point. I asked for a printed pocket book version to get an idea about the font sizes and paper format as well as how good the figures and images look in print, but also to test what the pocket book version would look like. After receiving the 500 page pocket book, it became obvious to me that that pocket book size is too small for this book. I believe the book is too thick, and several tables and figures do not look good in the size they get with that small page sizes. I believe I will go with the 5.5x8.5 inch size instead. A surprise discovery from the paper version was how bad the URLs look in print. They are very hard to read in the colophon page. The URLs are red in the PDF, but light gray on paper. I need to change the color of links somehow to look better. But there is a printed book in my hand, and it feels great. :) Now I only need to fix the cover, wrap up the postscript with the store behind the book, and collect the last corrections from the proof readers before the book is ready for proper printing. Cover artists willing to work for free and create a Creative Commons licensed vector file looking similar to the original is most welcome, as my skills as a graphics designer are mostly missing.

On a private mailing list there have been some recent discussions about a Code of Conduct which demonstrate some great misunderstandings. The misunderstandings don t seem particular to that list so it s worthy of a blog post. Also people tend to think more about what they do when their actions will be exposed to a wider audience so hopefully people who read this post will think before they respond. Jokes The first discussion concerned the issue of making jokes . When dealing with the treatment of other people (particularly minority groups) the issue of jokes is a common one. It s fairly common for people in positions of power to make jokes about people with less power and then complain if someone disapproves. The more extreme examples of this concern hate words which are strongly associated with violence, one of the most common is a word used to describe gay men which has often been associated with significant violence and murder. Men who are straight and who conform to the stereotypes of straight men don t have much to fear from that word while men who aren t straight will associate it with a death threat and tend not to find any amusement in it. Most minority groups have words that are known to be associated with hate crimes. When such words are used they usually send a signal that the minority groups in question aren t welcome. The exception is when the words are used by other members of the group in question. For example if I was walking past a biker bar and heard someone call out geek or nerd I would be a little nervous (even though geeks/nerds have faced much less violence than most minority groups). But at a Linux conference my reaction would be very different. As a general rule you shouldn t use any word that has a history of being used to attack any minority group other than one that you are a member of, so black rappers get to use a word that was historically used by white slave-owners but because I m white I don t get to sing along to their music. As an aside we had a discussion about such rap lyrics on the Linux Users of Victoria mailing list some time ago, hopefully most people think I m stating the obvious here but some people need a clear explanation. One thing that people should consider jokes is the issue of punching-down vs punching-up [1] (there are many posts about this topic, I linked to the first Google hit which seems quite good). The basic concept is that making jokes about more powerful people or organisations is brave while making jokes about less powerful people is cowardly and serves to continue the exclusion of marginalised people. When I raised this issue in the mailing list discussion a group of men immediately complained that they might be bullied by lots of less powerful people making jokes about them. One problem here is that powerful people tend to be very thin skinned due to the fact that people are usually nice to them. While the imaginary scenario of less powerful people making jokes about rich white men might be unpleasant if it happened in person, it wouldn t compare to the experience of less powerful people who are the target of repeated jokes in addition to all manner of other bad treatment. Another problem is that the impact of a joke depends on the power of the person who makes it, EG if your boss makes a joke about you then you have to work on your CV, if a colleague or subordinate makes a joke then you can often ignore it. Who does a Code of Conduct Protect One member of the mailing list wrote a long and very earnest message about his belief that the CoC was designed to protect him from off-topic discussions. He analysed the results of a CoC on that basis and determined that it had failed due to the number of off-topic messages on the mailing lists he subscribes to. Being so self-centered is strongly correlated with being in a position of power, he seems to sincerely believe that everything should be about him, that he is entitled to all manner of protection and that any rule which doesn t protect him is worthless. I believe that the purpose of all laws and regulations should be to protect those who are less powerful, the more powerful people can usually protect themselves. The benefit that powerful people receive from being part of a system that is based on rules is that organisations (clubs, societies, companies, governments, etc) can become larger and achieve greater things if people can trust in the system. When minority groups are discouraged from contributing and when people need to be concerned about protecting themselves from attack the scope of an organisation is reduced. When there is a certain minimum standard of treatment that people can expect then they will be more willing to contribute and more able to concentrate on their contributions when they don t expect to be attacked. The Public Interest When an organisation declares itself to be acting in the public interest (EG by including Public Interest in the name of the organisation) I think that we should expect even better treatment of minority groups. One might argue that a corporation should protect members of minority groups for the sole purpose of making more money (it has been proven that more diverse groups produce better quality work). But an organisation that s in the Public Interest should be expected to go way beyond that and protect members of minority groups as a matter of principle. When an organisation is declared to be operating in the Public Interest I believe that anyone who s so unable to control their bigotry that they can t refrain from being bigoted on the mailing lists should not be a member.

• [1] http://reasonableconversation.wordpress.com/2012/07/19/punching-up/

I bumped into Mark Shuttleworth today at Linuxcon and we had a brief conversation about Canonical's IP policy. The short summary:

• Canonical assert that the act of compilation creates copyright over the binaries, and you may not redistribute those binaries unless (a) the license prevents Canonical from restricting redistribution (eg, the GPL), or (b) you follow the terms of their IP policy. This means that, no matter what Dustin's blogpost says, Canonical's position is that you must ask for permission before distributing any custom container images that contain Ubuntu binaries, even if you use no Ubuntu trademarks in the process. Doing so without their permission is an infringement of their copyright.
  
• Canonical have no intention of clarifying their policy, because Canonical benefit from companies being legally uncertain as to whether they have permission to do something or not.
  
• Mark justifies maintaining this uncertainty by drawing an analogy between it and the perceived uncertainties that exist around certain aspects of the GPL. I disagree with this analogy pretty strongly. One of the main reasons for the creation of GPLv3 was to deal with some more ambiguous aspects of GPLv2 (such as what actually happened after license termination and how patents interacted with the GPL). The FSF publish a large FAQ intended to provide further clarity. The major ambiguity is in what a derivative work actually is, which is something the FSF can't answer absolutely (that's going to be up to courts) but will give its opinion on when asked. The uncertainties in Canonical's IP policy aren't a result of a lack of legal clarity - they're a result of Canonical's refusal to answer questions.

The even shorter summary: Canonical won't clarify their IP policy because they believe they can make more money if they don't.

Why do I keep talking about this? Because Canonical are deliberately making it difficult to create derivative works, and that's one of the core tenets of the definition of free software. Their IP policy is fundamentally incompatible with our community norms, and that's something we should care about rather than ignoring.

comments

Dear Lazyweb, I m currently trying to find a way to port python-debianbts to Python3. Debian s standard bugreport tool reportbug depends on python-debianbts and can thus not convert to Python3 if python-debianbts does not as well. Unfortunately python-debianbts depends on SoapPy for parsing the Debian bugtracker s responses, and that library is not ported to Python3 yet, and probably never will. I m planning to replace SoapPy with pysimplesoap which is available for Python2 and Python3. Unfortunately debbugs does not support WSDL which makes parsing of the replies extremely painful and error-prone. I wonder if there is a SOAP/Python expert out there who d be willing to give some assistance in porting python-reportbug to pysimplesoap? python-reportbug s repository is on GitHub and patches are very welcome. Since SOAP is quite a beast and debbugs uses it for read-only purposes only, another attractive solution would be to replace/augment debbugs API with something much more simple, like JSON. That would make parsing extremely easy as many programming languages including Python support JSON without any external libraries. In theory this could be quite easy but requires some serious Perl skills.

Some years ago Barwon South Water gave LUV 3 old 1RU Sun servers for any use related to free software. We gave one of those servers to the Canberra makerlab and another is used as the server for the LUV mailing lists and web site and the 3rd server was put aside for training. The servers have hot-swap 15,000rpm SAS disks IE disks that have a replacement cost greater than the budget we have for hardware. As we were given a spare 70G disk (and a 140G disk can replace a 70G disk) the LUV server has 2*70G disks and the 140G disks (which can t be replaced) are in the server for training. On Saturday I ran a BTRFS and ZFS training session for the LUV Beginners SIG. This was inspired by the amount of discussion of those filesystems on the mailing list and the amount of interest when we have lectures on those topics. The training went well, the meeting was better attended than most Beginners SIG meetings and the people who attended it seemed to enjoy it. One thing that I will do better in future is clearly documenting commands that are expected to fail and documenting how to login to the system. The users all logged in to accounts on a Xen server and then ssh d to root at their DomU. I think that it would have saved a bit of time if I had aliased commands like btrfs to echo you must login to your virtual server first or made the shell prompt at the Dom0 include instructions to login to the DomU. Each user or group had a virtual machine. The server has 32G of RAM and I ran 14 virtual servers that each had 2G of RAM. In retrospect I should have configured fewer servers and asked people to work in groups, that would allow more RAM for each virtual server and also more RAM for the Dom0. The Dom0 was running a BTRFS RAID-1 filesystem and each virtual machine had a snapshot of the block devices from my master image for the training. Performance was quite good initially as the OS image was shared and fit into cache. But when many users were corrupting and scrubbing filesystems performance became very poor. The disks performed well (sustaining over 100 writes per second) but that s not much when shared between 14 active users. The ZFS part of the tutorial was based on RAID-Z (I didn t use RAID-5/6 in BTRFS because it s not ready to use and didn t use RAID-1 in ZFS because most people want RAID-Z). Each user had 5*4G virtual disks (2 for the OS and 3 for BTRFS and ZFS testing). By the end of the training session there was about 76G of storage used in the filesystem (including the space used by the OS for the Dom0), so each user had something like 5G of unique data. We are now considering what other training we can run on that server. I m thinking of running training on DNS and email. Suggestions for other topics would be appreciated. For training that s not disk intensive we could run many more than 14 virtual machines, 60 or more should be possible. Below are the notes from the BTRFS part of the training, anyone could do this on their own if they substitute 2 empty partitions for /dev/xvdd and /dev/xvde. On a Debian/Jessie system all that you need to do to get ready for this is to install the btrfs-tools package. Note that this does have some risk if you make a typo. An advantage of doing this sort of thing in a virtual machine is that there s no possibility of breaking things that matter.

1. Making the filesystem
   1. Make the filesystem, this makes a filesystem that spans 2 devices (note you must use the-f option if there was already a filesystem on those devices):
      mkfs.btrfs /dev/xvdd /dev/xvde
   2. Use file(1) to see basic data from the superblocks:
      file -s /dev/xvdd /dev/xvde
   3. Mount the filesystem (can mount either block device, the kernel knows they belong together):
      mount /dev/xvdd /mnt/tmp
   4. See a BTRFS df of the filesystem, shows what type of RAID is used:
      btrfs filesystem df /mnt/tmp
   5. See more information about FS device use:
      btrfs filesystem show /mnt/tmp
   6. Balance the filesystem to change it to RAID-1 and verify the change, note that some parts of the filesystem were single and RAID-0 before this change):
      btrfs balance start -dconvert=raid1 -mconvert=raid1 -sconvert=raid1 force /mnt/tmp
      btrfs filesystem df /mnt/tmp
   7. See if there are any errors, shouldn t be any (yet):
      btrfs device stats /mnt/tmp
   8. Copy some files to the filesystem:
      cp -r /usr /mnt/tmp
   9. Check the filesystem for basic consistency (only checks checksums):
      btrfs scrub start -B -d /mnt/tmp
2. Online corruption
   1. Corrupt the filesystem:
      dd if=/dev/zero of=/dev/xvdd bs=1024k count=2000 seek=50
   2. Scrub again, should give a warning about errors:
      btrfs scrub start -B /mnt/tmp
   3. Check error count:
      btrfs device stats /mnt/tmp
   4. Corrupt it again:
      dd if=/dev/zero of=/dev/xvdd bs=1024k count=2000 seek=50
   5. Unmount it:
      umount /mnt/tmp
   6. In another terminal follow the kernel log:
      tail -f /var/log/kern.log
   7. Mount it again and observe it correcting errors on mount:
      mount /dev/xvdd /mnt/tmp
   8. Run a diff, observe kernel error messages and observe that diff reports no file differences:
      diff -ru /usr /mnt/tmp/usr/
   9. Run another scrub, this will probably correct some errors which weren t discovered by diff:
      btrfs scrub start -B -d /mnt/tmp
3. Offline corruption
   1. Umount the filesystem, corrupt the start, then try mounting it again which will fail because the superblocks were wiped:
      umount /mnt/tmp
      dd if=/dev/zero of=/dev/xvdd bs=1024k count=200
      mount /dev/xvdd /mnt/tmp
      mount /dev/xvde /mnt/tmp
   2. Note that the filesystem was not mountable due to a lack of a superblock. It might be possible to recover from this but that s more advanced so we will restore the RAID.
      Mount the filesystem in a degraded RAID mode, this allows full operation.
      mount /dev/xvde /mnt/tmp -o degraded
   3. Add /dev/xvdd back to the RAID:
      btrfs device add /dev/xvdd /mnt/tmp
   4. Show the filesystem devices, observe that xvdd is listed twice, the missing device and the one that was just added:
      btrfs filesystem show /mnt/tmp
   5. Remove the missing device and observe the change:
      btrfs device delete missing /mnt/tmp
      btrfs filesystem show /mnt/tmp
   6. Balance the filesystem, not sure this is necessary but it s good practice to do it when in doubt:
      btrfs balance start /mnt/tmp
   7. Umount and mount it, note that the degraded option is not needed:
      umount /mnt/tmp
      mount /dev/xvdd /mnt/tmp
4. Experiment
   1. Experiment with the btrfs subvolume create and btrfs subvolume delete commands (which act like mkdir and rmdir).
   2. Experiment with btrfs subvolume snapshot SOURCE DEST and btrfs subvolume snapshot -r SOURCE DEST for creating regular and read-only snapshots of other subvolumes (including the root).

<Sigh/> For the second time since I joined Debian, I missed DebConf. This time, mostly for two completely happy reasons (which have, of course, grown up quite significatively): But adding to that very important factor, early-to-mid August is possibly the worst date for me to attend DebConf As that's when we start classes at UNAM, and I really don't want to delegate introducing my class to somebody else (besides it being or not possible). Life has been quite busy here. Besides starting my seventh semester as a teacher (finally being able to present my book on operating systems to the students!), I also took on teaching two modules for a diploma-course on embedded Linux. I'm co- teaching the "User-space Linux" module together with Gabriel Salda a, and will teach the "Boot process" module with Sandino Araico. There are many things that should be improved about the covered program, but we are having good fun working our way on it; Gabriel and I have given two (out of six) 6hr sessions each, and have reached the point where it is actually becoming fun :) As for Debian... I have been doing minimal maintenance work. Answering to some keyring tickets, or taking care of only high-profile important issues. I do not have time to do much. I have been wanting to do some interesting analysis on the evolution of our keyring for several months, but have not had the time to follow it up. Will do at some point, /mehopes. Anyway... This post is probably just because I need to somehow be there at our community's highest social, technical exchange period in the year. That is, there's not much to report, it's only me waving from home!

A question that I'm asked repeatedly recently is why I chose not to use an existing library for serialising data structures in Obnam. This blog post is the answer. Obnam is a backup program, and it needs to store various data about files. This includes stat(2) information about each file in the live data, as well as data Obnam needs to keep track of everything. At run-time, Obnam keeps this data in memory data structures, such as Python dicts. For storage, these data structures need to be converted, serialised, to and from streams of bytes. The are a variety of libraries for doing this, designed for different purposes and with their own constraints and pitfalls. Python's standard library comes with the cPickle library, for example, but its serialisation format is not guaranteed to be compatible with any other version of Python. For Obnam, I need something that will last a long time. I do not want to have to deal with a library changing its serialisation format, as that would mean either that Obnam can't handle old backups, or that I need to start maintaining the old version of the library. A way to look at this is that any dependencies your software have a cost, and that cost should be smaller than the benefit you get from them. For example, Obnam depends on the paramiko library to implement the SSH protocol. This library has some cost, and I've run into one or two bugs in it that have been rather unfortunate. However, the benefit it brings is huge: I don't have to implement SSH myself. I'm happy to have Obnam depend on paramiko. For the serialisation thing, I wrote my own library, after a small about of research into existing ones. Research time is a cost, too. Mine is somewhat Obnam specific, in that it can make some assumptions about the data to be serialised, and this allows a simpler library. A generic library would have to handle a number of special cases that mine can ignore. It took me less than an hour to write this twice. I first wrote a quick prototype and a little microbenchmark to see if my approach would be feasible. Then I deleted that code, and started from scratch, TDD style, to make sure the code was reliable. The cost of writing my own serialisation code was less than the cost of finding, let alone evaluating existing libraries. It may be that my own library turns out to be inadequate. Then, and only then, is when I start researching other libraries. Until then, I'll avoid the cost of research to find a suitable library, the cost of learning the chosen one, the cost of integrating it into Obnam, the cost to porters of Obnam of dealing with a new dependency, and the risk of the library changing in ways that are unsuitable for Obnam. Obviously, writing your own code has costs, too. Designing and implementing a library is a cost, as is maintaining it (debugging, changes in requirements, etc). Write your own or use existing code? It's a cost/benefit analysis. There's no clear one answer that's always correct.

Today is the day for minor software releases. It's amazing how much more free time I have when I'm not unpacking boxes. Osamu Aoki submitted a bug report a while back asing for --update, --create, and --login to be supported as options to git-pbuilder, in addition to the versions without leading hyphens, since pbuilder and cowbuilder require the hyphens and people are used to typing them. I've finally merged his patch and released git-pbuilder 1.35 with that change. It will probably show up in git-buildpackage shortly. (Still need to rewrite this script in Python one of these days so that it can be properly and fully merged with git-buildpackage.) You can get the latest version of git-pbuilder from my scripts page.

The Asus t100 tablet is this amazing and odd little thing: it sells for under $200, yet has a full-featured Atom 64-bit CPU, 2GB RAM, 32 or 64GB SSD, etc. By default, it ships with Windows 8.1. It has a detachable keyboard, so it can be used as a tablet or a very small 10 laptop. I have never been a fan of Windows on it. It does the trick for web browsing and email, but I d like to ssh into my machines sometimes, and I just can t bring myself to type sensitive passwords into Windows. I decided to try installing Debian on it. After a lot of abortive starts due to the UEFI-only firmware, I got jessie installed. (The installer was fine; it was Debian Live that wouldn t boot.) I got wifi and battery status working via an upgrade to the 4.1 kernel. A little $10 Edimax USB adapter was handy to spare a bunch of copying via USB disks. I have been using XFCE with XMonad for so many years that I am somewhat a stranger to other desktop environments. XMonad isn t really suitable for a tablet, however, so I thought I d try Gnome, especially after a fairly glowing review about its use on a tablet. I am already disappointed after just a few minutes. There is no suspend button on the menu. Some Googling showed that holding Alt while hovering over the power off button will change it to a suspend button. And indeed it does. But uh, what? That is so common and so non-obvious. And pushing the power button does nothing. That s right, nothing. Apparently the way to enable some action when you push the power button is to type in a settings command in a terminal. There s no setting in the settings panel. I initially ditched Gnome some years ago due to its penchant for removing features. I had hoped that this much time later, it would have passed that stage, but I m already disappointed. I was hoping for some really nice integration with the system. But my XFCE setup has a very clear When power button is pressed setting. I have no idea why Gnome doesn t. Also, the touch screen works fine and it registers my touches, but whenever I touch anywhere, the cursor disappears. Weird, eh? There are some things to fix yet on the tablet (sound, brightness adjustment, and making suspend reliable) but others have solved these in Ubuntu so I don t think it ll be too hard. In the meantime, any suggestions regarding Gnome? Is it just going to annoy me? Maybe I should try KDE also. I ve heard good things about Plasma Active, but don t see it in Debian though.

I wrote a Bash one-liner to open the source code (in Debsources) of any file on your system (if it belongs to a Debian package). It will simply retrieve the associated package and point your default browser to its source code. Add this somewhere in your $PATH, and name this file debsrc: And try something like debsrc /usr/share/doc/acpi/AUTHORS. Enjoy! Update: improved the one-liner thanks to josch's advice.

Well, here are the stats for week 6 of the DUCK challenge:

• Kenneth J. Pronovici uploaded ncompress
• Alastair McKinstry uploaded libterralib
• Francois-Rene Rideau uploaded cl-launch
• Antti J rvinen uploaded qemuctl
• St phane Glondu uploaded yojson
• Mehdi Dogguy uploaded postgresql-ocaml, cmigrep and pcre-ocaml
• Christian M. Ams ss uploaded arandr

So we had 9 packages fixed and uploaded by 7 different uploaders. A big "Thank You" to you!! Since the start of this challenge, a total of 68 packages, were fixed. Here is a quick overview:

	Week 1	Week 2	Week 3	Week 4	Week 5	Week 6	Week 7
# Packages	10	15	10	14	10	9	-
Total	10	25	35	49	59	68	-

The list of the fixed and updated packages is availabe here. I will try to update this ~daily. If I missed one of your uploads, please drop me a line. So, assuming that the current rate of packages fixed will be somewhat stable and there will be no additional regessions, the number of packages with issues should be down to 0 in about 209 weeks (~ 4 years ) I just arrived at DebConf15 in Heidelberg, and will try to find all of you who fixed & uploaded packages. If you are one of the guys and see me lingering around, please talk to me and get your lighter! The DUCK Challenge will run until the end of DebConf15, but as there might be some delay by my scripts detecting your upload, please contact my directly. Pevious articles are here: Week 1, Week 2, Week 3, Week 4, Week 5.

As with all the previous versions, I have prepared a mega update for the Kobo firmware 3.17.0. Big warning for a start this is for Mark6 hardware, thus GloHD only. The update includes all my favorite patches and features. Please see details (although for for Kobo Glo) for 3.16.0, 3.15.0, 3.13.1 and 3.12.1. As before, the following addons are included: Kobo Start Menu, koreader, coolreader, pbchess, ssh access, custom dictionaries, and some side-loaded fonts. What I dropped this time is most of the kobohack part, as the libraries seem to get outdated. But I included the dropbear ssh server from the kobohack package. So what are all these items:

• firmware (thread): the basic software of the device, shipped by Kobo company
• Metazoa firmware patches (thread): fix some layout options and functionalities, see below for details.
• Kobo Start Menu (V07, update 4 thread): a menu that pops up before the reading software (nickel) starts, which allows to start alternative readers (like koreader) etc.
• KOreader (koreader-nightly-20150808, thread): an alternative document reader that supports epub, azw, pdf, djvu and many more
• pbchess and CoolReader (2015.7, thread): a chess program and another alternative reader, bundled together with several other games
• kobohack (web site): I only use the ssh server
• ssh access (old post: makes a full computer from your device by allowing you to log into it via ssh
• custom dictionaries (thread): this fix updates dictionaries from the folder customdicts to the Kobo dictionary folder. For creating your own Japanese-English dictionary, see this blog entry
• side-loaded fonts: GentiumBasic and GentiumBookBasic, Verdana, DroidSerif, and Charter-eInk

Install procedure Latest firmware Warning: Sideloading or crossloading the incorrect firmware can break/brick your device. The link below is for Kobo GloHD ONLY. The first step is to update the Kobo to the latest firmware. This can easily be done by just getting the latest firmware (thread, direct link for Kobo 3.17.0 for GloHD) and unpacking the zip file into the .kobo directory on your device. Eject and enjoy the updating procedure. Mega update Get the combined Kobo-3.17.0-combined/KoboRoot.tgz and put it into the .kobo directory, then eject and enjoy the updating procedure again. After this the device should reboot and you will be kicked into KSM, from where after some time of waiting Nickel will be started. If you consider the fonts too small, select Configure, then the General, and add item, then select kobomenuFontsize=55 and save. Remarks to some of the items included The full list of included things is above, here are only some notes about what specific I have done.

• Metazoa firmware patches I have included the experimental sickel patch to extend the waiting time until sickel reboots your device. The patches I have enabled in this build are:
  • libadobe.so.patch: none
  • librmsdk.so.1.0.0.patch: default ( Fix page breaks bug , Default ePub monospace font (Courier) )
  • libnickel.so.1.0.0.patch: Custom reading footer style , My 15 line spacing values , Custom left & right margins , Brightness fine control , Search in Library by default , Disable pinch-to-zoom font resizing
  • sickel.patch: default ( SickelService::Ping() timer , SickelService::Resume() timer , SickelService::SickelService() timer )
  If you need any other patches, you need to do the patching yourself.
• kobohack-h Kobohack (latest version 20150110) originally provided updated libraries and optimizations, but unfortunately it is now completely outdated and using it is not recommended for the library part. I only include the ssh server (dropbear) so that connections to the Kobo via ssh.
• ssh fixes See the detailed instructions here, the necessary files are already included in the mega upload. It updates the /etc/inittab to run also /etc/init.d/rcS2, and this one again starts the inetd server and run user supplied commands in /mnt/onboard/run.sh which is where your documents are.
• Custom dictionaries The necessary directories and scripts are already included in the above combined KoboRoot.tgz, so nothing to be done but dropping updated, fixed, changed dictionaries into your Kobo root into the directory customdict. After this you need to reboot to get the actual dictionaries updated. See this thread for more information. The adaptions and script mentioned in this post are included in the mega update.

WARNINGS After installing this patch, you need to fix the password for root and disable telnet. This is an important step, here are the steps you have to take (taken from this old post):

1. Turn on Wifi on the Kobo and find IP address
   Go to Settings Connect and after this is done, go to Settings Device Information where you will see something like
IP Address: 192.168.1.NN
   (numbers change!)
2. telnet into your device
   telnet 192.168.1.NN
   it will ask you the user name, enter root (without the quotes) and no password
3. (ON THE GLO) change home directory of root
   edit /etc/passwd with vi and change the entry for root by changing the 6th field from: / to /root (without the quotes). After this procedure the line should look like
   root::0:0:root:/root:/bin/sh
   don t forget to save the file
4. (ON THE GLO) create ssh keys for dropbear
   [root@(none) ~]# mkdir /etc/dropbear
[root@(none) ~]# cd /etc/dropbear
[root@(none) ~]# dropbearkey -t dss -f dropbear_dss_host_key
[root@(none) ~]# dropbearkey -t rsa -f dropbear_rsa_host_key
5. (ON YOUR PERSONAL COMPUTER) check that you can log in with ssh
   ssh root@192.168.1.NN
   You should get dropped into your device again
6. (ON THE GLO) log out of the telnet session (the first one you did)
   [root@(none) ~]# exit
7. (ON THE GLO) in your ssh session, change the password of root
   [root@(none) ~]# passwd
   you will have to enter the new password two times. Remember it well, you will not be easily able to recover it without opening your device.
8. (ON THE GLO) disable telnet login
   edit the file /etc/inetd.conf.local on the GLO (using vi) and remove the telnet line (the line starting with 23).
9. restart your device

The combined KoboRoot.tgz is provided without warranty. If you need to reset your device, don t blame me!