Starting up a new experimental physics research group is again and again interesting. Last time I was really nervous was when I for the first time signed the paperwork to hire someone (in case you're from the US, in Germany and many other European countries PhD students are in the sciences paid employees). Today, another lengthy process came to its (momentary) conclusion; I'll have however to explain this a bit.
Our research is focussing on electronic and mechanical processes at extremely low temperatures. "Extremely low" means in that case something like 20mK, or 0.02 degrees above absolute zero, or -272.95°C. To reach such temperatures, several steps of cooling have to be employed. First, the entire experimental assembly is submerged in a dewar (something like a thermos flask) filled with liquid helium, boiling away at 4.2K. Then, inside another vacuum chamber, evaporation cooling with again liquid helium is used to lower the temperature even further to somewhere around 1.5K. Lastly a closed cooling cycle with a mixture of the two isotopes of helium, helium-3 and helium-4, is used to lower the temperature even further to the base temperature of 0.02K. This entire machinery is called a dilution refrigerator; it was invented in 1951, and is by now available commercially from several companies worldwide.
So what happened today? Well, after getting a grant for buying one of them beasties, writing up the specifications, starting the Europe-wide call for tenders, awaiting and carefully evaluating the quotes, finally I've sent off the decision letter. "Please buy this one." Phew. I hope all works out, this thing costs about as much as a top-range Ferrari...
Tuesday, May 17, 2011
Saturday, May 14, 2011
Hunting the glib-networking / libproxy mystery bug
Just when we wanted to stabilize KDE-4.6, an unpleasant surprise appeared out of nowhere. For no apparent reason, polkit was failing to make DBUS connections. As one consequence, some users could not log into KDE; the desktop would simply hang during the session initialization. After upgrading and downgrading packages, and after a lot of communication on bugzilla (since noone from the Gentoo KDE team could reproduce the bug), a pattern emerged: net-libs/glib-networking-2.28.6.1 was somehow causing the problem, force-unmerging it with "emerge -C" restored correct behaviour. Later, this was narrowed down to net-libs/glib-networking[libproxy].
Minus docs and debug info, this is what is installed by glib-networking:
cause DBUS hangs. Let's just say, the Gnome guys did not know either, but obviously the most intrusive part is the proxy autoconfiguration service registered in dbus.
As KDE-4.6.2 stabilization was pending, one way to temporarily get around the problem was to block concurrent installation of net-libs/glib-networking[libproxy]. After all that package appeared only on 24 Apr 2011 (one week before the bug report was filed) as ~arch in the main tree, and is hard-required in exactly one package (net-voip/telepathy-gabble). Yes, we checked that thoroughly before. User responses however were not so, err, welcoming.
Minus docs and debug info, this is what is installed by glib-networking:
/usr/lib/gio/modules/libgiolibproxy.soWhich leads to the question, how can these seemingly unrelated libraries
/usr/lib/gio/modules/libgiognutls.so
/usr/lib/gio/modules/libgiognomeproxy.so
/usr/share/dbus-1/services/org.gtk.GLib.PACRunner.service
/usr/libexec/glib-pacrunner
cause DBUS hangs. Let's just say, the Gnome guys did not know either, but obviously the most intrusive part is the proxy autoconfiguration service registered in dbus.
As KDE-4.6.2 stabilization was pending, one way to temporarily get around the problem was to block concurrent installation of net-libs/glib-networking[libproxy]. After all that package appeared only on 24 Apr 2011 (one week before the bug report was filed) as ~arch in the main tree, and is hard-required in exactly one package (net-voip/telepathy-gabble). Yes, we checked that thoroughly before. User responses however were not so, err, welcoming.
"Anyway it is high time ppl start thinking before committing any changes in the main tree... even if we are talking about an unstable ~ stuff..." (bug 365479, comment 38)Ah well. Now the blocker is gone again and we won't hinder people from shooting themselves in the foot, but we still dont know what actually the problem is. In any case, libproxy seems to be prone to more misbehaviour (what the %$&%$ is it doing in NVidia OpenGL code??!!). So far the reports of various details do not really add up to a coherent picture.
"Now we have repeat with strange blocker... and all because some guy forgotten (or didnt want to) try it before pushing into tree... Sometimes i think that Gentoo developers comes from the round-up." (bug 365479, comment 43)
Subscribe to:
Posts (Atom)