Tuesday, November 23rd, 2010, 12:51 pm
My First Major Disappointment in Fedora (Updated)
Filed under: 
BOUT three weeks ago I decided to go back to working with Fedora. This distribution served me well over the years, especially in distributed clusters. Fedora 14 looked very promising and it still is, but there are creases that are hard to undo and to hide. In order for matters to improve I will post a quick rant and hope that someone, somewhere will help address the issue that I’ve already reported (I also submit bug reports whenever that’s possible).
My main problem is package specific. The problem was first mentioned here. Thanks to a blog comment from Rahul I was made aware of fairly trustworthy repositories where packagers offer alternative packages. I soon found this newer build of Octave (needed to manually uninstall the existing one as it does not support updating existing packages). It is one of those unsigned packages, which require the user to jump through some hoops. The changelog looked promising because the latest entry mentioned exactly the bug that I was suffering from (many other people must be suffering from it too):
* Sun Feb 28 2010 Alex Lancaster <alexlan[AT]fedoraproject org> – 6:3.2.4-3
- Temporarily disable %check to enable build to complete and ensure upgrade path works. This works around a crash in the imread.m image test script, this may be the same problem as described by upstream here:https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2010-January/014891.html
So, here goes:
[root@blueberry roy]# yum remove octave Loaded plugins: langpacks, presto, refresh-packagekit Adding en_US to language list Setting up Remove Process Resolving Dependencies --> Running transaction check ---> Package octave.i686 6:3.2.4-3.fc14 set to be erased --> Processing Dependency: libcruft.so for package: pfstools-octave-1.8.1-1.fc14.2.i686 --> Processing Dependency: libcruft.so for package: octave-forge-20090607-17.fc14.i686 --> Processing Dependency: liboctave.so for package: octave-forge-20090607-17.fc14.i686 --> Processing Dependency: liboctave.so for package: pfstools-octave-1.8.1-1.fc14.2.i686 --> Processing Dependency: liboctave.so for package: plplot-octave-5.9.6-5.fc14.i686 --> Processing Dependency: liboctinterp.so for package: octave-forge-20090607-17.fc14.i686 --> Processing Dependency: liboctinterp.so for package: pfstools-octave-1.8.1-1.fc14.2.i686 --> Processing Dependency: liboctinterp.so for package: plplot-octave-5.9.6-5.fc14.i686 --> Processing Dependency: octave(api) = api-v37 for package: octave-forge-20090607-17.fc14.i686 --> Processing Dependency: octave(api) = api-v37 for package: plplot-octave-5.9.6-5.fc14.i686 --> Processing Dependency: octave >= 3.2.0 for package: qtoctave-0.9.1-2.fc14.i686 --> Processing Dependency: octave for package: plplot-octave-5.9.6-5.fc14.i686 --> Processing Dependency: octave = 6:3.2.4-3.fc14 for package: 6:octave-devel-3.2.4-3.fc14.i686 --> Running transaction check ---> Package octave-devel.i686 6:3.2.4-3.fc14 set to be erased ---> Package octave-forge.i686 0:20090607-17.fc14 set to be erased ---> Package pfstools-octave.i686 0:1.8.1-1.fc14.2 set to be erased ---> Package plplot-octave.i686 0:5.9.6-5.fc14 set to be erased ---> Package qtoctave.i686 0:0.9.1-2.fc14 set to be erased --> Finished Dependency Resolution Dependencies Resolved ======================================================================================================= Package Arch Version Repository Size ======================================================================================================= Removing: octave i686 6:3.2.4-3.fc14 @fedora 32 M Removing for dependencies: octave-devel i686 6:3.2.4-3.fc14 @fedora 2.5 M octave-forge i686 20090607-17.fc14 @fedora 39 M pfstools-octave i686 1.8.1-1.fc14.2 @fedora 254 k plplot-octave i686 5.9.6-5.fc14 @fedora 1.3 M qtoctave i686 0.9.1-2.fc14 @fedora 2.9 M Transaction Summary ======================================================================================================= Remove 6 Package(s) Installed size: 78 M Is this ok [y/N]: y Downloading Packages: Running rpm_check_debug Running Transaction Test Transaction Test Succeeded Running Transaction Erasing : pfstools-octave-1.8.1-1.fc14.2.i686 1/6 Erasing : qtoctave-0.9.1-2.fc14.i686 2/6 Erasing : octave-forge-20090607-17.fc14.i686 3/6 Erasing : plplot-octave-5.9.6-5.fc14.i686 4/6 Erasing : 6:octave-devel-3.2.4-3.fc14.i686 5/6 Erasing : 6:octave-3.2.4-3.fc14.i686 6/6 Removed: octave.i686 6:3.2.4-3.fc14 Dependency Removed: octave-devel.i686 6:3.2.4-3.fc14 octave-forge.i686 0:20090607-17.fc14 pfstools-octave.i686 0:1.8.1-1.fc14.2 plplot-octave.i686 0:5.9.6-5.fc14 qtoctave.i686 0:0.9.1-2.fc14 Complete!
This can be done from the GUI as well. But it’s not working. The bug still exists and prevails after the new package gets installed. To make matters worse, for some reason, yum just disallows installing unsigned packages. It does not even produce a warning with an opt-out/force option. It’s very stubborn, so I had to use the GUI. Then, running the program (the new build) showed that:
octave:4> imshow('Konqueror.jpg')
octave: magick/semaphore.c:525: LockSemaphoreInfo: Assertion `semaphore_info != (SemaphoreInfo *) ((void *)0)' failed.
panic: Aborted -- stopping myself...
Aborted (core dumped)
[root@blueberry roy]# qtoctave
[main()] Error loading the QT Translation file for locale 'en_US'.
[main()] Error loading the translation file for locale 'en_US'. Not found in /usr/share/qtoctave/lang
[Main::Main] Building commands list.
[Main::Main] Commands list builded.
QWidget::setMinimumSize: (/QMdi::ControlLabel) Negative sizes (-1,-1) are not possible
[OctaveConnection::startOctave] Octave path: octave
[OctaveConnection::startOctave] Octave version: 3.2.4 (3.2.4)
[OctaveConnection::startOctave] Starting octave: "octave" --eval "PS1('octave:\#>');PS2('octave:\#+>');addpath('/usr/share/qtoctave/scripts_octave/')" --persist --no-history -i
[OctaveConnection::startOctave] Octave running
klauncher(2168) kdemain: No DBUS session-bus found. Check if you have started the DBUS server.
kdeinit4: Communication error with launcher. Exiting!
Segmentation fault (core dumped)
Oh, wonderful. Well, eventually I found a way to run qtoctave again. Checking the version/build names again:
[root@blueberry roy]# yum remove octave Loaded plugins: langpacks, presto, refresh-packagekit Adding en_US to language list Setting up Remove Process Resolving Dependencies --> Running transaction check ---> Package octave.i686 6:3.2.4-3.el6 set to be erased --> Processing Dependency: octave >= 3.2.0 for package: qtoctave-0.9.1-2.fc14.i686 --> Processing Dependency: octave = 6:3.2.4-3.el6 for package: 6:octave-devel-3.2.4-3.el6.i686 --> Running transaction check ---> Package octave-devel.i686 6:3.2.4-3.el6 set to be erased ---> Package qtoctave.i686 0:0.9.1-2.fc14 set to be erased --> Finished Dependency Resolution Dependencies Resolved ======================================================================================================= Package Arch Version Repository Size ======================================================================================================= Removing: octave i686 6:3.2.4-3.el6 @/2067.0.octave-3.2.4-3.el6.i686 32 M Removing for dependencies: octave-devel i686 6:3.2.4-3.el6 @/2220.0.octave-devel-3.2.4-3.el6.i686 2.5 M qtoctave i686 0.9.1-2.fc14 @fedora 2.9 M Transaction Summary ======================================================================================================= Remove 3 Package(s) Installed size: 37 M
Yes, even octave-3.2.4-3.el6.i686 has this same bug, so what gives? In Kubuntu 10.04 there is no such problem, not in the packaged version of Octave. Having to go through less official routes to unsigned packages is daunting enough for most people; finding out that it still does not work is even a lot worse. The problem here is not really Fedora but lack of coordination between octave and the magick folks. qtoctave handles this admirably well by restarting octave and not just letting the entire program crash. But still, having wasted several hours on this first looking for bugs in my code and then playing with packages rather than doing research (realising that my code was not the problem), I am left a bit bitter about my Fedora 14 experience. It is not as though I have been too lazy trying to resolve this and for the time being it seems like I will do more of my work on my Kubuntu box. It happens to have done packaging of Octave more successfully (at least that older version).
Update: not even stepping back to older versions of ImageMagic has worked and yum had the same limitations because the packages were unsigned.
[root@blueberry roy]# yum remove ImageMagick Loaded plugins: langpacks, presto, refresh-packagekit Adding en_US to language list Setting up Remove Process Resolving Dependencies --> Running transaction check ---> Package ImageMagick.i686 0:6.6.4.1-14.fc14.1 set to be erased --> Finished Dependency Resolution Dependencies Resolved ======================================================================================================= Package Arch Version Repository Size ======================================================================================================= Removing: ImageMagick i686 6.6.4.1-14.fc14.1 @fedora 6.5 M Transaction Summary ======================================================================================================= Remove 1 Package(s) Installed size: 6.5 M Is this ok [y/N]: y Downloading Packages: Running rpm_check_debug Running Transaction Test Transaction Test Succeeded Running Transaction Erasing : ImageMagick-6.6.4.1-14.fc14.1.i686 1/1 Removed: ImageMagick.i686 0:6.6.4.1-14.fc14.1 Complete!
Then installing the older version via the GUI. Still the same issue.
[root@blueberry roy]# yum remove ImageMagick Loaded plugins: langpacks, presto, refresh-packagekit Adding en_US to language list Setting up Remove Process Resolving Dependencies --> Running transaction check ---> Package ImageMagick.i686 0:6.6.0.2-8.fc14 set to be erased --> Finished Dependency Resolution Dependencies Resolved ======================================================================================================= Package Arch Version Repository Size ======================================================================================================= Removing: ImageMagick i686 6.6.0.2-8.fc14 @/2494.0.ImageMagick-6.6.0.2-8.fc14.i686 6.3 M Transaction Summary ======================================================================================================= Remove 1 Package(s) Installed size: 6.3 M Is this ok [y/N]: n Exiting on user Command Complete! [root@blueberry roy]# octave GNU Octave, version 3.2.4 Copyright (C) 2009 John W. Eaton and others. This is free software; see the source code for copying conditions. There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. For details, type `warranty'. Octave was configured for "i386-redhat-linux-gnu". Additional information about Octave is available at http://www.octave.org. Please contribute if you find this software useful. For more information, visit http://www.octave.org/help-wanted.html Report bugs to(but first, please read http://www.octave.org/bugs.html to learn how to write a helpful report). For information about changes from previous versions, type `news'. octave:1> imshow('in') octave: magick/semaphore.c:525: LockSemaphoreInfo: Assertion `semaphore_info != (SemaphoreInfo *) ((void *)0)' failed. panic: Aborted -- stopping myself... Aborted (core dumped)
I’m giving up. Maybe I just need to go to far older versions for compatibility, but I tried the oldest ones built for Fedora 14.
November 24th, 2010 at 4:11 am
It’s hard to beat Debian package management. Sometimes you might need an “old libs” package for compatibility.
If you need to run old versions of software, why don’t you do it in a VM with a stable version that used to run it?
November 26th, 2010 at 9:54 am
That’s why I do it with Kubuntu for the time being.