Ask Your Question

dmalcolm's profile - activity

2012-11-04 10:36:56 -0500 received badge  Critic (source)
2012-11-02 10:07:40 -0500 answered a question Yum problem

Judging by the error message, it looks like you have a custom build of Python 2.6 in your $PATH. The system copy of yum (/usr/bin/yum) assumes it will be run with the system copy of python /usr/bin/python), and since Fedora 14, the system copy of Python has been Python 2.7

You can run:

which python

to see which version of Python is in the $PATH

As a workaround, you can explicitly invoke yum with the system python like this:

/usr/bin/python /usr/bin/yum

followed by any yum commands, all on one line

2012-10-23 21:47:29 -0500 commented question How to build an USB driver and data extractor (Magnetic Card Reader)? [Python, Ruby]

FWIW it sounds like the card reader is already functioning as a USB Keyboard: when you swipe, it's effectively "typing" the data from the card, and that's why those characters appear in the text editor. So it sounds like you need some way of decoding that data.

2012-10-18 10:13:11 -0500 answered a question libstdc++ source code

The easiest way to see the source code that you're actually running from is to install the relevant debuginfo package, via debuginfo-install (part of the yum-utils package).

"strcpy" is actually implemented as part of glibc

# debuginfo-install glibc

Then look below /usr/src/debug.

strcpy is something of a special case. Given how commonly it occurs, it's a prime target for optimization. Looking at this on my F17 machine I see that the header files that declare strcpy also have a tangled web of preprocessor macros cases that can turn a call to strcpy into a more specialized function, depending on whether the source string is a string-literal of known size, and, if so, the length of that string.

To make things even more convoluted, note that strcpy is a prime target for compiler optimization, and that at any given callsite of strcpy the compiler might not have generated machine code that calls strcpy if it thinks it can do things faster. For example, looking at the sources of gcc on my F17 machine, I see in gcc/builtins.c:expand_builtin_strcpy that if gcc sees a "strcpy" call it can instead generate a movstr instruction when targetting CPUs that support it.

So it's worth invoking the compiler with -E to see the preprocessed output, and disassembling the generated machine code to see if strcpy is actually being called (e.g. by stepping through it in gdb and using the disassemble command within the function of interest).

2012-10-15 13:08:17 -0500 commented question libvirt does not show all interfaces

FWIW it looks like you have a typo in your sample code: libConnect.listInterfaces should read libConnect.listInterfaces()

2012-10-12 14:19:26 -0500 answered a question Packaging RPM where SOURCE0 basename != source archive name.

Where exactly does rpmbuild complain?

I'm not sure if I'm reading your question correctly, but it sounds like you might be running into a common "gotcha" with the %setup macro.

By default %setup assumes that the top-level directory within the source tarball is the "Name-Version" of the package, for example "subversion-1.6.18". If the "Name" attribute of the package is non-standard (e.g. "subversion16"), this macro's default will get confused and erroneously look for a directory called e.g. subversion16-1.6.18 (note that extra "16")

The way to fix it is to pass the "-n" parameter to %setup, for something like this:

%setup -n subversion-%{version}

See for more information

Hope this is helpful

2012-10-10 14:48:29 -0500 answered a question where to find kernel-devel-2.6.18-1.2869.fc6 ?

FWIW I tried looking in Koji for you, with this search:

Unfortunately it finds no results.

2012-10-09 09:55:46 -0500 answered a question /usr/libexec/gconfd-2 requires an additional plugin to decode this file

I'm not familiar with the given error message, but I did some detective work to try to track this down. In the hope that it's useful to others, here's what I did.

First I used "find" and "grep" to try to locate error message within the packaged string files on my Fedora box:

find /usr/share/locale -exec grep "requires an additional plugin to decode this file" {} +

The results of the above showed that /usr/share/locale/en_GB/LC_MESSAGES/ and many other .mo files for other locales contain this string:

%s requires an additional plugin to decode this file


rpm -qf /usr/share/locale/en_GB/LC_MESSAGES/

shows that these files are part of the "gnome-packagekit" rpm (on my machine it's gnome-packagekit-3.4.2-1.fc17.x86_64), so presumably this is a format string that gnome-packagekit uses to build error messages. (note that it's not the exact string you saw, the "%s" is used at run-time to substitute another string fragment - in this case "/usr/libexec/gconfd-2"

Looking at "rpm -qi gnome-packagekit" on my box shows that the SourceRPM field is "gnome-packagekit-3.4.2-1.fc17.src.rpm", confirming that the "gnome-packagekit" RPM is built from a source rpm named "gnome-packagekit".

Grabbing the sources via:

[david@surprise dist-git-fedora]$ fedpkg clone gnome-packagekit
Cloning into 'gnome-packagekit'...
remote: Counting objects: 1228, done.
remote: Compressing objects: 100% (803/803), done.
remote: Total 1228 (delta 441), reused 971 (delta 333)
Receiving objects: 100% (1228/1228), 204.87 KiB, done.
Resolving deltas: 100% (441/441), done.

[david@surprise dist-git-fedora]$ cd gnome-packagekit/

[david@surprise gnome-packagekit]$ fedpkg prep
Downloading gnome-packagekit-3.6.0.tar.xz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 4185k  100 4185k    0     0  1516k      0  0:00:02  0:00:02 --:--:-- 1577k
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.C5u9jX
+ umask 022
+ cd /home/david/coding/dist-git-fedora/gnome-packagekit
+ export LANG
+ unset DISPLAY
+ cd /home/david/coding/dist-git-fedora/gnome-packagekit
+ rm -rf gnome-packagekit-3.6.0
+ /usr/bin/xz -dc /home/david/coding/dist-git-fedora/gnome-packagekit/gnome-packagekit-3.6.0.tar.xz
+ /usr/bin/tar -xf -
+ '[' 0 -ne 0 ']'
+ cd gnome-packagekit-3.6.0
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ exit 0

[david@surprise dist-git-fedora]$ cd gnome-packagekit-3.6.0/

Looking for the error message with grep within the source tree via:

[david@surprise gnome-packagekit-3.6.0]$ grep -nrH "requires an additional plugin to decode this file" *

shows numerous copies within the "po" subdirectory (in theory, translations for different languages, though clearly in this case it hasn't been translated), along with the place where it actually gets used:

src/gpk-dbus-task.c:1563:           title = g_strdup_printf (ngettext ("%s requires an additional plugin to decode this file",
src/gpk-dbus-task.c:1577:           title = g_strdup (ngettext ("A program requires an additional plugin to decode this file",

Running the source through "cat" to get lines numbers:

 [david@surprise gnome-packagekit-3.6.0]$ cat -n src/gpk-dbus-task.c | less

and using "/" in less to ... (more)

2012-10-08 15:36:17 -0500 commented answer Can I write a GUI program in the C language in Fedora?

Looks like the title got edited to refer specifically to a GUI program after I posted this.

2012-10-08 13:54:54 -0500 received badge  Supporter (source)
2012-10-08 13:51:09 -0500 answered a question WoW 5.0 10-15 fps

This may be too advanced, but you could try using oprofile to analyze your system as the program is running. It can give you a report on where the time goes, which perhaps may give ideas on how to tweak things, or, at least, create a better bug report for the driver maintainers...

Install oprofile using:

# yum install oprofile

As root, start a profiling session using:

# opcontrol --start

Then launch your program as normal (not as root!).

After a while of the activity you're trying to analyze, stop the profiling session (as root) using:

# opcontrol --stop

You should then be able to generate a report using:

# opreport --symbols |less

which will show every process that was running, how much time each one took.

Some time will be spent by the program you're running, some by the X server. You can zero in on the program in question by passing the path to it e.g.:

# opreport --symbols /usr/bin/wine |less

to see what a specific process was spending its time on. You'll want the debuginfo packages installed for wine and for the X server. See for some examples of the kind of output you'll see.

This may give clues as to whether the issue is in terms of the number of polygons being drawn, or the number of pixels, or the complexity of the shaders, or some other unexpected issue, and whether or not it's actually managing to use the GPU, or whether the CPU is having to do the work instead. However, to figure all of this out will likely require knowledge of 3D programming. It should at least make for a better bug report...

Hope this is helpful

2012-10-08 13:24:42 -0500 answered a question pygobject make error

It looks like you've got a mismatch between gobject-introspection and pygobject.

The relevant enum values GI_INFO_TYPE_ERROR_DOMAIN etc that were in gobject-introspection were removed in but the version of pygobject you're building still uses them, hence the compilation errors.

The changelog for pygobject 2.90.1 at includes:

    - remove references to deprecated GI_INFO_TYPE_ERROR_DOMAIN (John (J5) Palmieri)

so if you're still attempting this, it looks like you'll want that version or later.

Hope this is helpful

2012-10-08 13:10:07 -0500 answered a question Can't run Python3 IDLE in Fedora 16

Which version of python3-tools were you using?

Note that "python" in Fedora means Python 2; running

python /usr/lib/python3.2/idlelib/

is erroneous, since it's attempting to run Python 3 code with the Python 2 interpreter. There are enough differences between the versions of Python that there's no guarantee that that Python 3 script is even syntactically valid Python 2 code.

To run IDLE for Python 3, python3-tools provides a /usr/bin/idle3.2 for Python 3.2 (or 3.3 for Fedora 18 onwards). This has the content:


from idlelib.PyShell import main
if __name__ == '__main__':

though you shouldn't need to know that; it's packaged as part of the rpm.

So you should simply run:

$ idle3.2

and it should have just worked.

Should there be a "/usr/bin/idle3" as well?

Hope this is helpful

2012-10-08 12:40:13 -0500 answered a question Can I write a GUI program in the C language in Fedora?

A "graphics program" could cover many different things.

If you're interested in learning graphics programming in C on Fedora, a good place to start might be the Cairo tutorial:

Cairo is the 2D API that underpins the GTK stack, and the principles are applicable to many other graphical APIs, so it's worth a look if you want to learn graphical programming.


yum install cairo-devel gcc

on a Fedora box should give you the dependencies you need to run the demo.

Hope this is helpful

2012-10-05 23:46:06 -0500 received badge  Enlightened (source)
2012-10-05 13:31:55 -0500 received badge  Good Answer (source)
2012-10-05 11:08:43 -0500 received badge  Nice Answer (source)
2012-10-05 10:11:00 -0500 received badge  Teacher (source)
2012-10-05 10:11:00 -0500 received badge  Necromancer (source)
2012-10-05 09:49:20 -0500 received badge  Editor (source)
2012-10-05 09:48:27 -0500 answered a question What is the best way to compile a python program with many old dependencies?

Are these libraries C and C++? Many libraries (such as those that use autoconf) respect setting "prefix" at configure-time, so if you do something like:

mkdir ~/my-installation-root/
cd unpacked-sources-of-library
./configure --prefix=~/my-installation-root/
make install

then the "make install" phase will copy the built files into a directory structure below ~/my-installation-root/ and not affect the "system" copies below /usr

You can then set PATH and LD_LIBRARY_PATH accordingly to find them.

2012-10-05 09:28:56 -0500 answered a question Fedora 18/python 3.3

Yes - the "python3" stack will be 3.3 as of Fedora 18 onwards.

See for more information.