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