My personal KDEPIM upgrade (again): laptop

One year after my last blog post on this topic I encountered some minor difficulties with combining KDEPIM-4.4 (i.e. kmail1) and the KDE 4.10 betas. These difficulties are fixed now, and the combination seems to work fine again. Anyway, I became curious about the level of stability of Akonadi-based kmail2 once more. After all, I've been running it continuously over the year on my office desktop with a constant-on fast internet connection, and that works quite well. So, I gave it a fresh try on my laptop too. I deleted my Akonadi configuration and cache, switched to Akonadi mysql backend, updated kmail and the rest of KDEPIM without migrating to 4.9.4, and re-added my IMAP account from scratch (with "Enable offline mode"). The overall use case description is "laptop with large amount of cached files from IMAP account, fluctuating internet connectivity". Now, here are my impressions...

• Reaction time is occasionally sluggish, but overall OK.
• The progress indicator behaves a bit odd, it checks the mail folders in seemingly random order and only knows 0% and 100% completion.
• Random warning messages. It seems that kmail2 uses some features that "my" IMAP server does not understand. So, I'm getting frequent warning notifications that don't tell me anything and that I cannot do anything about. SET ANNOTATION, UID, ... Please either handle the errors, inform the user what exactly goes wrong, or ignore them in case they are irrelevant. Filed as a wish, bug 311265.
• Network activity stops working sometime. This sounds worse than it actually is, since in 99% of all cases Akonadi now detects fine that the connection to the server is broken (e.g., after suspend/resume, after switching to a different WLAN, or after enabling a VPN tunnel) and reconnects immediately. In the few remaining cases, re-starting the Akonadi server does the trick. You just have to know what to kick.
• More problematic is, while you're in online mode, any problems with connectivity will make kmail "hang". Clicking on a message leads to an attempt to retrieve it, which requires some response from the network. As it seems to me, all such requests are queued up for Akonadi to handle, and if that does not get a reply, pending requests are stuck in the queue... OK, you might say that this is a typical use case for offline mode, but then I would have to be able to predict when exactly my train enters the tunnel... Compare this to kmail1 disconnected IMAP accounts, where regular syncing would be delayed, but local work remained unaffected.
• Offline mode is a nice concept, and half a solution for the last problem, but unfortunately it does not work as expected. For mysterious reasons, a considerable part of the messages is not cached locally. I switch my account to offline mode, click on a message, and obtain an error message "Cannot fetch this in offline mode". Well, bummer. Bug 285935.
• This may just be my personal taste, but once something goes wrong (e.g., non-kde related crash, battery empty, ...) and the cache becomes corrupted somehow, I'd like to be able to do something from kmail2 without having to fiddle with akonadiconsole. A nice addition would be "Invalidate cache" in the context menu of a mail folder, or some sort of maintenance menu with semi-safe options.
• Finally... something is definitely going wrong with PGP signatures; the signatures do not always verify on other mail clients. Tracking this down, it seems that CRLF is not preserved in messages, see bug 306005.

On the whole, for the laptop use case the "new" KDEPIM is now (4.9.4) more mature than the last time I tried. I'll keep it now and not downgrade again, but there are still some significant rough edges. The good thing is, the KDEPIM developers are aware of the above issues and debugging is going on, as you can see for example from this blog post by Alex Fiestas (whose use case pretty much mirrors my own).

The difference between Ubuntu and Gentoo ;)

This gem comes from the xda developers forums; thanks barry99705!

"Using/installing Ubuntu is like buying a car. It may have a few features you'll never need or use, and might need to have a couple features added as aftermarket parts.

Using/installing Gentoo is like buying a pile of sheet metal, a few rubber trees, small pile of copper, a pile of sand, and an oil well. Then you have to cut and fabricate the car's body from the sheet metal, extract the rubber from the trees, then use that to make the tires and all the seals on the car. Use the pile of copper to make all the wires, and use the leftover rubber(you did save the scraps didn't you) to make the insulation. Melt down the pile of glass to make the windshield, side and back windows, also the headlights and lights themselves. Then you need to extract the crude oil from the well to refine your own engine oil and gas. In the end, you have a car created to your exact specifications (if you know what the hell you're doing) that may or may not be any better than just buying a car off the lot."

Of course I should additionally mention that Gentoo provides awesome documentation for all the steps and most of the actual assembly work is done single-handedly by portage!

How app-office/libreoffice-bin is made

While usually Gentoo users compile all their packages on their own computers, LibreOffice tends to be too big a bite for that. This is why we provide for amd64 and x86 app-office/libreoffice-bin and app-office/libreoffice-bin-debug, two packages with a precompiled binary installation and its debug information. In the beginning we just used the binaries from the official LibreOffice distribution. Turns out, however, that these binaries bundle a large number of libraries that we have in Gentoo anyway (bug 361695), and for a lot of reasons bundled libraries are bad. So, we decided to roll our own binaries for stable Gentoo installations. Let me describe a bit how it is done.

Linux pinacolada 3.4.9-gentoo #2 SMP Thu Oct 11 00:05:55 CEST 2012 x86_64 Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz GenuineIntel GNU/Linux

On the machine doing the build, two chroots are dedicated to the package build process, one a plain amd64 chroot, the other an x86 chroot entered via linux32. Both have no ~arch packages installed at all, only stable keywords are accepted; both have a very minimal world file listing only a few packages useful for a maintainer as e.g. gentoolkit or eix. Procedure is identical for both.  In addition, in both chroots the compiler flags are chosen for as wide compatibility as possible. This means

# for x86
CFLAGS="-march=i586 -mtune=generic -O2 -pipe -g"
# for amd64
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -g"

and obviously the same for CXXFLAGS. Both chroots also use the portage features splitdebug and compressdebug to make debug information available in a separate directory tree. Prior to build, the existing packages are updated, unnecessary packages are cleaned, and dynamic linking is checked:

emerge --sync
emerge -uDNav world
emerge --depclean --ask
revdep-rebuild

In case any problems occur, these are checked, solved, and the procedure is repeated until all the operations become a no-op.
Next step is adapting the (rather simplistic) build script to the new libreoffice version. This means mainly checking for new or discarded useflags, and deciding which value these should have in the binary build. Since LibreOffice-3.6 we also have to decide now which bundled extensions to build. The choice of useflags is influenced by several factors. For example, pdfimport is disabled because the resulting dependency on poppler might lead to broken binaries rather too often.
Then, well, then it's running the build. Generating all 12 flavours (base, kde, gnome with and without java for both amd64 and x86) takes roughly a weekend. Time to go out to the christmas market and sip a Glühwein.
In the meantime, we can also adapt the libreoffice-bin ebuilds for the new version. The defined phase functions are mostly boring, since they only have to copy files into the system. Normally, they can be taken over from the previous version. The dependency declarations, however, have to be copied anew each time from the corresponding app-office/libreoffice ebuild, taking into account the chosen use-flag values. DEPEND is set empty since we're not actually building anything during installation.
Finally, COMMON_DEPEND is extended by an additional block named BIN_COMMON_DEPEND, specific for the binary package. Here, we specify any dependencies that need to be stricter now, where a library upgrade would for a normal package require revdep-rebuild - which is not possible for a binary package. Typical candidates where we have to fix the minimum or exact library version are glibc, icu, or libcmis.
Once the build has finished, 8.8G of files have to be uploaded to the Gentoo server, added to the mirror system, and then given some time to propagate. Then, we can commit the new ebuild, and open a stabilization request bug. Finished!
(Oh and in case you're wondering, new packages are coming tomorrow. :)

Lecture announcement: Low Temperature Physics

It's a real pleasure to do the Low Temperature Physics lecture again this winter term. This is a so-called "Modulvorlesung" and "Wahlpflichtfach" (compulsory optional subject?), meaning you'll be able to pick it as examination subject for the MSc physics (possibly also for other courses as e.g. chemistry). Slides are in English, the lecture itself will be in German unless the audience requests otherwise.  In short, we'll be covering the following topics: 

• properties of cold gases and liquids
• cryotechnology
• properties of cold solids (all except superconductivity)
• superconductivity
• low-temperature nanophysics

A lot more information can be found on the homepage of the lecture itself. For legal reasons, the slides are only available to participants; I'll tell you the password during the first lecture. So, see you on tuesday morning 8:00ct, PHY 5.0.21!

Kudos to Lenovo / IBM service

Since over a year I'm the happy owner of a Lenovo Thinkpad T520, and on the whole I can only recommend it as a power-user Linux machine. Excellent for day-to-day work as well as measurement data processing, Gentoo runs on it nicely, and with a Core i5 and 8G RAM even app-office/libreoffice has lost its horrors. Since I'm travelling often and also tend to working on the weekend in one of these beautiful cafes in the historic city centre of Regensburg, I'm relying on it a lot. So when I bought it, I added a ThinkPlus warranty upgrade to the basket, according to the paperwork 3 years next-workday on-site service for 87€.
The surprise of last friday evening was the laptop's complete refusal to boot. Just some blinking of the power indicator, nothing else. No idea what caused it... Anyway. I started worrying, even took out the harddrive and replaced it with a blank one I had lying around, and prepared myself for being laptop-less for a while.
Called service tuesday morning. A technician called me back wednesday morning, and came along wednesday afternoon. After about 90min, the laptop was completely disassembled, reassembled with a new mainboard and the original hard drive, and worked flawlessly. Yay! One happy customer.

New dilution refrigerator arriving!

We've been waiting patiently for this for quite some time, but now, it seems, our brand new Oxford Instruments Kelvinox HA400 dilution refrigerator is about to arrive in our lab. Yay! The first two boxes are already there... and another seven, I've been told, are on the way from the UK.
The first picture on the right shows the main insert assembly, which is later dipped into a liquid helium-4 bath for precooling. (Remember, we're going to the millikelvin range, so liquid helium-4 at 4.2K is pretty hot.) The lower, copper-coated part of the insert is a vacuum can, the so-called IVC, and inside there, thermally shielded by the vacuum, all the ultra-low temperature cooling goes on. The lower end of this can finally with a slender tail fits into the 3" central bore of a small superconducting magnet. Some experiments which do not need a magnetic field can be conducted directly at the last cooling stage, others are mounted at the center of this tail, i.e. in the center of the magnet.

The second picture shows the actual main cooling circuit, the so-called dilution unit, which will be mounted into the vacuum can when the system is undergoing final assembly. The cooling process is based on the quantum mechanical properties of liquid helium-3 and helium-4 at temperatures below 0.9K; this particular model can reach temperatures down to 7mK (yes that's 0.007 degrees above the absolute zero of temperature). A simplified description of the process can be found on the dilution refrigerator wikipedia page. We'll post some more and nicer pictures once the final assembly is on the way...

Lab::Measurement 3.10

Since we've got several interesting measurements running in the lab at the moment, our scripts are receiving a lot of attention. Which means we can already release a new feature (and bugfix) version, Lab::Measurement 3.10. Packages are on CPAN (and in Gentoo portage); you'll find the major changes listed below. Cheers!

Lab::Bus and Lab::Connection classes

• Initial support for the USBtmc Linux kernel driver
  
• GPIB (i.e. IEEE-488) termination characters are now handled identically in LinuxGPIB and VISA_GPIB
  
• New VISA_RS232 connection which takes all arguments as RS232
  

Lab::Instrument classes

• HP34420A nanovoltmeter re-added
  
• Many improvements in the Oxford Instruments ITC503 driver
  
• Re-named the Oxford Instruments IPS12010 driver to OI_IPS
  
• New driver: Trinamic PD-110-42 stepper motor
  
• New driver: Agilent U2000 rf power sensor
  

Lab::Measurement classes

• Started refactoring the keyboard handling code
  

NJP accepted: Magnetic damping of a carbon nanotube NEMS resonator

There's very good news- our first Regensburg article on carbon nanotube nano-electromechanical systems, "Magnetic damping of a carbon nanotube NEMS resonator", was just accepted for publication by New Journal of Physics.
Let me give you a short introduction what we've been working on here. A very exciting discovery some time ago was that at low temperatures (T<0.1K) mechanical resonators made from single-wall carbon nanotubes show very large quality factors Q. That means, once vibrating they store energy for a long time, and the vibration decays only very slowly - a piano string with a similar Q would sound for over five minutes after hitting the key! 
Now this has all sorts of interesting side effects. It's so easy to keep the vibration going that it basically runs on its own once a current passes through the device and some prerequisites are given. The device switches between different stability regions, and the usually very predictable transport spectroscopy pattern of a carbon nanotube quantum dot gains strange shapes and sharp edges.
Amazingly, as soon as you apply a magnetic field, this effect is all gone again, and the transport spectrum becomes regular. The overall current does not change significantly, so our tunnel rates should not be influenced too much by the magnetic field. Which means, according to the theory, that our magnetic field has to tune the second available "knob", the quality factor Q of the mechanical vibration. And indeed if we now drive the system with a radio-frequency signal, we see that the resonance becomes broader in frequency in a high magnetic field - the quality factor decreases.
So what's the damping mechanism? Actually, that is pretty straightforward. In a magnetic field, the vibrating nanotube acts as an ac voltage source, generating a small voltage the same way as a macroscopic ac generator. In addition, high-frequency signals can be transmitted capacitively between, say, parallel cables. Consequently a small ac current flows across a parasitic circuit with a ~100kOhm resistance somewhere, which dissipates energy; the resulting upper limit for Q scales with 1/B². We can compare this model with our observed Q(B), and see a very nice agreement. Effectively, we've built the world's smallest eddy current brake!

"Magnetic damping of a carbon nanotube NEMS resonator"
D. R. Schmid, P. L. Stiller, Ch. Strunk, and A. K. Hüttel
accepted for publication by New Journal of Physics; arXiv:1203.2319 (PDF)

Gentoo in c't magazine

For the German speakers around here, today's edition of c't magazine (that's the company that people from UK/USA may know as "The H") includes an introductory article on Gentoo Linux: "Made to measure - Gentoo Linux: source code and rolling releases". So, go to your newsagent and grab it while it's hot! :)

Lab::Measurement 3.00 released

I'm happy to be able to announce a first real release of the Lab::Measurement Perl package, providing a platform for measurement control with Perl.

Lab::Measurement is based on the packages Lab::VISA, Lab::Instrument, and Lab::Tools started by Daniel Schröer in 2005. Many people have contributed in the meantime, amongst others in roughly historical order Daniela Taubert, David Kalok, Florian Olbrich, and Alois Dirnaichner. The efforts of the last year have focussed on a general modularization, originally driven by a certain frustration with National Instruments NI-VISA support on Linux. Now, the hardware driver backend can be exchanged transparently, making measurements both with NI-VISA and with e.g. LinuxGPIB or the operating system serial port drivers on Linux and Windows possible.
Since VISA does not form a central part or even requirement anymore, the original use of Lab::VISA as name for the entire package became impractical, and we've decided to switch to Lab::Measurement instead. As version numbers of all components should still increase monotonously, our first release of the code rewrite then actually ended up as Lab::Measurement 3.00.

For downloads and documentation, including installation instructions for Linux and Windows and examples, visit the homepage of the package, http://www.labmeasurement.de/. Of course, if you're using Gentoo, the package is readily available in the main portage tree as dev-perl/Lab-Measurement.

Not all device drivers have been ported to the new internal architecture so far, but work is progressing swiftly. In the Regensburg nanophysics groups, we're using the new code already all the time in measurements at three different cryogenic setups. More drivers, bugfixes, and improvements are present in Git master. If you're willing to hack, I can only recommend that you give it a try. Contributors are always welcome; feel free to clone our git repository on Gitorious.

Top position in condensed matter physics

While everyone in the German research landscape was following the selection of the "Elite Universities" during the last days, we've had some remarkable news here ourselves: the DFG, which awards all the federal research funding in Germany, published the statistics of the last years. The full "Förderatlas" can be found on the website of the DFG, here's the interesting bit (self-made translation):



In the comparison of all German universities, Regensburg managed to get to rank 4 in physics in total, and to a clear number one position in the field of condensed matter physics! Actually we've gotten more funding in CM than TU München and LMU München together! Now if that's not something to celebrate...
Summarizing, now you know where to go for top-notch physics research. :)

cups-1.6 will be loads of fun

I've spent a bit of time recently looking at the current state of what will become cups-1.6, and preparing a live ebuild for subversion head (net-print/cups-9999). My only conclusion is, the transition from 1.5 to 1.6 will give us all loads of fun time... Here are some of the highlights:

• The serial and parallel port backends have been removed. Need USB or LAN now to talk to your printer.
• The PHP and Perl scripting modules have been removed.
• Remote printer discovery via CUPS, LDAP, or SLP is not supported anymore (what was known so-far as "browsing"). Instead you will need to use Zeroconf/Bonjour or Avahi.
• The filter code that allowed to directly print images is gone. (Maybe just moved to a separate package.)

Nice, isn't it? Anyway...  if any of you feels like joining the printing team give me a shout!

edit, 21/May: most of the removed code just made its way into cups-filters, as several people pointed out in comments below... so no need to panic...

CMake is getting verbose

Public announcement: we've just changed the default settings in cmake-utils.eclass, and as a result now cmake-based builds will display a verbose build log instead of the terse "one line per file" version. In the same way as with autotools, the entire compiler / linker / whatever command line is printed, which should simplify bug hunting a lot...

Calligra 2.4.0 is out!

Let's all congratulate the Calligra team for releasing Calligra 2.4.0, the first version of their integrated application suite for KDE. It has really gone a long way from the old KOffice codebase. Of course, Gentoo already has ebuilds as app-office/calligra. Give it a try! Cheers!

A neat trick for testing patches in Gentoo (source-based distros are great!)

Imagine you are running... say... Kubuntu, OpenSuSE, or Fedora, or any other of these famous and fantastic binary Linux distributions. You find a bug, report it to the authors of the package, and they come up with a possible solution. "Hey, here's a small patch to the source, could you please try if applying that helps?" Well... Either now you compile manually, which may or may not give the same packages as your distribution. Or you start setting up the full build system of your distro, which will take a while...
With Gentoo as a source-based distribution, however, this is very easy. Let's assume you want to apply a patch for more debug output to some kde plasma applets. The patch file is called debug.patch, the package name for the plasma applets is kde-base/plasma-apps. All you have to do is

mkdir -p /etc/portage/patches/kde-base/plasma-apps
cp debug.patch /etc/portage/patches/kde-base/plasma-apps/
emerge -a1 kde-base/plasma-apps

Finished. The patch is automatically applied during the emerge command:

 >>> Preparing source in /var/tmp/portage/kde-base/plasma-apps-4.8.2/work/plasma-apps-4.8.2 ...
 * Applying user patches from /etc/portage/patches//kde-base/plasma-apps ...
 *   debug.patch ...                      [ ok ]
 * Done with patching
>>> Source prepared.

Isn't that a nice trick? :)
Just one small warning... this does not work for all ebuilds in the portage tree yet, in case of doubt better check the build log if your patch was really applied. It does work for all ebuilds using base.eclass, which effectively includes all of KDE and all KDE applications.

Please test cups-1.5

CUPS 1.5 has now been in the tree for quite some time, so we should think about getting it stable. As I'm actually not really a person who prints a lot or uses a lot of different printer drivers, it would however be great to get some more widespread testing... So please: If you are still running stable CUPS (i.e. net-print/cups-1.4.8-r1), please give the newest ~arch ebuild a try, and if you are encountering problems, please file bug reports on Gentoo bugzilla! Thanks a lot in advance!!!

Open post-doc position: carbon nanotube-based NEMS

We're still looking for some support in the Regensburg carbon nanotube nanomechanics team! The job description can be found below; please e-mail me if interested! The position is available immediately, however I'm travelling during March and may be hard to reach, so arranging a meeting and a presentation may take a bit of time...

You have already been working successfully with millikelvin RF equipment in your PhD research, and have a good understanding of low temperature physics as well as gigahertz technology? Ideally, you are coming from a research group specialized in superconductor-related mesoscopic physics, quantum information, or cavity QED? You are interested in contributing to a young and dynamic team, trying to push the limits of what is doable in nano-electromechanical systems?
Then you might be just about right here. Your will conduct measurements on coupled superconductor-carbon nanotube nano-electromechanical systems, with a low-temperature high frequency measurement setup in a state-of-the-art dilution refrigerator. Our NEMS team consists at the moment of one PhD student and two MSc students (who you'll help supervise). We expect your work to lead to exceptional publications!
Your salary will be based on the German TV-L E13 (info in German). Regensburg university has a strong focus on nanophysics, in particular on spin phenomena and carbon-based systems. The natives are friendly, and while our university buildings feature classic 1965 concrete, the medieval city of Regensburg is a jewel on its own, with a vibrant young atmosphere. Both mountains and Munich airport are not far away.
Interested? Have a look at our web pages, and contact Andreas K. Hüttel (e-mail: andreas.huettel@physik.uni-r.de) for more information!

Hardened Desktop

My work desktop is on one of these university networks where you have an internet connection in the most direct sense. No NAT, no significant firewall, fast pipe. Which naturally gives you an interesting attack surface; while I only allow ssh login via public key cryptography, it's still amusing to watch all the automated "invalid username" login attempts from all over the world. Anyway, some time ago I decided that this deserves some more attention, and switched to a hardened profile...
So, about profiles. You have probably seen this string default/linux/amd64/10.0/desktop before. A profile actually is something pretty simple- a set of predefined defaults for e.g. use flags, system set, package and use masks, ... The main purpose of the desktop profile, which many people use, is to provide sensible defaults for a typical desktop workstation, i.e. enabling useflags like "consolekit jpeg png". Profiles are inheritance-based, meaning this desktop profile inherits defaults from linux and from amd64. You can select your profile with eselect profile, but in the end whatever that does is only redirect the symlink /etc/make.profile to the appropriate target in /usr/portage/profile.
eselect profile also provides a list of profiles to choose from. Here on my laptop this is

huettel@porto ~ $ eselect profile list
Available profile symlink targets:
  [1]   default/linux/amd64/10.0
  [2]   default/linux/amd64/10.0/selinux
  [3]   default/linux/amd64/10.0/desktop *
  [4]   default/linux/amd64/10.0/desktop/gnome
  [5]   default/linux/amd64/10.0/desktop/kde
  [6]   default/linux/amd64/10.0/developer
  [7]   default/linux/amd64/10.0/no-multilib
  [8]   default/linux/amd64/10.0/server
  [9]   hardened/linux/amd64
  [10]  hardened/linux/amd64/selinux
  [11]  hardened/linux/amd64/no-multilib
  [12]  hardened/linux/amd64/no-multilib/selinux

The list comes from /usr/portage/profiles/profiles.desc. However, if you are brave (or insane), nothing keeps you from manually pointing your /etc/make.profile symlink to a different directory. As it turns out, there is a worthwile target hidden away, which provides a "hardened desktop" profile:

huettel@grenadine ~ $ ls -l /etc/make.profile
lrwxrwxrwx 1 root root 52 24. Jan 18:45 /etc/make.profile -> ../usr/portage/profiles/hardened/linux/amd64/desktop

So, if you want to void all your warranties, set your symlink like this and your profile will inherit from both hardened and desktop profile. Then follow the rest of the guide for switching to hardened.

What will you lose? Mainly, nvidia-drivers, ati-drivers, and skype. All three do at the moment not play nicely with hardened protection features. At least in the case of skype that is pure lazyness by the company; the programmers of skype could easily fix it if they wanted. In addition, the security benefits will lead to a performance hit; how much I cannot really judge yet.

What will you gain? For example, Stack Smashing Protector (SSP), Position Independent Executables (PIEs), Default full binding at load-time (BIND_NOW), ... There's a lot of documentation on hardened floating around, and I'm only just learning...

I'm running a full KDE desktop with radeon driver and accelerated graphics, so far I have not noticed any unpleasant side effects yet. I'll stay with it. :)

What about my precious Xpdf ?!?!?

I keep getting e-mails asking me why app-text/xpdf is masked for removal from the portage tree. It's getting too much to reply individually, so let me sum up the situation here in a blog post.

# Andreas K. Hüttel <dilfridge@gentoo.org> (27 Jan 2012)
# Has developed into an unmaintainable mess, and everyone who
# knows about it is either retired or missing in action.
# Several minor bugs and one ugly security issues (#386271).
# Masked for removal because of lack of maintainer.
# Please try app-text/epdfview as light-weight replacement.
app-text/xpdf

Xpdf is a package with a long history, and in a way a strange remnant of bygone times. Since PDF rendering is a function that many different programs could use, some years ago the Poppler library was forked from the Xpdf codebase. By now, Poppler is a much more active project, and used by dozens of packages in the Gentoo portage tree, all the way from LibreOffice and PDFTeX to Calligra, GIMP, and e.g. Okular or Evince. Being the more active project is important in this case, because PDF files are frequently shared and distributed and PDF rendering is thus a security-relevant task.
The original Xpdf remained independent of Poppler, not using the library - with the effect that every now and then security bugs kept popping up. Some time ago, some Gentoo developers started modifying and patching Xpdf to use the Poppler library. What resulted was the complicated construct that right now noone here is willing to maintain anymore. (Otherwise some Gentoo developer would have contacted me in the meantime.) Implementing a version bump to a more recent Xpdf version is a non-trivial task because all the Gentoo-specific patches have to be reviewed and if necessary rewritten.
Thus, app-text/xpdf needs to go the way of the dinosaur. Two alternatives exist, but both do not seem realistic at the moment:
1) We could go back to the original, unpatched Xpdf from upstream. I'm not going to do it, and I doubt anyone else of the Gentoo devs will.
2) Rogério Brito has started maintaining a fork of Xpdf at Github, which uses the Poppler library. However, there is no released version yet, and as he told me myself, he's rather busy in real life right now...
In the meantime, please try one of the following packages:

• app-text/zathura (based on poppler & gtk+)
• app-text/apvlv (based on poppler & gtk+)
• app-text/epdfview (based on poppler & gtk+, ~unmaintained)
• app-text/mupdf
• app-text/gv (based on ghostscript)
• app-text/evince (based on poppler, Gnome application)
• kde-base/okular (based on poppler, KDE application)
• app-text/acroread (yes I know...)

Ironically, the first mail reply to the last-riting of xpdf was from one of our security team members, promising me a beer the next time we meet in person. Only afterwards the complaints started.

Gentoo zero-day packaging of new KDE releases explained

Usually, whenever a new KDE release is published, Gentoo users can update already the same day, as suddenly a complete and polished set of ebuilds appears in the portage tree. (Stay tuned on upcoming wednesday for KDE 4.8.0, it's shaping up very nicely!) How is this possible? Well... let me explain.

If you're a stable version user, you may have never heard of so-called live ebuilds. This is a special variant, usually denoted by a version number ending in 9999, that does not rely on a source tarball. Instead, it contains a URL of a revsion control system (say on anongit.kde.org). When you emerge such a version of a package, the sources of the specified branch are checked out or updated to the newest upstream state, and that is used for building the installation package. Obviously this is not for everyone; depending how well upstream structures commits, things may not build for a while, contain fresh bugs, ... Also, reporting bugs from live versions on Gentoo bugzilla is discouraged as most of the times we can't do anything about it (do it only if you are sure it's a problem with the ebuilds, not with the source). If you're running live, you should be willing to hack yourself and work with upstream.

However, many of the Gentoo KDE team members run these live ebuilds, partly the current bugfix branch (i.e. KDE/4.8), partly even git master. They continuously keep the live ebuilds in the Gentoo KDE overlay updated to the newest state of the source. When a release is made, the corresponding live ebuilds of this branch are copied to the version ebuilds. For example, the KDE/4.8 branch live ebuilds have the version number 4.8.49.9999 (i.e.
kde-base/kdelibs-4.8.49.9999), so when the pre-release tarballs for KDE 4.8.0 were released to the packagers a few days ago, we only had to copy all 4.8.49.9999 ebuilds to 4.8.0 and immediately had a working set for testing. Most problems at that point are only caused by changes in tarball packaging. As distribution packagers get the pre-release tarballs (that still may change due to last-minute bugfixes) a week before the official release date, these can easily be fixed in time.

This also means that KDE maintenance in Gentoo is really a team effort. Whoever moves a released version to the main portage tree and/or commits bugfixes there builds on all the work that the team has done in the overlay in the meantime. Cheers!

Calling for brave testers: net-print/cups-1.5.0-r2

Maybe some of you have noticed that CUPS 1.5.0 is still hard-masked. Well, the reason for that is simple- at home, I'm nearly not printing at all, and at work, I have to rely on printing too much to tinker with it on the side a bit. So... if you would like to help, please unmask net-print/cups-1.5.0-r2 and give it a try. You will for sure find some problems, as the only thing I tested looong time ago was building it, never actually running it. Report them on bugs.gentoo.org, and we'll have a look... with a bit of luck, the package mask can then go away at some point. Any feedback (also positive) is appreciated. Cheers!

My personal KDEPIM upgrade status

Some time ago when we were filing the first stable request for KDE 4.7 I decided I'd have to give KDEPIM-4.7 also a try. I used to be a pine (and later alpine) user for ages, some time ago I switched to kmail1 (maybe at version 4.2 or so) and have been using it ever since... About the setup, incoming mail is stored and filtered server-side (Novell Groupwise), and accessed as disconnected IMAP.

1) Office desktop.
This one's usually running the latest and greatest KDE RC or beta, with a static IP and something like a 100MBps-FD link to the mail server. No local folders, so this was the natural candidate to test first. I did not even try the data migration, but wiped my entire local configuration of the KDEPIM programs as thoroughly as possible before updating. On the whole this went rather well. From 4.7.3 to 4.7.95 I've seen my share of kmail2 / kontact / akonadi crashes, but none of them really led to bigger problems. Impressively, I could also see each of these crash bugs I hit get fixed on KDE bugzilla in the meantime! Since upgrading to 4.7.97 I haven't had a crash anymore.
The only thing that is really bugging me a the moment is that I absolutely can't drag an e-mail message into another folder (I always have to right-click on the entry in the message list, select "Move to folder", ...). However, that is likely a problem in one of the underlying libraries. :| I would really like to help debugging this problem; if you can give me any clue where to look, please message...

2) Laptop.
Going home for christmas meant spending some time on a train. The days before I had upgraded this box to QT-4.8.0 and KDE+KDEPIM 4.7.95. Again, clean start with a new configuration. On the train I spent some time ironing out bugs there. The GPRS connection was happily going down and up again with every tunnel or less-populated countryside. That's when the akonadi backend started really acting up. When I arrived at my family's place, my e-mail had become fully non-functional (no fetching e-mails, no sending e-mails, the backend making kmail hang, regular crashes, and all fumbling with akonadiconsole did not help). After a while of trying, I gave up, wiped my entire KDEPIM configuration and data and downgraded to 4.4 again. I was impressed how responsive my e-mail program suddenly became.
Talking to other people, it seems that some have problems with bad internet connections, some don't. Maybe I should have used networkmanager, at least Alexxy reports that it's working fine with it.

3) Home desktop.
Well... Here I store my e-mail archive since 1996- that's maildir folders with roughly 50000 messages. Maybe I'll consider upgrading KDEPIM sometime around KDE 4.9.

I'm sorry if this blog entry is demotivating for the program developers. Some time ago I followed part of an animated discussion on irc between a kdepim user and a kdepim developer. Quoting a small part,

<user> first: fix bugs. second:dont change data formats. third: change gui only if absolutly nessary.
<developer> no
<developer> first: have fun; second: make it work for others

While this is of course oversimplifying, both points have clear validity, the first because people have come to rely on the software, the second because it's volunteer work by people enthusiastic about their creation. In the end we'll have to find a good compromise.