Q: How to install latest XBMC on Debian?
A: Just run apt-get install xbmc Well, it actually installs XBMC from Debian and to get the 12.3 you also have to enable backports on Wheezy, but I guess you can forgive me for those nuances. Many thanks to the Debian Multimedia team, Modestas Vainius and Ron Lee who kindly backported XBMC s dependencies and also many thanks to the XBMC Developers for XBMC itself! The package is well tested on amd64, i386 and armhf, and it is now built on powerpc and armel, too. If you would like to see your favorite architecture running XBMC, please check the build logs and submit a patch fixing the build to the BTS. Happy hacking!

(Debian) packaging and Git. The big picture is as follows. In my view, the most natural way to work on a packaging project in version control [1] is to have an upstream branch which either tracks upstream Git/Hg/Svn, or imports of tarballs (or some combination thereof, and a Debian branch where both modifications to upstream source and commits to stuff in ./debian are added [2]. Deviations from this are mainly motivated by a desire to export source packages, a version control neutral interchange format that still preserves the distinction between upstream source and distro modifications. Of course, if you're happy with the distro modifications as one big diff, then you can stop reading now gitpkg $debian_branch $upstream_branch and you're done. The other easy case is if your changes don't touch upstream; then 3.0 (quilt) packages work nicely with ./debian in a separate tarball. So the tension is between my preferred integration style, and making source packages with changes to upstream source organized in some nice way, preferably in logical patches like, uh, commits in a version control system. At some point we may be able use some form of version control repo as a source package, but the issues with that are for another blog post. At the moment then we are stuck with trying bridge the gap between a git repository and a 3.0 (quilt) source package. If you don't know the details of Debian packaging, just imagine a patch series like you would generate with git format-patch or apply with (surprise) quilt. From Git to Quilt. The most obvious (and the most common) way to bridge the gap between git and quilt is to export patches manually (or using a helper like gbp-pq) and commit them to the packaging repository. This has the advantage of not forcing anyone to use git or specialized helpers to collaborate on the package. On the other hand it's quite far from the vision of using git (or your favourite VCS) to do the integration that I started with. The next level of sophistication is to maintain a branch of upstream-modifying commits. Roughly speaking, this is the approach taken by git-dpm, by gitpkg, and with some additional friction from manually importing and exporting the patches, by gbp-pq. There are some issues with rebasing a branch of patches, mainly it seems to rely on one person at a time working on the patch branch, and it forces the use of specialized tools or workflows. Nonetheless, both git-dpm and gitpkg support this mode of working reasonably well [3]. Lately I've been working on exporting patches from (an immutable) git history. My initial experiments with marking commits with git notes more or less worked [4]. I put this on the back-burner for two reasons, first sharing git notes is still not very well supported by git itself [5], and second Gitpkg maintainer Ron Lee convinced me to automagically pick out what patches to export. Ron's motivation (as I understand it) is to have tools which work on any git repository without extra metadata in the form of notes. Linearizing History on the fly. After a few iterations, I arrived at the following specification.

• The user supplies two refs upstream and head. upstream should be suitable for export as a .orig.tar.gz file [6], and it should be an ancestor of head.
• At source package build time, we want to construct a series of patches that
  1. Is guaranteed to apply to upstream
  2. Produces the same work tree as head, outside ./debian
  3. Does not touch ./debian
  4. As much as possible, matches the git history from upstream to head.

Condition (4) suggests we want something roughly like git format-patch upstream..head, removing those patches which are only about Debian packaging. Because of (3), we have to be a bit careful about commits that touch upstream and ./debian. We also want to avoid outputting patches that have been applied (or worse partially applied) upstream. git patch-id can help identify cherry-picked patches, but not partial application. Eventually I arrived at the following strategy.

1. Use git-filter-branch to construct a copy of the history upstream..head with ./debian (and for technical reasons .pc) excised.
2. Filter these commits to remove e.g. those that are present exactly upstream, or those that introduces no changes, or changes unrepresentable in a patch.
3. Try to revert the remaining commits, in reverse order. The idea here is twofold. First, a patch that occurs twice in history because of merging will only revert the most recent one, allowing earlier copies to be skipped. Second, the state of the temporary branch after all successful reverts represents the difference from upstream not accounted for by any patch.
4. Generate a "fixup patch" accounting for any remaining differences, to be applied before any if the "nice" patches.
5. Cherry-pick each "nice" patch on top of the fixup patch, to ensure we have a linear history that can be exported to quilt. If any of these cherry-picks fail, abort the export.

Yep, it seems over-complicated to me too. TL;DR: Show me the code. You can clone my current version from

git://pivot.cs.unb.ca/gitpkg.git

This provides a script "git-debcherry" which does the history linearization discussed above. In order to test out how/if this works in your repository, you could run

git-debcherry --stat $UPSTREAM

For actual use, you probably want to use something like

git-debcherry -o debian/patches

There is a hook in hooks/debcherry-deb-export-hook that does this at source package export time. I'm aware this is not that fast; it does several expensive operations. On the other hand, you know what Don Knuth says about premature optimization, so I'm more interested in reports of when it does and doesn't work. In addition to crashing, generating multi-megabyte "fixup patch" probably counts as failure. Notes

1. This first part doesn't seem too Debian or git specific to me, but I don't know much concrete about other packaging workflows or other version control systems.
2. Another variation is to have a patched upstream branch and merge that into the Debian packaging branch. The trade-off here that you can simplify the patch export process a bit, but the repo needs to have taken this disciplined approach from the beginning.
3. git-dpm merges the patched upstream into the Debian branch. This makes the history a bit messier, but seems to be more robust. I've been thinking about trying this out (semi-manually) for gitpkg.
4. See e.g. exporting. Although I did not then know the many surprising and horrible things people do in packaging histories, so it probably didn't work as well as I thought it did.
5. It's doable, but one ends up spending about a bunch lines of code on duplicating basic git functionality; e.g. there is no real support for tags of notes.
6. Since as far as I know quilt has no way of deleting files except to list the content, this means in particular exporting upstream should yield a DFSG Free source tree.

Finally, it happened! I became a Debian Developer! I wish to thank everybody involved in this process: from those who helped me in my initial packaging efforts, to who actually created the account. Many thanks to the pkg-perl team for accepting newbies and helping them: props to Damyan Ivanov, Gregor Herrmann, Gunnar Wolf! Thanks to Debian-Med and Debian CLI: they always believed in me, and I had a great time in these teams. A special thanks goes to Andreas Tille, who advocated my NM candidature. Thanks to my two AMs, Bart Martens and Bernd Zeimetz. Even if my NM was long, difficult and not so flawless, it all went good, at the end . A special thanks to Enrico Zini: he was the first DD signing my GPG key, thus allowing me to have more "rights" (being a DM), and experience some more responsibility than I previously had. Thanks to his "Become a DD. NOW!" right after checking my ID in Palermo -- Enrico, it finally happened! Thanks to Christoph Berg, Ron Lee, and Stephen Gran, which handled the final steps of the overall process. And now, dapal is here to break the world. Be warned!

A friend recommended me Steve Miller and Sharon Lee’s Liaden books. The first question, reading order, was not very easy to find an answer to. I went with publication order within the Agent of Change sequence – Agent of Change, Conflict of Honors, Carpe Diem, Plan B, and I Dare. In retrospect it would have been better to start with Conflict of Honors followed by Agent of Change, as this corresponds to story chronology, and AoC and CD have the same protagonists while CoH doesn’t. The story speed between Plan B and I Dare was too fast to break the sequence, but it might have made the latter book fuller if I had read the first batch of prequels Local Custom and Scout’s Progress before it. The second prequel sequence Crystal Soldier and Crystal Dragon works well at any point in the series, as does the third (single-book) prequel sequence Balance of Trade. I’m still reading Fledgling and the first short story collection. Confusing? I thought so, but it definitely is worth the investment. Instead of all the usual superlatives, I’ll say something unique to this series: These books changed my perspective in that I now cannot read (in any fiction) about a character bowing without asking in my head “in which mode, dammit!?”. (Update on 8th June: The friend referred to above, after reading this section, said (I paraphrase): “In the peculiar mode of humans, of course”.) The Liaden books are romances in a (very good) science-fictional setting. With two exceptions, each book creates at least one new lifetime romantic pairing, and they’re in my opinion convincing romances. One of the exceptions deepens one of the earlier relationships, so there is no lack of romance there. The only place I know where one can get all the novels reliably is Webscriptions, as e-books. Some of the paper books seem to be hard to find, and the recent closing down of the main publisher Meisha Merlin cannot help there. * * * The promotional material for The Mote in God’s Eye by Larry Niven and Jerry Pournelle includes a quote by Robert Heinlein: Possibly the finest science fiction novel I have ever read. It is hard for me to disagree with that statement (including the qualifier, in all honesty), having recently read this book. Mote is a complex first-contact story, set in Pournelle’s alternate history (originally future history) universe. It begins in the year 3017. The recently created Second Empire of Man gets a visit from the aliens, leading to a counter-visit by humans to the aliens’ star system. The aliens seem friendly, but are they? What could they possibly be hiding? In retrospect, the Moties remind me (in style, not in detail) of Orson Scott Card’s Piggies (Speaker for the Dead and sequels); I would be surprised if Card had not read this book before writing his. The sequel, The Gripping Hand is not the masterpiece that Mote is, but I had no trouble enjoying it. The solution to the Motie problem has held for decades, but it won’t hold forever, and it might actually be breaking down now. The mission: save both humans and Moties from an eventual assured mutual destruction. * * * I actually started reading Pournelle’s alternate/future history from the cronological beginning. This is another series where reading order becomes a complicated matter, as many of the books tell parallel subthreads of the story; and it becomes even more complicated by the fact that there is an omnibus edition in which the story is told in chronological order, this having been accomplished by breaking the books down into chunks and then arranging the chunks in chronological order. My reading order went as follows: West of Honor, The Mercenary, Prince of Mercenaries, Go Tell the Spartans and Prince of Sparta. This is a good reading order; my only problem with it is that the protagonist of West of Honor fails to appear in most of the other books. The following is not in my opinion a real spoiler, even though it reveals certain key events of the series. The premise is that sometime between the 1970’s and the early decades of the 21st Century the United States and the Soviet Union form a union, called the CoDominium, which dominates the international politics of the Earth for most of the 21st Century. In early 21st Century, faster-than-light travel is discovered, and the CoDominium starts to colonise other star systems, first with voluntary colonists and then with convicts and involuntary colonists. The series takes place in the final decades of CoDominium, and focuses on the actions of one John Christian Falkenberg (though he is not the protagonist of all the books), first as an officer in the CoDominium (extraterrestrial) military, and then as the Colonel of a mercenary outfit, Falkenberg’s Legion. The Legion is at the center of events that eventually (after the events described in these books) leads to the creation of the first Empire of Man. The books are entertaining military science fiction, solid, enjoyable journeyman pieces.