I have been delighted with git for several years now. It's a very powerful tool and I use it every day.
I try to use git in all possible tasks: bind servers, configurations, firewalls, and other personal stuff.

However, there has been always a thing in my git-TODO: a blog managed with git.

After a bit of searching, I found an interesting technology: jekyllrb hosted at github pages. Jekyll looked easy to manage and easy to learn for a newbie like me.
There are some very good looking blogs out there using this combination, for example: https://rsms.me/

But I was lazy to migrate this 'ral-arturo' blog from blogger to jekyll, so I decided to create a new blog from scratch.

This time, the new blog in written in Spanish and is about adventures, nature, travels and outdoor sports.
Perhaps you noticed this article about the Mulhacen mountain (BTW, we did it! :-))
The new blog is called alfabravo.org,

I like the workflow with git & jekyll & github:

• clone the repository
• write a new post in markdown
• read it and correct it locally with 'jekyll serve'
• commit and push to github
• done!

Who knows, perhaps this 'ral-arturo' blog ends being migrated to the new system as well.

The GNU Privacy Guard (GnuPG) upstream team maintains three branches of development: 1.4 ("classic"), 2.0 ("stable"), and 2.1 ("modern").They differ in various ways: software architecture, supported algorithms, network transport mechanisms, protocol versions, development activity, co-installability, etc.Debian currently ships two versions of GnuPG in every maintained suite -- in particular, /usr/bin/gpg has historically always been provided by the "classic" branch.That's going to change!Debian unstable will soon be moving to the "modern" branch for providing /usr/bin/gpg. This will give several advantages for Debian and its users in the future, but it will require a transition. Hopefully we can make it a smooth one.

What are the benefits?Compared to "classic", The "modern" branch has:

• updated crypto (including elliptic curves)
• componentized architecture (e.g. libraries, some daemonized processes)
• improved key storage
• better network access (including talking to keyservers over tor)
• stronger defaults
• more active upstream development
• safer info representation (e.g. no more key IDs, fingerprints easier to copy-and-paste)

If you want to try this out, the changes are already made in experimental. Please experiment!

What does this mean for end users?If you're an end user and you don't use GnuPG directly, you shouldn't notice much of a change once the packages start to move through the rest of the archive.Even if you do use GnuPG regularly, you shouldn't notice too much of a difference. One of the main differences is that all access to your secret key will be handled through gpg-agent, which should be automatically launched as needed. This means that operations like signing and decryption will cause gpg-agent to prompt the the user to unlock any locked keys directly, rather than gpg itself prompting the user.If you have an existing keyring, you may also notice a difference based on a change of how your public keys are managed, though again this transition should ideally be smooth enough that you won't notice unless you care to investigate more deeply.If you use GnuPG regularly, you might want to read the NEWS file that ships with GnuPG and related packages for updates that should help you through the transition.If you use GnuPG in a language other than English, please install the gnupg-l10n package, which contains the localization/translation files. For versions where those files are split out of the main package, gnupg explicitly Recommends: gnupg-l10n already, so it should be brought in for new installations by default.If you have an archive of old data that depends on known-broken algorithms, PGP3 keys, or other deprecated material, you'll need to have "classic" GnuPG around to access it. That will be provided in the gnupg1 package

What does this mean for package maintainers?If you maintain a package that depends on gnupg: be aware that the gnupg package in debian is going through this transition.A few general thoughts:

• If your package Depends: gnupg for signature verification only, you might prefer to have it Depends: gpgv instead. gpgv is a much simpler tool that the full-blown GnuPG suite, and should be easier to manage. I'm happy to help with such a transition (we've made it recently with apt already)
• If your package Depends: gnupg and expects ~/.gnupg/ to be laid out in a certain way, that's almost certainly going to break at some point. ~/.gnupg/ is GnuPG's internal storage, and it's not recommended to rely on any specific data structures there, as they may change. gpg offers commands like --export, --import, and --delete for manipulating its persistent storage. please use them instead!
• If your package depends on parsing or displaying gpg's output for the user, please make sure you use its special machine-readable form (--with-colons). Parsing the human-readable text is not advised and may change from version to version.

If you maintain a package that depends on gnupg2 and tries to use gpg2 instead of gpg, that should stay ok. However, at some point it'd be nice to get rid of /usr/bin/gpg2 and just have one expected binary (gpg). So you can help with that:

• Look for places where your package expects gpg2 and make it try gpg instead. If you can make your code fall back cleanly
• Change your dependencies to indicate gnupg (>= 2)
• Patch lintian to encourage other people to make this switch ;)

What specifically needs to happen?The last major step for this transition was renaming the source package for "classic" GnuPG to be gnupg1. This transition is currently in the ftp-master's NEW queue. Once it makes it through that queue, and both gnupg1 and gnupg2 have been in experimental for a few days without reports of dangerous breakage, we'll upload both gnupg1 and gnupg2 to unstable.We'll also need to do some triage on the BTS, reassigning some reports which are really only relevant for the "classic" branch.Please report bugs via the BTS as usual! You're also welcome to ask questions and make suggestions on #debian-gnupg on irc.oftc.net, or to mail the Debian GnuPG packaging team at pkg-gnupg-maint@lists.alioth.debian.org.Happy hacking!Tags: gnupg

ChaosKey v1.0 Released USB Attached True Random Number Generator ChaosKey, our random number generator that attaches via USB, is now available for sale from the altusmetrum store. We talked about this device at Debconf 16 last month Support for this device is included in Linux starting with version 4.1. Plug ChaosKey into your system and the driver will automatically add entropy into the kernel pool, providing a constant supply of true random numbers to help keep the system secure. ChaosKey is free hardware running free software, built with free software on a free operating system.

• Schematic
• Hardware design files
• Firmware

I've been funded for two years by the DataLad project to work on git-annex. This has been a super excellent gig; they provided funding and feedback on ways git-annex could be improved, and I had a large amount of flexability to decide what to work on in git-annex. Also plenty of spare time to work on new projects like propellor, concurrent-output, and scroll. It was an awesome way to spend the last two years of my twenty years of free software. That funding is running out. I'd like to continue this great streak of working on the free software projects that are important to me. I'd normally dip into my savings at this point and keep on going until some other source of funding turned up. But, my savings are about to be obliterated, since I'm buying the place where I've had so much success working distraction-free. So, I've started a Patreon page to fund my ongoing work. Please check it out and contribute if you want to. Some details about projects I want to work on this fall:

• make debugging easier by building debug-me
• adding type level port conflict detection to Propellor
• finishing up git-annex v6 repository mode

The Cat Model of Package Ownership

Debian has been moving away from strong ownership of packages by package maintainers and towards encouraging group maintainership, for very good reasons: single maintainers have a bad bus factor and a number of other disadvantages.

When single maintainership is changed into maintainership by a small , open group of people who can easily communicate and sync with each other, everything is just better: there is an easy way to gradually replace people who want to leave, but there is also no duplication of efforts (because communication is easy), there are means to always have somebody available for emergency work and generally package quality can only gain from it.

Unfortunately, having such group of maintainers for every package would require more people than are available and willing to work on it, and while I think it's worth doing efforts to have big and important packages managed that way, it may not be so for the myriad of small ones that make up the long tail of a distribution.

Many of those packages may end up being maintained in a big team such as the language-based ones, which is probably better than remaining with a single maintainer, but can lead to some problems.

My experience with the old OpenEmbedded, back when it was still using monotone instead of git and everybody was maintaining everything, however, leads me to think that this model has a big danger of turning into nobody maintains anything, because when something needs to be done everybody is thinking that somebody else will do it.

As a way to prevent that, I have been thinking in the general direction of a Cat Model of Package Ownership, which may or may not be a way to prevent some risks of both personal maintainership and big teams.

The basic idea is that the my in my packages is not the my in my toys , but the my in my Cat, to whom I am a servant .

As in the case of a cat, if my package needs a visit to the vet, it's my duty to do so. Other people may point me to the need of such a visit, e.g. by telling me that they have seen the cat leaving unhealty stools, that there is a bug in the package, or even that upstream released a new version a week ago, did you notice?, but the actual putting the package in a cat carrier and bringing it to the vet falls on me.

Whether you're allowed to play with or pet the cat is her decision, not mine, and giving her food or doing changes to the package is usually fine, but please ask first: a few cats have medical issues that require a special diet.

And like cats, sometimes the cat may decide that I'm not doing a good enough job of serving her, and move away to another maintainer; just remember that there is a difference between a lost cat who wants to go back to her old home and a cat that is looking for a new one. When in doubt, packages usually wear a collar with contact informations, trying to ping those is probably a good idea.

This is mostly a summer afternoon idea and will probably require some refinement, but I think that the basic idea can have some value. Comments are appreciated on the federated social networks where this post is being published, via email (valid addresses are on my website http://www.trueelena.org/computers/articles/the_cat_model_of_package_ownership.html and on my GPG key http://www.trueelena.org/about/gpg.html) or with a post on a blog that appears on planet debian http://planet.debian.org/.

how small is small depends a lot on the size of the package, the amount of work it requires, how easy it is to parallelize it and how good are the people involved at communicating, so it would be quite hard to put a precise number here.

I've moved away from it because the boards I was using could run plain Debian, but I've heard that after the move to git there have been a number of workflow changes (of which I've seen the start) and everything now works much better.

Debian LTS July marked the fifteenth month I contributed to Debian LTS under the Freexian umbrella. As usual I spent the 8 hours working on these LTS things:

• Updated QEMU and QEMU-KVM packages to fix CVE-2016-5403, CVE-2016-4439, CVE-2016-4020, CVE-2016-2857 and CVE-2015-5239 resulting in DLA-573-1 and DLA-574-1
• Updated icedove to 45.2.0 fixing CVE-2016-2818 resulting in DLA-574-1
• Reviewed and uploaded xen 4.1.6.lts1-1. The update itself was prepared by Bastian Blank.
• The little bit of remaining time I spent on further work the ruby-active model,record -3.2 and ruby-actionpack-3.2 (aka rails) CVEs. Although I have fixes for most of the CVEs already there are still some left where I'm not yet clear if the packages are affected.
• Added some trivial autopkgtest for qemu-img (#832982) (on non LTS time)

Other Debian stuff

• Fixed CVE-2016-5008 by uploading libvirt 2.0.0 to sid and 1.2.9-9+deb8u3 to stable-p-u
• Uploaded libvirt 2.1.0~rc1 to experimental
• Uploaded libvirt-python 2.0.0 to sid
• Uploaded libosinfo 0.3.1 to sid preparing for the upcoming upstream package split
• Uploaded virt-manager 1.4.0 to sid
• Uploaded network-manager-iodine 1.2.0 to sid
• Uploaded cups-pk-helper 0.2.6 to sid
• Triaged apparmor related bugs in libvirt most notably the one affecting hotplugging of disks (#805002) which turned out to be rooted in the kernel not reloading profiles properly.
• Uploaded git-buildpackage 0.8.0, 0.8.1 to experimental adding additional tarball support to gbp import-orig among other things

A week has gone by and another small sharing about Doha and one package that quite a few of us use everyday but don t think much of them. Let s start with Doha with these two pictures which tells/shares a bit about what the Doha of today is like While I have more than a dozen snapshots of Doha, all of them show same thing, all are huge skyscrapers and overall Doha seems to be aping Dubai and is in a frenzy as World Cup 2022 is around the corner. We did see a few of the older places but these seemed to be more done for tourists rather than the real thing. We saw stuff like This was a picture taken by Ritesh Raj Saraff, a friend and a DD whom I met while I was going to Debconf. The place where this picture has been taken is known as a Souk or what we know as market-place. This was a place where you could get spices. Quite a few of the spices that we get and use in India were bought from Middle-East in the olden times. In fact, it has been argued that the whole Mughlai food that is part of Indian culture was imported from Middle-East when we were trading them before India or Akhand Bharat was invaded. What was interesting to both of us is that we could perceive that most of the buildings had a sort of fakeness to it, they tried to show that it had a lot of detailed work on the buildings but we could see it was all done recently so not that old as being led to believe. One of the other interesting bits that we came to know throughout our stay in Qatar that almost 80-90% of the staff we met inside Qatar airport as well as in the Souk were people from Asian sub-continent and more specifically from South India. I had few interesting conversations with some of the people who were managing the shops were that almost of them were just employees while the owners were Qataris . I could understand this as the distance and flight between Qatar and India is hardly 3 hours. It seemed very similar to how Mexicans look for work in United States. The most expensive thing there was water as it s desert other than housing and most workers seemed to have shared accommodation from anywhere between 5-15 people in one room. It s only the relative strength of the Qatari Rial which probably compels them to be there. The temperature was around 45 degrees with a bit of humidity as it s next to the Ocean. For all the money in the world, I wouldn t work there. It is true that you know your city s worth only when you go outside I do have some more stories about Qatar but that would have to wait for another day now. Also, I really don t want to talk much about this part as it s part depressing but probably would explore it a bit in a further blog-post. One of the more interesting topics that I attended was the apt talk . There are 3-4 tools in the Debian world i.e. apt, aptitude, apt-get, dpkg and dselect. More often than not people know aptitude and apt-get whereas the rest of the packages are not thought so much about. What I somewhat suspected about the history of apt was revealed to be true today, courtesy David K. You can see the talk/video about apt at http://meetings-archive.debian.net/pub/debian-meetings/2016/debconf16/The_past_year_in_APT.webm. I had been curious about apt,libapt,dpkg and the entire tool-chain which goes into updating packages and like. I had a couple of conversations here in India before on mail, in person and IRC as well as couple of conversations in South Africa as well before the APT talk where it was told that packages are not signed or it s not easy to figure out the integrity. Being a Debian fan-boy I could not believe this to be true. Hence I asked and to my dismay found it to be true . I also then asked the same with a bit more background on the mailing list as well and got to know that this has been a concern since 2005. As I do not have the requisite skills and the person would require probably knowledge of dpkg internals as well as have probably good social skills to have at least 1-2 DD s help her/im to work on it and have probably some server space where even some partial archive is re-built using debian packages which use dpkg-sig . I also had some concerns that even if somebody did do the work, it might come in the way of the reproducible builds concept where Neils shared ways in which it could be overcome. Having said the above, it is totally doable if somebody has the will, skills and the patience to do it. Just look at the amazing work done by the team which re-built almost all the archive using clang. See clang.debian.net for the amazing work that they have done. Now, one of the issues in India which comes in popularizing Debian or in fact any free software distribution in India is the bandwidth issue or rather the lack of it or how expensive it is. The situation for better lack of term is pathetic . While nothing can be done till the time the Govt. gives limited term oligopoly licenses to telecom operators and they have a cabal (cabal closed team where decisions and policies are made without any knowledge of and to other stakeholders.) we need to find ways to make the best of the situation. Anyways, while there are some ideas to tackle that but that s a long-term goal and I will share some aspects of it in probably another blog post. In the interim somethings can definitely be made better. Now one of the issues that is there for most people is getting the package updates. Before updating the packages, the package index needs to be updated. Now, both in home and work environments most people are cautious to update the package index. But many times, either due to bandwidth issues or some other issue which is outside your control, your package index is corrupted. I have put both the possible reasons of why and how the package index corruption takes place and a probable work-around of in the deity mail post. I do hope to put in a more coherent state by probably making smaller bug issues so they could be tackled or answered one by one. Any improvements would be better for stability of debian infrastructure only. If anybody does do the required work and need a guinea pig for testing, count me in. Just holler and share you will be working on this aspect and at least one of my workstations would definitely take part in seeing if its better or not. Even if you are able to just provide a way to make a copy of /var/lib/apt/lists after every successful update and do the comparison with time-stamp on next run and only change the copy when a successful update occurs, that will be a huge help in itself. Look forward to hearing form one and all.
Filed under: Miscellenous Tagged: #Debconf16, #feature-request, #Julian Andreas Klose, #shell-script ?, apt, aptitude

We, the Debian project and the Tor project are enabling Tor onion services for several of our sites. These sites can now be reached without leaving the Tor network, providing a new option for securely connecting to resources provided by Debian and Tor. The freedom to use open source software may be compromised when access to that software is monitored, logged, limited, prevented, or prohibited. As a community, we acknowledge that users should not feel that their every action is trackable or observable by others. Consequently, we are pleased to announce that we have started making several of the various web services provided by both Debian and Tor available via onion services. While onion services can be used to conceal the network location of the machine providing the service, this is not the goal here. Instead, we employ onion services because they provide end-to-end integrity and confidentiality, and they authenticate the onion service end point. For instance, when users connect to the onion service running at http://sejnfjrq6szgca7v.onion/, using a Tor-enabled browser such as the TorBrowser, they can be certain that their connection to the Debian website cannot be read or modified by third parties, and that the website that they are visiting is indeed the Debian website. In a sense, this is similar to what using HTTPS provides. However, crucially, onion services do not rely on third-party certification authorities (CAs). Instead, the onion service name cryptographically authenticates its cryptographic key. In addition to the Tor and Debian websites, the Debian FTP and the Debian Security archives are available from .onion addresses, enabling Debian users to update their systems using only Tor connections. With the apt-transport-tor package installed, the following entries can replace the normal debian mirror entries in the apt configuration file (/etc/apt/sources.list): Likewise, Tor's Debian package repository is available from an onion service : Where appropriate, we provide services redundantly from several backend machines using OnionBalance. The Debian OnionBalance package is available from the Debian backports repository. Lists of several other new onion services offered by Debian and Tor are available from https://onion.debian.org and https://onion.torproject.org respectively. We expect to expand these lists in the near future to cover even more of Debian's and Tor's services.

Before I started contributing to the iptables package back in December 2015 it suffered from a numbers of problems so the package was clearly in very bad shape.

One of the first problems was the lack of VCS for the package, no git, not even svn. Of course this was easy to solve and I did it straight away importing iptables 1.4.21-2 into a git repository.

The 1.4.21-2 version was dated in May 2014. This is a lot of time for a package which is active upstream and which is installed in almost all the Debian systems out there.

The number of Debian bugs opened for the package was simply huge, and I cleaned the bugtracker as reported in the blogpost "Current status of iptables & nftables in Debian".

Netfilter project upstream released version 1.6.0 which includes the nftables-compat stuff (iptables on top of the nftables kernel engine, and also the translation tools). Adding this was not an easy task given the overall state of the package.

Also, users were asking for normal things, like Multi-Arch support (see #776041). Adding Multi-Arch support to iptables has been my personal packaging nightmare for a couple of months.

Michael Biebl, who is systemd Debian maintainer, required some changes in the iptables package as well (see #787480). This change asked for a package split to libiptc, libip4tc, libip6tc and libxtables-dev (instead of iptables-dev).
This binary package split was also required for a proper Multi-Arch support.

The situation has been clearly a huge challenge for me,: I made a lot of mistakes, I discovered how little I know about complex packaging, and I had to learn a lot about several stuff.
Probably some experts and experienced DD's could have solved the situation with more solvency, but at the end I enjoyed all the work and the learning :-)

All this changes required me about 60 commits to complete, in several uploads. The last one is 1.6.0-3 which is now in the NEW queue.

I would like to note that both Ana Guerrero and Michael Biebl invested a lot of time in reviewing and sponsoring the packages. Thanks you!

There are still work to be done, of course.

This is a repost and update of my retirement letter sent privately to Debian last month, July 10, 2016. At that time I received many notes of appreciation and good wishes which I treasure. Now, I d like to say goodbye to the broader Debian community and, as well, indicate which of the cleanup items have since been addressed in strikethrough style and with annotations. Also, I d like to stay in touch with many of you, so I have added some comments oriented towards those of you who are interested in doing that after the letter.

When in 1995, on a tip from a friend, I installed Debian on my 386 at work and was enthralled with the results, I could not have foreseen that two years later, friends I had made on channel #debian would nudge me to become a Debian developer. Nor when that happened did I have any idea that twenty years later, I d consider Debian to be like family, the greatest free software community in the world, and would still be promoting it and helping people with it whenever I could. Debian quietly, unexpectedly became a part of what defines me. My priorities in life have changed over that time, though. I have shifted my attention to things that are more important to me in life, such as my family, my health and well-being physically and spiritually, and bringing all I can to bear on the task of preserving our local wilderness areas and trails. In the latter area, I m now bringing all of what Debian has helped shaped me to be to the table, launching some ambitious projects I hope will bear fruit in the coming years, and make a measurable contribution to help us hang onto our precious natural preserves where I live. Unfortunately, as I ve poured more time and energy into these things, I ve increasingly not been giving my packages the care they need. Nor do I have any roles or goals now for any of the Debian projects I was previously involved in. So, after much careful deliberation, and as much as it pains me to say it, it s time to retire as a Debian developer. It has been a great privilege to work with you, and to meet many of you in New York at Debconf 10. I plan to be around online, and will continue to take an interest in Debian, lending a hand when I can. Thanks for all of the fun times, for all that I ve learned, and for the privilege to make awesome things with you. I ll treasure this forever. So much for the soppy bits. Now, business. These things remain to clean up upon my departure, and I d appreciate help from QA, and anyone else who can lend a hand. My packages are effectively orphaned, but I haven t the time to do any of the cleanup myself, so please speak up if you can help.

1. Debian Jr.
   • O: junior-doc. The junior-doc package has been awaiting an overhaul by whoever revives the project since I gave it up years ago. I m still listed as maintainer and that should be changed to Debian Junior Maintainers <debianjr-maintainers@lists.alioth.debian.org> if they want it. Otherwise, it is orphaned.
   • I should also be dropped from Uploaders from debian-junior, the metapackages source. Fixed in git.
2. Tux Paint. This is a very special package that deserves to go to someone who will love it and care for it well. There are three source packages in all:
   • O: tuxpaint
   • O: tuxpaint-config
   • O: tuxpaint-stamps
3. O: xletters. This is a cute little typing practice game and needs a new maintainer.
4. XPilot is co-maintained by Phil Brooke <pjb@debian.org>, so he should replace me as Maintainer. Phil said he ll pick up xpilot-ng and will also look at xpilot-extra.
   • xpilot-ng
   • O: xpilot-extra (recently removed from testing due to my neglect, and not co-maintained by Phil; it s unclear if anyone really uses this anymore)
5. GTypist is co-maintained by Daniel Leidert <dleidert@debian.org> and should replace me as Maintainer.
6. My ruby packages. A group of packages that I brought into Debian as dependencies of taskwarrior-web, which I never completed. Maybe they ll be useful in and of themselves, and maybe not. In any case, they are maintained by pkg-ruby-extras-maintainers, but I m the sole developer in Uploaders and should be removed: Fixed in git.
   • ruby-blockenspiel
   • ruby-parseconfig
   • ruby-rack-flash3
   • ruby-simple-navigation
   • ruby-sinatra-simple-navigation
   • ruby-term-ansicolor
   • ruby-versionomy
7. Debian Live stuff: I am listed in Uploaders for live-manual (fixed in git) and debian-installer-launcher (fixed in git) and need to be removed.
8. O: eeepc-acpi-scripts. The defunct Debian EeePC project has just this one package. Recently, the mailing list was asked about its status, and it was recently NMU d. To my knowledge, nobody from the original team remains to take care of it, so it needs a new maintainer. I should be removed from Uploaders, and since the Debian Eee PC Team no longer exists, it should be removed as maintainer. It is effectively orphaned unless someone speaks up.

There are also some Alioth projects / lists that are defunct that I ll need to talk to the Alioth admins about cleaning up in the coming days. One of these is <debian-eeepc-devel@lists.alioth.debian.org> and since it is still listed as the maintainer of eeepc-acpi-scripts, that needs to be sorted out before the list can be closed. Thanks again, and see you around!
Ben

Stay in touch For those of you who would like to stay in touch, here are some ways to do that:

• Follow my blog: http://syn.theti.ca
  If you already do that, great! If not, welcome to my blog! For the past couple of years you may have noticed a decrease in technical content and increase in local trails and conservation oriented posts. You can expect more of the latter.
• Say hi to me on irc: SynrG (also SynrGy) on irc.oftc.net (irc.debian.org) or irc.freenode.net.
  I still intend to hang out and offer support when I can, just no longer as a developer. Channel #debian-offtopic on either network is a good place to catch up with me socially.
• Follow me on Facebook: https://www.facebook.com/SynrG
  For better or worse, a lot of the trails and conservation folks hang out here, and many of you in the Debian community are already my Facebook friends.
• Look for my Bluff Trail posts on their site: https://wrweo.ca
  Providing tech support to this organization is where much of my time and energy is going these days. I post here once in a while, but do most of my work behind the scenes as a volunteer and, newly this year, as a board member.

Here is my monthly update covering a large part of what I have been doing in the free software world (previously):

• Presented "Reproducible Builds status update" at DebConf16, the annual Debian GNU/Linux developer conference.
• Attended a Core Infrastricture Initiative summit meeting. The CII was set up in the wake of the Heartbleed SSL vulnerability to support software projects that are critical to the functioning of the internet.

• Ensured that the Webconverger web kiosk operating system builds reproducibly. I may rework some of the patches to libisoburn and libisofs before sending them upstream. This work was sponsored by Webconverger.
• Proposed a pull request for Regex Replace (a Chrome extension to automatically replace text on webpages) to ensure that the rules were correctly HTML encoded on the options page. (#3)
• Proposed a change to ronn, a documentation generator that "is the opposite of roff", to make the output reproducible. (#98)
• Fixed an issue in django-enumfield, a custom Django web development field for type-safe named constants, to make the Enum.get interface more consistent. (#36)
• Proposed a change to txt2tags to make the output use SOURCE_DATE_EPOCH and non-timezone timestamps. (#204).

---

PocketCHIP is the pocket sized Linux terminal I always used to want. Which is to say, it runs (nearly) stock Debian, X, etc, it has a physical keyboard, and the hardware and software is (nearly) non-proprietary and very hackable. Best of all, it's fun and it encourages playful learning. It's also clunky and flawed and constructed out of cheap components. This keeps it from being something I'd actually carry around in my pocket and use regularly. The smart thing they've done though is embrace these limitations, targeting it at the hobbiest, and not trying to compete with smart phones. The PocketCHIP is its own little device in its own little niche. Unless you're into hardware hacking and want to hook wires up to the GPIO pins, the best hardware feature is the complete keyboard, with even Escape and Control and arrow keys. You can ssh around and run vi on it, run your favorite REPL (I use ghci) to do quick programming, etc. The keyboard is small and a little strange, but you get used to it quickly; your QWERTY muscle memory is transferrable to it. I had fun installing nethack on it and handing it to my sister who had never played nethack before, to watch her learn to play. The screen resolution is 480x272, which is pretty tiny. And, it's a cheap resistive touchscreen, with a bezil around it. This makes it very hard to use scroll bars and icons near the edge of the screen. The customized interface that ships with it avoids these problems, and so I've been using that for now. When I have time, I plan to put a fullscreen window manager on it, and write a pdmenu menu configuration for it, so everything can be driven using the keyboard. I also have not installed Debian from scratch on it yet. This would be tricky because it uses a somewhat patched kernel (to support the display and wifi). The shipped distribution is sadly not entirely free software. There are some nonfree drivers and firmwares. And, they included a non-free gaming environment on it (a very nice one for part of the audience, that allows editing the games, but non-free nevertheless). They did do a good job of packaging up all the custom software they include on it, although they don't seem to have published source packages for everything. (They might be infringing my GPL copyright of flash-kernel by distributing a modified version without source. I say "might" because flash-kernel is a pile of shell scripts, so you could probably extract the (probably trivial) modifications. Still.. Also, they seem to have patched network-manager in some way and I wasn't able to find the corresponding source.) The battery life is around 5 hours. Unfortunately the "sleep" mode only turns off the backlight and maybe wifi, and leaves the rest of the system running. This and the slightly awkward form factor too big to really comfortably fit in a pocket limit the use of PocketCHIP quite a bit. Perhaps the sleeping will get sorted out, and perhaps I'll delete the GPIO breakout board from the top of mine to make it more pocket sized.

About a year ago, I bought a Projector after I finally admitted that I could actually use a TV in my apartment. I settled on buying a ViewSonic PJD5132. It was a really great value, and has been nothing short of a delight to own. I was always a bit curious about the DB9 connector on the back of the unit, so I dug into the user manual, and found some hex code strings in there. So, last year, between my last gig at the Sunlight Foundtion and USDS, I spent some time wandering around the US, hitting up DebConf, and exploring Washington DC. Between trips, I set out to figure out exactly what was going on with my Projector, and see if I could make it do anything fun. So, I started off with basics, and tried to work out how these command codes were structured. I had a few working codes, but to write clean code, I'd be better off understanding why the codes looked like they do. Let's look at the "Power On" code. 0x06 0x14 0x00 0x04 0x00 0x34 0x11 0x00 0x00 0x5D Some were 10 bytes, other were 11, and most started with similar looking things. The first byte was usually a 0x06 or 0x07, followed by two bytes 0x14 0x00, and either a 0x04 or 0x05. Since the first few bytes were similarly structured, I assumed the first octet (either 0x06 or 0x07) was actually a length, since the first 4 octets seemed always present. So, my best guess is that we have a Length byte at index 0, followed by two bytes for the Protocol, a flag for if you're Reading or Writing (best guess on that one), and opaque data following that. Sometimes it's a const of sorts, and sometimes an octet (either little or big endian, confusingly). Right. OK. So, let's get to work. In the spirit of code is data, data is code, I hacked up some of the projector codes into a s-expression we can use later. The structure of this is boring, but it'll let us both store the command code to issue, as well as define the handler to read the data back. As well as defining some of the const responses that come back from the Projector itself. These are pretty boring, but it's helpful to put a name to the int that falls out. After defining a few simple functions to write the byte arrays to the serial port as well as reading and understanding responses from the projector, I could start elaborating on some higher order functions that can talk projector. So the first thing I wrote was to make a function that converts the command entry into a native Hy function. Fun. Fun! Now, we can invoke it to create a Hy & Python importable API wrapper in a few lines! Cool. So, now we can import things like power-on from *commands* which takes a single argument (serial) for the serial port, and it'll send a command, and return the response. The best part about all this is you only have to define the data once in a list, and the rest comes for free. Finally, I do want to be able to turn my projector on and off over the network so I went ahead and make a Flask "API" on top of this. First, let's define a macro to define Flask routes: Now, we can define how we want our API to look, so let's define the power route, which will expand out into the Flask route code above. And now, let's play with it! Or, the volume! Check out the full source over at github.com/paultag/PJD5132!

I recently attended Snappy Sprint Heidelberg, the first Snappy sprint focused on upstream and cross-distribution collaboration.

Snappy is a technology with an interesting history: initially started to provide App Store-like semantics (atomicity, declarative security) for the Ubuntu Phone project, it has since expanded to be a platform for desktop application deployment (e.g. VLC), as well as server applications and the IoT space.

There were a number of productive discussions with people working on Snappy itself, as well as folks from Fedora, elementary OS, KDE, and elsewhere.

At the start of the week, Snappy was technically usable in several different distributions, but only shipped fully-featured (in the main distribution repositories, with confinement, etc) in Ubuntu. Some great progress was made on AppArmor confinement in Arch Linux, and there is currently beta support for confinement via SELinux.

Providing a full-featured Snappy experience in Debian has its challenges, mostly relating to the lack of a default LSM. While AppArmor in Debian is supported and there's desire to have it be the default in "buster", Ubuntu carries a number of patches that add additional functionality not yet present upstream. I'm not sure whether pursuing getting those patches merged is more viable than waiting for SELinux support in snapd, however.

I've agreed to co-maintain the snapd package in Debian, and am excited to see intentions to support building snaps on a variety of distribution bases. While I do not expect Snappy (or Flatpak, or AppImage) to replace distribution-maintained software in the foreseeable future, nor do I feel that's a desirable outcome, I do think offering users freedom to choose to use software via these systems in a safe manner is critical.

I bought a new laptop E200HA, because my previous was a MacBook and It broke after a fall into the ground. I let it boot first in Win10 to check if everything was OK and because I could not found the way to enter in the UEFI/BIOS. It is F2 and is edge triggered. It boots fast into Win10, but I got the feeling of being a little slow. No worries because I it bought for running Debian and because of the autonomy of the battery, 14hours playing music according to Asus. A little research if the new laptop could run Linux almost return no hits, but one very valuable link on how to setup the Wifi. So I got the feeling that I needed a Debian stretch CD for installation. So I download the first installation DVD from here. Run a trial of the DVD image using kvm

kvm -m 2047 -cdrom debian-stretch-DI-alpha7-amd64-DVD-1.iso

Found that the installer DVD now have the functionality of Live CD. This will be useful. Copy the image to a USB stick using dd command. I turned on the E200HA, entered into the UEFI/BIOS by pressing and releasing the F2 key. Turned off the secure boot and select USB storage for boot. The E200HA happily boot the Linux and I select the rescue mode. Using another USB stick of 32GB that was formatted in xfs, because of the lower slack for storing the inodes than ext3/4. In this USB stick I put a raw image of the internal storage of the E200HA, preserving this way the Win10. Another reboot, this time for installation of Debian stretch. It detected the lack of firmware files, for the WiFi adaptor. This link come very handy. The instructions are for an older Linux kernel. So I recommend doing something similar to the following commands:

git clone https://github.com/ajaybhatia/Qualcomm-Atheros-QCA9377-Wifi-Linux
cd Qualcomm-Atheros-QCA9377-Wifi-Linux/firmware-only
tar cvf QCA9377.tar QCA9377

Copy the tar file to a a second USB stick and connect it to the other USB port. This tar is not the files the Debian installer are expecting, so you need to change to the second console "Alt-F2", press enter to activate a shell, and do the following commands:

cd /lib/firmware
mkdir ath10k
mount /dev/sdb1 /mnt
cd ath10k
tar xf /mnt/QCA9377.tar

Return to the first console "Alt-F1" and continue with the installation. The list of missing firmware files is reduced and the WiFi can work. I had problems with the WiFI, but was because a neighbor router was on the same channel, since I changed the channel of my router the WiFi is working as a charm. The following links maybe useful in the future or as a reference: kvalo/ath10k-firmware kernel/git/firmware/linux-firmware.git

Talks have been finished, and as a special present to the participants, Pavneet has organized an excursion that probably was one of the best I ever had. First we visited the Toronto Reference Library where we were treated to a delicious collection of rare books (not to mention all the other books and architecture), and then a trip through the Ismaili Centre Toronto and the Aga Khan Museum.
(Kelmscott press edition from 1892 of William Morris A Dream of John Ball.) All these places were great pieces of architecture with excellent samples of the writing and printing art. And after all that and not to be mentioned, the conference dinner evening cruise! Our first stop was the Toronto Reference Library. Designed by Raymond Moriyama, it features a large open atrium with skylights, and it gives the library an open and welcoming feeling. We were told that it resembles a tea cup that needs to be filled with knowledge.
The library also features running water at several places the architect had the idea that natural ambient noise is more natural for a library than the eclectic silence that anyway never happens. Originally there were lots of greens hanging down into the Atrium, resembling the Hanging Gardens, but they have been scrapped due to financial reasons. But there are still green oasis like this beautiful green wall in a corner of the library.
We were guided first to the fifth floor where the special collection is housed. And what a special collection. The librarian in charge has laid out about 20 exquisite books starting from early illuminated manuscripts over incunabula to high pieces of printing art from the 18th and 19th century. Here we have a illuminated script in Carolingian minuscule.
What was really surprising for all of us in this special collection that all these books were simply laid out in front of us, that the librarian touched and used it without gloves, and above all, that he told us that if one wants it is common practice to check out these books for study sessions and enjoy them on the spot in the reading room. I don t know any other library that allows you to actually handle these rare and beauty specimens! The library not only featured lots of great books, it also had some art installation like these light rods.
In one of the books I found by chance a map of my hometown of Vienna. Looking at this map from very old times, the place where I grew up is still uninhabited somewhere in the far upper right corner of the map. Times have changed.
After we left this open and welcoming treasure house of beautiful books, we moved to the Aga Khan Museum and Ismaili Centre Toronto, which are standing face-to-face separated by some water ponds in the Aga Khan park a bit outside of central Toronto. Here we see the Ismaili Centre from the Aga Khan Museum entrance. The big glass dome is the central prayer room, and is illuminated at night. Just one detail one can see in the outer wall one part that looks like glass, too. This is the prayer alcove in the back of the prayer hall, and is made from huge slabs of Onyx that are also lit up in the night.
The Ismaili Centre, designed by Charles Correa combines modern functional and simple style with the wonderful ornamental art of the Islam heritage. The inside of the Ismaili Centre features many pieces of exquisite art calligraphy, murals, stone work, etc here is a medallion made from precious stone and set onto a hand-carved wall.
A calligraphy on the wall in the Ismaili Centre
Following the Ismaili Centre we turned to the Aga Khan museum which documents Islamic art, science, and history with an extensive collection. We didn t have much time, and in addition I had to do some fire-fighting over the phone, but the short trip through the permanent collection with samples of excellent calligraphy was amazing.
After returning from this lovely excursion and a short break, we set off for the last stop for tonight, the dinner cruise. After a short bus ride we could board our ship and off we go. Although the beer selection was not on par with what we are used from carft breweries, the perfectly sized boat with two decks and lots of places to hang around invited us to many discussions and chitchats. And finally I could enjoy also the skyline of Toronto.
After the dinner we had some sweets, one of which was a specially made cake with the TUG 2016 logo on it. I have to say, it was not only this cake but the whole excellent and overboarding food we had during all these days, that will make me go on diet when I am back in Japan. Pavneet organized for the lunch breaks three different style of kitchens (Thai, Indian, Italian), then the excursions to local brewers and and and If it wouldn t be for TeX, I would call it a Mastkur .
During the cruise we also had a little ceremony thanking Jim for his work as president of the TUG, but above all Pavneet for this incredible well organized conference. I think everyone agreed that this was the best TUG conference since long.
During the ceremony, Pavneet also announced the winners of the TUG 2016 fountain pen auction. These pens have a long history/travel behind them, see details on the linked page, and were presented to the special guests of the conference. Two remaining pens were auctioned with funds going to the TUG. The first one was handed over to Steve Grathwohl, and to my utter surprise the second one to myself. So now I am a happy owner of a TUG 2016 fountain pen. What a special feature! Just one more detail about these pens: They are traditional style, so without ink capsules, but one needs to insert the ink with a syringe. I guess I need to stack up a bit at home, and more importantly, train my really ugly hand-writing, otherwise it would be a shame to use this exquisite tool. We returned to the harbor around 10pm, and back to the hotel, where there was much greeting and thanking, as many people will return the following day.
I will also leave on Friday morning to meet with friends, thus I will not be participating in (and not reporting on) the last excursion of the TUG 2016. I will leave Toronto and the TUG 2016 with (nearly) exclusively good memories of excellent talks, great presentations, wonderful excursions, and lots of things I have learned. I hope to see all of the participants on next year s TUG meeting and I hope I will be able to attend it. Thanks a lot to Pavneet, you have done an incredible job. And last but not least, thanks to your lovely wife for letting you do all this, I know how much time we did steal from her. A few more photos can be found at the album Day 4 Books, ooh books.

kvm virtualization on a liberated X200, part 1

As the libreboot website warns https://libreboot.org/docs/hcl/x200.html: there are issues with virtualization on x200 without microcode updated.

Virtualization is something that I use, and I have a number of VMs on that laptop, managed with libvirt; since it has microcode version 1067a, I decided to try and see if I was being lucky and virtualization was working anyway.

The result is that the machines no longer start: the kernel loads, and then it crashes and reboots. I don't remember why, however, I tried to start a debian installer CD (iso) I had around, and that one worked.

So, I decided to investigate a bit more: apparently a new installation done from that iso (debian-8.3.0-amd64-i386-netinst.iso) boots and works with no problem, while my (older, I suspect) installations don't. I tried to boot one of the older VMs with that image in recovery mode, tried to chroot in the original root and got failed to run command '/bin/bash': Exec format error.

Since that shell was lacking even the file command, I tried then to start a live image, and choose the lightweight debian-live-8.0.0-amd64-standard.iso: that one didn't start in the same way as the existing images.

Another try with debian-live-8.5.0-i386-lxde-desktop.iso confirmed that apparently Debian > 8.3 works, Debian 8.0 doesn't (I don't have ISOs for versions 8.1 and 8.2 to bisect properly the issue).

I've skimmed the release notes for 8.3 https://www.debian.org/News/2016/20160123 and noticed that there was an update in the intel-microcodehttps://packages.debian.org/jessie/intel-microcode package, but AFAIK the installer doesn't have anything from non-free, and I'm sure that non-free wasn't enabled on the VMs.

My next attempt (thanks tosky on #debian-it for suggesting this obvious solution that I was missing :) ) was to run one of the VMs with plain qemu instead of kvm and bring it up-to-date: the upgrade was successful and included the packages in this screenshot, but on reboot it's still not working as before.

http://social.gl-como.it/photos/valhalla/image/ecb0e193b16fbd507d0148636177961b

Right now, I think I will just recreate from scratch the images I need, but when I'll have time I'd like to investigate the issue a bit more, so hopefully there will be a part 2 to this article.

Uploading to ftp-master (via ftp to ftp.upload.debian.org):
Uploading nageru_1.3.3-1.dsc: done.
Uploading nageru_1.3.3.orig.tar.gz: done.
Uploading nageru_1.3.3-1.debian.tar.xz: done.
Uploading nageru-dbgsym_1.3.3-1_amd64.deb: done.
Uploading nageru_1.3.3-1_amd64.deb: done.
Uploading nageru_1.3.3-1_amd64.changes: done.

So now it's in the NEW queue, along with its dependency bmusb. Let's see if I made any fatal mistakes in release preparation :-) Edit: Whoa, that was fast ACCEPTED into unstable.