I think before anyone can give you a more detailed review, there are some things you should address and fix.

As an initial point, you should run rpmlint with -vi switch to give you more information.  Since this is a Python application, you may want to read the Python packaging wikipage (http://fedoraproject.org/wiki/Packaging:Python).

It also appears you do not use the Makefile that is included with the source and it looks like the Makefile supports DESTDIR, PREFIX etc.  Why do you not use it?

Specifc comments are below:

> gnomenu.src: W: non-standard-group Graphical desktop/GNOME

As the message says, you have a non-standard group.  Run "less /usr/share/doc/rpm-*/GROUPS" to get a list.  I would also check similar packages in Fedora and see what groups they use.

> gnomenu.noarch: E: explicit-lib-dependency python-xlib

Add python-xlib as a BuildRequires.

> gnomenu.src:49: E: hardcoded-library-path in /usr/lib/gnomenu/GnoMenu.py

You have a hardcoded path in your spec file (line 49).  You should use macros instead (http://fedoraproject.org/wiki/Packaging/RPMMacros).

If hardcoded paths are in the source, (and I think they are in the Makefile, for example) you may need to figure out a way to fix that if you can, either by overriding it if possible or using an inline sed or patch.  Patches should be sent upstream.

> gnomenu.src:62: W: libdir-macro-in-noarch-package (main package)
> %{_libdir}/bonobo/servers/*.server
> gnomenu.src:63: W: libdir-macro-in-noarch-package (main package)
> %{_libdir}/%{name}/*

Following on with the previous comment, double-check whether this really is a noarch package.  I believe the Python packaging page linked to above has information on multilib installations.

> gnomenu.noarch: E: script-without-shebang
> /usr/lib/gnomenu/locale/Settings_LangPack_en.xml

...

All of these "script without shebang" messages are explained here:
http://fedoraproject.org/wiki/Common_Rpmlint_issues#script-without-shebang

Perhaps these xml files have an executible bit set when it is not needed.  If so, you may need to remove that.

> gnomenu.noarch: W: non-conffile-in-etc /etc/gnomenu/prefix

Configuration files often need to be handled with %config(noreplace) as mentioned here:
http://fedoraproject.org/wiki/Packaging/Guidelines#Configuration_files

> gnomenu.noarch: W: hidden-file-or-dir /usr/share/gnomenu/Themes/Menu/Short/.png
...
> gnomenu.noarch: W: hidden-file-or-dir /usr/share/gnomenu/Themes/Icon/BW/.png

Are these two files just cruft left over in the source?  If so, should they be deleted before cleaning RPM_BUILD_ROOT?

HTH

(In reply to comment #1)
> > gnomenu.noarch: E: explicit-lib-dependency python-xlib
> 
> Add python-xlib as a BuildRequires.

No, this is correct. RPM does not pick up requires of Python packages, they have to be listed explicitly. rpmlint is misguided by the 'lib' in the dependency.

**

Instead of BR: python you should BR: python-devel as per the Python packaging guidelines.

**

You are using 'cp' in the spec file, so use -p to preserve timestamps.
http://fedoraproject.org/wiki/Packaging/Guidelines#Timestamps

**

The script-without-shebang warnings are probably caused by wrong permissions. Remove the executable flags from the files with e.g.
 find %{buildroot} -type f -exec chmod 644 {} \;

**

You must own
 %{_datadir}/gnomenu/
as no other package provides it.

(In reply to comment #2)
> (In reply to comment #1)
> > > gnomenu.noarch: E: explicit-lib-dependency python-xlib
> > 
> > Add python-xlib as a BuildRequires.
> 
> No, this is correct. RPM does not pick up requires of Python packages, they
> have to be listed explicitly. rpmlint is misguided by the 'lib' in the
> dependency.
> 
> **
> 
> Instead of BR: python you should BR: python-devel as per the Python packaging
> guidelines.
> 
> **

Ah, thanks for clarifying both of the above points.

Hello, guys, sorry to keep you waiting. I'm back to work now. Very soon I'll post another update here.

Hi, I'm sorry for the delay.

SPEC: http://lonelyspooky.com/uploads/rpm/gnomenu/1.9.9-2/gnomenu.spec
SRPM: http://lonelyspooky.com/uploads/rpm/gnomenu/1.9.9-2/gnomenu-1.9.9-2.fc11.src.rpm

[lonely@localhost noarch]$ rpmlint gnomenu-1.9.9-2.fc11.noarch.rpm 
gnomenu.noarch: E: explicit-lib-dependency python-xlib
gnomenu.noarch: W: non-conffile-in-etc /etc/gnomenu/prefix
1 packages and 0 specfiles checked; 1 errors, 1 warnings.

Can I ignore this? >> gnomenu.noarch: E: explicit-lib-dependency python-xlib

rpmlint is still complaining about /etc/gnomenu/prefix do not look like an .conf file, but this file only contains this parameter: /usr

(In reply to comment #5)
> Can I ignore this? >> gnomenu.noarch: E: explicit-lib-dependency python-xlib

Yes, that's really not an error.

> rpmlint is still complaining about /etc/gnomenu/prefix do not look like an
> .conf file, but this file only contains this parameter: /usr  

I'd mark it as a config file. Of course, if you do then you'll get the warning about the file not being noreplace...

Surry, but, how can I do that? "I'd mark it as a config file."

Replace
 %{_sysconfdir}/%{name}/prefix
with
 %config %{_sysconfdir}/%{name}/prefix

Oh, you can safely drop
 %{_builddir}/%{name}
from the commands in %prep.

And I'd replace
 find %{_builddir}/%{name} -name "*.xml" -type f -exec chmod 644 {} \;
 find %{_builddir}/%{name} -name "*.py" -type f -exec chmod a+x {} \;
 find %{_builddir}/%{name} -name "*.sh" -type f -exec chmod a+x {} \;
with
 find -name "*.xml" -type f -exec chmod 644 {} \;
 find \( -name "*.py" -o -name "*.sh" \) -type f -exec chmod 755 {} \;
for consistency.

And instead of
 sh %{_sourcedir}/%{name}-shebang.sh
just run
 sh %{SOURCE1}

Hi, Jussi.
Thanks for your patience. =) I'm really learning a lot here.
Here we go:
SPEC: http://lonelyspooky.com/uploads/rpm/gnomenu/1.9.9-3/gnomenu.spec
SRPM: http://lonelyspooky.com/uploads/rpm/gnomenu/1.9.9-3/gnomenu-1.9.9-3.fc11.src.rpm

Following your advice we have only this error:
gnomenu.noarch: E: explicit-lib-dependency python-xlib
1 packages and 0 specfiles checked; 1 errors, 0 warnings
But, as we already know, it can be ignored.

Again, thank you very much!

Ping?
Any reviewer available?

* repeat "rpmlint -i gnomenu-1.9.9-3.fc11.src.rpm" as some of the older issues are still there

* you should really not mix usage of %buildroot and $RPM_BUILD_ROOT
https://fedoraproject.org/wiki/Packaging/Guidelines#macros

* multiple directories are not included:

  %{_sysconfdir}/%{name}
  /usr/lib/%{name}
  %{_datadir}/gnomenu
  %{_datadir}/gnomenu/Themes

https://fedoraproject.org/wiki/Packaging/Guidelines#FileAndDirectoryOwnership

See also bug 546202, which appears to be an assertion failure running a pre-release version of GnoMenu

Well, with GNOME reaching 3.0, gnomenu will be useless.
Maybe packaging it should be a waste of time. 
Dont you think, guys?

(In reply to comment #15)
> Well, with GNOME reaching 3.0, gnomenu will be useless.
> Maybe packaging it should be a waste of time. 
> Dont you think, guys?    

Don't think so! I won't be using gnome 3.0, buti don't use gnome 2.0.
I will reveiw for you if you still want to go ahead!

Ok. As soon as possible I'll try to finish it.

hello, im the lead dev of GnoMenu.

The version you are trying to package is a very old version of GnoMenu.

The current one is 2.5 available here https://launchpad.net/gnomenu

Also GnoMenu will not die with Gnome 3.0

GnoMenu currently supports Gnome-Panel, Avant-Window-Navigator, Cairo-Dock, XfApplet and in the system tray.

Hi. I'm aware of that, but, thank you.
Soon I'll be back to this package.

Hi,

I've created a new spec file for version 2.5 of GnoMenu:

http://wiki.thoughtbit.com/_media/linux:fedora:gnomenu.spec

The patches for that spec file, as well as a link to the openSUSE src rpm I based my spec file and patches on, are here:

http://wiki.thoughtbit.com/linux:fedora:gnomenu

(In reply to comment #20)
> Hi,
> 
> I've created a new spec file for version 2.5 of GnoMenu:
> 
> http://wiki.thoughtbit.com/_media/linux:fedora:gnomenu.spec
> 
> The patches for that spec file, as well as a link to the openSUSE src rpm I
> based my spec file and patches on, are here:
> 
> http://wiki.thoughtbit.com/linux:fedora:gnomenu    

Thanks, John, I'm working on it right now. If you want to help (or take) this work, be my guest.

(In reply to comment #21)
> > http://wiki.thoughtbit.com/linux:fedora:gnomenu    
> 
> Thanks, John, I'm working on it right now. If you want to help (or take) this
> work, be my guest.    

There is also a src rpm on my gnomenu wiki page above.  The package builds/installs/works fine on Fedora 12 x86-64.

I think we just need someone to approve the new spec file, unless you (or someone else) see any problems with it?

(In reply to comment #22)
> (In reply to comment #21)
> > > http://wiki.thoughtbit.com/linux:fedora:gnomenu    
> > 
> > Thanks, John, I'm working on it right now. If you want to help (or take) this
> > work, be my guest.    
> 
> There is also a src rpm on my gnomenu wiki page above.  The package
> builds/installs/works fine on Fedora 12 x86-64.
> 
> I think we just need someone to approve the new spec file, unless you (or
> someone else) see any problems with it?    

No, there is no need to approve the spec first, but some opensuse macros doesn't work to fedora.

(In reply to comment #23)

> No, there is no need to approve the spec first, but some opensuse macros
> doesn't work to fedora.    


I think I stripped out all the openSUSE macros - are you having problems with the spec file?

The package is building ok, but, to have it approved we need to solve all the rpmlint issues, since Fedora have some rigid guidelines to follow.

(In reply to comment #25)
> The package is building ok, but, to have it approved we need to solve all the
> rpmlint issues, since Fedora have some rigid guidelines to follow.

Hi Henrique -- are you still working on this? If so, I'm happy to review it for you. Otherwise, we should probably close this request.

Cheers
Rudi

Hi, I'll be happy to restart the work here.
Thank you Ruediger. I'll be posting updates here ASAP.

Hi Henrique - I've updated my source rpm to fix the desktop file issue, but I don't see a clean/easy way to resolve the Makefile problem (the Makefile isn't 64bit aware) without the %ifarch x86_64 statement.

I also noticed that there is a new version of gnomenu (2.9), and while this new version's Makefile is easier to work with, the setup.py script that is called by the Makefile no longer seems to adjust the bonobo server file correctly for 64bit builds.


https://wiki.thoughtbit.com/_media/linux:fedora:gnomenu-2.5-2.fc12.src.rpm

Hi, John, I've downloaded the new 2.9 version to see what have changed since my last package (1.9!) and, despite some great improvements in this new version I'm still finding some pretty annoying bugs (like this 64 bits issue).
To be honest, maybe this software is going to require a lot of basic work to be done by upstream.

Agreed - it seems to be a bit more work than it's worth...  The src rpm is still available on my wiki for anyone who wants it.

Looks like WONTFIX. Closing.