MacLochlainns Weblog

Michael McLaughlin's Technical Blog

Site Admin

Gnome Menu Editing Fix

with 35 comments

Fedora 16 is clearly better than Fedora 15 but I found Menu Editing (Alacarte package) was broken in it because of a missing library dependency, and I’ve updated Fedora Bug 734442 with the work around. Here’s what’s wrong and how to fix it.

Update on Status of Bug 734442

The GNOME Desktop Bug 626220 is the one that will permanently fix this problem. It appears that the GNOME Desktop left all symbols in that point to the PyGTK library when they should have migrated to the dynamic Python bindings in the PyGObject project.

Download Site Change

It appears you can no longer download the packages from http://download.fedora.redhat.com. You must go the Fedora project web site http://archive.fedoraproject.org/pub/fedora/linux. I’ve updated the links to reflect the new site.

After installing the Menu Editing (Alacarte) package, you’ll encounter this error when trying to launch the menu editor:

MainWindow.py:19:<module>:Import Error: No module named gmenu

That error occurs because the gnome-menus-3.2.0.1-1.fc16.x86_64 is missing the /usr/lib64/python2.7/site-packages/gmenu.so library. So, I copied the version of gmenu.so from a Fedora 15 release as the root user. Naturally, at this point you’d test if it was fixed, I did. It wasn’t, and I got a new error:

MainWindow.py:19:<module>:Import Error: libgnome-menu.so.2: cannot open shared object file: No such file or directory

That error occurs because the gnome-menus-3.2.0.1-1.fc16.x86_64 is missing the /usr/lib64/libgnome-menu.so.2 symbolic link to the /usr/lib64/libgnome-menu.so.2.4.13 library. While the package meets the dependency check, the libraries fail the run time validation.

If digging in like this is all new to you, I’d recommend Unix and Linux System Administration Handbook, 4th Edition (University of Colorado at Bolder folks) for the Linux stuff and The Quick Book of Python, 2nd Edition for Python basics.

You can get a copy of the Fedora 15 package with the following command, which you should connect as the root user in navigate to the /tmp directory. Then, create a copy directory and change the /tmp/copy directory before running either of the next two commands.

Use this for 32-bit Installs

# wget http://archive.fedoraproject.org/pub/fedora/linux/releases/15/Fedora/i386/os/Packages/gnome-menus-3.0.1-1.fc15.i686.rpm

Use this for 64-bit Installs

# wget http://archive.fedoraproject.org/pub/fedora/linux/releases/15/Fedora/x86_64/os/Packages/gnome-menus-3.0.1-1.fc15.x86_64.rpm

That command only a copy of the RPM file, but the following converts it into an exploded directory. Assuming you created a copy directory in the /tmp directory, execute the following command from within the /tmp/copy directory. It will create a directory tree with the required files. After you copy the files, you can remove (rm) the copy directory from the /tmp directory.

Use this for 32-bit Installs

# rpm2cpio http://archive.fedoraproject.org/pub/fedora/linux/releases/15/Fedora/i386/os/Packages/gnome-menus-3.0.1-1.fc15.i686.rpm | cpio -ivd

Use this for 64-bit Installs

# rpm2cpio http://archive.fedoraproject.org/pub/fedora/linux/releases/15/Fedora/x86_64/os/Packages/gnome-menus-3.0.1-1.fc15.x86_64.rpm | cpio -ivd

You can now copy the files with these files. The target location differs between the 32-bit and 64-bit versions of the operating system.

Use this for 32-bit Installs

# cp /tmp/copy/usr/lib/libgnome-menu.so.2* /usr/lib
# cp /tmp/copy/usr/lib/python2.7/site-packages/gmenu.so /usr/lib/python2.7/site-packages

Alternatively, you can copy the following two files from any valid 32-bit Fedora 15 instance into a Fedora 16 instance, and manually create the symbolic link.

# /usr/lib/libgnome-menu.so.2.4.13
# /usr/lib/python2.7/site-packages/gmenu.so

Use this for 64-bit Installs

# cp /tmp/copy/usr/lib64/libgnome-menu.so.2* /usr/lib64
# cp /tmp/copy/usr/lib64/python2.7/site-packages/gmenu.so /usr/lib64/python2.7/site-packages

Alternatively, you can copy the following two files from any valid Fedora 64-bit 15 instance into a Fedora 16 instance, and manually create the symbolic link.

/usr/lib64/libgnome-menu.so.2.4.13
/usr/lib64/python2.7/site-packages/gmenu.so

After you copy the two files into the right directories as root, you can create the necessary symbolic link with the following command (this isn’t necessary with the wildcard instruction provided earlier in the post). You need to ensure that you’re in the /usr/lib directory when you run the ln command, as noted by Gavin’s comment:

Use this for 32-bit Installs

# ln -s /usr/lib/libgnome-menu.so.2.4.13 libgnome-menu.so.2

Use this for 64-bit Installs

# ln -s /usr/lib64/libgnome-menu.so.2.4.13 libgnome-menu.so.2

As mentioned by Darr247, don’t forget to remove the /tmp/copy directory when you’re done making the changes.

Somebody asked me to add the Red Hat Package Manager (RPM) commands that let me find these dependencies. That seemed like a good idea, here they are:

RPM Commands
Description of Options
rpm -qa search_string
Lists all installed packages that find the string in their package name. The results are typically piped through grep to filter the list.
rpm -qf file_name
Lists the package that owns a file. You need to fully qualify the location of the file with the complete path.
rpm -q package_name
Lists information about the package.
rpm -qi package_name
Lists information about the package.
rpm -qR package_name
Lists dependent libraries and commands for a package.
rpm -ql package_name
Lists files in a package.
rpm -qd package_name
Lists documentation files for a package.
rpm -qc package_name
Lists configuration files for a package.

If you want to set a menu item up manually, check this blog post. You also have the LXMenuEditor that’s available in beta as an alternative. Hope this helps those in need, as always.

Written by maclochlainn

November 24th, 2011 at 1:23 pm

Posted in Fedora,Linux,Red Hat

«
»

35 Responses to 'Gnome Menu Editing Fix'

Subscribe to comments with RSS or TrackBack to 'Gnome Menu Editing Fix'.

  1. Another alternative is to use this Java utility:

    https://github.com/efruchter/Gnome3_AppMenuEditor/downloads

    Worked for me on Fedora 16 perfectly, after installing java-1.7.0-openjdk.

    Kayvan SYlvan

    28 Nov 11 at 12:54 pm

  2. I’m sorry to bother you, but I followed the instructions but wound up with this error.

    MainWindow.py:19::ImportError: /usr/lib64/python2.7/site-packages/gmenu.so: wrong ELF class: ELFCLASS32

    Is there anyway to fix this? I’m using Fedora 16 64-bit.

    MMXZ

    28 Nov 11 at 8:27 pm

  3. Thanks for letting me know. It had only demonstrated the 32-bit files, which is more often the convention. I’ve updated the post to show the syntax differences and specific 32-bit versus 64-bit packages. You can just copy over the files without a problem. What’s you’re getting is an error raised when 64-bit software calls a 32-bit library. You want the 64-bit files.

    maclochlainn

    28 Nov 11 at 10:39 pm

  4. I’m using a 32-bit Fedora, and I created the /usr/lib64 directory. Which directory do I need to create the symbolic link in? I still get an error on running alacarte:

    Traceback (most recent call last):
    File “/usr/bin/alacarte”, line 22, in
    from Alacarte.MainWindow import MainWindow
    File “/usr/lib/python2.7/site-packages/Alacarte/MainWindow.py”, line 19, in
    import gtk, gmenu, gobject, gio
    ImportError: No module named gmenu

    Jim Brittain

    30 Nov 11 at 3:11 pm

  5. If you’re on a 32-bit install, they go in the /usr/lib not /usr/lib64 directory path.

    maclochlainn

    30 Nov 11 at 7:45 pm

  6. Also – I had 5to change the second copy command to show gmenu.so instead of gnome.so. Instead of this:

    cp /tmp/copy/usr/lib/python2.7/site-packages/gnome.so /usr/lib/python2.7/site-packages

    … I had to use this:

    cp /tmp/copy/usr/lib/python2.7/site-packages/gmenu.so /usr/lib/python2.7/site-packages

    But it seems to be working now

    Jim Brittain

    1 Dec 11 at 3:54 am

  7. Thanks for letting me know that I’d fat fingered it. I’ve updated the blog entry.

    maclochlainn

    1 Dec 11 at 2:40 pm

  8. Thank you very much, it works very well.

    Edward Reznor

    6 Dec 11 at 1:32 pm

  9. I just followed the 64 bit instructions. I had to change the copy commands. The source path should include “lib64″ instead of “lib”.

    For instance:
    cp /tmp/copy/usr/lib/libgnome-menu.so.2* /usr/lib64
    cp /tmp/copy/usr/lib/python2.7/site-packages/gmenu.so /usr/lib64/python2.7/site-packages

    should be:
    cp /tmp/copy/usr/lib64/libgnome-menu.so.2* /usr/lib64
    cp /tmp/copy/usr/lib64/python2.7/site-packages/gmenu.so /usr/lib64/python2.7/site-packages

    It works. Thanks.

    Fred Odendaal

    6 Dec 11 at 5:34 pm

  10. Thanks, it looks like when I fixed the other typo I introduced another. I think they’re correct now.

    maclochlainn

    7 Dec 11 at 1:05 am

  11. Thank you very much for posting this detailed description! It saved me a lot of time for “research”.

    Your description places files into directories that normally are only controlled by the package management system.

    Therefore I’d recommend to copy the libraries to /usr/local/lib (or lib64 respectively) and then create symlinks from /usr/lib (lib64) and …/python2.7/…

    That way you won’t interfere with the package management and will later still be able to figure out which files you’ve added manually. But that’s just “cosmetics”.

    Paul McAllister

    12 Dec 11 at 2:05 am

  12. Great instructions, thanks. Can you submit this to Fedora? They really should include these two files (plus one link) in the gnome-menus package, at least until they work out the retrogression. Sheesh.

    John F

    12 Dec 11 at 4:19 am

  13. Ii updated the bug a while back and its been triaged.

    maclochlainn

    12 Dec 11 at 8:49 am

  14. Thanks,
    It also worked for my Kororaa Linux 16.

    E3D3

    17 Dec 11 at 11:16 am

  15. Hi MacLochlainns,

    When the user needs to make temporary subdirs and change to them, you should probably include the actual commands needed to make and change to them right in the ‘Use this for xx-bit Installs’ instructions.

    Also, the user level needed is typically indicated by prefacing each command with the correct prompt.
    i.e. $ for user; # for root like,

    # cp /tmp/copy/usr/lib64/libgnome-menu.so.2* /usr/lib64

    Still, thanks for the kludge. :-)
    This problem was filed on bugzilla.redhat.com in August… you’d think there would be an “official” fix floating downstream by now.

    Darr247

    27 Dec 11 at 12:40 pm

  16. By the way, running:

    # ln -s libgnome-menu.so.2.4.13 libgnome-menu.so.2

    as directed puts the link in /tmp/copy because no path is specified and the instructions never say to cd anywhere else first.

    Where is it **supposed** to be?
    (there’s already a file named libgnome-menu.so.2 in /usr/lib64, from the first cp command.)

    Alacarte works, but I noticed the link in /tmp/copy as I was cleaning up.

    Darr247

    27 Dec 11 at 1:03 pm

  17. Darr247, all good catches. I’ve updated the post for them. Also, beyond the packaging error the symbols should change in the future and no longer point to the PyGTK library. They should point to the dynamic binding libraries in PyGObject.

    maclochlainn

    27 Dec 11 at 1:11 pm

  18. You need to be in the appropriate directory, before you apply the symlink!

    Alacarte now works fine in xfce (as one would normally expect),

    In am now using xfce rather than GNOME 3 in Fedora 16, as I was previously a power GNOME 2 user in Fedora 14, and GNOME 3 is unusable for serious use.

    Gavin Flower

    17 Jan 12 at 1:22 pm

  19. Yes, you’re right. It was an omission that I’ve fixed above based on your comment.

    maclochlainn

    17 Jan 12 at 2:48 pm

  20. So, I’m a beginner, but I followed all of these steps and received the following error when trying to create the symbolic link:

    “ln: failed to create symbolic link `libgnome-menu.so.2′: File exists”

    How can I fix that?

    Josh

    20 Jan 12 at 7:12 pm

  21. The earlier instruction copies the symbolic link, which could then cause this error. Did you check if already have the symbolic link in the directory?

    maclochlainn

    20 Jan 12 at 7:40 pm

  22. [...] sure! sorry about that. i didn't see any replies, so i didn't think anyone would want to know. when i first got Alacarte working, i had to change the libgnome-menu.so.2 file. an update changed the link to that file back to how it was originally, so i had to download an older version of the file for it to work with the menu again. also, i found the original solution to the Alacarte problem on this site – http://blog.mclaughlinsoftware.com/2…u-editing-fix/ [...]

    [SOLVED] unable to delete menu entry

    1 Feb 12 at 11:09 am

  23. Thanks, I can use alacarte now!

    Strangiato

    7 Feb 12 at 8:52 am

  24. [...] you. That looks promising, but I did get Alacarte working thanks to the information in this link: http://blog.mclaughlinsoftware.com/2…u-editing-fix/ and from Alacarte I can create a launcher and as you said, right click on it and have it in the [...]

    How to create custom app launcher with Fedora 16 gnome3?

    15 Feb 12 at 3:53 am

  25. Hi!
    It appears to me that the links have been expired. I don’t want to copy the error I get because my Fedora isn’t English, but after translation it says something like this: download.fedora.redhat.com unlock failed
    Thanks

    Tamas

    20 Feb 12 at 10:37 am

  26. Yes, they did. Thanks for letting me know. I’ve posted the master location and will update the others shortly.

    maclochlainn

    20 Feb 12 at 12:07 pm

  27. Works like a charm! Thank you!

    Tamas

    23 Feb 12 at 9:45 am

  28. Thanks, worked for me. Fedora 16 x64
    Thank you for the books also.

    shaiang

    24 Feb 12 at 3:48 am

  29. Thanks for this, worked perfectly. The only thing I have found missing in Gnome3 is creating custom launchers, and this resolves that quite nicely.

    x1101

    1 Mar 12 at 6:48 am

  30. [...] the download URL was invalid [...]

    Fedora download site changes

    3 Mar 12 at 9:47 am

  31. Thanks a lot for this solution, worked perfectly on Fedora 16 x64.

    LDPDC

    9 Mar 12 at 10:32 am

  32. [...] repository and copy over a couple of library files [...]

    Fedora 16: “no gmenu”

    12 Mar 12 at 6:37 pm

  33. I followed the instructions. Thanks a lot for your work! Alacarte is working fine.
    However, it doesn’t fix the problem of editing menus in Gnome 3 (fallback), because with alacarte you can edit menus, but they don’t correspond with what you see in Applications view…
    Anybody knows why?

    jentiger

    17 Mar 12 at 3:30 am

  34. Thanxxxxxx………..Works great !!!!!!!

    Nikhil Parmar

    2 Apr 12 at 10:17 am

  35. [...] adalah tidak compatible antara alacarte dengan gnome 3. Sebenarnya ada cara mengatasinya di sini, tapi untuk saat ini saya lebih memilih yang mudah saja. Setelah saya googling lagi ternyata ada [...]

    Install dan Membuat Launcher Eclipse di Fedora 16 « From Zero to Hero

    21 Apr 12 at 10:38 pm

Leave a Reply