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!

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