Search Results: "skitt"

26 April 2020

In the contested space between the interested amateur and the trained
expert lies the enthusiast. A topic has, for often inexplicable reasons,
caught fire in their thoughts and become a mild obsession. They may not
have formal training or systematic conceptual grounding beneath their
interest, but they partly make up for that lack with sustained
fascination. They research widely and obscurely about their particular
focus, develop novel theories, see distinctions and classifications that
few others would bother to investigate, and present their discoveries to
anyone who will stand still long enough. And occasionally, when that
interest happens to coincide with writing skill, they produce some
surprisingly excellent essays or books.
Matt Potter's enthusiasm is resignation letters.

Every damaging resignation letter, every cornered truth attack, every
out-of-control speech by a former friend, is more than just an
inconvenience, to be countered with positive spin and internal memos:
it's an open challenge to the official version of the story, the
perfectly controlled brand. They are breaks in an otherwise perfectly
planned, smoothly executed narrative of the powerful. Holes in the
program code. A rare, irresistible chance to hack into history's
shiny, unstoppable operation.

The Last Goodbye: A History of the World in Resignation Letters is
not, in truth, a history of the world. It is, first and foremost, a
taxonomy, because there are types of resignation letters. The opening
chapter, the truth bomb, is the type that one would expect upon
discovering that someone wrote a book on the topic (that wasn't advice on
how to write a good one). But there are other types, less heavy on the
fireworks but just as fascinating. The unquotable expert construction.
The knife in the back. The incoherent scream of rage. But also the
surprisingly gentle and graceful conclusion.

It is the question that the letters themselves try in vain to answer,
over and over again even as they explain, analyse, protest and bear
witness to a million other details.
The question is: Why?
All the forces in the universe stack up against unburdening ourselves
in a resignation letter. Professionally, it can be suicide. In
practical terms, it is often self-defeating. Self-help books coach
against unleashing its force; colleagues and confidantes urge caution,
self-restraint. And yet we do it, and damn the consequences. We have
no choice but to speak in sorrow, love, grief, cold anger, thirst
for revenge, wounded pride, the pain of injustice, loyalty, pangs of
regret, throes of vengeful madness, deluded righteousness, panic,
black distress, isolation, ecstasies of martyrdom, and a million other
shades of human extremity we need to say our piece even as we leave
the stage.

The risk of the enthusiast's book is that the lack of structural grounding
can leave the conclusions unsupported. A fair critique of this book is
that it contains a lot of amateur sociology. Potter has a journalist's
eye for motive and narrative, but some of his conclusions may not be
warranted. But he compensates for the lack of rigor with, well,
enthusiasm. Potter is fascinated by resignation letters and the insight
they offer, and that fascination is irresistibly contagious.
It's probably obvious that the chapters on truth bombs, fuck yous, and
knives in the back have visceral appeal. The resignation letter as a
force of truth-telling, as the revenge of a disregarded peon, as a crack
in the alliance between the powerful that may let some truth shine
through, is what got me to buy this book. And Potter doesn't disappoint;
he quotes from both famous and nearly unknown examples, dissects the
writing and the intent, and gives us a ringside seat to a few effective
acts of revenge.
That's not the best part of this book, though. The chapter that I will
remember the longest is Potter's dissection of the constructed resignation
letter. The carefully drafted public relations statement, the bland
formality, the attempt to make a news story disappear. The
conversation-ender.
It's a truism that any area of human endeavor involves more expertise than
those who have only observed it from the outside will realize, but I had
never thought to apply that principle to the ghost-written resignation
letter. The careful non-apology, the declaration that one has "become a
distraction," the tell-tale phrasing of "spending more time with my
family" is offensive in its bland dishonesty. But Potter shows that the
blandness is expertly constructed to destroy quotability. Those
statements are nearly impossible to remember or report on because they
have been built that way: nouns carefully separated from verbs, all force
dissipated by circuities and modifiers, and subtle grammatical errors
introduced to discourage written news from including direct quotes.
Potter's journalism background shines here because he can describe the
effect on news reporting. He walks the reader through the construction to
reveal that the writing is not incompetent but instead is skillfully bad
in a way that causes one's attention to skitter off of it. The letter
vanishes into its own vagueness. The goal is to smother the story in such
mediocrity that it becomes forgettable. And it works.
I've written several resignation letters of my own. Somewhat unusually,
I've even sent several of them, although (as Potter says is typical) fewer
than I've written. I've even written (and sent) the sort of resignation
letter that every career advisor will say to never send. Potter's
discussion of the motives and thought process behind those letters rang
true for me. It's a raw and very human moment, one is never in as much
control of it as one wishes, the cracks and emotions break through in the
writing, and often those letters are trying to do far too many things at
the same time. But it's also a moment in which one can say something
important and have others listen, which can be weirdly challenging to do
in the normal course of a job.
Potter ends this book beautifully by looking at resignation letters that
break or transcend the mold of most of the others he's examined: letters
where the author seems to have found some peace and internal understanding
and expresses that simply and straightforwardly. I found this
surprisingly touching after the emotional roller-coaster of the rest of the
book, and a lovely note on which to end.
This is a great book. Potter has a good eye for language and the emotion
encoded in it, a bracing preference for the common worker or employee over
the manager or politician, and the skill to produce some memorable turns
of phrase. Most importantly, he has the enthusiast's love of the topic.
Even if you don't care about resignation letters going in, it will be hard
to avoid some fascination with them by the end of this book. Recommended.
This book was originally published as F*ck You and Goodbye in the
UK.
Rating: 8 out of 10

12 November 2017

As a cat owner, being surprised by cat intelligence delights me. They re not exactly smart like a human, but they are smart in cattish ways. The more I watch them and try to sort out what they re thinking, the more it pleases me to discover they can solve problems and adapt in recognizably intelligent ways, sometimes unique to each individual cat. Each time that happens, it evokes in me affectionate wonder.
Today, I had one of those joyful moments.
First, you need to understand that some months ago, I thought I had my male cat all figured out with respect to mealtimes. I had been cleaning up after my oafish boy who made a watery mess on the floor from his mother s bowl each morning. I was slightly annoyed, but was mostly curious, and had a hunch. A quick search of the web confirmed it: my cat was left-handed. Not only that, but I learned this is typical for males, whereas females tend to be right-handed. Right away, I knew what I had to do: I adjusted the position of their water bowls relative to their food, swapping them from right to left; the messy morning feedings ceased. I congratulated myself for my cleverness.
You see, after the swap, as he hooked the kibbles with his left paw out of the right-hand bowl, they would land immediately on the floor where he could give them chase. The swap caused the messes to cease because before, his left-handed scoops would land the kibbles in the water to the right; he would then have to scoop the kibble out onto the floor, sprinkling water everywhere! Furthermore, the sodden kibble tended to not skitter so much, decreasing his fun. Or so I thought. Clearly, I reasoned, having sated himself on the entire contents of his own bowl, he turned to pilfering his mother s leftovers for some exciting kittenish play. I had evidence to back it up, too: he and his mother both seem to enjoy this game, a regular fixture of their mealtime routines. She, too, is adept at hooking out the kibbles, though mysteriously, without making a mess in her water, whichever way the bowls are oriented. I chalked this up to his general clumsiness of movement vs. her daintiness and precision, something I had observed many times before.
Come to think of it, lately, I ve been seeing more mess around his mother s bowl again. Hmm. I don t know why I didn t stop to consider why
And then my cat surprised me again.
This morning, with Shadow behind my back as I sat at my computer, finishing up his morning meal at his mother s bowl, I thought I heard something odd. Or rather, I didn t hear something. The familiar skitter-skitter sound of kibbles evading capture was missing. So I turned and looked. My dear, devious boy had squished his overgrown body behind his mother s bowls, nudging them ever so slightly askew to fit the small space. Now the bowl orientation was swapped back again. Stunned, I watched him carefully flip out a kibble with his left paw. Plop! Into the water on the right. Concentrating, he fished for it. A miss! He casually licked the water from his paw. Another try. Swoop! Plop, onto the floor. No chase now, just satisfied munching of his somewhat mushy kibble. And then it dawned on me that I had got it somewhat wrong. Yes, he enjoyed Chase the Kibble, like his mom, but I never recognized he had been indulging in a favourite pastime, peculiarly his own
I had judged his mealtime messes as accidents, a very human way of thinking about my problem. Little did I know, it was deliberate! His private game was Bobbing for Kibbles. I don t know if it s the altered texture, or dabbling in the bowl, but whatever the reason, due to my meddling, he had been deprived of this pleasure. No worries, a thwarted cat will find a way. And that is the joy of cat intelligence.

The Mage Wars series (or the Gryphon series, which isn't its official
title but which is in all of the titles) is part of the sprawling Valdemar
mega-series, but it's a prequel to all of the other stories. It's also
slightly challenging if you're reading in publication order, since it was
published simultaneously with the Mage Storms series. If you're following
publication order, in theory you should interleave the two series, but I
hate doing that. I'm therefore reading it after Mage Winds and before Mage Storms. We'll see whether that was a good
idea when I get to the next series.
You could, if you really wanted to, read this series before any other
Valdemar book. As a prequel from the deep past of Valdemar's world, it
doesn't depend on the other series, and you'll get a rediscovery of lost
knowledge feel from later books. The downside is that it's a rather
boring introduction, and that order would spoil a lot of the revelatory
flow of the other series (particularly Elspeth's adventures in the Mage
Winds books).
I'm now getting into the Valdemar books that I've only read once. I've
been putting off continuing my Valdemar re-read because this series was
next and I remember being rather bored with it the first time I read it.
But I'm re-reading for the world-building and background as much as for
the characters, and this is a huge chunk of world background that fills in
the bones underneath Winds of Fate and
its sequels. Here's why Dhorisha is a crater, here's why the Pelagiris
forests are such a mess, here's where Ma'ar starts, here's the origin of
both the gryphons and K'Leshya, and here, finally, we get to see the
legendary Urtho on the page.
The problem with writing novels set in the epic backstory of your universe
is that it's hard to live up to the drama that readers have invented for
themselves. A lot of The Black Gryphon is background to events
Valdemar readers already know will happen, creating a corresponding lack
of surprise. I reached the end of the book and said "yup, that's pretty
much what everyone said had happened."
Lackey and Dixon do try to do some interesting things here, one of which
being the backgrounding of the war. The Black Gryphon starts in
the middle of a long-running conflict between Urtho and Ma'ar and doesn't
follow the generals or the battles. The protagonists, instead, are a
kestra'chern (a type of psychiatrist and spiritual healer who
also uses sex, with the expected conflicts of people who incorrectly think
of them as prostitutes) and the eventual leader of the gryphons
(Skandranon, who is referenced in later books and who provides the title).
We get some combat scenes from Skandranon and later another gryphon, but a
lot of the book is Amberdrake fighting the effects of the war instead of
the details of the war itself.
There's a deep and moving story in that idea, and in some of the attached
love stories that play out in the army camps. There's also a great story
somewhere around Urtho: a brilliant but detached mage who is way out of
his depth trying to run an army but smart enough to gather good people
around him. He's also a creator of new life, including the gryphons.
The Black Gryphon tries to talk about Urtho's paternalism, the
weird emotional currents of his relationship with his creations, and the
places Urtho keeps things from others for, supposedly, their own good. If
this book had looked a bit deeper at the support structure for an army
that's trying to be humane, or at the ways in which Urtho strays far too
close to being an abusive tyrant through inaction despite having the best
of intentions at every step, I think it could have said something
significant.
Unfortunately, that's not this book. This book is full of relentlessly
black and white morality (the flaw of much of the Valdemar series) that
bleaches away interesting shades of grey. Urtho is good and wise by
authorial fiat, and Ma'ar is the same utterly irredeemable force of evil
that he is in other books. The story skitters over Urtho's odd tyrannies,
making them all better with the pure power of friendship and good
intentions. There just isn't much emotional depth, and while I don't
expect that of Lackey in general, this story really needed that depth to
work.
What we get instead is repetition, as Lackey and Dixon hit the same
emotional notes with Amberdrake repeatedly. This is one of those books
that makes me wonder if Lackey was trying to write too many novels in a
short time than was good for their individual quality. (Collaborations
often mean that the lesser-known name is doing all the work, but Dixon is
Lackey's husband and the tone of the book is sufficiently Lackey that I
don't think that happened here.) It felt padded by Amberdrake turning
over the same emotional rocks repeatedly, to largely the same effect.
This is, in short, not Lackey's finest effort, although it does have its
moments. As always, Lackey is at her best when writing psychological
healing narratives. Zhaneel's story is a bit too easy, but the dynamic
between Amberdrake and Winterhart is the best part of the book. And
The Black Gryphon does tell the reader exactly what led up to the
Cataclysm and why. There are no major surprises, but there are some small
ones, and it's a nice payoff for the lore-obsessed (like me).
This is missable unless you want the full world-building behind Valdemar's
past, and it's not the best writing. But if you're heavily invested in
the Valdemar universe, it's at least readable and provides an important
bit of the history.
Followed by The White Gryphon.
Rating: 5 out of 10

24 October 2017

Raven Stratagem is the sequel to Ninefox Gambit and will make very little sense if you've not read
the previous book. In fact, I'll add a rare warning, one that I wish I'd
had and followed: you need to be deeply familiar with the details of the
end of Ninefox Gambit or large chunks of this book will make no
sense. I read the previous book earlier this year, but my memory of some
of the specifics of the ending had slipped, and I ended up having to
skim the ending of the previous book several times. Consider re-reading
that bit before starting this book if you share my lack of memory for plot
specifics and it's been more than a few months.
I unfortunately can't provide a plot summary, since there's almost nothing
I can say about the plot that doesn't spoil Ninefox Gambit. It is
basically the story that you would expect from the very end of
Ninefox Gambit, though, although the way it's carried out is not
quite as dramatic as I was expecting.
I wanted to like this book a great deal. Ninefox Gambit introduced
a beautiful magitech system, but it was otherwise mostly setup and one
extended battle. Its ending promised engagement with larger universe
politics, and prospects of doing something about the deep unfairness of
the current political system. I was hoping this book would contain the
payoff of that escalation. It does deliver on that payoff, but something
about it didn't quite work for me.
The best description I've been able to come up with is that Raven
Stratagem skitters. Some of this is an increase in the number of
viewpoint characters, which made it harder for me to get into a reading
rhythm with any of them. But most of it, I think, is that the characters
have so many layers of deception, emotional shielding, weariness, and
resignation that it's hard to find the true emotional beats of the story
except in retrospect. I kept bouncing off surfaces, so many different and
conflicting surfaces. This book is full of people who are not being
honest with each other, or sometimes with themselves, and who are
pretending to motives they don't really have. As a reader, I wanted to be
placed in a privileged position where I could experience the character
emotions even when they were lying about them. For good or ill,
Raven Stratagem doesn't do that.
There was also something about the dramatic structure of the story that
didn't work for me. When describing the book to a friend, I said that the
main plot climax was off-camera. In skimming the book again for this
review, I found that wasn't the case, but it still felt that way. I think
that's because, despite some event build-up, the emotional build-up wasn't
in place for me, so I wasn't ready as a reader for the climax when it
came. The build-up to the climax is partly sacrificed to keep the secrecy
of a couple of long-awaited revelations. I very much enjoyed those
revelations (one satisfying one was set up with Cheris's behavior at the
start of Ninefox Gambit), but I wanted the catharsis of the climax
as well. As written, the strongest emotional hit was from a somewhat
ancillary climax, and that involved characters who mattered considerably
less to me than Cheris.
The climax also involves quite a lot of hand-waving. While some of that
is expected in magitech, I would have liked to understand the mechanisms
of what happened, not just the effects.
Lee introduces several new viewpoint characters here, including two very
contrasting Kel. I warmed to them by the end of the book, but I liked
Cheris as a viewpoint character considerably better than either of them.
Both of them spend most of this book in conditions of varying
powerlessness; Cheris, despite difficult circumstances, was at least
driving the plot. I can kind of see why Lee picked the viewpoint
characters he did, but I still feel grumbly about it. I would have loved
to have a servitor as a primary viewpoint character in this story.
All that said, I'm still glad I read this book. The climax is satisfying,
as is the growing respect of the characters and the growing realization of
just how the universe is being changed. I wanted more of that on camera
rather than being held for dramatic surprise, but I still savored it when
it happened. The mechanisms of the Hexarchate, particularly formation
instinct, are considerably creepier than Ninefox Gambit reveals,
which is saying something, and yet oddly logical in their own magitech
way. I liked all the pieces; I just wanted them to have more emotional
oomph and momentum. Instead, I felt like I was bringing my own emotion to
the story rather than letting the story sweep me away, which meant being
more analytical and less engrossed than I prefer to be in a novel.
I'm still going to read the third book, though. By the end of Raven
Stratagem, Lee has set most of the scenery on fire, and I want to see
what sort of world rises from the flames.
Rating: 6 out of 10

Receive messages the moment they are sent without draining the battery

I am now fairly convined that both problems are well-solved on Android via the Conversations app and a well-tuned XMPP server (I had no idea how easy it was to install your own Prosody modulues -- the client state indicator module is only 22 lines of lua code!)
I think the current technical challenges could be better summarized as: adding iOS (iPhone) support. Both end-to-end encryption and receiving messages consistently seem to be hurdles. However, it seems that Chris Ballinger and the Chat Secure team are well on their way toward solving the push issue and facing funder skittishness on the encryption front. Nonetheless, but seem to be progressing.
With the obvious technical hurdles in progress, we have the luxury of talking about the less obvious ones - particularly the ones requiring trade-offs.
In particular: Signal replaces your SMS client. It looks and feels like an SMS client and automatically sends un-encrypted messages to everyone your address book that is not on signal and sends encrypted messages to those that are on signal.
The significance of this feature is hard to over-state. It differentiates tools by and for technically minded people and those designed for a mass audience.
When I convince people to use Conversations, in contrast, I have to teach them to:

Create an entirely new address book by entering addresses for your friends that you don't already have

Use a new and different app for sending encrypted messages

For most people who don't (yet) have their friends XMPP addresses or for people who don't have any friends who use XMPP, it means that they will install it, send me a few messages and then never use it again.
The price Signal pays for this convenience is steep: Signal seems to synchronize your entire address book to their servers so they can keep a map of cell phone numbers to signal users. It's not only creepy (I get a text message everytime someone in my address book joins Signal) but it's flies in the face of expectations for a privacy-minded application.
How could we take advantage of this feature, without the privacy problems?
What if...

Our app could send both XMPP messages and SMS messages

Everytime you added a new XMPP contact, it added the contact to your address book with a new XMPP field

Anytime you send a message to a contact with an XMPP field filled in, it would send via XMPP and otherwise it would send a normal SMS message

The main downside (which Signal faces as well) is that you have to contend with the complexities of sending SMS messages on top of the work needed to write a well-functioning XMPP client. As I mentioned in my Signal blog, there are no shortage of MMS bugs against Signal. Nobody wants that head-ache.
Additinally, we would still lose one Signal feature: with Signal, when a user joins, everyone automatically sends them encrypted messages. With this proposed app, each user would have to manually add the XMPP address and have no way of knowing when one of their friends gets an XMPP address.
Any other ideas?

17 May 2016

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

Many contributors did not use all their allocated hours. This is partly explained by the fact that in April Wheezy was still under the responsibility of the security team and they were not able to drive updates from start to finish.
In any case, this means that they have more hours available over May and since the LTS period started, they should hopefully be able to make a good dent in the backlog of security updates.
Evolution of the situation
The number of sponsored hours reached a new record with 132 hours per month, thanks to two new gold sponsors (Babiel GmbH and Plat Home). Plat Home s sponsorship was aimed to help us maintain Debian 7 Wheezy on armel and armhf (on top of already supported amd64 and i386). Hopefully the trend will continue so that we can reach our objective of funding the equivalent of a full-time position.
The security tracker currently lists 45 packages with a known CVE and the dla-needed.txt file lists 44 packages awaiting an update.
This is a bit more than the 15-20 open entries that we used to have at the end of the Debian 6 LTS period.
Thanks to our sponsors
New sponsors are in bold.

23 April 2016

As a follow-up to my recent post on the debate in the US over new encryption restrictions, I thought a short addition might be relevant. This continues.
There was a recent Congressional hearing on the topic that featured mostly what you would expect. Police always want access to any possible source of evidence and the tech industry tries to explain that the risks associated with mandates to do so are excessive with grandstanding legislators sprinkled throughout. What I found interesting (and I use that word with some trepidation as it is still a multi-hour video of a Congressional hearing) is that there was rather less grandstanding and and less absolutism from some parties than I was expecting.

There is overwhelming consensus that these requirements [for exceptional access] are incompatible with good security engineering practice
Dr. Matthew Blaze

The challenge is that political people see everything as a political/policy issue, but this isn t that kind of issue. I get particularly frustrated when I read ignorant ramblings like this that dismiss the overwhelming consensus of the people that actually understand what needs to be done as emotional, hysterical obstructionism. Contrary to what seems to be that author s point, constructive dialogue and understanding values does nothing to change the technical risks of mandating exceptional access. Of course the opponents of Feinstein-Burr decry it as technologically illiterate, it is technologically illiterate.
This doesn t quite rise to the level of that time the Indiana state legislature considered legislating a new value (or in fact multiple values) for the mathematical constant Pi, but it is in the same legislative domain.

16 April 2016

As a rule, I avoid writing publicly on political topics, but I m making an exception.
In case you haven t been following it, the senior Republican and the senior Democrat on the Senate Intelligence Committee recently announced a legislative proposal misleadingly called the Compliance with Court Orders Act of 2016. The full text of the draft can be found here. It would effectively ban devices and software in the United States that the manufacturer cannot retrieve data from. Here is a good analysis of the breadth of the proposal and a good analysis of the bill itself.
While complying with court orders might sound great in theory, in practice this means these devices and software will be insecure by design. While that s probably reasonably obvious to most normal readers here, don t just take my word for it, take Bruce Schneier s.
In my opinion, policy makers (and it s not just in the United States) are suffering from a perception gap about security and how technically hard it is to get right. It seems to me that they are convinced that technologists could just do security right while still allowing some level of extraordinary access for law enforcement if they only wanted to. We ve tried this before and the story never seems to end well. This isn t a complaint from wide eyed radicals that such extraordinary access is morally wrong or inappropriate. It s hard core technologists saying it can t be done.
I don t know how to get the message across. Here s President Obama, in my opinion, completely missing the point when he equates a desire for security with fetishizing our phones above every other value. Here are some very smart people trying very hard to be reasonable about some mythical middle ground. As Riana Pfefferkorn s analysis that I linked in the first paragraph discusses, this middle ground doesn t exist and all the arm waving in the world by policy makers won t create it.
Coincidentally, this same week, the White House announced a new Commission on Enhancing National Cybersecurity . Cybersecurity is certainly something we could use more of, unfortunately Congress seems to be heading off in the opposite direction and no one from the executive branch has spoken out against it.
Security and privacy are important to many people. Given the personal and financial importance of data stored in computers (traditional or mobile), users don t want criminals to get a hold of it. Companies know this, which is why both Apple IOS and Google Android both encrypt their local file systems by default now. If a bill anything like what s been proposed becomes law, users that care about security are going to go elsewhere. That may end up being non-US companies products or US companies may shift operations to localities more friendly to secure design. Either way, the US tech sector loses. A more accurate title would have been Technology Jobs Off-Shoring Act of 2016.
EDIT: Fixed a typo.

11 March 2016

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

Evolution of the situation
The number of sponsored hours continued to decrease a little bit. It s not worrisome yet but we should try to get back to a positive slope if we want to be able to do an outstanding job for wheezy LTS. On the positive side, TOSHIBA renewed their platinum sponsorship for another 6 months at least and we have some contacts for new sponsors, though they are far from being concluded yet.
We are now in transition between squeeze LTS and wheezy LTS. The paid contributors are helping the security team by fixing packages that were fixed in squeeze already but that are still outstanding in wheezy. They are also taking generic measures to prepare wheezy LTS (for example to ensure all packages work with OpenJDK 7.x since support for 6.x will be dropped in the LTS period).
Thanks to our sponsors
New sponsors are in bold (none this month).

29 February 2016

This was my tenth month as a Freexian sponsored LTS contributor. I was assigned 8 hours for the month of February.
As I did last month, I worked on updating clamav in wheezy and squeeze-lts. As with previous updates to clamav, we updated it to the new upstream version[1]. As an added complexity, this version bumped soname, so it s now libclamav7 instead of libclamav6. This bump necessitated a small transition in jessie/wheezy-proposed-updates and squeeze-lts.
The update for Jessie (included for completeness here) was done early in the month by other pkg-clamav team members. It and the rebuilt/update libclamav reverse-depends will be included in the next Jessie point release.
For wheezy, I uploaded libclamunrar (which bumped soname as well) and worked with other pkg-clamav team members on getting clamav to build on sparc and preparing a fix for c-icap. It and the rebuilt/update libclamav reverse-depends will be included in the next Wheezy point release.
As a result of the amount of time it took, the squeeze-lts update landed later than I hoped it would, but it is there. As documented in DLA 437-1, there are new packages for clamav, libclamunrar, python-clamav, and klamav. The last squeeze libclamav reverse-depend, dansguardian, took more work, but it too is updated, see DLA 440-1.
[1] The primary reason for this is that anti-virus is an arms race. Unlike other types of packages being stable with only fixes for severe bugs and security issues does not result in a stable capability. It will regress over time. In order to keep up, the new version is needed.

26 February 2016

Postfix 3.0 recently hit Debian Unstable (and Ubuntu Xenial for those that care about that). It s been a bit of a bumpy road, but it seems to mostly be there for new installs. For package upgrades, there s still issues. We hope to have that sorted shortly, but in the meantime, all you should need to do to get an upgraded system working is add or adjust two parameters in your main.cf
shlib_directory=/usr/lib/postfix
daemon_directory=/usr/lib/postfix/sbin
You can either edit the file directly or use postconf:
postconf -e shlib_directory=/usr/lib/postfix
postconf -e daemon_directory=/usr/lib/postfix/sbin
No need to file more bugs and yes, we also know postfix 3.1 was just released. One thing at a time.

14 February 2016

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

Evolution of the situation
As expected, we had a small drop in the amount of hours sponsored. New sponsors (re-)joined but others stopped too (Gree this time) mostly balancing the result. We only lost 2 hours of sponsored work.
It would be nice if we could invert that curve and actually start again to get closer to our objective of funding the equivalent of a full time position. Let s hope that the switch to wheezy as the version supported by the LTS team will motivate many companies relying on Debian 7 in their IT system.
In terms of security updates waiting to be handled, the situation is close to last month(17 packages in dla-needed.txt, 27 in the list of CVE). It looks like that having about 20 packages needing an update is the normal situation and that we can t really get further down given the time required to process some updates (sometimes we wait until the upstream authors provides a patch, and so on).
Thanks to our sponsors
New sponsors are in bold.

13 February 2016

This was my ninth month as a Freexian sponsored LTS contributor. I was assigned 8 hours for the month of January.
My time this month was spent preparing updates for clamav and the associated libclamunrar for squeeze and wheezy. For wheezy, I ve only helped a little, mostly I worked on squeeze.
This update is more complex than usual because with clamav 0.99 upstream bumped soname and so in addition to the normal case of transitions in unstable, we ve needed transitions for stable, oldstable, and squeeze-lts. We also try to be careful and maintain higher versions in newer releases, so stable needed to wait for 0.99 in testing, oldstable needed to wait for stable, etc.
Currently 0.99 is in stable proposed updates and I ve requested that the update for wheezy (oldstable) go forward. Once that s done, I ve got squeeze-lts ready to go.

20 January 2016

As a follow-up to my last post where I discussed common Python packaging related errors, I thought it would be worth to have a separate post on how to decide on build-depends for Python (and Python3) packages.
The python ecosystem has a lot of packages built around supporting multiple versions of python (really python3 now) in parallel. I m going to limit this post to packages you might need to build-depend on directly.

Python (2)
Since Jessie (Debian 8), python2.7 has been the only supported python version. For development of Stretch and backports to Jessie there is no need to worry about multiple python versions. As a result, several all packages are (and will continue to be) equivalent to their non- all counterparts. We well continue to provide the all packages for backward compatibility, but they aren t really needed any more.
python (or python-all)
This is the package to build-depend on if your package is pure Python (no C extensions) and does not for some other reason need access to the Python header files (there are a handful of packages this latter caveat applies to, if you don t know if it applies to your package, it almost certainly doesn t).
You should also build-depend on dh-python. It was originally shipped as part of the python package (and there is still an old version provided), but to get the most current code with new bug fixes and features, build-depend on dh-python.
python-dev (or python-all-dev)
If your package contains compiled C or C++ extensions, this package either provides or depends on the packages that provide all the header files you need.
Do not also build-depend on python. python-dev depends on it and it is just an unneeded redundancy.
python-dbg (or python-all-dbg)
Add this if you build a -dbg package (not needed for -dbgsym).
Other python packages
There is not, AFAICT, any reason to build-dep on any of the other packages provided (e.g. libpython-dev). It is common to see things like python-all, python, python-dev, libpython-dev in build-depends. This could be simplified just to python-all-dev since it will pull the rest in.

Python3
Build-depends selection for Python 3 is generally similar, except that we continue to want to be able to support multiple python3 versions (as we currently support python3.4 and python3.5). There are a few differences:
All or not -all
Python3 transitions are much easier when C extensions are compiled for all supported versions. In many cases all that s needed if you use pybuild is to build-depend on python3-all-dev. While this is preferred, in many cases this would be technically challenging and not worth the trouble. This is mostly true for python3 based applications.
Python3-all is mostly useful for running test suites against all supported python3 versions.
Transitions
As mentioned in the python section above, build-depends on python3- all- dev is generally only needed for compiled C extensions. For python3 these are also the packages that need to be rebuilt for a transition. Please avoid -dev build-depends whenever possible for non-compiled packages. Please keep your packages that do need rebuilding binNMU safe.
Transitions happen in three stages:

A new python3 version is added to supported python3 versions and packages that need rebuilding due to compiled code and that support multiple versions are binNMUed to add support for the new version.

The default python3 is changed to be the new version and packages that only support a single python3 version are rebuilt.

The old python3 version is dropped from supported versions and packages will multiple-version support are binNMUed to remove support for the dropped version.

This may seem complex (OK, it is a bit), but it enables a seamless transition for packages with multi-version support since they always support the default version. For packages that only support a single version there is an inevitable period when they go uninstallable once the default version has changed and until they can be rebuilt with the new default.
Specific version requirements
Please don t build-depend against specific python3 versions. Those don t show up in the transition tracker. Use X-Python3-Version (see python policy for details) to specify the version you need.

Summary
Please check your packages and only build-depend on the -dev packages when you need it. Check for redundancy and remove it. Try and build for all python3 versions. Don t build-depend on specific python3 versions.

13 January 2016

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

Evolution of the situation
We lost our first silver sponsor (Gandi.net, they prefer to give the same amount of money to Debian directly) and another sponsor reduced his sponsorship level. While this won t show in the hours dispatched in January, we will do a small jump backwards in February (unless we get new sponsors replacing those in the next 3 weeks).
This is a bit unfortunate as we are rather looking at reinforcing the amount of sponsorship we get as we approach Wheezy LTS and we will need more support to properly support virtualization related packages and other packages that were formerly excluded from Squeeze LTS. Can you convince your company and help us reach our second goal?
In terms of security updates waiting to be handled, the situation is close to last month. It looks like that having about 20 packages needing an update is the normal situation and that we can t really get further down given the time required to process some updates (sometimes we wait until the upstream authors provides a patch, and so on).
Thanks to our sponsors
We got one new bronze sponsor but he s not listed (he did not fill the form where we request their permission to be listed).

11 January 2016

As of today, python3 -> python3.5. There s a bit of a transition, but fortunately because most extensions are packaged to build for all supported python3 versions, we started this transition at about 80% done. Thank you do the maintainers that have done that. It makes these transitions much smoother.
As part of getting ready for this transition, I reviewed all the packages that needed to be rebuilt for this stage of the transition to python3.5 and a few common errors stood out:

For python3 it s python3:Depends not python:Depends .

Do not use python3:Provides . This has never been used for python3 (go read the policy if you doubt me [1]).

Almost for sure do not use python:Provides . The only time it should still be used is if some package depends on python2.7-$PACKAGE. It would surprise me if any of these are left in the archive. If so, since python2.7 is the last python2, then they should be adjusted. Work with the maintainer of such an rdepend and once it s removed, then drop the provides.

Do not use XB-Python-Version. We no longer use this to manage transitions (there won t be any more python transitions).

10 January 2016

This was my eighth month as a Freexian sponsored LTS contributor. I was assigned 8 hours for the month of December. It s also the month in which I (re)learned an important lesson.

I decided to take another run at backporting the security fixes for Quassel. Unlike the first time, I was successful at getting the fixes backported. Then I ran into another problem: the changes took advantage of new features in c++11 such as std::function.
I made an attempt to change things away from c++11 with my limited c++ foo and after running head first into a brick wall several times finally consulted with the upstream author of the original fixes. He let me know that while the problematic code is in fact present in the quassel versions in squeeze and wheezy, it s not actually possible to trigger the security issue and that the CVEs should not actually apply to those versions.
That s my report of a singularly unproductive and unpleasant 8 hours. Next time I ask upstream first if there s any doubt. I shouldn t assume they only care about current/recent releases.

14 December 2015

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

Ben Hutchings did 5 hours only (out of 15 hours allocated + 5 extra hours remaining, meaning that he has 15 extra hours to do over December).

Evolution of the situation
We lost one hour of funding for December due to a sponsor not renewing, and we don t have any new sponsor lined up right now. There s another sponsor who will reduce his sponsorship starting with 2016.
While the situation is relatively healthy right now, we should continue the efforts to find new sponsors, both to ensure we can cover more software in wheezy and to better share the costs: having many small sponsors is more resilient than relying on a few big ones. And we still haven t reached our second goal of funding the equivalent of a full-time position.
In terms of security updates waiting to be handled, the situation is close to last month: the dla-needed.txt file lists 19 packages awaiting an update (2 less than last month), the list of open vulnerabilities in Squeeze shows about 22 affected packages in total (1 less than last month).
Thanks to our sponsors
The new sponsors are in bold.

1 December 2015

This was my seventh month as a Freexian sponsored LTS contributor. I was assigned 8 hours for the month of November.
As I did last month, I worked on review and testing of the proposed MySQL 5.5 packages for squeeze-lts and did a bit more work on Quassel. It has been suggested that maybe we ought to just EOL Quassel since backporting the necessary fixes is so complicated. I think they may be right, but I haven t quite given up yet.
I reviewed CVE-2015-6360 for SRTP and my assessment was that squeeze-lts was not affected (same for the other Debian releases while I was at it).
I published one security update, it was for libphp-snoopy. This resolves the outstanding security issues by updating to the newest version as was done for all other Debian releases.
Finally, in the interest of getting better support in tools for Debian LTS, I came up with a patch for the pull-debian-source[1] script in ubuntu-dev-tools so that it will download Debian LTS packages correctly. Although it took a bit of investigating, the patch turned out to be very simple. I filed bug #806749. I also started looking at the distro-info package (thinking I d need it updated to fix pull-debian-source, which turned out not to be the case), but didn t finish it yet. I plan to work on that this month.
[1] Even though this is in ubuntu-dev-tools and not devscripts, there s really nothing Ubuntu specific about it.

13 November 2015

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

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.