Spec URL: http://beta.glwb.info/kmenugnome/kmenu-gnome.spec SRPM URL: http://beta.glwb.info/kmenugnome/kmenu-gnome-0.5-1.src.rpm Description: K Menu with Gnome folder and extra icons for Fedora Core 5.
This spec file is rather particular, based on the project leader's spec file, Ive tried to make it fit to FE policies, but still Its far from getting accept to Fedora Extras. rpmlint -i complains: chitlesh(i386)[0]$rpmlint -i kmenu-gnome-0.5-1.i386.rpm E: kmenu-gnome no-binary The package should be of the noarch architecture because it doesn't contain any binaries. E: kmenu-gnome standard-dir-owned-by-package /usr/share This package owns a directory that is part of the standard hierarchy, which can lead to default directory permissions or ownerships being changed to something non-standard. E: kmenu-gnome standard-dir-owned-by-package /usr This package owns a directory that is part of the standard hierarchy, which can lead to default directory permissions or ownerships being changed to something non-standard. E: kmenu-gnome standard-dir-owned-by-package /etc This package owns a directory that is part of the standard hierarchy, which can lead to default directory permissions or ownerships being changed to something non-standard. E: kmenu-gnome standard-dir-owned-by-package /usr/share/icons This package owns a directory that is part of the standard hierarchy, which can lead to default directory permissions or ownerships being changed to something non-standard. W: kmenu-gnome non-conffile-in-etc /etc/xdg/menus/applications-merged/kmenu-gnome.menu A non-executable file in your package is being installed in /etc, but is not a configuration file. All non-executable files in /etc should be configuration files. Mark the file as %config in the spec file. W: kmenu-gnome dangerous-command-in-%post rm W: kmenu-gnome dangerous-command-in-%preun rm
Chitlesh, It seems that you misunderstand the sponsoring process. You've already been sponsored by me for knetstats and you only need to be sponsored once. So now this is a regular review request which can be done by any FE packager. Resetting the blocker bug to FE-NEW. I'll get back to you on your rpmlint issues when I find the time. You'll probably have to find someone else todo the review though I'm rather busy at the moment.
Not an official review as I'm not yet sponsored Chitlesh, I also found that rpmlint -i kmenu-gnome-0.5-1.src.rpm E: kmenu-gnome invalid-spec-name kmenu-gnome-fc5.spec Your spec filename must end with '.spec'. If it's not the case, rename your file and rebuild your package. so rename spec file name to kmenu-gnome.spec also try to list which files this package belongs under %files section
Ok let me try to solve rpmlint errors for you. >rpmlint -i complains: >chitlesh(i386)[0]$rpmlint -i kmenu-gnome-0.5-1.i386.rpm >E: kmenu-gnome no-binary >The package should be of the noarch architecture because it doesn't contain >any binaries. Then you can add to SPEC file BuildArchitectures: noarch >E: kmenu-gnome standard-dir-owned-by-package /usr/share >This package owns a directory that is part of the standard hierarchy, which >can lead to default directory permissions or ownerships being changed to >something non-standard. >E: kmenu-gnome standard-dir-owned-by-package /usr >This package owns a directory that is part of the standard hierarchy, which >can lead to default directory permissions or ownerships being changed to >something non-standard. >E: kmenu-gnome standard-dir-owned-by-package /etc >This package owns a directory that is part of the standard hierarchy, which >can lead to default directory permissions or ownerships being changed to >something non-standard. >E: kmenu-gnome standard-dir-owned-by-package /usr/share/icons >This package owns a directory that is part of the standard hierarchy, which >can lead to default directory permissions or ownerships being changed to >something non-standard. You should not make Systems standard direcory's to belong to your package. thats what i ask you to add only those files that are installed by your package. W: kmenu-gnome non-conffile-in-etc /etc/xdg/menus/applications-merged/kmenu-gnome.menu A non-executable file in your package is being installed in /etc, but is not a configuration file. All non-executable files in /etc should be configuration files. Mark the file as %config in the spec file. under %files section you can add %config /etc/xdg/menus/applications-merged/kmenu-gnome.menu W: kmenu-gnome dangerous-command-in-%post rm W: kmenu-gnome dangerous-command-in-%preun rm why the patch is needed to apply at post routine??
I've gotta say this one does some absolutely nasty stuff in %post, including symlinking icons, and patching xdg menu files, (almost?) all of which could be implemented via an alternate icon theme and making a proper xdg menu and using $XDG_CONFIG_DIRS. IMO, definitely a MUSTFIX.
True, It's the spec file from kmenu-gnome, I did my best to make it compatible with FE policies, but Ill rather need help to complete this process. Ill send an update soon.
(In reply to comment #5) > I've gotta say this one does some absolutely nasty stuff in %post, including > symlinking icons, and patching xdg menu files, (almost?) all of which could be > implemented via an alternate icon theme and making a proper xdg menu and using > $XDG_CONFIG_DIRS. IMO, definitely a MUSTFIX. Symlinking the icons is not essential so I don't mind removing it from kmenu-gnome.spec but I don't see how symlinking _these specific icons_ would be harmful. It is unlikely that they would ever be included in Bluecurve or Crystal SVG. However, patching xdg merge files like /etc/xdg/menus/system-settings.menu is a must if you put anything into /etc/xdg/menus/applications-merged to suppress a bug caused by a harmful piece of code found in (almost?) all of the xdg merge files installed with redhat-menus. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196275 for details. The patch in %post temporarily fixes the bug caused by redhat-menus while the patch in %preun is a reverse patch to undo what the patch in %post did. As for making a proper xdg menu and using $XDG_CONFIG_DIRS, I don't understand how one could do it less intrusively than kmenu-gnome does.
> I don't see how symlinking _these specific icons_ would be > harmful. symlinking icons in %post will make unowned files -> bad. Making symlinks in %install, and having the rpm *own* them is ok.
> As for making a proper xdg menu and using $XDG_CONFIG_DIRS, I don't understand > how one could do it less intrusively than kmenu-gnome does. See bug #178320 for one example (of how kde uses a different menu than gnome) using $XDG_CONFIG_DIRS
(In reply to comment #8) > symlinking icons in %post will make unowned files -> bad. > Making symlinks in %install, and having the rpm *own* them is ok. I see. I will do so. (In reply to comment #9) > See bug #178320 for one example (of how kde uses a different menu than gnome) > using $XDG_CONFIG_DIRS Yes, it is another solution to keep K Menu and Gnome's Applications menu apart but it does not fix bug #196275 Going back to the ownership of directories that are part of the standard hierarchy, it is already fixed in the upcoming release of kmenu-gnome-0.5.1.
Created attachment 131715 [details] kmenu-gnome.spec without dangerous commands in %post and %preun
Created attachment 131716 [details] kmenu-gnome-0.5.1-3.src.rpm
Uploaded new spec. It no longer fixes bug #196275 - it only hides it using a Fedora-specific additional merge file. While fixing a bug is preferable to hiding it, I accept the criticism that %post is not the best place for patches. The symlinks are moved under %install so they all are owned by the package. rpmlint warns about symbolic links pointing nowhere but that's normal: http://qa.mandriva.com/twiki/bin/view/Main/PackagingProblems#RpmLint_Warnings
updated: Spec URL: http://beta.glwb.info/kmenugnome/kmenu-gnome.spec SRPM URL: http://beta.glwb.info/kmenugnome/kmenu-gnome-0.5.1-2pre3.src.rpm %changelog - dropped gtk-update-icon-cache from %%post and %preun - corrected the top-level icon directory in %%post and %preun
(In reply to comment #14) > %changelog > > - dropped gtk-update-icon-cache from %%post and %preun Erm, why? You make changes to the icon dirs, thus the cache needs updating.
from http://fedoraproject.org/wiki/ScriptletSnippets: For KDE, just 'touch'ing the top-level icon directory is enough. Also since kmenu-gnome does not affect on gnome menus, its useless to have gtk-update-icon-cache.
I see, could you add a comment to explain this to the spec-file then? This is sorta in direct contradiction with the scriptlets wiki page. But I guess thats ok in this case.
updated: Spec URL: http://beta.glwb.info/kmenugnome/kmenu-gnome.spec SRPM URL: http://beta.glwb.info/kmenugnome/kmenu-gnome-0.5.1-3pre3.src.rpm Hans, can you do an official review taking into consideration the comment #13 ? Ariszló is the kmenu-gnome developper.
Nope, Sorry Chitlesh, but I'm both rather busy and not a KDE user and this package looks like it needs a thorough review preferably by someone intimate with KDE. Rex, maybe this is something for you?
New release 0.6 Spec URL: http://chitlesh.ch.funpic.de/kmenugnome/kmenu-gnome.spec SRPM URL: http://chitlesh.ch.funpic.de/kmenugnome/kmenu-gnome-0.6-2.src.rpm
I'll see if I can bang this one out...
* upstream source checks out: 9b36e22fc02f022e35fae3241ec9d622 31025-kmenu-gnome-0.6.tar.gz 1. missing %build section. Though this is mostly harmless... 2. drop the use of $RPM_BUILD_DIR. 3. rm -rf %{buildroot} should be at beginning of %install section, not %prep 4. scriptlets should (instead) be touch --no-create %{_datadir}/icons/Bluecurve ||: touch --no-create %{_datadir}/icons/crystalsvg ||: similarly, I'd recommend replacing %files %{_icondir}/*/*/*/* with %{_datadir}/icons/Bluecurve/*/*/* %{_datadir}/icons/crystalsvg/*/*/* 5. Due to ownership of stuff under %{_datadir}/icons/Bluecurve, to avoid possible unowned directory, you should Requires: redhat-artwork (yucky yes, but unowned dirs are even worse) 6. License. Should probably be License: GPL/LGPL since there are bits of both in this package. Fix (at least) 2-6, and I'll approve this.
> NEEDINFO requested of cgoorah.au Chitlesh writes at clunixchit.blogspot.com that he will be on vacation until about the middle of August.
OK, we can wait. (:
I'm back :) Updated: SRPM: http://chitlesh.funpic.de/rpm/kmenu-gnome-0.6-3.src.rpm SPEC: http://chitlesh.funpic.de/rpm/kmenu-gnome.spec
Excellent, APPROVED.