While using mondorescue to perform a full backup of a server running RHEL 5, here is a list of error messages found in /var/log/mondoarchive.log :

File descriptor 3 (/tmp/mojo-jojo.blah.qN83BE) leaked on lvm invocation. Parent PID 3006: /bin/bash
File descriptor 3 (/tmp/mojo-jojo.blah.qN83BE) leaked on lvm invocation. Parent PID 3049: /bin/bash
File descriptor 3 (/tmp/mojo-jojo.blah.qN83BE) leaked on lvm invocation. Parent PID 3109: /bin/bash
File descriptor 3 (/tmp/mojo-jojo.blah.qN83BE) leaked on lvm invocation. Parent PID 3129: /bin/bash
File descriptor 3 (/tmp/mojo-jojo.blah.qN83BE) leaked on lvm invocation. Parent PID 3196: /bin/bash
File descriptor 3 (/tmp/mojo-jojo.blah.qN83BE) leaked on lvm invocation. Parent PID 3268: /bin/bash
File descriptor 3 (/tmp/mojo-jojo.blah.qN83BE) leaked on lvm invocation. Parent PID 3326: /bin/bash
File descriptor 3 (/tmp/mojo-jojo.blah.qN83BE) leaked on lvm invocation. Parent PID 3385: /bin/bash
File descriptor 3 (/tmp/mojo-jojo.blah.qN83BE) leaked on lvm invocation. Parent PID 3450: /bin/bash
File descriptor 3 (/tmp/mojo-jojo.blah.qN83BE) leaked on lvm invocation. Parent PID 3512: /bin/bash
File descriptor 3 (/tmp/mojo-jojo.blah.qN83BE) leaked on lvm invocation. Parent PID 3574: /bin/bash
File descriptor 3 (/tmp/mojo-jojo.blah.qN83BE) leaked on lvm invocation. Parent PID 3631: /bin/bash
File descriptor 3 (/tmp/mojo-jojo.blah.qN83BE) leaked on lvm invocation. Parent PID 3687: /bin/bash
File descriptor 3 (/tmp/mojo-jojo.blah.qN83BE) leaked on lvm invocation. Parent PID 3749: /bin/bash
File descriptor 3 (/tmp/mojo-jojo.blah.qN83BE) leaked on lvm invocation. Parent PID 3805: /bin/bash
File descriptor 3 (/tmp/mojo-jojo.blah.qN83BE) leaked on lvm invocation. Parent PID 3861: /bin/bash

After googling a little bit, here is the first explanation I managed to find. It seems that the lvm utility inherited all the opened file descriptors from the shell where it was launched.

By default, only three file descriptors are opened : 0 standard input,  1 standard output and 2 error output. So, a file descriptor named 3 was opened by a program but not closed properly.

A similar bug was reported within the official Debian bugreport :

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466138

What ties in reckless glibc unmasking GTK+ 2.20 issues Ruby 1.9 porting and --as-needed failures all together? Okay the title is a dead giveaway for the answer: undefined symbols.

Before deepening within the topic I first have to tell you about symbols I guess; and to do so, and to continue further, I’ll be using C as the base language for everyone of my notes. When considering C, then, a symbol is any function or data (constant or variable) that is declared extern; that is anything that is neither static or defined in the same translation unit (that is, source file, most of the time).

Now, what nm shows as undefined (U code) is not really what we’re concerned about; for object files (.o, just intermediate) will report undefined symbols for any function or data element used that is not in the same translation unit; most of those get resolved at the time all the object files get linked in to form a final shared object or executable — actually, it’s a lot more complex than this, but since I don’t care about describing here symbolic resolution, please accept it like it was true.

The remaining symbols will be keeping the U code in the shared object or executable, but most of them won’t concern us: they will be loaded from the linked libraries, when the dynamic loader actually resolve them. So for instance, the executable built from the following source code, will have the printf symbol “undefined” (for nm), but it’ll be resolved by the dynamic linker just fine:

int main() {
  printf("Hello, world!");
}

I have explicitly avoided using the fprintf function, mostly because that would require a further undefined symbol, so…

Why do I say that undefined symbols are our worst enemy? Well, the problem is actually with undefined, unresolved symbols after the loader had its way. These are either symbols for functions and data that is not really defined, or is defined in libraries that are not linked in. The former case is what you get with most of the new-version compatibility problems (glibc, gtk, ruby); the latter is what you get with --as-needed.

Now, if you have a bit of practice with development and writing simple commands, you’d be now wondering why is this a kind of problem; if you were to mistype the function above into priltf – a symbol that does not exist, at least in the basic C library – the compiler will refuse to create an executable at all, even if the implicit declaration was only treated as a warning, because the symbol is, well, not defined. But this rule only applies, by default, to final executables, not to shared objects (shared libraries, dynamic libraries, .so, .dll or .dylib files).

For shared objects, you have to explicitly ask to refuse linking them with undefined reference, otherwise they are linked just fine, with no warning, no error, no bothering at all. The way you can tell the linker to refuse that kind of linkage is passing the -Wl,--no-undefined flag; this way if there is even a single symbol that is not defined in the current library or any of its dependencies the linker will refuse to complete the link. Unfortunately, using this by default is not going to work that well.

There are indeed some more or less good reasons to allow shared objects to have undefined symbols, and here come a few:

Multiple ABI-compatible libraries: okay this is a very far-fetched one, simply for the difficulty to have ABI-compatible libraries (it’s difficult enough to have them API-compatible!), but it happens; for instance on FreeBSD you – at least used to – have a few different implementations of the threading libraries, and have more or less the same situation for multiple OpenGL and mathematical libraries; the idea behind this is actually quite simply; if you have libA1 and libA2 providing the symbols, then libB linking to libA1, and libC linking to libA2, an executable foo linking to libB and libC would get both libraries linked together, and creating nasty symbol collisions.

Nowadays, FreeBSD handles this through a libmap.conf file that allows to link always the same library, but then switch at load-time with a different one; a similar approach is taken by things like libgssglue that allows to switch the GSSAPI implementation (which might be either of Kerberos or SPKM) with a configuration file. On Linux, beside this custom implementation, or hacks such as that used by Gentoo (eselect opengl) to handle the switch between different OpenGL implementations, there seem to be no interest in tackling the problem at the root. Indeed, I complained about that when --as-needed was softened to allow this situation although I guess it at least removed one common complain about adopting the option by default.

Plug-ins hosted by a standard executable: plug-ins are, generally speaking, shared objects; and with the exception of the most trivial plugins, whose output is only defined in terms of their input, they use functions that are provided by the software they plug. When they are hosted (loaded and used from) by a library, such as libxine, they are linked back to the library itself, and that makes sure that the symbols are known at the time of creating the plugin object. On the other hand, when the plug-ins are hosted by some software that is not a shared object (which is the case of, say, zsh), then you have no way to link them back, and the linker has no way to discern between undefined symbols that will be lifted from the host program, and those that are bad, and simply undefined.

Plug-ins providing symbols for other plug-ins : here you have a perfect example in the Ruby-GTK2 bindings; when I first introduced --no-undefined in the Gentoo packaging of Ruby (1.9 initially, nowadays all the three C-based implementations have the same flag passed on), we got reports of non-Portage users of Ruby-GTK2 having build failures. The reason? Since all the GObject-derived interfaces had to share the same tables and lists, the solution they chose was to export an interface, unrelated to the Ruby-extension interface (which is actually composed of a single function, bless them!), that the other extensions use; since you cannot reliably link modules one with the other, they don’t link to them and you get the usual problem of not distinguish between expected and unexpected undefined symbols.

Note: this particular case is not tremendously common; when loading plug-ins with dlopen() the default is to use the RTLD_LOCAL option, which means that the symbols are only available to the branch of libraries loaded together with that library or with explicit calls to dlsym(); this is a good thing because it reduces the chances of symbol collisions, and unexpected linking consequences. On the other hand, Ruby itself seems to go all the way against the common idea of safety: they require RTLD_GLOBAL (register all symbols in the global procedure linking table, so that they are available to be loaded at any point in the whole tree), and also require RTLD_LAZY, which makes it more troublesome if there are missing symbols — I’ll get later to what lazy bindings are.

Finally, the last case I can think of where there is at least some sense into all of this trouble, is reciprocating libraries, such as those in PulseAudio. In this situation, you have two libraries, each using symbols from one another. Since you need the other to fully link the one, but you need the one to link the other, you cannot exit the deadlock with --no-undefined turned on. This, and the executable-plugins-host, are the only two reasons that I find valid for not using --no-undefined by default — but unfortunately are not the only two used.

So, what about that lazy stuff? Well, the dynamic loader has to perform a “binding” of the undefined symbols to their definition; binding can happen in two modes, mainly: immediate (“now”) or lazy, the latter being the default. With lazy bindings, the loader will not try to find the definition to bind to the symbol until it’s actually needed (so until the function is called, or the data is fetched or written to); with immediate bindings, the loader will iterate over all the undefined symbols of an object when it is loaded (eventually loading up the dependencies). As you might guess, if there are undefined, unresolved symbol, the two binding types have very different behaviours. An immediately-loaded executable will fail to start, and a loaded library would fail dlopen(); a lazily-loaded executable will start up fine, and abort as soon as a symbol is hit that cannot be resolved; and a library would simply make its host program abort at the same way. Guess what’s safer?

With all these catches and issues, you can see why undefined symbols are a particularly nasty situation to deal with. To the best of my knowledge, there isn’t a real way to post-mortem an object to make sure that all its symbols are defined. I started writing support for that in Ruby-Elf but the results weren’t really… good. Lacking that, I’m not sure how we can proceed.

It would be possible to simply change the default to be --no-undefined, and work around with --undefined the few that require the undefined symbols to be there (we decided to proceed that way with Ruby); but given the kind of support I’ve received before in my drastic decisions, I don’t expect enough people to help me tackle that anytime soon — and I don’t have the material time to work on that, as you might guess.

So, after a take on Metacity , I just went ahead and implemented the same quick workspace switching feature for KDE (namely, kwin) – with great help from Nicolas Lécureuil (a.k.a. Neoclust) of course!

Basically, it works essentially like the same feature in xfwm4 – when you switch to a different workspace via a keyboard shortcut, and press the same shortcut again while on this workspace, it will bring you back to the previous one. So you can press ctrl-f2 to switch to from workspace 1 workspace 2, and when you press ctrl-f2 again kwin will recognize that you want switch back, to whatever workspace you were before, and will do it. An extremely handy quirk which I cannot live without anymore .

I have to assume that I have never ever coded anything for KDE until yesterday, but it turned out to be extremely simple. KDE has its flaws, its infrastructure with billions of libraries and processes everywhere is hard to understand, but I actually was surprised on how easy it was.

So, without further words, the patch for kdebase4-workspace which adds this functionality follows (sorry for the formatting, but kde has some very long lines of code..):

diff -p -up kdebase-workspace-4.5.65svn1165394/kwin/kcmkwin/kwindesktop/main.cpp.switchback kdebase-workspace-4.5.65svn1165394/kwin/kcmkwin/kwindesktop/main.cpp
--- kdebase-workspace-4.5.65svn1165394/kwin/kcmkwin/kwindesktop/main.cpp.switchback 2010-09-01 09:10:02.000000000 -0300
+++ kdebase-workspace-4.5.65svn1165394/kwin/kcmkwin/kwindesktop/main.cpp    2010-09-01 09:21:13.000000000 -0300
@@ -184,6 +184,7 @@ void KWinDesktopConfig::init()
     connect( m_ui->popupHideSpinBox, SIGNAL(valueChanged(int)), SLOT(changed()));
     connect( m_ui->desktopLayoutIndicatorCheckBox, SIGNAL(stateChanged(int)), SLOT(changed()));
     connect( m_ui->wrapAroundBox, SIGNAL(stateChanged(int)), SLOT(changed()));
+    connect( m_ui->switchBackBox, SIGNAL(stateChanged(int)), SLOT(changed()));
     connect( m_editor, SIGNAL(keyChange()), SLOT(changed()));
     connect( m_ui->allShortcutsCheckBox, SIGNAL(stateChanged(int)), SLOT(slotShowAllShortcuts()));
     connect( m_ui->effectComboBox, SIGNAL(currentIndexChanged(int)), SLOT(changed()));
@@ -252,6 +253,8 @@ void KWinDesktopConfig::defaults()

     m_ui->wrapAroundBox->setChecked( true );

+    m_ui->switchBackBox->setChecked( false );
+
     m_editor->allDefault();

     emit changed(true);
@@ -285,6 +288,9 @@ void KWinDesktopConfig::load()
     KConfigGroup windowConfig( m_config, "Windows" );
     m_ui->wrapAroundBox->setChecked( windowConfig.readEntry<bool>( "RollOverDesktops", true ) );

+    // Quick switching back to previous desktop
+    m_ui->switchBackBox->setChecked( windowConfig.readEntry<bool>( "SwitchBackDesktops", false ) );
+
     // Effect for desktop switching
     // Set current option to "none" if no plugin is activated.
     KConfigGroup effectconfig( m_config, "Plugins" );
@@ -341,6 +347,9 @@ void KWinDesktopConfig::save()
     // Wrap Around on screen edge
     KConfigGroup windowConfig( m_config, "Windows" );
     windowConfig.writeEntry( "RollOverDesktops", m_ui->wrapAroundBox->isChecked() );
+    //
+    // Quickly back to previous desktop
+    windowConfig.writeEntry( "SwitchBackDesktops", m_ui->switchBackBox->isChecked() );

     // Effect desktop switching
     KConfigGroup effectconfig( m_config, "Plugins" );
diff -p -up kdebase-workspace-4.5.65svn1165394/kwin/kcmkwin/kwindesktop/main.ui.switchback kdebase-workspace-4.5.65svn1165394/kwin/kcmkwin/kwindesktop/main.ui
--- kdebase-workspace-4.5.65svn1165394/kwin/kcmkwin/kwindesktop/main.ui.switchback  2010-09-01 09:09:59.000000000 -0300
+++ kdebase-workspace-4.5.65svn1165394/kwin/kcmkwin/kwindesktop/main.ui 2010-09-01 09:59:02.000000000 -0300
@@ -7,7 +7,7 @@
     <x>0</x>
     <y>0</y>
     <width>572</width>
-    <height>310</height>
+    <height>334</height>
    </rect>
   </property>
   <layout class="QHBoxLayout" name="horizontalLayout">
@@ -141,6 +141,16 @@
          </property>
         </widget>
        </item>
+       <item>
+        <widget class="QCheckBox" name="switchBackBox">
+         <property name="whatsThis">
+          <string>Enable this option if you want to remember and recall previous desktop when switching via keyboard shortcuts. E.g., if you switched to desktop 2 by pressing its shortcut, pressing it again while on desktop 2 will bring you back to the previous desktop.</string>
+         </property>
+         <property name="text">
+          <string>Remember and recall previous desktop when switching via keyboard shortcuts</string>
+         </property>
+        </widget>
+       </item>
        <item>
         <widget class="QGroupBox" name="groupBox_3">
          <property name="title">
diff -p -up kdebase-workspace-4.5.65svn1165394/kwin/kwin.kcfg.switchback kdebase-workspace-4.5.65svn1165394/kwin/kwin.kcfg
--- kdebase-workspace-4.5.65svn1165394/kwin/kwin.kcfg.switchback    2010-09-01 09:10:56.000000000 -0300
+++ kdebase-workspace-4.5.65svn1165394/kwin/kwin.kcfg   2010-09-01 09:16:20.000000000 -0300
@@ -41,6 +41,7 @@
   <entry key="ShadeHover" type="Bool" />
   <entry key="GeometryTip" type="Bool" />
   <entry key="RollOverDesktops" type="Bool" />
+  <entry key="SwitchBackDesktops" type="Bool" />
   <entry key="FocusStealingPreventionLevel" type="Int" />
   <entry key="Placement" type="String" />
   <entry key="AutoRaise" type="Bool" />
diff -p -up kdebase-workspace-4.5.65svn1165394/kwin/options.cpp.switchback kdebase-workspace-4.5.65svn1165394/kwin/options.cpp
--- kdebase-workspace-4.5.65svn1165394/kwin/options.cpp.switchback  2010-09-01 09:12:09.000000000 -0300
+++ kdebase-workspace-4.5.65svn1165394/kwin/options.cpp 2010-09-01 09:26:40.000000000 -0300
@@ -87,6 +87,8 @@ unsigned long Options::updateSettings()

     rollOverDesktops = config.readEntry("RollOverDesktops", true);

+    switchBackDesktops = config.readEntry("SwitchBackDesktops", false);
+
     legacyFullscreenSupport = config.readEntry( "LegacyFullscreenSupport", false );

 //    focusStealingPreventionLevel = config.readEntry( "FocusStealingPreventionLevel", 2 );
diff -p -up kdebase-workspace-4.5.65svn1165394/kwin/options.h.switchback kdebase-workspace-4.5.65svn1165394/kwin/options.h
--- kdebase-workspace-4.5.65svn1165394/kwin/options.h.switchback    2010-09-01 09:12:07.000000000 -0300
+++ kdebase-workspace-4.5.65svn1165394/kwin/options.h   2010-09-01 09:22:14.000000000 -0300
@@ -215,6 +215,11 @@ class Options : public KDecorationOption
          */
         bool rollOverDesktops;

+        /**
+         * whether or not quick switching back to previous desktop is allowed via keyboard shortcuts
+         */
+        bool switchBackDesktops;
+
         // 0 - 4 , see Workspace::allowClientActivation()
         int focusStealingPreventionLevel;

diff -p -up kdebase-workspace-4.5.65svn1165394/kwin/workspace.cpp.switchback kdebase-workspace-4.5.65svn1165394/kwin/workspace.cpp
--- kdebase-workspace-4.5.65svn1165394/kwin/workspace.cpp.switchback    2010-05-20 08:42:10.000000000 -0300
+++ kdebase-workspace-4.5.65svn1165394/kwin/workspace.cpp   2010-09-01 10:10:02.000000000 -0300
@@ -95,6 +95,7 @@ Workspace::Workspace( bool restore )
     , desktopGridSize_( 1, 2 ) // Default to two rows
     , desktopGrid_( new int[2] )
     , currentDesktop_( 0 )
+    , prevDesktop_( 0 )
     , desktopLayoutDynamicity_( false )
     , tilingEnabled_( false )
     // Unsorted
@@ -1403,6 +1404,15 @@ bool Workspace::setCurrentDesktop( int n
     StackingUpdatesBlocker blocker( this );

     int old_desktop = currentDesktop();
+
+    // Eugeni: are we trying to switch back to previous desktop?
+    if (options->switchBackDesktops && (old_desktop == new_desktop ) && (prevDesktop() > 0) )
+        {
+        // go back to previous desktop
+        new_desktop = prevDesktop();
+        kDebug(1212) << "Switching back to " << new_desktop;
+        }
+
     if (new_desktop != currentDesktop() )
         {
         ++block_showing_desktop;
@@ -1413,6 +1423,7 @@ bool Workspace::setCurrentDesktop( int n
         ObscuringWindows obs_wins;

         currentDesktop_ = new_desktop; // Change the desktop (so that Client::updateVisibility() works)
+        prevDesktop_ = old_desktop;

         for( ClientList::ConstIterator it = stacking_order.constBegin();
             it != stacking_order.constEnd();
diff -p -up kdebase-workspace-4.5.65svn1165394/kwin/workspace.h.switchback kdebase-workspace-4.5.65svn1165394/kwin/workspace.h
--- kdebase-workspace-4.5.65svn1165394/kwin/workspace.h.switchback  2010-08-11 07:08:13.000000000 -0300
+++ kdebase-workspace-4.5.65svn1165394/kwin/workspace.h 2010-08-31 23:34:01.000000000 -0300
@@ -245,6 +245,10 @@ class Workspace : public QObject, public
          */
         int currentDesktop() const;
         /**
+         * @returns The ID of the previous desktop.
+         */
+        int prevDesktop() const;
+        /**
          * Set the current desktop to @a current.
          * @returns True on success, false otherwise.
          */
@@ -314,6 +318,7 @@ class Workspace : public QObject, public
         QSize desktopGridSize_;
         int* desktopGrid_;
         int currentDesktop_;
+        int prevDesktop_;
         QString activity_;
         bool desktopLayoutDynamicity_;

@@ -1142,6 +1147,11 @@ inline int Workspace::currentDesktop() c
     return currentDesktop_;
     }

+inline int Workspace::prevDesktop() const
+    {
+    return prevDesktop_;
+    }
+
 inline int Workspace::desktopAtCoords( QPoint coords ) const
     {
     return desktopGrid_[coords.y() * desktopGridSize_.width() + coords.x()];

The title, by itself, is pretty obvious; I’m a geek, otherwise I wouldn’t be doing what I’m doing, even with the bile refluxes I end up having, just for the gratitude of a few dozens users (which I’ll thank once again from my heart; you make at least part of the insults I receive bearable). But it’s more a reminder for those who follow me since a long time ago, and who could remember that I started this blog over four years ago, using Rails 1.1 and a Gentoo/FreeBSD install.

Well, at the time my domain wasn’t “flameeyes.eu”, which I only bought two years ago but rather the more tongue-in-cheek Farragut.Flameeyes.Is-A-Geek.org where Farragut was the name of the box (which was contributed by Christoph Brill and served Gentoo/FreeBSD as main testing and stagebuilding box until PSU/MB gave up).

At any rate, I’ve been keeping the hostname, hoping one day to be able to totally phase it out and get rid of it; this because while at the start it was easy to keep it updated, DynDNS has been pressing more and more for free users to register for the “pro” version. Up to now, I’ve been just refreshing it whenever it was on the verge of expiring, but.. since the latest changes will not allow me to properly re-register the same hostname if it failed, and a lot of websites still link to my old addresses, I decided to avoid problems and scams, and I registered the hostname with DynDNS Pro, for two years, which means it won’t risk expiration.

Given that situation, I decided to change the Apache (and AWStats) configuration so that the old URLs for the blog and the site won’t redirect straight to the new sites, but rather accept the request and show the page normally. Obviously, I’d still prefer if the new canonical name is used. Hopefully, at some point in time, browsers and other software will support the extended metadata provided by OpenGraph which not only breaks down the title in site and page title (rather than the current mess of different separators between the two in the <title> element!), but also provides a “canonical URL” value that can solve the problem of multiple-hostnames as well (yes that means that if you were to link one post of mine on Facebook with the old URLs it’ll be automatically translated to the new, canonical URLs).

But it’s not all stopping here; for the spirit of old times, I also ended up looking at some of the articles I wrote around that time, or actually before that time, for NewsForge/Linux.com (as I said in my previous post noted). At the time, I wasn’t even paid for them, but the only requirement was a one year exclusive; last one was in December 2005, so the exclusive definitely expired a long time ago. So, since their own website (now only Linux.com, and changed owner as well) is degrading (broken links, comments with different text formatting functions, spam, …) I decided to re-publish them on my own website in the newly refurbished articles section and, wait for it…

I decided to re-license all three of the articles I wrote in 2005 under CreativeCommons Attribution-ShareAlike license.

Okay, nothing exceptional I guess, but given there was some doubts about my choices of licenses, this actually makes available a good chunk of my work under a totally free license. I could probably ask Jonathan whether I could do something like that to the articles I wrote for LWN, but since that site is still well maintained I see no urgency.

I should also be converting from PDF/TeX to HTML the rest of the articles on that index page, but they are also not high on my priority list.

Finally, I’m still waiting on FSF to give me an answer regarding the FSWS licensing — Matija helped me adapt the Autoconf exception into something usable for the web… unfortunately the license of the exception itself is quite strict, and so I had to ask FSF for permission of using that.. the request has been logged into their RT, I hope it’ll get me an answer soon… who knows, FSWS might be my last “gift” before I throw the towel.

The lives of distributions packagers are full of words that make them cringe – backport, regression, hotfix, custom patch, … – but there are two that can make your day truly shine: merged upstream.

When you’re maintaining a package for any kind of software, you have to mediate between the original upstream intentions and requests, and the distribution policy; in Gentoo, that policy includes respecting the user-chosen flags, especially since some of those are mandated by us and are needed to make sure that the software installed on the users’ systems is actually working as intended, but that’s just one of a long list of things you have to care about.

Most of the time, because of this, you have to end up patching the software itself: modifying the code so that it behaves like the distribution wants, even if that diverges from upstream behaviour, or in the best of cases, making it abide to both restrictions. Sometimes, you have to take a fix that has been already applied to the upstream repository, for instance in a development branch, and apply to the currently packaged version (backport). The least boring case is when users report a problem to you, that might or might not apply to other distributions, and you have to fix it anew.

When that’s the case, Gentoo’s guideline is to write patches so that they can be sent upstream (I also wrote about that — and I’m tempted to just re-publish my articles on my website rather than keep them there, especially given that the page is more broken each time I visit it). Unfortunately, some upstream are more difficult to work than others, plus sometimes the patches are really too Gentoo-specific that they make no sense to be sent upstream (for instance the S/Key patch for sudo, as it’s to support the Gentoo-specific port of OpenBSD’s S/Key support).

Now, as part of the Ruby team I’ve already written over and over about our need to patch a huge number of gems and other Ruby libraries, a lot of times simply to fix their Rakefile, less often to fix their tests… and in very rare occasions to hack or unhack the packages. Thankfully, these patches tend to be merged in quite quickly — I’m still not sure whether that’s due to the use of GitHub and of merge requests, or because releasing a Ruby gem is so quick and easy (which is a definite pro of RubyGems even for us packagers).

With other kind of software, the merge-and-release approach is not that common, but luckily there are exceptions; Robin Gareus has been terrific at merging my patches for liboauth and release a new version, which means that while I added it to the tree with three patches to be applied, you can get it now with no patch at all: vanilla 0.8.9!

Less quick to release, but that’s understandable considering the criticality of it, has been Linux-PAM; the newly released version, 1.1.2, which I added to the tree today, comes back to two patches, against the previous six of 1.1.1-r2. The remaining two are a bit tricky; one is something I’m keeping around since the 0.99 series, so a very long time ago, and is just a simple way for us to not build a bunch of test programs that we wouldn’t be using anyway; the other is a fix for the Berkeley DB detection in configure to work with the libraries are installed in Gentoo (with the prefix on the library name, but no prefix on the ELF symbols; we use versioning instead to avoid collisions between them). I’m now trying to find a compromise with Thorsten Kukuk (my upstream Linux-PAM contact) so that the patches can be applied, and we can stop patching it altogether.

Being able to ship packages that are not patched at all is important for many reasons, and at least one applies even to people who don’t use that package at all. Obviously, staying closer to upstream’s code is a positive thing because it means that you don’t risk that upstream counts your users out of support range (well, they can still do that if you are using non-default build options, but in general, it’s much easier for them to help you out if you don’t touch their code), but sending your own fixes to the original developers has another important result: the same fix is available to all the users of the program, not just those using your particular distribution. And finally, even people not using it will have a positive result, as long as they use Gentoo: less patch files in the tree means less files, and less overhead — and trust me, there is lots of overhead in the tree as it is right now, not sure if worse or better than what we had at the time I originally wrote that rundown, but it certainly needs some kind of proper solutions to be devised.

So I’m happy to thank for their merges Robin (liboauth), Thorsten (Linux-PAM), Karel (util-linux-ng), Cole (virt-inst), Thibault (fcron), Ludovic (ccid), … — the list goes a lot further, they are just the most recent upstreams I’ve exchanged email with!

On a side note; yes I picked up co-maintainership of bti with Greg; the reason is that I’ve been using it to dent the tinderbox results. I’ve also branched it upstream to cleanup a few things in the build system, and to implement one feature I’d very much like to use (--background); those fixes will come straight on 028 release, though, as they are not critical.

One of the nicest features of OpenRC/Baselayout 2 (that sooner or later will hit stable I’m sure) is that you can replace bash (which is slow, as its own documentation admits) with a faster, slimmer pure POSIX shell. Okay, so maybe Fedora is now moving away from shells altogether and I guess I can see why from some point of views; but as Nirbheek said it’s unlikely to be suitable for all use cases; in particular, our init system tends to work perfectly fine as is for servers and embedded systems, so … I don’t see the reason we should be switching there. Adding support for dash or any other POSIX sh-compatible fast shell is going to be a win-win situation there — do note that you still need bash to run ebuilds, though!

Now, you can use dash already for the basic init scripts provided by OpenRC and Baselayout, but all the packages need to install proper Posix SH-compatible init scripts if you want to use it with them. Thankfully a number of users seem to care about that, such as Davide last year and Kai right now.

But POSIX compatibility is not the only thing we should actually look out for in our init scripts:

• Eray pointed out that some scripts don’t re-create their /var/run subdirectories which is indeed a problem that should go fixed at some point; I had similar bad issues with running my own router based on Gentoo;
• one too often misused parameter of start-stop-daemon is --quiet which can be… way too quiet; if it’s passed, you’re not going to receive any output at all if the daemon you’ve tried to start fails; and that is a problem;
• there are problems with the way the system-services PAM chain is passed through so that limits are not respected (and if that’s the case, caps wouldn’t be respected coming from PAM either);
• the way LXC works, init scripts looking just at the process’s name could cause a guest’s daemon to stop if the host’s is closed… this is mostly exercised by killall but also start-stop-daemon when not given a pidfile (and rather just an executable) will have the same problem; and the same goes for pkill, goes without saying.

These are a number of polishing tasks that are by all count minors and not excessively important but… if you’ve free time and care about Gentoo on LXC, embedded or with fast startup, you might want to look into those. Just saying!

Such as lspci, lshw, discover is a hardware identification system based on the libdiscover2 library.
The available version for Debian lenny is the following one : 2.1.2-3

To install it :

root@localhost:~# apt-get install discover

It will install the following extra packages : discover-data libdiscover2

To use it, run the command /sbin/discover as root or with an user having sufficient privileges.
To get a summary of the devices found on the different buses :

root@localhost:~# discover -b

To make a search by device type :

root@localhost:~# discover -t network
Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet

More information : man discover
http://packages.debian.org/lenny/discover

If you want to perform  redirection of a command run by sudo, you will get the following error :

The file access permissions do not allow the specified action 0403-005 Cannot create the specified file

What does it mean?

Redirection is some kind of built-in features of your current running shell. (bash or ksh). When you issue a command with sudo, the built-in fonctions can not work within the child process.  To overcome this issue, the only workaround is to launch your command within a subshell :

sudo sh -c ‘your command > file.out’

The nice thing about standards is that you have so many to choose from.

Andrew S. Tanenbaum

The quote from Tanenbaum is a classic, something that most developers at some point in their career will have to face. But I’d like to expand on that; taking into consideration Open Standards as well. Most Free Software developers (and, argh, advocates!) will agree that Open Standards are a very good thing; make sure that they are fully documented, and let people develop royalty-free implementations, and you got a win.

Or do you? As the title of this post let you know, there is one further problem, with the standards to choose from: their implementation. I’ve already delved into a number of problems related to standards and their implementation; for instance the KWord vs OpenOffice problem, with the two using (at the time they started boasting OpenDocument support) two completely different, non-interoperable methods to define bullet-lists. And again with the inconsistent SVG implementations that cause the same file to appear in vastly different ways, without even an error reported, with multiple software.

And eBooks are nothing different either; let’s leave alone the problem with formatting them (for instance, O’Reilly books are easily readable, but are actually formatting “randomly” for me, compared to others; or The Dragon Reborn which probably underwent an OCR pass, given that Thom sometimes became Torn). I’ve already ranted about DTBook ebooks but this time I’m seriously pissed.

Let me explain again the whole DTBook problem first, because it provides a basic context for the trouble that follows right now. I have a PRS-505 Sony Reader; when I bought it, it only supported PDFs (sort-of) and Sony’s own BBeB/LRF format. Thankfully, Sony updated the firmware to add support for the ePub format, which is supposedly an open standard and should have a number of working implementations, on various operating systems and hardware devices. Apple’s iPad among others is supposed to read ePub files. So what’s the catch?

Well, first of all, since I called in Apple’s iPad, there is the problem of DRM; ePub by itself does not really define a DRM scheme; O’Reilly does not use any DRM in their electronic media (bless them), and Apple does not support DRM-locked ePub files either (and as far as I know they provide no DRM for their files either, but I don’t have a device to test it myself). On the other hand, most online bookstores, and the devices such as the Sony Reader or Kobo’s eReader, support Adobe’s DRM scheme, technically called ADEPT, but marketed as “Adobe Digital Editions”. Of course, as far as I know at least, there is no open source software that can deal with ADEPT-locked files, although there is code out there that allows you to unlock the files once you fetch your personal encryption key out of an enabled system.

Okay, let’s leave DRM out now, and speak about the format itself; ePub files are ZIP files, not tremendously different from an OpenDocument file.. it actually comes with the same META-INF directory and mimetype file. Within that, you have a series of XML files, with the metadata of the book, the Table of Contents, a filename for the cover file, and the list of files with the actual book’s content. A note here: at least The Dragon Reborn seems to be a corrupted ZIP files for both unzip and the inept script, but is read fine by the Reader Library, and by the the Reader itself.

The content files can be of different formats; the most common case is (X)HTML; which as you might expect is the easiest to support, given the wide range of software rendering HTML out there. But a different format, called DTBook, was designed to support text-to-speech reading of audiobooks. Files can easily be called ePub, even though the actual content is in DTBook, and not supported by most devices and software; neither the Reader nor Calibre support that format, and can’t thus read the copy I bought of The Salmon of Doubt (sigh!).

Something even stranger happened when I bought (with a $2 discount, as this time it worked) Sourcery by Terry Pratchett … I started the series a year or two ago, but rather than getting the books, at the time I got the audiobooks version to get some sleep (I’m still doing the same thing, over an year and a half later… whenever I don’t have my iPod on during the night, I wake up feeling worse than when I went to sleep, because of bad nightmares…).. Sourcery is the only one that I haven’t been able to listen in its entirety since I started (well, I also didn’t listen to Mort and rather read it as eBook already). Unfortunately the downloaded ePub, even though not resulting corrupt for what unzip is concerned, cannot be viewed on the Reader, just like the DTBook version it reports a “Page error”, shows no Table of Content, lists a start and end page of 1.

After un-locking the file with inept; I could load it on Calibre and.. it actually reads fine. So the file is a valid ePub book, why on earth would the Reader not read it at all? Not something I can answer without having access to the sources obviously. Luckily, at least this time I can read my book, since Calibre could process it and create a new ePub copy that the Reader actually seem to load and read.

Alas. I really have nothing else I could possibly say.