Eugene V. Lyubimkin: Debian packages with big number of bugs
While working on Debian, I often don't realize how some important packages lack manpower to handle issues. Examples that touched me are 'apt' and 'perl'. As someone told many times, it would be good if someone with free time, especially newcomers to Debian, help triaging/reproducing bugs in the BTS, writing patches etc. This activity usually doesn't require helper to be a DD or DM, and will usually be more appreciated than preparing 11th web server or 30th window manager to Debian archive. Just ask maintainer(s). Also, you may want to read http://wiki.debian.org/HelpDebian to get the wider picture.
I tried to quickly find a table with Debian packages with highest bug rates over the Debian BTS, but failed, so I constructed my own one, with the help of UDD. This list contains BTS packages with number of bugs > 100 and is available here. The top ten:
I tried to quickly find a table with Debian packages with highest bug rates over the Debian BTS, but failed, so I constructed my own one, with the help of UDD. This list contains BTS packages with number of bugs > 100 and is available here. The top ten:
source rc_bugs all_bugs
--------------------------+---------+----------
wnpp 0 3024
installation-reports 10 2119
apt 4 682
linux-2.6 0 617
aptitude 0 576
iceweasel 3 490
openssh 1 417
evolution 0 362
util-linux 1 344
dpkg 1 343
Thanks to people who reacted to this post of mine.
As expected, when one posts such angry post, reactions come. Guess what: that was intended..:-)
So, I got more background on this 
This is the fifth year we hold an EDUSOL, and we are closing in on it. EDUSOL is an online encounter whose topics are Education and Free Software Actually, this year we are widening our scope, and we will include Free Culture as well as a base area.
Now, besides those three general areas, each year we have had a base topic around which we invite the speakers to talk about (although it is a lax requirement). This year, the base topic is social networks No, not in the Twitter/Facebook/blah sense, but as a wider phenomenon, studying interaction between people, the forming of communities. And for our particular areas, the forming of knowledge-based communities.
Anyway I agreed with the organizers to provide the English translation of the participation invitation. I will skip the call for papers, as we are basically at the proposal deadline (October 17), but if you have anything you want to propose, please tell us so!
Leaving that aside... Please excuse the quality of my translation, it is late and I'm tired. We will work on it :)
Videoconference reception
EDUSOL spans several participation categories. The closest category to a traditional, face to face conference. Each year, we invite a group of speakers to talk about a topic related to our main discoursive line.
Among the speakers that have confirmed so far, we have:
So, next Saturday 
Speaking of Minas Gerais, it is, according to Wikipedia, the fourth in size among the 26 States of Brazil, being just a bit bigger than mainland-France. Minas Gerais is one of the main earth transports hubs of the country (having the largest number of federal roads), and is famous for its tasty food, the beauty of its people, its cheeses, the calm, introspective nature of its people, its interesting way of speaking portuguese, and its alcoholic beverages.
Now, going away from Rio to Belo Horizonte has a single big disadvantage associated with it: we don t get to have the Sea a few minutes away, anymore. Our solution to that is, of course, going to one of the numerous bars (the legend goes around that BH has the largest absolute number of bars of all cities in the world), and drinking instead of swimming! Quem n o tem mar, vai pro bar!
The first Telepathy session session on Saturday evening at the Boston GNOME Summit was very much of a Q&A where myself and Will answered various technical and roadmap issues from a handful of developers and downstream distributors. It showed me that there s a fair amount of roadmap information we should do better at communicating outside of the Telepathy project, so in the hope its useful to others, read on
MC5
Ted Gould was wondering why Mission Control 4 had an API for getting/setting presence for all of your accounts whereas MC5 does not. MC5 has a per-account management of desired/current presence which is more powerful, but loses the convenience of setting presence in one place. Strictly speaking, doing things like deciding which presence to fall back on (a common example being if you have asked for invisible but the connection doesn t support it) is a UI-level policy which MC should not take care of, but in practice there aren t many different policies which make sense, and the key thing is that MC should tell the presence UI when the desired presence isn t available so it could make a per-account choice if that was preferable. As a related side point, Telepathy should implement more of the invisibility mechanisms in XMPP so it s more reliably available, and then we could more meaningfully tell users which presence values were available before connecting, allowing signing on as invisible.
Since MC5 gained support for gnome-keyring, its not possible to initialise Empathy s account manager object without MC5 prompting the user for their keyring password un-necessarily (especially if the client is Ubuntu s session presence applet and the user isn t using Empathy in the current session but has some accounts configured). Currently the accounts D-Bus API requires that all properties including the password are presented to the client to edit. A short-term fix might be to tweak the spec so that accounts don t have to provide their password property unless it s explicitly queried, but this might break the ABI of tp-glib. Ultimately, passwords being stored and passed around in this way should go away when we write an authentication interface which will pass authentication challenges up to the Telepathy client to deal with, enabling a unified interface for OAuth/Google/etc web token, Kerberos or SIP intermediate proxy authentication, and answering password requests from the keyring lazily or user on demand.
Stability & Security
Jonathan Blandford was concerned about the churn level of Telepathy, from the perspective of distributions with long-term support commitments, and how well compatibility will be maintained. Generally the D-Bus API and the tp-glib library APIs are maintained to the GNOME standards of making only additive changes and leaving all existing methods/signals working even if they are deprecated and superseded by newer interfaces. A lot of new interfaces have been added over the past year or so, many of which replace existing functionality with a more flexible or more efficient interface. However, over the next 4-6 months we hope to finalise the new world interfaces (such as multi-person media calls, roster, authentication, certificate verification, more accurate offline protocol information, chat room property/role management), and make a D-Bus API break to remove the duplicated cruft. Telepathy-glib would undergo an ABI revision in this case to also remove those symbols, possibly synchronised with a move from dbus-glib to GVariant/etc, but in many cases clients which only use modern interfaces and client helper classes should not need much more than a rebuild.
Relatedly there was a query about the security of Telepathy, and how much it had been through the mill on security issues compared to Pidgin. In the case of closed IM protocols (except MSN where we have our own implementation) then we re-use the code from libpurple, so the same risks apply, although the architecture of Telepathy means its possible to subject the backend processes to more stringent lockdowns using SElinux or other security isolation such as UIDs, limiting the impact of compromises. Other network code in Telepathy is based on more widely-used libraries with a less chequered security history thus far.
OTR
The next topic was about support for OTR in Telepathy. Architecturally, it s hard for us to support the same kind of message-mangling plugins as Pidgin allows because there is no one point in Telepathy that messages go through. There are multiple backends depending on the protocol, multiple UIs can be involved in saving (eg a headless logger) or displaying messages (consider GNOME Shell integration which previews messages before passing conversations on to Empathy), and the only other centralised component (Mission Control 5) does not act as an intermediary for messages. Historically, we ve always claimed OTR to be less appealing than native protocol-level end-to-end encryption support, such as the proposals for Jingle + peer to peer XMPP + TLS which are favoured by the XMPP community, mostly because if people can switch to an unofficial 3rd party client to get encryption, they could switch to a decent protocol too, and because protocol-level support can encrypt other traffic like SRTP call set-up, presence, etc.
However, there is an existing deployed OTR user base, including the likes of Adium users on the Mac, who might often end up using end to end encryption without being aware of it, who we would be doing a disservice by Telepathy not supporting OTR conversations with these people. This is a compelling argument which was also made to me by representatives from the EFF, and the only one to date which actually held some merit with me compared to just implementing XMPP E2E encryption. Later in the summit we went on to discuss how we might achieve it in Telepathy, and how our planned work towards XMPP encryption could also help.
Tubes
We also had a bit of discussion about Tubes, such as how the handlers are invoked. Since the introduction of MC5, clients can register interest in certain channel types (tubes or any other) by implementing the client interface and making filters for the channels they are interested in. MC5 will first invoke all matching observers for all channels (incoming and outgoing) until all of them have responded or timed out (eg to let a logger daemon hook up signal callbacks before channel handling proceeds), all matching approvers for incoming channels until one of them replies (eg to notify the user of the new channel before launching the full UI), and then sending it to the handler with the most specific filter (eg Tomboy could register for file transfers with the right MIME type and receive those in favour to Empathy whose filter has no type on it). Tubes can be shared with chat rooms, either as a stream tube where one member shares a socket for others to connect to (allowing re-sharing an existing service implementation), or a D-Bus tube where every member s application is one endpoint on a simulated D-Bus bus, and Telepathy provides a mapping between the D-Bus names and the members of the room.
In terms of Tube applications, now we ve got working A/V calling in Empathy, as well as desktop sharing, and an R&D project on multi-user calls, our next priority is on performance and Tube-enabling some more apps such as collaborative editing (Gobby, AbiWord, GEdit, Tomboy ?). There was a question about whether Tube handlers can be installed on demand when one of your contacts initiates that application with you. It d be possible to simulate this by finding out (eg from the archive) which handlers are available, and dynamically registering a handler for all of those channel types, so that MC5 will advertise those capabilities, but also register as an approver. When an incoming channel actually arrives at the approval stage, prompt the user to install the required application and then tell MC5 to invoke it as the handler.
Colin Walters asked about how Telepathy did NAT traversal. Currently, Telepathy makes use of libnice to do ICE (like STUN between every possible pair of addresses both parties have, works in over 90% of cases) for the UDP packets involved in calls signalled over XMPP, either the Google Talk variant which can benefit from Google s relay servers if one or other party has a Google account, so is more reliable, or the latest IETF draft which can theoretically use TURN relays but its not really hooked up in Telepathy and few people have access to them. XMPP file transfers and one-to-one tube connections use TCP which is great if you have IPv6, but otherwise impossible to NAT traverse reliably, so often ends up using strictly rate-limited SOCKS5 -ish XMPP proxies, or worse, in-band base64 in the XML stream. We hope to incorporate (and standardise in XMPP) a reliability layer which will allow us to use Jingle and ICE-UDP for file transfers and tubes too, allowing peer to peer connections and higher-bandwidth relays to enhance throughput significantly.
Future
Ted Gould had some good questions about the future of Telepathy
There is no secret that many Debian contributors share their time between various projects, while Debian is one of those projects.
I tend to dress quite casually - unless there's a good reason to do otherwise I'll be in jeans and a t-shirt, or something similar. I'm comfortable in it and I take the view point that in general people shouldn't be making assumptions based on what I'm wearing. Of course they do, and while this can be infuriating at times it can also be amusing. The man at the RBoS who witnessed me signing the personal DD guarantee form for Black Cat obviously couldn't reconcile my appearance with what I was there to do, for example.
I wasn't going to write about this since I thought that 
Earlier today the 33rd Chicago Marathon was held. I will organise my
comments by pointing out three epic fails.
First, of course, was the Chicago weather. After two successive marathon in
excessive heat --- the
I also updated my 'performance by race type through time' chart which suggests
that I may be getting slower for marathons (if we allow for a non-linear
effect). Eek.
So, Waldi filed 
Debian maintainer:
Some days ago I had the great announcement that my 
Today I was working all day on 
I haven't written about politics since the election for several reasons. First and foremost, Obama won fair and square. While I might wish the other guy had won, I can't whine and pout or threaten to move to Canada like some people. The vox populi chose and that choice has to be respected.
Secondly, one of the worst aspects of the current American political scene is the paranoid obsession with personalities in which the president is not just an implementor of policies good or bad, but personally responsible for the entire state of the cosmos. It started with Nixon, started getting alarming with Clinton and reached batshit levels of insanity with George W. Bush. But just because the left does it it, doesn't mean we have to follow suit. Although I figured Obamas policies would end up a trainwreck, I wanted to see what he actually did before calling him on it.
The Nobel comittee isn't hoping and changing with me. In a decison that is bizarre even by the lax standards of a prize that long since 
I just put online new Wammu and Gammu website at 
So I finally got around to checking out the 
Like 
