a wily blog

Background:
I had been running Fedora 12 on my home server with a 5-year old CPU and Nvidia video card. Last weekend, I decided to modernize with fancy new hardware, an Intel G6950 dual-core with integrated graphics. This is great, but Fedora 12 has graphics drivers that like to crash with Intel integrated graphics hardware, so once I changed the hardware, my desktop would freeze, about 30 seconds after logging in. So I decided to upgrade to Fedora 13.

The generally recommended way to upgrade on Fedora is to use the preupgrade tool, which would be nice, graphical, and great if my graphical desktop didn’t crash (and if it didn’t, I’d be sticking with F12 for now). So the alternative is supposed to be “preupgrade-cli”. This would work, because I could boot and do a console (non-graphical) login, so the video driver couldn’t muck things up (as easily?).

Problem: preupgrade-cli doesn’t work in Fedora 12.
(Okay, maybe it will for you, because you have executive platinum status with Fedora.) I got this error, which is pasted below:
# preupgrade-cli
Loaded plugins: blacklist, dellsysidplugin2, priorities, versionlock, whiteout
No plugin match for: rpm-warm-cache
No plugin match for: auto-update-debuginfo
No plugin match for: refresh-packagekit
No plugin match for: presto
Traceback (most recent call last):
File "/usr/share/preupgrade/preupgrade-cli.py", line 316, in
pu = PreUpgradeCli()
File "/usr/share/preupgrade/preupgrade-cli.py", line 52, in __init__
PreUpgrade.__init__(self)
File "/usr/lib/python2.6/site-packages/preupgrade/__init__.py", line 80, in __init__
self._getConfig()
File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 282, in _getConfig
startupconf.pluginconfpath,disabled_plugins,enabled_plugins)
File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 465, in doPluginSetup
plugin_types, confpath, disabled_plugins, enabled_plugins)
File "/usr/lib/python2.6/site-packages/yum/plugins.py", line 160, in __init__
self.run('config')
File "/usr/lib/python2.6/site-packages/yum/plugins.py", line 177, in run
func(conduitcls(self, self.base, conf, **kwargs))
File "/usr/lib/yum-plugins/versionlock.py", line 153, in config_hook
conduit.registerCommand(VersionLockCommand())
File "/usr/lib/python2.6/site-packages/yum/plugins.py", line 499, in registerCommand
self._base.registerCommand(command)
File "/usr/share/yum-cli/cli.py", line 106, in registerCommand
if name in self.yum_cli_commands:
AttributeError: 'PreUpgradeCli' object has no attribute 'yum_cli_commands'

Apparently the anonymous poster at the How to Upgrade page had the same problem. Perhaps we are the only two to bother with the “arcane” command-line preupgrade tool. I am curious as to whether anyone (at all) succeeded with preupgrade-cli for Fedora 12 to Fedora 13.

Solution: Patch preupgrade-cli.py. If you don’t have experience writing code on Linux, this is probably not for you. But it’s pretty straightforward. You need to change the definition of the PreUpgradeCli class so that it self.yum_cli_commands is valid. Do this by replacing the line:

class PreUpgradeCli(PreUpgrade, YumUtilBase):

with

class PreUpgradeCli(PreUpgrade, YumUtilBase, YumBaseCli):

so that it inherits from a class with such an attribute and insert this line:

        YumBaseCli.__init__(self)

as the first line of the initializer, below

    def __init__(self):

and before

        PreUpgrade.__init__(self)

so that the parent class's initializer gets called and self.yum_cli_commands gets populated. The file is found at /usr/share/preupgrade/preupgrade-cli.py

Remember, this is Python, so line indentation is important. There you go. preupgrade-cli should work as normal now.

Note: I don't know whether this is the Right Way To Fix It, but it seemed reasonable to me, and I got the result I wanted. I will probably point the developer of preupgrade-cli.py to this page so he/she can compose a better fix.

I’m sure these things are obvious to seasoned Solaris developers, but here are a few things I’ve learned today:

• gcc 3.4.3 does not support threads on Solaris. The “-pthread” option doesn’t exist for Solaris except in later versions, so upgrade your compiler or use the Sun compiler (where you’ll use “-mt” to request threaded code).
• scons on Solaris assumes you are using a Sun compiler and applies flags as such, even when you’re using gcc. Yes, even if it detects and uses gcc. See the note about “-KPIC” in the scons changelog.
• boost doesn’t really compile on Solaris with Sun C++ 5.8, but you can hack stuff to make it sorta work.
  This relates to boost 1.40.0. There are two main issues:
  • int64_t and friends don’t get defined. You’ll have to patch cstdint.hpp. Here’s my hacked replacement.
  • The Sun compiler doesn’t do return object optimization, which means that code like:
    
    class Foo {
    private:
    Foo(Foo& f);
    public:
    explicit Foo(int i);
    };

    Foo bar(int x) {
return Foo(x);
}

    doesn’t work. The call to Foo(x) works fine, but the compiler thinks you need to copy the resulting Foo object in the act of returning it to the caller, which is commonly optimized out these days. Here’s a replacement for the affected boost/thread/detail/thread.hpp. Of course boost 1.41 doesn’t have the same problem since the return type for the affected function is different.

For reference, a couple of illustrative error messages:

• int64_t problem:
  
"/home/daniel/boost_1_40_0/boostdir/include/boost/date_time/time_duration.hpp", line 264: Error: int64_t is not a member of boost.
"/home/daniel/boost_1_40_0/boostdir/include/boost/date_time/time_resolution_traits.hpp", line 48: Error: int64_t is not a member of boost.

• Return value optimization problem:
  
"/home/daniel/boost_1_40_0/boostdir/include/boost/thread/detail/thread.hpp", line 344: Error: boost::thread::thread(boost::thread&) is not accessible from boost::move(boost::detail::thread_move_t).


---

I’m sure that most of my audience will find this incomprehensible, but I have high hopes that Google will index this properly and find it for a poor head-scratching soul with similar frustrations.

Have a nice day!

I was very, very annoyed that the 0.10 release of nautilus-open-terminal changed the accelerator from “t” to “e”, meaning that I could no longer right-click on my gnome desktop and press “t”.

Rather than unlearn years of muscle memory and learn to press “e” instead, I built my own version that reverts the change.

Here’s the fixed SRPM and RPM for Fedora 11 i586:
source: nautilus-open-terminal-0.13-2ac.fc11.src.rpm
binary: nautilus-open-terminal-0.13-2ac.fc11.i586.rpm

I know, the accelerator got changed to fix some bug that was filed against Ubuntu, but I don’t use “New Tab” (nor can I find it anywhere in nautilus). So I achieved victory by getting the source, changing a few lines, and rebuilding, since this is open source. Hooray!

Have a nice day.

(footnote: The problematic change was noted as: ‘Change “Open in Terminal” accelerator to “e”, for not conflicting with “New Tab”‘)

Update:
Versions for Fedora 12 (beta right now):
RPM: nautilus-open-terminal-0.17-4ac.fc12.i686.rpm
SRPM: nautilus-open-terminal-0.17-4ac.fc12.src.rpm

Although dovecot comes with its own full-text indexed search, it doesn’t seem to be enabled by default, at least in Fedora 10.  This is a shame.  For me, it makes a search for body text take a few seconds rather than a couple minutes.

To fix, modify your /etc/dovecot.conf and restart dovecot.

• Add fts and fts_squat to the mail_plugins line in your protocol section (protocol imap for me).

Specifically, look for:

protocol imap {
...
#mail_plugins =
...
}

and change it to look more like:

protocol imap {
...
mail_plugins = fts fts_squat
...
}

• Add fts = squat to the plugins section.

plugins {
...
fts = squat
...
}

Sadly, there was no Ubuntu help forum thread that made all this blindingly obvious, so I hope this post fills that need. This all worked on Fedora 10 with dovecot 1.1.10.

Have a nice day.