Gentoo mailing lists down

Since yesterday the host running all Gentoo mailing lists is down. So far there is no information yet available on the nature of the problem. Please check the Gentoo Infrastructure status page, http://infra-status.gentoo.org/, for updates.

[Edit: All fixed.]

This public service announcement has been brought to you by non-infra Andreas.

RDepending on Perl itself

Writing correct dependency specifications is an art in itself. So, here's a small guide for Gentoo developers how to specify runtime dependencies on dev-lang/perl. First, the general rule.
Check the following two things: 1) is your package linking anywhere to libperl.so, 2) is your package installing any Perl modules into Perl's vendor directory (e.g., /usr/lib64/perl5/vendor_perl/5.20.1/)? If at least one of these two questions is answered with yes, you need in your dependency string a slot operator, i.e. "dev-lang/perl:=" Obviously, your ebuild will have to be EAPI=5 for that. If neither 1) nor 2) are the case, "dev-lang/perl" is enough.
Now, with eclasses. If you use perl-module.eclass or perl-app.eclass, two variables control automatic adding of dependencies. GENTOO_DEPEND_ON_PERL sets whether the eclass automatically adds a dependency on Perl, and defaults to yes in both cases. GENTOO_DEPEND_ON_PERL_SUBSLOT controls whether the slot operator ":=" is used. It defaults to yes in perl-module.eclass and to no in perl-app.eclass. (This is actually the only difference between the eclasses.) The idea behind that is that a Perl module package always installs modules into vendor_dir, while an application can have its own separate installation path for its modules or not install any modules at all.
In many cases, if a package installs Perl modules you'll need Perl at build time as well since the module build system is written in Perl. If a package links to Perl, that is obviously needed at build time too.

So, summarizing:

eclass	1) or 2) true	1) false, 2) false
none	"dev-lang/perl:=" needed in RDEPEND and most likely also DEPEND	"dev-lang/perl" needed in RDEPEND, maybe also in DEPEND
perl-module.eclass	no need to do anything	GENTOO_DEPEND_ON_PERL_SUBSLOT=no possible before inherit
perl-app.eclass	GENTOO_DEPEND_ON_PERL_SUBSLOT=yes needed before inherit	no need to do anything

NJP accepted: Thermally induced subgap features in the cotunneling spectroscopy of a carbon nanotube

Today's good news is that our manuscript "Thermally induced subgap features in the cotunneling spectroscopy of a carbon nanotube" has been accepted for publication by New Journal of Physics.
In a way, this work is directly building on our previous publication on thermally induced quasiparticles in niobium-carbon nanotube hybrid systes. As a contribution mainly from our theory colleagues, now the modelling of transport processes is enhanced and extended to cotunneling processes within Coulomb blockade. A generalized master equation based on the reduced density matrix approach in the charge conserved regime is derived, applicable to any strength of the intradot interaction and to finite values of the superconducting gap.
We show both theoretically and experimentally that also in cotunneling spectroscopy distinct thermal "replica lines" due to the finite quasiparticle occupation of the superconductor occur at higher temperature T~1K: the now possible transport processes lead to additional conductance both at zero bias and at finite voltage corresponding to an excitation energy; experiment and theoretical result match very well.

"Thermally induced subgap features in the cotunneling spectroscopy of a carbon nanotube"
S. Ratz, A. Donarini, D. Steininger, T. Geiger, A. Kumar, A. K. Hüttel, Ch. Strunk, and M. Grifoni
New J. Phys. 16, 123040 (2014), arXiv:1408.5000 (PDF)

How do I run ~arch Perl on a stable Gentoo system?

Here's a small piece of advice for all who want to upgrade their Perl to the very newest available, but still keep running an otherwise stable Gentoo installation: These three lines are exactly what needs to go into /etc/portage/package.keywords:

dev-lang/perl
virtual/perl-*
perl-core/*

Of course, as always, bugs may be present; what you get as Perl installation is called unstable or testing for a reason. We're looking forward to your reports on our bugzilla.

EAPI=5 adoption has reached 50% of ebuilds in the portage tree

As of today, more than 50% of the 37527 ebuilds in the Gentoo portage tree use the newest ebuild API (EAPI) version, EAPI=5!
The details of the various EAPIs can be found in the package manager specification (PMS); the most notable new feature of EAPI 5, which has sped up acceptance a lot is the introduction of so-called subslots. A package A can specify a subslot, another package B that depends on it can specify that it needs to be rebuilt when the subslot of A changes. This leads to much more elegant solutions for many of the the link or installation path problems that revdep-rebuild, emerge @preserved-rebuild, or e.g. perl-cleaner try to solve... Another useful new feature in EAPI=5 is the masking of use-flags specifically for stable-marked ebuilds.
You can follow the adoption of EAPIs in the portage tree on an automatically updated graph page.

Perl in Gentoo: Upgrading pains, perl-cleaner, and EAPI=5

In a previous post, we've already looked at the structure of Perl ebuilds in Gentoo Linux. Now, let's see what happens in the case of a major Perl update.

Does this look familiar?

UPDATE THE PERL MODULES:
After updating dev-lang/perl you must reinstall
the installed perl modules.
Use: perl-cleaner --all

Then maybe you have updated your major Perl version recently, since this important message is printed by emerge afterwards. So, what is it about? In short, a certain disconnect between the "Perl way" of doing things and the rest of the world. Both have their merits, they just don't play very well with each other... and the result is that major Perl updates in Gentoo have traditionally also been a major pain. (This will become much better in the future, see below.)

Let's see where a perl package stores its files.

caipi ~ # equery files dev-perl/Email-Address
 * Searching for Email-Address in dev-perl ...
 * Contents of dev-perl/Email-Address-1.898.0:
/usr
/usr/lib
/usr/lib/perl5
/usr/lib/perl5/vendor_perl
/usr/lib/perl5/vendor_perl/5.16.3
/usr/lib/perl5/vendor_perl/5.16.3/Email
/usr/lib/perl5/vendor_perl/5.16.3/Email/Address.pm
/usr/share
/usr/share/doc
/usr/share/doc/Email-Address-1.898.0
/usr/share/doc/Email-Address-1.898.0/Changes.bz2
/usr/share/doc/Email-Address-1.898.0/README.bz2
caipi ~ #

Interesting- the installation path contains the Perl version! The reasons for upstream to do this are pretty much obvious, the application binary interface for compiled modules can change and it's necessary to keep the installed modules for different versions apart. Also, in theory you can keep different Perl versions installed in parallel. Nice idea, however if you have only one "system Perl" installation, and you exchange that for a newer version (say, 5.18.1 instead of 5.16.3), the result is that the new version won't find the installed packages anymore.

The results are rather annoying. Imagine you haven't updated your system for a while, one of the many packages to be updated is dev-lang/perl, and later maybe (just picking an example at random) gnome-base/gsettings-desktop-schemas. Perl is updated fine, but when portage arrives at building the gnome package, the build fails with something like

checking for perl >= 5.8.1... 5.18.2
checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool

Right. Perl is updated, dev-perl/XML-Parser is still installed in the old path, and Perl doesn't find it. Bah.

Enter perl-cleaner, the traditional "solution". This small program checks for files in "outdated" Perl installation paths, finds out which packages they belong to, and makes portage rebuild the corresponding packages. During the rebuild, the installation is run by the updated Perl, which makes the files go into the new, now correct path.

This sounds like a good solution, but there are a lot of details and potential problems hidden. For once, most likely you'll run perl-cleaner after a failed emerge command, and some unrelated packages still need updates. Portage will try to figure out how to do this, but blockers and general weirdness may happen. Then, sometimes a package isn't needed with the new Perl version anymore, but perl-cleaner can't know that. Again the result may be a blocker. We've added the following instructions to the perl-cleaner output, which may help cleaning up the most frequent difficulties:

 * perl-cleaner is stopping here:
 * Fix the problem and start perl-cleaner again.
 *
 * If you encounter blockers involving virtuals and perl-core, here are
 * some things to try:
 *   Remove all perl-core packages from your world file
 *     emerge --deselect --ask $(qlist -IC 'perl-core/*')
 *   Update all the installed Perl virtuals
 *     emerge -uD1a $(qlist -IC 'virtual/perl-*')
 *   Afterwards re-run perl-cleaner

In the end, you may have to try several repeated emerge and perl-cleaner commands until you have an updated and consistent system again. So far, it always worked somehow with fiddling, but the situation was definitely not nice.

So what's the future? Well...

EAPI=5 brings the beautiful new feature of subslots and slot operator dependencies. In short, a package A may declare a subslot, and a package B that depends on A may declare "rebuild me if A changes subslot". This mechanism is now used to automate the Perl rebuilds directly from within emerge: dev-lang/perl declares a subslot corresponding to its major version, say "5.18", and every package that installs Perl modules needs to depend on it with the subslot-rebuild requested, e.g.

RDEPEND="dev-lang/perl:="

The good news about this is that portage now knows the dependency tree and can figure out the correct reinstallation order.

The bad news is, it can only work perfectly after all Perl packages have been converted to EAPI=5 and stabilized. perl-core is done, but with about 2100 ebuilds that use perl-module.eclass in the portage tree still quite some work remains. I've plotted the current EAPI distribution of ebuilds using perl-module.eclass in a pie chart for illustration... Maybe we're done when Perl 5.20 goes stable. Who knows. :)

Perl in Gentoo: dev-lang/perl, virtuals, and perl-core packages

We've got the stabilization of Perl 5.18 upcoming, so what better chance is there to explain a bit how the Perl-related ebuilds in Gentoo work...

First of all, there is dev-lang/perl. This contains the Perl core distribution, installing the binaries and all the Perl modules that are bundled with Perl itself.

Then, there is the perl-core category. It contains independent ebuilds for Perl modules that are also present in the core Perl distribution. Most Perl modules that are bundled with Perl are also in addition released as independent tarballs. If any of these packages is installed from perl-core, its files are placed such that the perl-core download overrides the bundled copy. This means you can also update part of the bundled Perl modules, e.g. in case of a bug, without updating Perl itself.

Next, there are a lot of virtuals "virtual/perl-..." in the virtual category of the portage tree. What are these good for? Well, imagine you want to depend on a specific version of a module that is usually bundled with Perl. For example, you need Module::CoreList at at least version 3.  This can either be provided by a new enough Perl (for example, now hardmasked Perl 5.20 contains Module::CoreList 3.10), or by a separate package from perl-core (where we have Module::CoreList 5.021001 as perl-core/Module-CoreList-5.21.1).
To make sure that everything works, you should never directly depend on a perl-core package, but always on the corresponding virtual (here virtual/perl-Module-CoreList; any perl-core package must have a corresponding virtual). Then both ways to fulfil the dependency are automatically taken into account. (Future repoman versions will warn if you directly depend on perl-core. Also you should never have anything perl-core in your world file!)

Last, we have lots of lots of modules in the dev-perl category. Most of them are from CPAN, and the only thing they have in common is that they have no copy inside core Perl.

I hope this clarifies things a bit. More Perl posts coming...

Emmy Noether grant extended

Today we've received the good news that our Emmy Noether project on the electronic and nano-electromechanical properties of carbon nanotubes has been given a positive intermediate evaluation from the referees. This means funding for an additional period will be granted. Cheers!

Please test =app-admin/perl-cleaner-2.14

We've made a few small updates to perl-cleaner that should get you around subslot issues much better in the future.
If you are planning to do any major Perl update on your Gentoo box in the near future, please as a first step update to =app-admin/perl-cleaner-2.14, which is currently in ~arch but in my opinion a good stabilization candidate. This will hopefully give you a much better upgrade of your Perl modules.
Of course any feedback is appreciated, and if you encounter problems, please file bugs! If nothing unexpected happens, =app-admin/perl-cleaner-2.14 will go stable in a month.

PRB Rapid Comm. accepted: Sub-gap spectroscopy of thermally excited quasiparticles in a Nb contacted carbon nanotube quantum dot

Excellent news- our manuscript "Sub-gap spectroscopy of thermally excited quasiparticles in a Nb contacted carbon nanotube quantum dot" was just accepted for publication by Physical Review B as a Rapid Communication.
Once again we visit the topic of a carbon nanotube quantum dot with superconducting contacts, and again we use niobium for these contacts. Only, this time the connection between the nanotube and the superconductor is pretty bad, i.e., very low electronic tunnel rates. In the end this means that the superconductor does not influence the localized electronic system very much. However, in the metallic contacts we still have a superconductor, meaning electrons pair up into Cooper pairs, and for free quasiparticles carrying only one electron charge an energy gap evolves (the so-called BCS density of states).
Since we're using niobium, we can see superconducting effects over a fairly large temperature range. If we increase the temperature enough, thermal quasiparticles are excited over this energy gap. This precisely is what we observe in our experiment, as additional discrete lines in the transport spectrum. A detailed theoretical analysis of single electron tunneling, in a close cooperation with the research group Prof. Dr. M. Grifoni, confirms our results very well, especially also the temperature dependence of the features visible in the measurements.
In addition there is an interesting bonus to be had here. The thermally activated processes lead to a distinct double-peak of the conductance at zero bias, and the relative height of the two maxima is controlled by the degeneracy of the quantum dot ground states involved in tunneling. This means that looking at the thermally activated current provides additional information to identify the carbon nanotube level spectrum, even if it is not immediately clear from the usual "Coulomb diamond spectroscopy".

"Sub-gap spectroscopy of thermally excited quasiparticles in a Nb contacted carbon nanotube quantum dot"
M. Gaass, S. Pfaller, T. Geiger, A. Donarini, M. Grifoni, A. K. Hüttel, and Ch. Strunk
Phys. Rev. B 89, 241405(R) (2014), arXiv:1403.4456 (PDF)

Lab::Measurement moves to Github

We've decided to migrate the primary Git repository of our code from Gitorious to Github. The new project page of Lab::Measurement is

https://github.com/lab-measurement/lab-measurement

and you can anonymously clone the code e.g. from the following URL:

https://github.com/lab-measurement/lab-measurement.git

This means we'll also be able to use the Github issue tracker in the future. The copy on Gitorious will eventually be removed.

Lab::Measurement 3.31 released

Since we came up with a few good ideas at the last moment, we're skipping the announcement of Lab::Measurement 3.30 and hereby directly announce a new and shiny Lab::Measurement 3.31!
So why a version number increase again? First of all, the structure of the XPRESS package has changed once more a bit, and with it the way your measurement scripts should look like. The "hub" package is gone, and the whole XPRESS functionality is now made available by a simple

use Lab::Measurement;

statement at the start of your file. The example scripts (also on the website) have been adapted accordingly.
In addition, we have implemented a generic support for so-called multichannel instruments, as for example multimeters with several input channels. This is a more generic solution compared to earlier multichannel sources, and also ties in with the device cache mechanisms. So far, the drivers for the Oxford Instruments ITC temperature control system and the Agilent 34420A nanovoltmeter are multichannel-aware.
Next, now at the start of any measurement the entire device configuration as far as accessible by the driver is saved into a file for your later perusal. Should you ever try to decipher mystery data months later...
Finally, a driver for the Andeen-Hagerling AH 2700A capacitance measurement bridge has been added, and of course also quite some bugfixes. Enjoy!

PRB accepted: Temperature dependence of Andreev spectra in a superconducting carbon nanotube quantum dot

The new year once more brings good news. Our manuscript "Temperature dependence of Andreev spectra in a superconducting carbon nanotube quantum dot" was finally accepted for publication by Physical Review B. So what's this about?
When you place a carbon nanotube at low temperature between contacts made from a superconducting metal, lots of interesting things happen. Strongly simplifying, currents in a superconductor are carried by Cooper pairs of two electrons each, while the localized electronic system in the carbon nanotube is normal-conducting and carries single electrons. One mechanism at a superconductor - normal conductor interface that mediates between these two types of charge transport is so-called  Andreev reflection. An electron from the normal conductor enters the superconductor, at the same time a "missing electron", i.e. a "hole where an electron should be", is sent back into the normal conductor. The total charge passing through the interface is 2e, just right to form a Cooper pair. The superconductor-nanotube-superconductor system consistis of two such interfaces back to back; analogous to box potential, multiple reflections on both sides lead to the formation of bound quantum states within the nanotube, the so-called Andeev bound states (ABS).
So far, all other observations of ABS involved aluminum, which has a fairly low critical temperature and critical field. What is new in our work is that we use niobium as superconducting material, with higher critical temperature and larger energy gap. We can increase the temperature to over 1K and still see the superconductivity plus the ABS in the transport spectrum. This way, we can observe how thermal population of an excited Andreev state takes place. Additionally we observe a second pair of Andreev states in the larger superconducting energy gap, and a surprising multi-loop behaviour. All these effects are successfully modelled by calculations based on the superconducting Anderson model, in a collaboration with Alfredo Levy Yeyati and Alvaro Martin-Rodero from Universidad Autonoma de Madrid.

"Temperature dependence of Andreev spectra in a superconducting carbon nanotube quantum dot"
A. Kumar, M. Gaim, D. Steininger, A. Levy Yeyati, A. Martin-Rodero, A. K. Hüttel, and C. Strunk
Physical Review B 89, 075428 (2014), arXiv:1308.1020 (PDF)

Git and MediaWiki

I'm again and again amazed at the modular archtecture of Git, the distributed version control system. One feature that I've just discovered is its MediaWiki integration. In short, you can clone the contents of a wiki into a local git repository, pull, make changes in the wikitext, commit them, and even push them back onto the wiki. Amazingly, this is all possible without any special server-side support; the normal MediaWiki API is sufficient.
If you want to try, you'll need dev-vcs/git-1.8.5.2 or later with the mediawiki useflag enabled. (Because of missing dependencies, at the moment the useflag is masked on all arches except amd64, but that will hopefully change soon.) The documentation for the module can be found on github.
Here's a small demonstration. Since cloning a whole wiki is timeconsuming and also (if done repeatedly) not very nice towards the wiki operators, let's clone only all pages of the "Desktop" category on the Gentoo wiki:

git clone -c remote.origin.categories='Desktop' \
       mediawiki::http://wiki.gentoo.org

This creates a directory wiki.gentoo.org, we change directory in there and call "git log --stat", and obtain a version history:

commit d10a150c78e743d1e62c39f5a7feadf81c552e28
Author: Tox2ik <Tox2ik@wiki.gentoo.org>
Date:   Wed Jan 1 14:52:24 2014 +0000

    Broke up a long sentence.

 Fontconfig.mw | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

commit 1da83052b8062239e265458c538b2efb32ca25a8
Author: El Salmon <El Salmon@wiki.gentoo.org>
Date:   Tue Dec 3 19:05:37 2013 +0000

    Checking configuration

 Fontconfig.mw | 4 ++++
 1 file changed, 4 insertions(+)

commit 9583e17c82508d166d9a30733765d3bdfd9d7f3e
Author: Emery <Emery@wiki.gentoo.org>
Date:   Fri Oct 25 04:53:35 2013 +0000

    Tense changes (changes to tense).

 Tallscreen_Monitor.mw | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

...

The files in the Git working copy are raw wikitext files, and can easily be edited by hand. So, we edit a file and commit that change locally into Git:

commit 6af2bfa0bba4cf825d4e52242709ffccfe341223
Author: Andreas K. Huettel (dilfridge) <dilfridge@gentoo.org>
Date:   Sat Jan 4 23:47:55 2014 +0100

    Add klayout to the scientific applications

 Recommended_applications.mw | 1 +
 1 file changed, 1 insertion(+)

To be able to push the change back into the wiki, we need to log in there. So, we tell Git our wiki username:

git config remote.origin.mwLogin Dilfridge

Afterwards, a simple "git push" is enough to publish our change; Git will ask for the wiki password.
While definitely a cool feature, there are some limitations. The most obvious one that I have come across is the following: if different people clone from the wiki, they obtain different git histories, i.e. the commits in their histories will have different hashes. This means sharing changesets via git is only possible if the cloning from MediaWiki takes place only once, and then the generated git repository is cloned in turn. In addition, I suspect the author of a change in the wiki is set by the username when pushing the change, not by the author of the git commit.
Anyway, I think this might be useful.