This is a burst of notes that I wrote in an e-mail in June when asked about it, and I'm not going to have any better steps since I don't remember even that amount as back then. I figured it's better to have it out than not.

So... if you want to use LUKS In-Place Conversion Tool, the notes below on converting a shipped-with-Ubuntu Dell XPS 13 Developer Edition (2015 Intel Broadwell model) may help you. There were a couple of small learnings to be had...

The page http://www.johannes-bauer.com/linux/luksipc/ itself is good and without errors, although funnily uses reiserfs as an example. It was only a bit unclear why I did save the initial_keyfile.bin since it was then removed in the next step (I guess it's for the case you want to have a recovery file hidden somewhere in case you forget the passphrase).

For using the tool I booted from a 14.04.2 LTS USB live image and operated there, including downloading and compiling luksipc in the live session. The exact reason of resizing before luksipc was a bit unclear to me at first so I simply indeed resized the main rootfs partition and left unallocated space in the partition table.

Then finally I ran ./luksipc -d /dev/sda4 etc.

I realized I want /boot to be on an unencrypted partition to be able to load the kernel + initrd from grub before entering into LUKS unlocking. I couldn't resize the luks partition anymore since it was encrypted... So I resized what I think was the empty small DIAGS partition (maybe used for some system diagnostic or something, I don't know), or possibly the next one that is the actual recovery partition one can reinstall the pre-installed Ubuntu from. And naturally I had some problems because it seems vfatresize tool didn't do what I wanted it to do and gparted simply crashed when I tried to use it first to do the same. Anyway, when done with getting some extra free space somewhere, I used the remaining 350MB for /boot where I copied the rootfs's /boot contents to.

After adding the passphrase in luks I had everything encrypted etc and decryptable, but obviously I could only access it from a live session by manual cryptsetup luksOpen + mount /dev/mapper/myroot commands. I needed to configure GRUB, and I needed to do it with the grub-efi-amd64 which was a bit unfamiliar to me. There's also grub-efi-amd64-signed I have installed now but I'm not sure if it was required for the configuration. Secure boot is not enabled by default in BIOS so maybe it isn't needed.

I did GRUB installation I think inside rootfs chroot where I also mounted /dev/sda6 as /boot (inside the rootfs chroot), ie mounted dev, sys with -o bind to under the chroot (from outside chroot) and mount -t proc proc proc too. I did a lot of trial and effort so I surely also tried from outside the chroot, in the live session, using some parameters to point to the mounted rootfs's directories...

I needed to definitely install cryptsetup etc inside the encrypted rootfs with apt, and I remember debugging for some time if they went to the initrd correctly after I executed mkinitramfs/update-initramfs inside the chroot.

At the end I had grub asking for the password correctly at bootup. Obviously I had edited the rootfs's /etc/fstab to include the new /boot partition, I changed / to be "UUID=/dev/mapper/myroot / ext4 errors=remount-ro 0 ", kept /boot/efi as coming from the /dev/sda1 and so on. I had also added "myroot /dev/sda4 none luks" to /etc/crypttab. I seem to also have GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda4:myroot root=/dev/mapper/myroot" in /etc/default/grub.

I've previously written about Canonical's obnoxious IP policy and how Mark Shuttleworth admits it's deliberately vague. After spending some time discussing specific examples with Canonical, I've been explicitly told that while Canonical will gladly give me a cost-free trademark license permitting me to redistribute unmodified Ubuntu binaries, they will not tell me what Any redistribution of modified versions of Ubuntu must be approved, certified or provided by Canonical if you are going to associate it with the Trademarks. Otherwise you must remove and replace the Trademarks and will need to recompile the source code to create your own binaries actually means.

Why does this matter? The free software definition requires that you be able to redistribute software to other people in either unmodified or modified form without needing to ask for permission first. This makes it clear that Ubuntu itself isn't free software - distributing the individual binary packages without permission is forbidden, even if they wouldn't contain any infringing trademarks[1]. This is obnoxious, but not inherently toxic. The source packages for Ubuntu could still be free software, making it fairly straightforward to build a free software equivalent.

Unfortunately, while true in theory, this isn't true in practice. The issue here is the apparently simple phrase you must remove and replace the Trademarks and will need to recompile the source code. "Trademarks" is defined later as being the words "Ubuntu", "Kubuntu", "Juju", "Landscape", "Edubuntu" and "Xubuntu" in either textual or logo form. The naive interpretation of this is that you have to remove trademarks where they'd be infringing - for instance, shipping the Ubuntu bootsplash as part of a modified product would almost certainly be clear trademark infringement, so you shouldn't do that. But that's not what the policy actually says. It insists that all trademarks be removed, whether they would embody an infringement or not. If a README says "To build this software under Ubuntu, install the following packages", a literal reading of Canonical's policy would require you to remove or replace the word "Ubuntu" even though failing to do so wouldn't be a trademark infringement. If an @ubuntu.com email address is present in a changelog, you'd have to change it. You wouldn't be able to ship the juju-core package without renaming it and the application within. If this is what the policy means, it's so impractical to be able to rebuild Ubuntu that it's not free software in any meaningful way.

This seems like a pretty ludicrous interpretation, but it's one that Canonical refuse to explicitly rule out. Compare this to Red Hat's requirements around Fedora - if you replace the fedora-logos, fedora-release and fedora-release-notes packages with your own content, you're good. A policy like this satisfies the concerns that Dustin raised over people misrepresenting their products, but still makes it easy for users to distribute modified code to other users. There's nothing whatsoever stopping Canonical from adopting a similarly unambiguous policy.

Mark has repeatedly asserted that attempts to raise this issue are mere FUD, but he won't answer you if you ask him direct questions about this policy and will insist that it's necessary to protect Ubuntu's brand. The reality is that if Debian had had an identical policy in 2004, Ubuntu wouldn't exist. The effort required to strip all Debian trademarks from the source packages would have been immense[2], and this would have had to be repeated for every release. While this policy is in place, nobody's going to be able to take Ubuntu and build something better. It's grotesquely hypocritical, especially when the Ubuntu website still talks about their belief that people should be able to distribute modifications without licensing fees.

All that's required for Canonical to deal with this problem is to follow Fedora's lead and isolate their trademarks in a small set of packages, then tell users that those packages must be replaced if distributing a modified version of Ubuntu. If they're serious about this being a branding issue, they'll do it. And if I'm right that the policy is deliberately obfuscated so Canonical can encourage people to buy licenses, they won't. It's easy for them to prove me wrong, and I'll be delighted if they do. Let's see what happens.

[1] The policy is quite clear on this. If you want to distribute something other than an unmodified Ubuntu image, you have two choices:

1. Gain approval or certification from Canonical
2. Remove all trademarks and recompile the source code

Note that option 2 requires you to rebuild even if there are no trademarks to remove.

[2] Especially when every source package contains a directory called "debian"

comments

The second update in the 0.12.* series of Rcpp is now on the CRAN network for GNU R. As usual, I will also push a Debian package. This follows the 0.12.0 release from late July which started to add some serious new features, and builds upon the 0.12.1 release in September. It also marks the sixth release this year where we managed to keep a steady bi-montly release frequency. Rcpp has become the most popular way of enhancing GNU R with C or C++ code. As of today, 512 packages on CRAN depend on Rcpp for making analytical code go faster and further. That is up by more than fifty package from the last release in September (and we recently blogged about crossing 500 dependents). This release once again features pull requests from two new contributors with Nathan Russell and Tianqi Chen joining in. As shown below, other recent contributors (such as such as Dan) are keeping at it too. Keep'em coming! Luke Tierney also email about a code smell he spotted and which we took care of. A big Thank You! to everybody helping with code, bug reports or documentation. See below for a detailed list of changes extracted from the NEWS file.

Changes in Rcpp version 0.12.2 (2015-11-14)

• Changes in Rcpp API:
  • Correct return type in product of matrix dimensions (PR #374 by Florian)
  • Before creating a single String object from a SEXP, ensure that it is from a vector of length one (PR #376 by Dirk, fixing #375).
  • No longer use STRING_ELT as a left-hand side, thanks to a heads-up by Luke Tierney (PR #378 by Dirk, fixing #377).
  • Rcpp Module objects are now checked more carefully (PR #381 by Tianqi, fixing #380)
  • An overflow in Matrix column indexing was corrected (PR #390 by Qiang, fixing a bug reported by Allessandro on the list)
  • Nullable types can now be assigned R_NilValue in function signatures. (PR #395 by Dan, fixing issue #394)
  • operator<<() now always shows decimal points (PR #396 by Dan)
  • Matrix classes now have a transpose() function (PR #397 by Dirk fixing #383)
  • operator<<() for complex types was added (PRs #398 by Qiang and #399 by Dirk, fixing #187)
• Changes in Rcpp Attributes:
  • Enable export of C++ interface for functions that return void.
• Changes in Rcpp Sugar:
  • Added new Sugar function cummin(), cummax(), cumprod() (PR #389 by Nathan Russell fixing #388)
  • Enabled sugar math operations for subsets; e.g. x[y] + x[z]. (PR #393 by Kevin and Qiang, implementing #392)
• Changes in Rcpp Documentation:
  • The NEWS file now links to GitHub issue tickets and pull requests.
  • The Rcpp.bib file with bibliographic references was updated.

Thanks to CRANberries, you can also look at a diff to the previous release As always, even fuller details are on the Rcpp Changelog page and the Rcpp page which also leads to the downloads page, the browseable doxygen docs and zip files of doxygen output for the standard formats. A local directory has source and documentation too. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Over the rainy weekend we watched two movies: Monuments Men (in Japanese it is called Michelangelo Project!) and Interstellar. Both blockbuster movies from the usual American companies, they are light-years away when it comes to quality. The Monuments Men are boring, without a story, without depth, historically inaccurate, a complete failure. Interstellar, although a long movie, keeps you frozen in the seat while being as scientific as possible and starts your brain working heavily. My personal verdict: 3 rotten eggs (because Rotten Tomatoes are not stinky enough) for the Monuments Men, and 4 stars for Interstellar. Story First for the plot of the two movies: The Monuments Men is loosely based on a true story about rescuing pieces of art at the end of the second world war, before the Nazis destroy them or the Russian take them away. A group of art experts is sent into Europe and manages to find several hiding places of art taken by the Nazis. Interstellar is set in near future where the conditions on the earth are deteriorating to a degree that human life seems to be soon impossible. Some years before the movie plays a group of astronauts were sent through a wormhole into a different galaxy to search for new inhabitable planets. Now it is time to check out these planets, and try to establish colonies there. Cooper, a retired NASA officer and pilot, now working as farmer, and his daughter are guided by some mysterious way to a secret NASA facility. Cooper is drafted for being a pilot on the reconnaissance mission, and leaves earth and our galaxy through the same wormhole. (Not telling more!) Monuments Men Looking at the cast of Monuments Men (George Clooney, Matt Damon, Bill Murray, John Goodman, Jean Dujardin, Bob Balaban, Hugh Bonneville, and Cate Blanchett) one would expect a great movie but from the very first to the very last scene, it is a slowly meandering shallow flow of sticked together scenes without much coherence. Tension is generated only through unrelated events (stepping onto a landmine, patting a horse), but never developed properly. Dialogs are shallow and boring with one exception: When Frank Stokes (George Clooney) meets the one German and inquires general about the art, predicting his future being hanged. Historically, the movie is as inaccurate as it can be despite Clooney stating that 80 percent of the story is still completely true and accurate, and almost all of the scenes happened . That contrasts starkly with the verdict of Nigel Pollard (Swansea University): There s a kernel of history there, but The Monuments Men plays fast and loose with it in ways that are probably necessary to make the story work as a film, but the viewer ends up with a fairly confused notion of what the organisation was, and what it achieved. The movie leaves a bitter aftertaste, hailing of American heroism paired with the usual stereotypes (French amour, German retarded, Russian ignorance, etc). Together with the half baked dialogues it feels like a permanent coitus interruptus. Interstellar Interstellar cannot serve with a similar cast, but still a few known people (Matthew McConaughey, Anne Hathaway, and Michael Caine!). But I believe this is actually a sign of quality. Well balancing scientific accuracy and the requirements for blockbusters, the movie successfully spans the bridge between complicated science, in particular general gravity, and entertainment. While not going so far to call the move edutainment (like both the old and new Cosmos), it is surprising how much of hard science is packed into this movie. This is mostly thanks to the theoretical physicist Kip Thorne acting as scientific consultant for the movie, but also due to the director Christopher Nolan being serious about it and studying relativity at Caltech. Of course, scientific accuracy has limits nobody knows what happens if one crosses the event horizon of a black hole, and even the existence of wormholes is purely theoretical by now. Still, throughout the movie it follows the two requirements laid out by Kip Thorne: First, that nothing would violate established physical laws. Second, that all the wild speculations would spring from science and not from the fertile mind of a screenwriter. I think the biggest compliment was that, despite the length, despite a long day out (see next blog), despite the rather unfamiliar topic, my wife, who is normally not interested in space movies and that kind, didn t fall asleep throughout the movie, and I had to stop several times to explain details of the theory of gravity and astronomy. So in some sense it was perfect edutainment!

Midsummer for me is also known as Noite do Lume Novo (literally New Fire Night ), one of the big calendar events of the year, marking the end of the school year and the beginning of summer. On this day, there are celebrations not very unlike the bonfires in the Guy Fawkes Night in England or Britain ^[1]. It is a bit different in that it is not a single event for the masses, more of a friends and neighbours thing, and that it lasts for a big chunk of the night (sometimes until morning). Perhaps for some people, or outside bigger towns or cities, Guy Fawkes Night is also celebrated in that way and that's why during the first days of November there are fireworks rocketing and cracking in the neighbourhoods all around. Like many other celebrations around the world involving bonfires, many of them also happening around the summer solstice, it is supposed to be a time of renewal of cycles, purification and keeping the evil spirits away; with rituals to that effect like jumping over the fire when the flames are not high and it is safe enough. So it was fitting that, in the middle of June (almost Midsummer in the northern hemisphere), I learnt that I was about to leave my now-previous job, which is a pretty big signal and precursor for renewal (and it might have something to do with purifying and keeping the evil away as well ;-) ). Whatever... But what does all of this have to do with aptitude or Debian, anyway? For one, it was a question of timing. While looking for a new job (and I am still at it), I had more spare time than usual. DebConf 15 @ Heidelberg was within sight, and for the first time circumstances allowed me to attend this event. It also coincided with the time when I re-gained access to commit to aptitude on the 19th of June. Which means Renewal. End of June was also the time of the announcement of the colossal GCC-5/C++11 ABI transition in Debian, that was scheduled to start on the 1st of August, just before the DebConf. Between 2 and 3 thousand source packages in Debian were affected by this transition, which a few months later is not yet finished (although the most important parts were completed by mid-end September). aptitude itself is written in C++, and depends on several libraries written in C++, like Boost, Xapian and SigC++. All of them had to be compiled with the new C++11 ABI of GCC-5, in unison and in a particular order, for aptitude to continue to work (and for minimal breakage). aptitude and some dependencies did not even compile straight away, so this transition meant that aptitude needed attention just to keep working. Having recently being awarded again with the Aptitude Hat, attending DebConf for the first time and sailing towards the Transition Maelstrom, it was a clear sign that Something Had to Be Done (to avoid the sideways looks and consequent shame at DebConf, if nothing else). Happily (or a bit unhappily for me, but let's pretend...), with the unexpected free time in my hands, I changed the plans that I had before re-gaining the Aptitude Hat (some of them involving Debian, but in other ways maybe I will post about that soon). In July I worked to fix the problems before the transition started, so aptitude would be (mostly) ready, or in the worst case broken only for a few days, while the chain of dependencies was rebuilt. But apart from the changes needed for the new GCC-5, it was decided at the last minute that Boost 1.55 would not be rebuilt with the new ABI, and that the only version with the new ABI would be 1.58 (which caused further breakage in aptitude, was added to experimental only a few days before, and was moved to unstable after the transition had started). Later, in the first days of the transition, aptitude was affected for a few days by breakage in the dependencies, due to not being compiled in sequence according to the transition levels (so with a mix of old and new ABI). With the critical intervention of Axel Beckert (abe / XTaran), things were not so bad as they could have been. He was busy testing and uploading in the critical days when I was enjoying a small holiday on my way to DebConf, with minimal internet access and communicating almost exclusively with him; and he promptly tended the complaints arriving in the Bug Tracking System and asked for rebuilds of the dependencies with the new ABI. He also brought the packaging up to shape, which had decayed a bit in the last few years. Gruesome Challenges But not all was solved yet, more storms were brewing and started to appear in the horizon, in the form of clouds of fire coming from nearby realms. The APT Deities, which had long ago spilled out their secret, inner challenge (just the initial paragraphs), were relentless. Moreover, they were present at Heidelberg in full force, in or close to their home grounds, and they were Marching Decidedly towards Victory: In the talk @ DebConf This APT has Super Cow Powers (video available), by David Kalnischkies, they told us about the niceties of apt 1.1 (still in experimental but hopefully coming to unstable soon), and they boasted about getting the lead in our arms race (should I say bugs race?) by a few open bug reports. This act of provocation further escalated the tensions. The fierce competition which had been going on for some time gained new heights. So much so that APT Deities and our team had to sit together in the outdoor areas of the venue and have many a weissbier together, while discussing and fixing bugs. But beneath the calm on the surface, and while pretending to keep good diplomatic relations, I knew that Something Had to Be Done, again. So I could only do one thing jump over the bonfire and Keep the Evil away, be that Keep Evil bugs Away or Keep Evil APT Deities Away from winning the challenge, or both. After returning from DebConf I continued to dedicate time to the project, more than a full time job in some weeks, and this is what happened in the last few months, summarised in another graph, showing the evolution of the BTS for aptitude: The numbers for apt right now (15th November 2015) are:

• 629 open (731 if counting all merged bugs independently)
• 0 Release Critical
• 275 (318 unmerged) with severity Important or Normal
• 354 (413 unmerged) with severity Minor or Wishlist
• 0 marked as Forwarded or Pending

The numbers for aptitude right now are:

• 488 (573 if counting all merged bugs independently)
• 1 Release Critical (but it is an artificial bug to keep it from migrating to testing)
• 197 (239 unmerged) with severity Important or Normal
• 271 (313 unmerged) with severity Minor or Wishlist
• 19 (20 unmerged) marked as Forwarded or Pending

The Aftermath As we can see, for the time being I could keep the Evil at bay, both in terms of bugs themselves and re-gaining the lead in the bugs race the Evil APT Deities were thwarted again in their efforts. ... More seriously, as most of you suspected, the graph above is not the whole truth, so I don't want to boast too much. A big part of the reduction in the number of bugs is because of merging duplicates, closing obsolete bugs, applying translations coming from multiple contributors, or simple fixes like typos and useful suggestions needing minor changes. Many of remaining problems are comparatively more difficult or time consuming that the ones addressed so far (except perhaps avoiding the immediate breakage of the transition, that took weeks to solve), and there are many important problems still there, chief among those is aptitude offering very poor solutions to resolve conflicts. Still, even the simplest of the changes takes effort, and triaging hundreds of bugs is not fun at all and mostly a thankless effort althought there is the occasionally kind soul that thanks you for handling a decade-old bug. If being subjected to the rigours of the BTS and reading and solving hundreds of bug reports is not Purification, I don't know what it is. Apart from the triaging, there were 118 bugs closed (or pending) due to changes made in the upstream part or the packaging in the last few months, and there are many changes that are not reflected in bugs closed (like most of the changes needed due to the C++11 ABI transition, bugs and problems fixed that had no report, and general rejuvenation or improvement of some parts of the code). How long this will last, I cannot know. I hope to find a job at some point, which obviously will reduce the time available to work on this. But in the meantime, for all aptitude users: Enjoy the fixes and new features! Notes [1] ^{^} Some visitors of the recent mini-DebConf @ Cambridge perhaps thought that the fireworks and throngs gathered were in honour of our mighty Universal Operating System, but sadly they were not. They might be, some day. In any case, the reports say that the visitors enjoyed the fireworks.

Depending on the application, sometimes you want to have some socket operations going (such as loading a website) and have stdin being read. There are plenty of examples for this in python which usually boil down to making stdin behave like a socket and mixing it into the list of sockets select() cares about. A while ago I asked an email list could I have pysnmp use a different socket map so I could add my own sockets in (UDP, TCP and a zmq to name a few) and the Ilya the author of pysnmp explained how pysnmp can use a foreign socket map. This sample code below is merely an mixture of Ilya s example code and the way stdin gets mixed into the fold. I have also updated to the high-level pysnmp API which explains the slight differences in the calls. Some interesting lines from the above code:

• Lines 8-11 are the stdin class that is called (or rather its handle_read method is) when there is text available on stdin.
• Line 34 is where pysnmp is told to use our socket map and not its inbuilt one
• Line 37 is where we have used the socket map to say if we get input from stdin, what is the handler.
• Lines 39-46 are sending a SNMP query using the high-level API
• Lines 48-51 are my simple socket poller

With all this I can handle keyboard presses and network traffic, such as a simple SNMP poll.

Like each month, here comes a report about the work of paid contributors to Debian LTS. Individual reports In September, 85.50 work hours have been dispatched among 8 paid contributors. Their reports are available:

• Ben Hutchings did 14 hours (13.5h allocated, thus only catching up 0.5 hours out of the 5.5 extra hours he had left from former month).
• Chris Lamb did 11 hours (12h allocated, he will catch up later).
• Guido G nther did 4 hours (out of 8 hours allocated, thus keeping 4 extra hours for November).
• Mike Gabriel did nothing (out of 8 hours allocated, he will catch up in November).
• Rapha l Hertzog did 13.25 hours.
• Santiago Ruano Rinc n did 13.5 hours.
• Scott Kitterman did 8 hours (4 hours allocated and 4 hours remaining from September)
• Thorsten Alteholz did 13.25 hours.

Evolution of the situation November crossed a new record with 114.5 hours funded. This is mainly thanks to our first Platinum sponsor: TOSHIBA (through Toshiba Software Development Vietnam). They don t know yet if they can sponsor us in the long term (they hope so), but it s still a nice news as we jumped from 50% to 65% of the objective of the equivalent of a full-time position with a single new sponsor. Currently no change is expected for next month as we don t have any other new sponsor in the process of joining us. We still need more support to be able to support all the packages we could not afford to support during the squeeze cycle. We are currently discussing which package we can or cannot support on the LTS list, see the thread Unsupported packages for Wheezy LTS for the current situation. In terms of security updates waiting to be handled, the situation is close to last month: the dla-needed.txt file lists 21 packages awaiting an update (6 more than last month), the list of open vulnerabilities in Squeeze shows about 23 affected packages in total (exactly like last month). Thanks to our sponsors The new sponsors are in bold.

• Platinum sponsors:
• TOSHIBA
• Gold sponsors:
• The Positive Internet (for 17 months already)
• Blablacar (for 16 months already)
• Linode LLC (for 6 months already)
• Silver sponsors:
• David Ayers IntarS Austria (for 17 months already)
• Domeneshop AS (for 16 months already)
• Universit Lille 3 (for 16 months already)
• Trollweb Solutions (for 14 months already)
• Gandi SAS (for 11 months already)
• University of Luxembourg (for 8 months already)
• Rentabiliweb Group (for 6 months already)
• Univention GmbH
• Universit Jean Monnet de St Etienne
• Bronze sponsors:
• Offensive Security (for 17 months already)
• Seznam.cz, a.s. (for 17 months already)
• Evolix (for 16 months already)
• Freeside Internet Service (for 16 months already)
• MyTux (for 16 months already)
• Linuxhotel GmbH (for 14 months already)
• Intevation GmbH (for 13 months already)
• Daevel SARL (for 12 months already)
• Bitfolk LTD (for 11 months already)
• Megaspace Internet Services GmbH (for 11 months already)
• Gree, Inc. (for 10 months already)
• Greenbone Networks GmbH (for 10 months already)
• NUMLOG (for 10 months already)
• WinGo AG (for 9 months already)
• Ecole Centrale de Nantes LHEEA (for 5 months already)
• Sig-I/O (for 3 months already)
• Entr ouvert

No comment Liked this article? Click here. My blog is Flattr-enabled.

A little over a year ago I wrote about how I'd been using a Mac as my main work machine. I hadn't written anything on the subject since. Here are four useful Mac programs that I can recommend to people. Sizeup, from Irradiated Software. A bit Like Windows' aero snap, but on steroids. I love this. I regularly move windows between two desktops (external and internal display), resize and centre them or put them in one quarter of the screen with just a few presses. The "snapback" feature is also great. X Lossless Decoder (XLD). A handy transcoder that can use QuickTime encoders and so can write out Apple/Quicktime/iTunes-encoded AAC/MP4 files en-mass, translating file meta-data. LimeChat, an IRC client. I theme it to look like Colloquy. The net result is pretty clean. I like using a proportional-font for text things, so getting IRC out of a terminal is a win for me. LimeChat automatically fetches and thumbnails URIs to images that people paste in channels, which is either incredibly convenient or a curse, depending on the channel. You can toggle that behaviour but only across the whole client, not on a channel or network basis. Finally, 1Password is an incredibly slick password manager. I use it in a very basic fashion: no mobile client, no syncing to anything outside of my workstation. You could also use LastPass which is similar and has a Linux client. I haven't tried it, but there's a third party tool to read 1Password password stores on Linux written by Ryan Coleman of SDL fame called 1pass.

Ok, I have been an iPhone user since I moved to Japan and got my first smart-phone ever. First a 3s, then a 4s, then a 5s that I dropped into the toilet, so I switched the SIM back into the 4s to have a working phone. Furthermore, I am a heavy music listener and used iTunes Radio for 3 months. Since I am planning to change phones to an Android phone (being fed up with Apple s super-closed environment), I tried out Google Music Plus for about 3 months, too. Here is my verict Google Music is a big pain, far from iTunes in comfort and user friendliness. My move to Android is not very much in danger. General description of the service In principle, iTunes Radio and Google Music Subscription do the same things:

• allow you to have your own music in the cloud
• stream any music from the respective market place to your device
• provide radio stations, pre-curated or based on artist/genre/etc

There are slight differences, that often create confusion, especially with Apple s services: If you are only signed in, you can listen to music stations and can skip some music (limited), but you cannot listen to arbitrary songs from the whole Apple Music library. Then there is another service from Apple, called iTunes Match, that only allows you to upload your music library to the cloud, but other than that again only listening to normal radio stations. Google Music is much simpler, there are only two options: By default it is free to have your music (up to 25000 songs) in the cloud, but if you want to listen to radio stations or any other music in the Google music store, you need a subscription. Prizes and features overview:

	Apple			Google
	No subscription	iTunes Match	iTunes Radio	No subscription	With subscription
Prize	0	25$/year	10$/month	0	10$/month (early access 8$)
Cloud space	0	100000		25000
Extra service	Radio stations	Radio stations	Radio/all music	Nothing	Radio/all music

Music on the go the application Let us first consider the applications provided to listen to music on your smart phone: Apple Music can of course only be used on Apple devices, and uses the built-in Music application. Start up time is about a few seconds after a cold boot (all on my 4s), and music streaming starts with hardly any delay. Responsiveness is good, and the user interface is clear and easy. Google s application is available on iOS and Android. I have tested the latest version on iOS, but it is a pain in the butt:

• Starting the application, even after cold boot, is successful at a rate of 1/10. Most of the time the application crashes right away. This might be a problem due to my low end device (iPhone 4s with 64Gb), but not due to space problems (half empty) nor internet connectivity (wlan).
• Responsiveness is abysmal
• Access to additional content (radio, songs) and your own library is well done, similar to iMusic.

Managing your library Here iTunes is the way to go, bit of a pain when using Linux, but there are other reasons I have a Windows installation in parallel, so I don t mind to boot now and then into Windows. iTunes gives you very powerful tools to change all kind of data. Google gives you a few options: Use your iTunes library in this case all your playlists and ratings (but see later) are also uploaded. I am not sure what happens if I retag a song in iTunes, or change anything else in there. I guess the song will not be re-uploaded, but who knows for sure. Furthermore, you can edit your library via the web interface, but this is rather poor. Searching your library Over times your library grows and there are hundreds if not thousands of artists. So you want to search them. The natural way would be to scroll to the first letter of the artist you are searching, and then look it up. Well, that works perfectly in both Apple s and Google s application unless you are having artists written in some strange script like Japanese or Korean. iTunes allows you to set a field called something like Artist name for sorting , which allows me to put for example or into the artist field, and into the sort field Tomokawa Kazuki and Kim Doo Soo . This way I find the artists in the correct place. Google on the other hand uses simple Unicode order sorting how could you do that? This is simply plain wrong, and everyone should know that by now. Japanese people will never be able to find anything in their list. And in contrast to Goole Contacts Google Music does not support phonetic name fields (similar to the order sort artist) for artists. What I had to do now is to rename all the artists to include first the phonetic name, followed by the proper name, like in Tomokawa Kazuki ( ) . Something I strongly detest! Radio stations I might have a slightly peculiar music taste, but the radio stations mixed by Google are simply a pain. The reason is easy to explain: I live in Japan, and so what Google does is mixing about 80% of J-Pop into the radio, all those happy yodeling girlies I really dislike (see my Anti J-Pop campaign for alternatives yes, they do exist also in Japan!). iTunes radio is here more relaxed it seems. I appreciate Google s trial to cater to local (dis)taste, but besides voting down each and every song I hear I don t see any other option. And honestly, I cannot go through all this voting down without dying from pain inflicted by J-Pop. Other than this, the two radio stations are probably more or less the same but as I said, due to the local colorit it is hard to compare. Rating Ohhh, what a dire point. So there you have you well curated iTunes library with 5-star ratings. I used the ratings in a way that those songs I like get 1 star, those I even like more get 2 stars, and my absolute favorites got 5 stars. I didn t do any negative ratings. iTunes/iOS Music app allows you to easily adjust rating, and they are synced between devices. All as you would expect. Now for Google they did have a 5-star rating system at some time, but:

Thank you for your feedback. We ve decided to remove the 5-star Rating lab. This decision wasn t made lightly, but Thumbs Up/Down is integral for the future vision for Play Music and will be a central design point for our future releases. Please note that we ll continue to store your ratings that you ve set via the star lab or via iTunes, and we ll translate them to thumbs up/down (1-2 stars = thumbs down, 4-5 stars = thumbs up).

Here we go with the move to a new design they threw away the 5-star system, without any reason but integral for future vision rubbish sales speak. Besides being a very very poor rating system to have only an up and down (good-bad-don t care), the translation from my rating system to the thumbs up-down is just plain wrong. <rant>
Why on earth is the current movement to reduce functionality and rob users of control? Gnome 3 is the prime example of how we stupiditize users by taken any freedom from them in the name of simple design. Google now does the same. I am so sick of getting patronized this way, so Gnome3 was completely banished from my computer and replaced by Cinnamon, which uses the same (good) underlying technique, but takes users seriously!
</rant> Overall verdict As much as I would like to see Google Music a valid alternative to iTunes, by now it makes the impression of a quickly hacked together rotten piece of code that tries to get a share of the market without providing equivalent service. Google is using its market presence and convenience to convert people, not features and quality. I can only hope that this changes in the future. That still leaves me with the question move to Android or remain with iOS

Debian Live has passed on. And it has done so in not happy circumstances. (You can search the list archives for more if you are confused.) I have reposted here my response to this one thread because it s all I really want to say, after all of the years of working with the team. I d like to add as a postscript, that while the focus of this article was to remain positive in the face of Daniel s announcement of the closure of his project, that event has left a lot of users confused about the status of live support in Debian going forward. Read my posts here and here addressing that confusion.

On 09/11/15 12:47 PM, Daniel Baumann wrote:
> So long, and thanks for all the fish[7].
>
> Daniel
>
> [7] http://live.debian.net/project/downstream/ Enough bitter words have been said. I don t want to add any more. So: I m proud. Indeed, that long list of downstreams does speak to the impact you ve had in inspiring and equipping people to make their own live images. I m proud to have been a small part of this project. I m thankful. I m thankful that I was able to, through this project, contribute to something for a while that had a positive impact on many people, and made Debian more awesome. I remember the good times. I remember fondly the good times we had in the project s heyday. I certainly found your enthusiasm and vision for the project, Daniel, personally inspiring. It motivated me to contribute. Debconf10 was a highlight among those experiences, but also I had many good times and made many friendships online, too. I m sad. I m sad, because although I made some attempts to liaise between Debian Live and the CD and Installer teams, I don t feel I did an effective job there, and that contributed to the situation we now find ourselves in. If I did you or the project injury in trying to fulfill that role, please forgive me. I m hopeful. I m hopeful that whichever way we all go from here, that the bitterness will not be forever. That we ll heal. That we ll have learned. That we ll move on to accomplish new things, bigger and better things. Thank you, Daniel. Thank you, Debian Live team. Ben

What happened in the reproducible builds effort this week: Toolchain fixes

• Colin Watson uploaded groff/1.22.3-2 which implements support for SOURCE_DATE_EPOCH.
• Colin Watson uploaded halibut/1.1-2 which implements support for SOURCE_DATE_EPOCH.

Chris Lamb filled a bug on python-setuptools with a patch to make the generated requires.txt files reproducible. The patch has been forwarded upstream. Chris also understood why the she-bang in some Python scripts kept being undeterministic: setuptools as called by dh-python could skip re-installing the scripts if the build had been too fast (under one second). #804339 offers a patch fixing the issue by passing --force to setup.py install. #804141 reported on gettext asks for support of SOURCE_DATE_EPOCH in gettextize. Santiago Vila pointed out that it doesn't felt appropriate as gettextize is supposed to be an interactive tool. The problem reported seems to be in avahi build system instead. Packages fixed The following packages became reproducible due to changes in their build dependencies: celestia, dsdo, fonts-taml-tscu, fte, hkgerman, ifrench-gut, ispell-czech, maven-assembly-plugin, maven-project-info-reports-plugin, python-avro, ruby-compass, signond, thepeg, wagon2, xjdic. The following packages became reproducible after getting fixed:

• 4ti2/1.6.6+ds-1 uploaded by Jerome Benoit, fixed upstream.
• allegro4.4/2:4.4.2-7 uploaded by Andreas R nnquist, original patch by Reiner Herrmann.
• axel/2.5-2 by Joao Eriberto Mota Filho.
• bastet/0.43-4 by Markus Koschany.
• bbswitch/0.8-3 uploaded by Luca Boccassi, original patch by Reiner Herrmann.
• commons-math/2.2-5 by Emmanuel Bourg.
• fatresize/1.0.2-8 by Colin Watson, reported by Chris Lamb.
• giada/0.10.2~dfsg1-1 by IOhannes m zm lnig.
• groff/1.22.3-3 by Colin Watson.
• halibut/1.1-2 by Colin Watson.
• ivy/2.4.0-2 by Emmanuel Bourg.
• libfreemarker-java/2.3.23-2 by Emmanuel Bourg.
• libjna-java/4.2.1-1 by Emmanuel Bourg.
• lmemory/0.6c-8 by Markus Koschany.
• man-db/2.7.5-1 by Colin Watson.
• maven2-core/2.2.1-23 by Emmanuel Bourg.
• ncurses/6.0+20151024-2 by Sven Joachim, report by Esa Peuha.
• netmask/2.4.3-1 by Guilhem Moulin.
• ogre-1.9/1.9.0+dfsg1-7 uploaded by Manuel A. Fernandez Montecelo, original patch by Chris Lamb.
• praat/6.0.4-2 by Rafael Laboissiere.
• soundscaperenderer/0.4.2~dfsg-5 by IOhannes m zm lnig.
• usb-modeswitch-data/20151101-1 uploaded by Didier Raboud, original patch by Reiner Herrmann.

Some uploads fixed some reproducibility issues but not all of them:

• dbconfig-common/1.8.55 by Paul Gevers.
• mondrian/1:3.11.0.1-1 by Emmanuel Bourg.

Patches submitted which have not made their way to the archive yet:

• #803893 on goaccess by Guillaume Delacour: remove __DATE__ and __TIME__ macros.
• #803908 on starlink-pal by Chris Lamb: pass -info 0 to latex2html.

Chris Lamb closed a wrongly reopened bug against haskell-devscripts that was actually a problem in haddock. reproducible.debian.net FreeBSD tests are now run for three branches: master, stable/10, release/10.2.0. (h01ger) diffoscope development Support has been added for Free Pascal unit files (.ppc). (Paul Gevers) The homepage is now available using HTTPS, thanks to Let's Encrypt!. Work has been done to be able to publish diffoscope on the Python Package Index (also known as PyPI): the tlsh module is now optional, compatibility with python-magic has been added, and the fallback code to handle RPM has been fixed. Documentation update Reiner Herrmann, Paul Gevers, Niko Tyni, opi, and Dhole offered various fixes and wording improvements to the reproducible-builds.org. A mailing-list is now available to receive change notifications. NixOS, Guix, and Baserock are featured as projects working on reproducible builds. Package reviews 70 reviews have been removed, 74 added and 17 updated this week. Chris Lamb opened 22 new fail to build from source bugs. New issues this week: randomness_in_ocaml_provides, randomness_in_qdoc_page_id, randomness_in_python_setuptools_requires_txt, gettext_creates_ChangeLog_files_and_entries_with_current_date. Misc. h01ger and Chris Lamb presented Beyond reproducible builds at the MiniDebConf in Cambridge on November 8th. They gave an overview of where we stand and the changes in user tools, infrastructure, and development practices that we might want to see happening. Feedback on these thoughts are welcome. Slides are already available, and the video should be online soon. At the same event, a meeting happened with some members of the release team to discuss the best strategy regarding releases and reproducibility. Minutes have been posted on the Debian reproducible-builds mailing-list.

For my 11th month working on Debian LTS, I carried over 5.5 hours from September and was assigned another 13.5 hours of work by Freexian's Debian LTS initiative. I worked 14 of a possible 19 hours. As I mentioned in the report for September, I uploaded binutils and issued DLA-324-1 early in October. I fixed a few security issues in the kernel, uploaded and issued DLA-325-1. I had some email discussions about long-term support of the Linux kernel with Willy Tarreau (Linux 2.6.32 maintainer) and Greg Kroah-Hartman (overall stable maintainer). Greg normally selects one version per year to maintain as a 'longterm' branch for 2 years, after which he may hand it over to another maintainer. A few upstream versions have received long-term support entirely from another developer. We were in agreement that it's desirable to have fewer of these branches with more developers and distributions contributing to each, but didn't come to a conclusion about how to coordinate this. The topic came up again at the Kernel Summit, and Greg then agreed to select the first kernel version of each calendar year, starting with Linux 4.4 (expected in January). This doesn't fit well with Debian's current release schedule, but I mean to discuss with the release team whether the freeze date can be set to allow inclusion of 2017's LTS kernel. I spent another week in the 'front desk' role, where I triaged new security issues for squeeze. There was a mixture of serious and trivial, old and new (not affecting squeeze) issues. The many ntp issues announced in October were fixed in unstable by a new upstream release. I spent a long time digging out the specific commits that fixed them and comparing with the older version in squeeze. Several of the issues had been introduced in ntp 4.2.7 or 4.2.8 and therefore didn't affect squeeze (or the newer stable releases). Of the fixes that were needed, most applied with minimal changes. Having prepared an update, I asked the ntp maintainer, Kurt Roeckx, to review my work. (The package has a limited test suite and none of the fixes added new tests.) Following this review he added a few more patches, uploaded and issued DLA-335-1. MySQL 5.1, as shipped in squeeze, no longer receives security support from upstream, and the security fixes they do issue are mixed with other changes that make it impractical to backport them. The LTS team is planning to backport the mysql-5.5 package to squeeze while avoiding conflicts with the binaries built from mysql-5.1. Santiago Ruano Rinc n has prepared a backport and I spent some time reviewing this, but haven't yet sent my review comments.

I've been trying to run containers using systemd-nspawn for quite some time. I was always bumping to one or other dead end. This is not systemd-nspawn's fault, rather my impatience stopping me from reading manual pages properly lack of good tutorial like article available online. Compared to this LXC has a quite a lot of good tutorials and howto's available online. This article is my effort to create a notes putting all required information in one place.

Debian LTS October was the sixth month I contributed to Debian LTS under the Freexian umbrella. In total I spent four hours working on:

• krb5: I applied patches for CVE-2015-2697 and CVE-2015-2695. The DLA-340-1 was released on November though since one of the patches was incomplete.

Besides that I did CVE triaging of 16 CVEs to check if and how they affect oldoldstable security as part of my LTS front desk work. I also added some very basic indentation support to our CVE/list Emacs major-mode on non LTS time. Other Debian stuff

• I've released git-buildpackage 0.7.0 with lots of updates, most notably more complete rpm support, a git-pbuilder update and documentation updates. This release has patches from 9 different contributors, thanks a lot!
• Uploaded libvirt 1.2.21~rc1 to experimental, submitted a patch to fix running autopkg tests in pbuilder (#802379) and fixed RC bug #802281 in Icedove.
• I've updated cl2vcs, a CGI to link commit IDs in the debian/changelog to the VCS, to 0.0.4 fixing some bugs that showed up after I updated the hosting machine to Jessie as well as support for the [commitid1,commitd2,commit3,...] format when grouping commits. (SSL certificate of the server is CAcert signed)
• At Halloween five Debian aficionados met for Hacking Erpel 1 (aka HEPL1) in Erpel (link goes to German Wikipedia) between Bonn and Koblenz. Some details are here. We're aiming for more of these events on a more frequent basis (HEPL0 being back in 2013) so if you're somewhere from that area and want to join us next time just subscribe to the new mailing list (in German, SSL certificate of the server is CAcert signed).

Tomorrow the Japanese TeX User Meeting 2015 will be held in Tokyo. Since I have come to Japan I have attended more or less every year this meeting, and in 2013 we could get the (international) TeX User Group Meeting to Tokyo and had a joint conference TUG 2013, which was a great success. (update 2015-11-09: slides added at the end)
During tomorrows meeting I will give a talk on Support for Japanese in TeX (Live) present state and future?:

The support for typesetting Japanese in TeX, in particular TeX Live, has been improved over the last few years considerably, so that at the current point we can ask ourselves what is next? This talk reviews a bit of the history of Japanese typesetting support in TeX Live, and discusses future development directions.

For those interested, here is a bit of an extended abstract. With a set of Japan specific TeX engines, the Japanese TeX Users always had a hard time setting up a proper TeX environment. Besides compiling the programs for each new version again, users had to install packages from a variety of sources, which often involved complicated routines. Fortunately, due to the excellent support on the TeX Q&A these difficulties were manageable. Compiling the Japanese TeX engines was first part of the pteTeX project, which adjusted teTeX to include also the required programs. Compilation was done by obtaining the source code of teTeX, plus patches that implement the Japanese TeX engines and support in driver programs. After the end of development of teTeX, TeX Live became the main TeX distribution system, and ptexlive was born to adjust the TeX Live sources to include the Japanese TeX engines. But fundamentally the same procedure remain: Get the source code, patch in additional functionality, compile and install. The last five years have seen a step-wise inclusion of various Japan-related programs in the main TeX Live source repository. Starting with pTeX (and pbibtex etc) and adjustments to dvipdfmx, followed by upTeX, and later on also (u)pmetapost, the main TeX Live source repository now contains all (with the exception of pxdvi) programs related to the Japanese TeX environment. At the same time, developers of various packages started to upload their packages to CTAN, which automatically made these packages available in TeX Live. Thus, the current status is quite satisfactory, since a normal TeX Live installation, without the need for any compilation, provides all necessary programs and packages. What remains a problem are inter-release updates of the binaries, when bugs in various engines are found. Future developments Besides the actual development of packages, and in particular luatexja, I see possible improvements in the following area:

• bug fixes for engines
  Up to now tlptexlive repository was partly used to test new packages, but also to distribute bug fixes for binaries. We are working on a better approach based on texjp.org which separates bug fixes and experimental/testing packages.
• more uploads to CTAN
  I can only ask all developers of packages to

  release often upload fast

  Normally updates from CTAN via TeX Live arrive at users within 2-3 days. Thus, if there is a bug in an uploaded version, it can be easily and quickly fixed. Please do not hold development version for long time, and force users to pick your packages from different places. In the long run it makes it more complicated for everyone.
• pTeX-ng
  After a first rush of activity, we are now at a relatively inactive state. I don t know what will happen with pTeX-ng, especially since it does not fit into the TeX Live source eco system easily due to a completely different build procedure and kpathsea library usage, but the future might show new directions.

Summing up, I am quite happy to see that both the Japanese community, as well as the Korean community, have now taken the step to make their achievements available in an easy and straightforward way for everyone using TeX Live, and I am sure that the future will bring further improvements!

---

The slides accompanying the talk can be downloaded here: texconf15-texlive-japan.pdf. I also talked briefly on CJK font integration for Ghostscript, these slides can be downloaded here: texconf15-cjk-gs.pdf.

So the work on lumail2 is going well, and already I can see that it is a good idea. The main reason for (re)writing it is to unify a lot of the previous ad-hoc primitives (i.e. lua functions) and to try and push as much of the code into Lua, and out of C++, as possible. This work is already paying off with the introduction of new display-modes and simpler implementation. View modes are an important part of lumail, because it is a modal mail-client. You're always in one mode:

• maildir-mode
  • Shows you lists of Maildir-folders.
• index-mode
  • Shows you lists of messages inside the maildir you selected.
• message-mode
  • Shows you a single message.

This is nothing new, but there are two new modes:

• attachment-mode
  • Shows you the attachments associated with the current message.
• lua-mode
  • Shows you your configuration-settings and trivia.

Each of these modes draws lines of text on the screen, and those lines consist of things that Lua generated. So there is a direct mapping:

Mode	Lua Function
maildir	function maildir_view()
index	function index_view()
message	function message_view()
lua	function lua_view()

With that in mind it is possible to write a function to scroll to the next line containing a pattern like so:

function find()
   local pattern = Screen:get_line( "Search for:" )
   -- Get the global mode.
   local mode = Config:get("global.mode")
   -- Use that to get the lines we're currently displaying
   loadstring( "out = " .. mode .. "_view()" )()
   -- At this point "out" is a table containing lines that
   -- the current mode wishes to display.
    -- .. do searching here.
end

Thus the whole thing is dynamic and mode-agnostic. The other big change is pushing things to lua. So to reply to an email, populating the new message, appending your ~/.signature, is handled by Lua. As is forwarding a message, or composing a new mail. The downside is that the configuration-file is now almost 1000 lines long, thanks to the many little function definitions, and key-binding setup. At this rate the first test-release will be out at the weekend, but API documentation, and sample configuration file might make interesting reading until then.