Lisandro Damián Nicanor Pérez Meyer: My experiences with KMail2 in Debian
Thanks to the Qt/KDE team, specially to Maxy who has done most of the packaging and uploading, sid users are now enjoying KDE 4.10.5, including the new KDE PIM stuff that we have held out for the Wheezy release.I started using KMail2 (inside Kontact) a few days after Wheezy's release, getting it from experimental. And I have to admit that I really like it, just like with KMail1.
But my upgrade did have some bumps on the road, so I'm sharing them here so you can now how I solved them.
Mail import worked as we were waiting: it did work. So it was really useful to hold back Kmail1 until this really worked.
Now, I had a problem with my hard disk: whenever KMail started, it would start accessing it without pause. There where two reasons (for what I could test, I haven't looked at the source to really see if there was some other oddity) for this: I had a nepomuk/virtuoso DB created quite some time ago and initial mail indexing.
The initial mail indexing takes lots of time. For 1GB of DIMAP I had to wait like 5 hours (yes, 5 hours) on a 5600 rpm disk to let it fully finish. My desktop machine, with a faster hard drive, took a little less.
As far as people told me, that should have been enough, but my disk kept crawling. So I remembered someone from the team saying something about people with early-created nepomuk/virtuoso databases will have some speed issues. Mine where more than that, buy trying was worth the shot.
I had nepomuk disabled since I tried it the first version due to this exact problem. So I closed my KDE session and removed the nepomuk/virtuoso data:
rm -r ~/.kde/share/apps/nepomuk/
Then I logged back in KDE and waited (again) the 5 hours to let nepomuk re index my mail, this time totally finishing after 5 hours. Starting from that point, I get some one or two minutes of disk trashing some times I log in (not always), but it's actually not that bad. And I heard that in KDE 4.11 this has been improved a lot, so I should see a better behavior from that point on.
Please understand that this was my trial-and-error fix, it may be possible that someone comes with a better solution :-)
As you might (or might not) know, this summer, I have taken on mentoring of 
Well, the general idea was easy enough, but the task at hand is a challenge. First of all, fedmsg has a lot of (smallish) dependencies, most of them new to Debian.
Thanks to Simon s work during the bonding period, and thanks to paultag s careful reviews, the first batch of packages (the first dependency level, comprising kitchen, bunch, m2ext, grapefruit, txws, txzmq and stomper) is currently sitting in the NEW queue. The four remaining packages (fabulous, moksha.common, moksha.hub and fedmsg proper) are mostly ready, waiting in the Debian Python Module Team SVN repository for a review and sponsorship.
While we re waiting for the packages to trickle into Debian, Simon is not twiddling his thumbs. Work has taken place on a few fronts:
) all over the world, and thus faces different challenges than Fedora s infrastructure, which is more tightly integrated. Therefore, we have to ensure that a critical consumer (say, a buildd) doesn t miss any message it would need for its operation (say, that a package got accepted).
There has been work upstream, to ensure that fedmsg 
Some comments about the diagram:
This is part 4 in 
Or, 
I ve been 
A co-incidence that caught my eye this week was the failure of emergency call centers in Melbourne, Australia and Detroit, USA.
Melbourne's system 
Having 
Someone recently asked me about the Debian Xfce 4.10 status, as
apparently I forgot to update this post series.
So, as you might have noticed, the full Xfce 4.10 desktop
environment is currently in Debian Jessie (current name for
testing). All in all, the transition went well and smooth.
One of the most regular question I get about Xfce 4.10 is the
panel behavior when it comes to the task bar expansion. In
xfce4-panel 4.8, when people wanted to have a full side panel with
a task bar plugin inside, they added a Windows buttons plugin and
configured the panel to 100% length. Then the Windows buttons
would expand to occupy all the free space on the panel. It was a
special case plugins, as usually other plugins only used a fixed
space. Now, in 4.10, this is not the case anymore. Windows button
uses a fixed size. And the plugins are left-aligned, which means
usually people end up with some space at the far right of the
panel. To restore the previous behavior back (which is actually the
pre-4.8 behavior, 4.8 was an exception by itself), one needs to add
a Separator plugin, then configure it to expand (and optionnally
select a transparent handle). Then move it next right to the
Windows buttons plugin.
Another thing which might be a bit surprising for upgrading
users is the change in the Action buttons plugin, which people
usually use to logout. In 4.8, by default, it's set to run the
logout dialog. In 4.10, by default, it's set to logout directly
(but with a confirmation dialog). If you prefer the previous
behavior, you can just configure the Action buttons plugin and
select the Log out item instead of the Log out one (I know,
it's a bit confusing).
If you have any question, don't hesitate to reach us by mail or
on irc (#debian-xfce on Freenode). Other than that remember that
Xfce really needs you help, both in Debian and upstream (and at
that point, I'd say *especially* upstream). There's a lot of
unmaintained project under the Xfce umbrella, some of them part of
the core (like xfce4-power-manager), so if you have some spare time
and some C/GTK+ knowledge, feel free to contact the Xfce team on
the mailing list.
A month ago, a mail hit the 
Recent Intel-based systems often implement something called Intel Rapid Start Technology. Like many things with the word "Technology" in the name, there's a large part of this that's marketing. The relatively small amount of 