Spec URL: http://www.witt-family.net/mintmenu-4.9.0-1.fc12.src.rpm SRPM URL: http://www.witt-family.net/mintmenu.spec Description: One of the most advanced menus under Linux. MintMenu supports filtering, favorites, easy-uninstallation, autosession, and many other features. This is my forst package and I am in need of a sponsor.
Updated spec to account for python builddep and rebuilt srpm Spec URL: http://www.witt-family.net/mintmenu.spec SRPM URL: http://www.witt-family.net/mintmenu-4.9.0-2.fc12.src.rpm
Koji Build: https://koji.fedoraproject.org/koji/taskinfo?taskID=1836352 Spec URL: http://www.witt-family.net/mintmenu.spec SRPM URL: http://www.witt-family.net/mintmenu-4.9.0-3.fc12.src.rpm Fixed a bug in launching a terminal from the system manager plugin.
Fixed problems with rpmlint [unamanic@gimli ~]$ rpmlint /home/unamanic/rpmbuild/SRPMS/mintmenu-4.9.0-4.fc12.src.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. Koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=1836647 Spec URL: http://www.witt-family.net/mintmenu.spec SRPM URL: http://www.witt-family.net/mintmenu-4.9.0-4.fc12.src.rpm
Comments marked with ### #%global _libdir /usr/lib ### Remove Summary: Advanced Gnome menu Name: mintmenu Version: 4.9.0 ### align Name tag? BuildRequires: python-devel Requires: deskbar-applet, tracker, python >= 2.4, python < 3.0, pyxdg, gnome-python2-gnomedesktop, pygtk2, pygtk2-libglade, alacarte ### Split this line, many reviewers like only one package one each line. %description One of the most advanced menus under Linux. MintMenu supports filtering, favorites, easy-uninstallation, autosession, and many other features ### You could be a bit more informative here. %prep %setup -q -n mintmenu %install rm -rf %{buildroot} mkdir %{buildroot} cp -R usr %{buildroot}/ ### I would change that to cp -a ... cp %SOURCE1 %{buildroot}/%{_libdir}/linuxmint/mintMenu/ ### And this to cp -a %{SOURCE1} ... %post %postun ### Remove these %files %defattr(-,root,root,-) %attr(0755, root, root) %{_bindir}/mintmenu %{_libdir}/bonobo/servers/mintMenu.server %{_libdir}/linuxmint/mintMenu/applications.list %{_libdir}/linuxmint/mintMenu/compile.py ### You have to redo the file listing, should the package own ### %{_libdir}/linuxmint and %{_libdir}/linuxmint/mintMenu? ### Remove the leading spaces. %{_libdir}/linuxmint/mintMenu/compile.pyc %{_libdir}/linuxmint/mintMenu/dotted.png %{_libdir}/linuxmint/mintMenu/icon.png
Forgot, two more issues: - you should add a note why %build is empty. - seems like pure python code(?), then the package should be noarch
I copied the description tag directly from upstream. I can update it with something more descriptive if there is no reason to tay in sync with the description from them. How does one specify /usr/lib in a no arch package without using an absolute path? This is where upstream places the files. [unamanic@gimli ~]$ rpmlint rpmbuild/SRPMS/mintmenu-4.9.0-5.fc12.src.rpm mintmenu.src:68: W: libdir-macro-in-noarch-package (main package) %{_libdir}/bonobo/servers/mintMenu.server mintmenu.src:69: W: libdir-macro-in-noarch-package (main package) %{_libdir}/linuxmint 1 packages and 0 specfiles checked; 0 errors, 2 warnings. koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=1838646 Spec URL: http://www.witt-family.net/mintmenu.spec SRPM URL: http://www.witt-family.net/mintmenu-4.9.0-5.fc12.src.rpm
You might want to move to %{_datadir}. You then need to patch sources, /usr/lib seems to be hard coded.
The bonobo .server file must be in either /usr/lib/... or /usr/lib64/... but it's plain text so it doesn't really matter which one. Since the the package is purely interpreted, it makes sense to make it a noarch package, but the value of %{_libdir} changes based on build architecture. Is this a case where hard coding the file paths would be accepted?
Went with forgoing the noarch so that I could use %{_libdir}, then using some sed-fu to "patch" the source files based on build arch. I there is a better way of doing this, please let me know. rpmlint: [unamanic@gimli ~]$ rpmlint rpmbuild/SRPMS/mintmenu-4.9.0-9.fc12.src.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. [unamanic@gimli ~]$ rpmlint rpmbuild/RPMS/x86_64/mintmenu-4.9.0-9.fc12.x86_64.rpm mintmenu.x86_64: E: no-binary mintmenu.x86_64: W: no-documentation mintmenu.x86_64: E: script-without-shebang /usr/lib64/bonobo/servers /mintMenu.server 1 packages and 0 specfiles checked; 2 errors, 1 warnings. no-binary: it's pure python, so there won't be one no-documentation: upstream doesn't have any either script-without-shebang: this file is an xml bonobo server file not a script, I'm not sure what rpmlint is expecting here koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=1839656 Spec URL: http://www.witt-family.net/mintmenu.spec SRPM URL: http://www.witt-family.net/mintmenu-4.9.0-9.fc12.src.rpm
sed is ok, but should be done in %pre, so that package doesn't need to be touched after installation. If possible, try to preserver the timestams of the files, see https://fedoraproject.org/wiki/Packaging/Guidelines#Timestamps https://fedoraproject.org/wiki/PackageMaintainers/PackagingTricks I wonder it tracker is really sufficient or if tracker-search-tool is required. I think it is. %{_bindir}/mintmenu runs gconftool-2, so "Requires: Gconf2" is missing. %{_bindir}/mintmenu should be installed in %{_libexecdir} For licensing reasons, you are not allowed to include any Fedora icons in the package. You must use the logos provided by the fedora-logos package and Require: system-logos. system-logos is a virtual provides, so the package can be rebranded. If possible, use a generic name for the icon in the code, e.g. "icon-panel-menu.png" which is provided by different themes and on several distros such as Rhel or CentOS. Not sure about license of the mint icon, I think best is to leave it out. Disable building the empty debuginfo package with "%global debug_package %{nil}" at the beginning of the spec. /usr/lib64/bonobo/servers/mintMenu.server must not be executable, this is what causes the script-without-shebang error in rpmlint. I'd rather use install than cp because you can set proper permissions of the files. (In reply to comment #6) > How does one specify /usr/lib in a no arch package without using an absolute > path? This is where upstream places the files. %{_prefix}/lib, see http://fedoraproject.org/wiki/Packaging:RPMMacros But I agree with Terje that the noarch stuff should be moved to %{_datadir}.
(In reply to comment #10) > sed is ok, but should be done in %pre, so that package doesn't need to be > touched after installation. If possible, try to preserver the timestams of the > files, see moved sed-foo to %pre > I wonder it tracker is really sufficient or if tracker-search-tool is required. > I think it is. changed... > %{_bindir}/mintmenu runs gconftool-2, so "Requires: Gconf2" is missing. Added > %{_bindir}/mintmenu should be installed in %{_libexecdir} I have to disagree on this one, libexdir takes it off the path. The mintmenu script allows the menu to be cleaned or or launched from the command line in its own window. > For licensing reasons, you are not allowed to include any Fedora icons in the > package. You must use the logos provided by the fedora-logos package and > Require: system-logos. system-logos is a virtual provides, so the package can > be rebranded. > If possible, use a generic name for the icon in the code, e.g. > "icon-panel-menu.png" which is provided by different themes and on several > distros such as Rhel or CentOS. > > Not sure about license of the mint icon, I think best is to leave it out. removed both mint and fedora logos, replaced with /usr/share/icons/Bluecurve/24x24/apps/icon-panel-menu.png > > Disable building the empty debuginfo package with "%global debug_package > %{nil}" at the beginning of the spec. > Done > /usr/lib64/bonobo/servers/mintMenu.server must not be executable, this is what > causes the script-without-shebang error in rpmlint. I'd rather use install than > cp because you can set proper permissions of the files. Done > (In reply to comment #6) > > How does one specify /usr/lib in a no arch package without using an absolute > > path? This is where upstream places the files. > > %{_prefix}/lib, see http://fedoraproject.org/wiki/Packaging:RPMMacros > But I agree with Terje that the noarch stuff should be moved to %{_datadir}. I moved as much as I can to %{_datadir}, but as I said the bonobo stuff needs to be in /usr/lib or /usr/lib64, using %{_prefix}/lib sets off hardcoded errors. I don't think there is a way around that while still keeping the package no arch, which it really should be. If this is acceptable, I can keep it this way. [unamanic@gimli ~]$ rpmlint /home/unamanic/rpmbuild/RPMS/noarch/mintmenu-4.9.0-10.fc12.noarch.rpm mintmenu.noarch: W: no-documentation 1 packages and 0 specfiles checked; 0 errors, 1 warnings. [unamanic@gimli ~]$ rpmlint /home/unamanic/rpmbuild/SRPMS/mintmenu-4.9.0-10.fc12.src.rpm mintmenu.src:73: E: hardcoded-library-path in %{buildroot}/usr/lib/linuxmint/mintMenu/mint*.png mintmenu.src:74: E: hardcoded-library-path in %{buildroot}/usr/lib/linuxmint/mintMenu/mint*.svg mintmenu.src:82: E: hardcoded-library-path in %{_prefix}/lib/bonobo/servers/ mintmenu.src:83: E: hardcoded-library-path in %{_prefix}/lib/bonobo/servers/mintMenu.server mintmenu.src:91: E: hardcoded-library-path in %{_prefix}/lib/bonobo/servers/mintMenu.server 1 packages and 0 specfiles checked; 5 errors, 0 warnings. koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=1842604 Spec URL: http://www.witt-family.net/mintmenu.spec SRPM URL: http://www.witt-family.net/mintmenu-4.9.0-10.fc12.src.rpm
Do not use the previous koji build (In reply to comment #11) > (In reply to comment #10) > > sed is ok, but should be done in %pre, so that package doesn't need to be > > touched after installation. If possible, try to preserver the timestams of the > > files, see > > moved sed-foo to %pre > realized the sed in %pre with is not what is needed, moved it back to %install. koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=1842623 Spec URL: http://www.witt-family.net/mintmenu.spec SRPM URL: http://www.witt-family.net/mintmenu-4.9.0-11.fc12.src.rpm
koji should read: http://koji.fedoraproject.org/koji/taskinfo?taskID=1842625
Bumped version alonq with upstream now at 4.9.1: "Improved gmenu sub-category items detection, added python-gnomeapplet dependency, split other, administration and system tools categories" Added some move logic to ensure that timestamps are kept. koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=1850947 Spec URL: http://www.witt-family.net/mintmenu.spec SRPM URL: http://www.witt-family.net/mintmenu-4.9.1-0.fc12.src.rpm
- Fixed uninstall context menu item, it was hardcoded to use apt-get. Modified it to use packagekit (added packagekit dependency). - Moved file path changes to a patch vs. sed in the spec file. Sed was there when before it was a noarch package, now koji: currently down due to server move Spec URL: http://www.witt-family.net/mintmenu.spec SRPM URL: http://www.witt-family.net/mintmenu-4.9.1-6.fc12.src.rpm [unamanic@gimli ~]$ rpmlint rpmbuild/SRPMS/mintmenu-4.9.1-6.fc12.src.rpm mintmenu.src:76: E: hardcoded-library-path in %{buildroot}/usr/lib/linuxmint/mintMenu/mint*.png mintmenu.src:77: E: hardcoded-library-path in %{buildroot}/usr/lib/linuxmint/mintMenu/mint*.svg mintmenu.src:92: E: hardcoded-library-path in %{_prefix}/lib/bonobo/servers/ mintmenu.src:93: E: hardcoded-library-path in %{_prefix}/lib/bonobo/servers/mintMenu.server mintmenu.src:103: E: hardcoded-library-path in %{_prefix}/lib/bonobo/servers/mintMenu.server 1 packages and 0 specfiles checked; 5 errors, 0 warnings. [unamanic@gimli ~]$ rpmlint rpmbuild/RPMS/noarch/mintmenu-4.9.1-6.fc12.noarch.rpm mintmenu.noarch: W: no-documentation 1 packages and 0 specfiles checked; 0 errors, 1 warnings.
Any updates? Will it be in Fedora repos soon?
William: could you please do some informal reviews of other packages to demonstrate that you're familiar with Fedora packaging? I could sponsor you then so that we can move this review forward. Thanks!
Thanks, I'll do some informal reviews over the next week.
I tried switching my primary system back to Fedora from openSUSE in order to maintain this package, but unfortunately I can't give up the level of polish that SUSE has. Anyone who wants it is welcome to pick this package/request up. The most current src.rpm and spec are available at http://unamanic.fedorapeople.org/
Bummer :( I was really hoping this package makes it into fedora repos.
I made a new spec file for 4.9.9 and I have lots of issues, most of patches from last package don't work, I guess some of them are obsolete and already incorporated into mainstream code tree.
Created attachment 414643 [details] mintmenu.spec file for mintmenu 4.9.9 version, package builds but doesn't run. It needs files in /usb/lib/linuxmint but package installs files into /usr/share/linuxmint/ any idea how to fix this?
When I moved to SUSE, much of the work I did to get mintmenu to work on Fedora also worked on SUSE. You can find a SUSE src rpm here: http://download.opensuse.org/repositories/home:/unamanic/openSUSE_11.2/src/mintmenu-4.9.4-2.1.src.rpm you'll want to to tweak the branding patch and you may also need to tweak the datadir patch since it's applied after the branding, but it should get you going the right direction.
that should be http://download.opensuse.org/repositories/home:/unamanic/openSUSE_11.2/src/mintmenu-4.9.9-5.1.src.rpm
Thank you William, I got 4.9.9 to build and run properly ;) Now to continue this process...
This package has an unclear license. The only license mentioned is in debian/copyright. Each file should contain an appropriate license header. Additionally, the root of the source tree should contain a COPYING or LICENSE file with the full text of the license. I doubt Fedora can package this until a proper license is ascertained.
On mintMenu project page [1] it says licence is GPL v2 So only LICENSE file for GPL is missing, the licence is clear, right? [1] https://launchpad.net/mintmenu
(In reply to comment #27) > So only LICENSE file for GPL is missing, the licence is clear, right? Nope, the websites usually don't distinguish between "GPLv2 only" and "GPLv2 or any later version". I'm afraid you will have to ask the authors and while you are at it, please tell them to add proper license headers to their code.
(In reply to comment #27) > On mintMenu project page [1] it says licence is GPL v2 > So only LICENSE file for GPL is missing, the licence is clear, right? > Valent, Do I take it correctly that you are taking over the submitter role in this review given that William has withdrawn from this review? I believe that you are already sponsored, right? If so please remove the FE-NEEDSPONSOR blocker. WRT the license stuff, I think that the intent by upstream is clear, so although you do need to ask upstream to fix things, I think we can move forward with this, Can you please drop Spot a mail to make sure the license stuff is ok as is? Regards, Hans
Ok, I'll take over but will need some hand holding because this will be my first packet that I'll be maintaining. /me goes to read fedora packaging guidelines.
(In reply to comment #30) > Ok, I'll take over but will need some hand holding because this will be my > first packet that I'll be maintaining. Ok, so if I understand this correctly you're not a Fedora packager yet and you will need a sponsor ? If so let me know. I'm willing to sponsor you (provided you show decent knowledge of the packaging guidelines). The first step would be an updated mintmenu package which actually works (unlike the spec file from comment #22).
Yes I will take over this package. I'll read upon packaging guidelines and then report back.
Ping? Any progress here? Or we can close this review?
Stalled Review. Closing per: https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews If you ever want to continue with this review, please reopen or submit new review.